Re: [PATCH] hvc_dcc: Simplify assembly for v6 and v7 ARM
On Fri, 2010-12-17 at 21:16 -0800, Stephen Boyd wrote: The inline assembly differences for v6 vs. v7 in the hvc_dcc driver are purely optimizations. On a v7 processor, an mrc with the pc sets the condition codes to the 28-31 bits of the register being read. It just so happens that the TX/RX full bits the DCC driver is testing for are high enough in the register to be put into the condition codes. On a v6 processor, this feature isn't implemented and thus we have to do the usual read, mask, test operations to check for TX/RX full. Since we already test the RX/TX full bits before calling __dcc_getchar() and __dcc_putchar() we don't actually need to do anything special for v7 over v6. The only difference is in hvc_dcc_get_chars(). We would test RX full, poll RX full, and then read a character from the buffer, whereas now we will test RX full, read a character from the buffer, and then test RX full again for the second iteration of the loop. It doesn't seem possible for the buffer to go from full to empty between testing the RX full and reading a character. Therefore, replace the v7 versions with the v6 versions and everything works the same. While we're here, cleanup the for loops a bit and mark the inline assembly as volatile. Not marking it volatile causes GCC to cache the results of the status and RX buffer registers causing lockups. I would expect to see three patches. One that adds volatile, which appears to be a good fix. Another patch that changes the assembly lines, and another that does the clean up. The last two are more controversial ones. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hvc_dcc: Simplify assembly for v6 and v7 ARM
On 12/20/2010 09:51 AM, Daniel Walker wrote: I would expect to see three patches. One that adds volatile, which appears to be a good fix. Another patch that changes the assembly lines, and another that does the clean up. The last two are more controversial ones Ok. I'll send a series later today to give some more time for feedback. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hvc_dcc: Simplify assembly for v6 and v7 ARM
On Mon, 20 Dec 2010, Stephen Boyd wrote: On 12/20/2010 09:51 AM, Daniel Walker wrote: I would expect to see three patches. One that adds volatile, which appears to be a good fix. Another patch that changes the assembly lines, and another that does the clean up. The last two are more controversial ones Ok. I'll send a series later today to give some more time for feedback. I think you can do that right away. Splitting the patch will make that feedback easier to provide. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] usb: Add streams support to epautoconf.
On Thu, Dec 16, 2010 at 10:15AM, Greg KH wrote: What do you exactly mean by proprietary search algorithm? Our implementation for finding an EP with the required number of streams may not fit the needs and platform definitions of all controllers. For example, having the minimum number of streams as a parameter will allow controllers to compromise on the number of required streams in case there is no EP that answers their first request. At the beginning of usb_ep_autoconfig we could see many if statements for finding the fitting EP for several controllers (for example gadget_is_net2280). The new gadget op will prevent having additional if statements in the usb_ep_autoconfig in case a different search is needed. Thanks, Maya Erez Consultant for Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] hvc_dcc cleanups and fixes
Here are the split patches. The first two patches cleanup and fix the hvc_dcc driver for my compiler. The final patch is more controversial, it removes the v6 and v7 differences in this driver. Stephen Boyd (3): hvc_dcc: Fix bad code generation by marking assembly volatile hvc_dcc: Simplify put_chars()/get_chars() loops hvc_dcc: Simplify assembly for v6 and v7 ARM drivers/char/hvc_dcc.c | 43 +++ 1 files changed, 7 insertions(+), 36 deletions(-) -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] hvc_dcc: Fix bad code generation by marking assembly volatile
Without marking the asm __dcc_getstatus() volatile my compiler
decides it can cache the value of __ret in a register and then
check the value of it continually in hvc_dcc_put_chars() (I had
to replace get_wait/put_wait with 1 and fixup the branch
otherwise my disassembler barfed on __dcc_(get|put)char).
hvc_dcc_put_chars:
0: ee103e11mrc 14, 0, r3, cr0, cr1, {0}
4: e3a0c000mov ip, #0 ; 0x0
8: e2033202and r3, r3, #536870912 ; 0x2000
c: ea06b 2c hvc_dcc_put_chars+0x2c
10: e353cmp r3, #0 ; 0x0
14: 1afdbne 10 hvc_dcc_put_chars+0x10
18: e7d1000cldrbr0, [r1, ip]
1c: ee10fe11mrc 14, 0, pc, cr0, cr1, {0}
20: 2afdbcs 1c hvc_dcc_put_chars+0x1c
24: ee000e15mcr 14, 0, r0, cr0, cr5, {0}
28: e28cc001add ip, ip, #1 ; 0x1
2c: e15c0002cmp ip, r2
30: baf6blt 10 hvc_dcc_put_chars+0x10
34: e1a2mov r0, r2
38: e12fff1ebx lr
As you can see, the value of the mrc is checked against
DCC_STATUS_TX (bit 29) and then stored in r3 for later use.
Marking the asm volatile produces the following:
hvc_dcc_put_chars:
0: e3a03000mov r3, #0 ; 0x0
4: ea07b 28 hvc_dcc_put_chars+0x28
8: ee100e11mrc 14, 0, r0, cr0, cr1, {0}
c: e3100202tst r0, #536870912 ; 0x2000
10: 1afcbne 8 hvc_dcc_put_chars+0x8
14: e7d10003ldrbr0, [r1, r3]
18: ee10fe11mrc 14, 0, pc, cr0, cr1, {0}
1c: 2afdbcs 18 hvc_dcc_put_chars+0x18
20: ee000e15mcr 14, 0, r0, cr0, cr5, {0}
24: e2833001add r3, r3, #1 ; 0x1
28: e1530002cmp r3, r2
2c: baf5blt 8 hvc_dcc_put_chars+0x8
30: e1a2mov r0, r2
34: e12fff1ebx lr
which looks better and actually works. Mark all the inline
assembly in this file as volatile since we don't want the
compiler to optimize away these statements or move them around
in any way.
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Daniel Walker dwal...@codeaurora.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/char/hvc_dcc.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hvc_dcc.c b/drivers/char/hvc_dcc.c
index 6470f63..155ec10 100644
--- a/drivers/char/hvc_dcc.c
+++ b/drivers/char/hvc_dcc.c
@@ -33,8 +33,7 @@
static inline u32 __dcc_getstatus(void)
{
u32 __ret;
-
- asm(mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg
+ asm volatile(mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg
: =r (__ret) : : cc);
return __ret;
@@ -46,7 +45,7 @@ static inline char __dcc_getchar(void)
{
char __c;
- asm(get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ asm volatile(get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
bne get_wait \n\
mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
: =r (__c) : : cc);
@@ -58,7 +57,7 @@ static inline char __dcc_getchar(void)
{
char __c;
- asm(mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
+ asm volatile(mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
: =r (__c));
return __c;
@@ -68,7 +67,7 @@ static inline char __dcc_getchar(void)
#if defined(CONFIG_CPU_V7)
static inline void __dcc_putchar(char c)
{
- asm(put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ asm volatile(put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
bcs put_wait \n\
mcr p14, 0, %0, c0, c5, 0
: : r (c) : cc);
@@ -76,7 +75,7 @@ static inline void __dcc_putchar(char c)
#else
static inline void __dcc_putchar(char c)
{
- asm(mcr p14, 0, %0, c0, c5, 0 @ write a char
+ asm volatile(mcr p14, 0, %0, c0, c5, 0 @ write a char
: /* no output register */
: r (c));
}
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] hvc_dcc: Simplify put_chars()/get_chars() loops
Casting and anding with 0xff is unnecessary in
hvc_dcc_put_chars() since buf is already a char[].
__dcc_get_char() can't return an int less than 0 since it only
returns a char. Simplify the if statement in hvc_dcc_get_chars()
to take this into account.
Cc: Daniel Walker dwal...@codeaurora.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/char/hvc_dcc.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/char/hvc_dcc.c b/drivers/char/hvc_dcc.c
index 155ec10..ad23cc8 100644
--- a/drivers/char/hvc_dcc.c
+++ b/drivers/char/hvc_dcc.c
@@ -89,7 +89,7 @@ static int hvc_dcc_put_chars(uint32_t vt, const char *buf,
int count)
while (__dcc_getstatus() DCC_STATUS_TX)
cpu_relax();
- __dcc_putchar((char)(buf[i] 0xFF));
+ __dcc_putchar(buf[i]);
}
return count;
@@ -99,15 +99,11 @@ static int hvc_dcc_get_chars(uint32_t vt, char *buf, int
count)
{
int i;
- for (i = 0; i count; ++i) {
- int c = -1;
-
+ for (i = 0; i count; ++i)
if (__dcc_getstatus() DCC_STATUS_RX)
- c = __dcc_getchar();
- if (c 0)
+ buf[i] = __dcc_getchar();
+ else
break;
- buf[i] = c;
- }
return i;
}
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hvc_dcc: Fix bad code generation by marking assembly volatile
On Mon, 20 Dec 2010, Stephen Boyd wrote:
Without marking the asm __dcc_getstatus() volatile my compiler
decides it can cache the value of __ret in a register and then
check the value of it continually in hvc_dcc_put_chars() (I had
to replace get_wait/put_wait with 1 and fixup the branch
otherwise my disassembler barfed on __dcc_(get|put)char).
hvc_dcc_put_chars:
0: ee103e11mrc 14, 0, r3, cr0, cr1, {0}
4: e3a0c000mov ip, #0 ; 0x0
8: e2033202and r3, r3, #536870912 ; 0x2000
c: ea06b 2c hvc_dcc_put_chars+0x2c
10: e353cmp r3, #0 ; 0x0
14: 1afdbne 10 hvc_dcc_put_chars+0x10
18: e7d1000cldrbr0, [r1, ip]
1c: ee10fe11mrc 14, 0, pc, cr0, cr1, {0}
20: 2afdbcs 1c hvc_dcc_put_chars+0x1c
24: ee000e15mcr 14, 0, r0, cr0, cr5, {0}
28: e28cc001add ip, ip, #1 ; 0x1
2c: e15c0002cmp ip, r2
30: baf6blt 10 hvc_dcc_put_chars+0x10
34: e1a2mov r0, r2
38: e12fff1ebx lr
As you can see, the value of the mrc is checked against
DCC_STATUS_TX (bit 29) and then stored in r3 for later use.
Marking the asm volatile produces the following:
hvc_dcc_put_chars:
0: e3a03000mov r3, #0 ; 0x0
4: ea07b 28 hvc_dcc_put_chars+0x28
8: ee100e11mrc 14, 0, r0, cr0, cr1, {0}
c: e3100202tst r0, #536870912 ; 0x2000
10: 1afcbne 8 hvc_dcc_put_chars+0x8
14: e7d10003ldrbr0, [r1, r3]
18: ee10fe11mrc 14, 0, pc, cr0, cr1, {0}
1c: 2afdbcs 18 hvc_dcc_put_chars+0x18
20: ee000e15mcr 14, 0, r0, cr0, cr5, {0}
24: e2833001add r3, r3, #1 ; 0x1
28: e1530002cmp r3, r2
2c: baf5blt 8 hvc_dcc_put_chars+0x8
30: e1a2mov r0, r2
34: e12fff1ebx lr
which looks better and actually works. Mark all the inline
assembly in this file as volatile since we don't want the
compiler to optimize away these statements or move them around
in any way.
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Daniel Walker dwal...@codeaurora.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
---
drivers/char/hvc_dcc.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/char/hvc_dcc.c b/drivers/char/hvc_dcc.c
index 6470f63..155ec10 100644
--- a/drivers/char/hvc_dcc.c
+++ b/drivers/char/hvc_dcc.c
@@ -33,8 +33,7 @@
static inline u32 __dcc_getstatus(void)
{
u32 __ret;
-
- asm(mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg
+ asm volatile(mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg
: =r (__ret) : : cc);
return __ret;
@@ -46,7 +45,7 @@ static inline char __dcc_getchar(void)
{
char __c;
- asm(get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ asm volatile(get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
bne get_wait \n\
mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
: =r (__c) : : cc);
@@ -58,7 +57,7 @@ static inline char __dcc_getchar(void)
{
char __c;
- asm(mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
+ asm volatile(mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
: =r (__c));
return __c;
@@ -68,7 +67,7 @@ static inline char __dcc_getchar(void)
#if defined(CONFIG_CPU_V7)
static inline void __dcc_putchar(char c)
{
- asm(put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ asm volatile(put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
bcs put_wait \n\
mcr p14, 0, %0, c0, c5, 0
: : r (c) : cc);
@@ -76,7 +75,7 @@ static inline void __dcc_putchar(char c)
#else
static inline void __dcc_putchar(char c)
{
- asm(mcr p14, 0, %0, c0, c5, 0 @ write a char
+ asm volatile(mcr p14, 0, %0, c0, c5, 0 @ write a char
: /* no output register */
: r (c));
}
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] hvc_dcc: Simplify assembly for v6 and v7 ARM
On Mon, 20 Dec 2010, Stephen Boyd wrote:
The inline assembly differences for v6 vs. v7 in the hvc_dcc
driver are purely optimizations. On a v7 processor, an mrc with
the pc sets the condition codes to the 28-31 bits of the register
being read. It just so happens that the TX/RX full bits the DCC
driver is testing for are high enough in the register to be put
into the condition codes. On a v6 processor, this feature isn't
implemented and thus we have to do the usual read, mask, test
operations to check for TX/RX full.
Since we already test the RX/TX full bits before calling
__dcc_getchar() and __dcc_putchar() we don't actually need to do
anything special for v7 over v6. The only difference is in
hvc_dcc_get_chars(). We would test RX full, poll RX full, and
then read a character from the buffer, whereas now we will test
RX full, read a character from the buffer, and then test RX full
again for the second iteration of the loop. It doesn't seem
possible for the buffer to go from full to empty between testing
the RX full and reading a character. Therefore, replace the v7
versions with the v6 versions and everything works the same.
Cc: Tony Lindgren t...@atomide.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Daniel Walker dwal...@codeaurora.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
---
drivers/char/hvc_dcc.c | 24
1 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/drivers/char/hvc_dcc.c b/drivers/char/hvc_dcc.c
index ad23cc8..435f6fa 100644
--- a/drivers/char/hvc_dcc.c
+++ b/drivers/char/hvc_dcc.c
@@ -40,19 +40,6 @@ static inline u32 __dcc_getstatus(void)
}
-#if defined(CONFIG_CPU_V7)
-static inline char __dcc_getchar(void)
-{
- char __c;
-
- asm volatile(get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
- bne get_wait \n\
- mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
- : =r (__c) : : cc);
-
- return __c;
-}
-#else
static inline char __dcc_getchar(void)
{
char __c;
@@ -62,24 +49,13 @@ static inline char __dcc_getchar(void)
return __c;
}
-#endif
-#if defined(CONFIG_CPU_V7)
-static inline void __dcc_putchar(char c)
-{
- asm volatile(put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
- bcs put_wait \n\
- mcr p14, 0, %0, c0, c5, 0
- : : r (c) : cc);
-}
-#else
static inline void __dcc_putchar(char c)
{
asm volatile(mcr p14, 0, %0, c0, c5, 0 @ write a char
: /* no output register */
: r (c));
}
-#endif
static int hvc_dcc_put_chars(uint32_t vt, const char *buf, int count)
{
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hvc_dcc: Fix bad code generation by marking assembly volatile
Hi, On Mon, Dec 20, 2010 at 3:08 PM, Stephen Boyd sb...@codeaurora.org wrote: Without marking the asm __dcc_getstatus() volatile my compiler decides [...] What compiler ? That might be a usefull information to know, espectially 5 years from now when tracing code history. There has been similar issue with gcc 4.5 recently. AFAIK, in the same idea, the final change has been to mark the asm volatile. Thanks, - Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hvc_dcc: Fix bad code generation by marking assembly volatile
On 12/20/2010 01:49 PM, Arnaud Lacombe wrote: Hi, On Mon, Dec 20, 2010 at 3:08 PM, Stephen Boyd sb...@codeaurora.org wrote: Without marking the asm __dcc_getstatus() volatile my compiler decides [...] What compiler ? That might be a usefull information to know, espectially 5 years from now when tracing code history. There has been similar issue with gcc 4.5 recently. AFAIK, in the same idea, the final change has been to mark the asm volatile. Sure, we can replace my compiler with my compiler (arm-eabi-gcc (GCC) 4.4.0). -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hvc_dcc: Fix bad code generation by marking assembly volatile
On Mon, 20 Dec 2010, Stephen Boyd wrote: On 12/20/2010 01:49 PM, Arnaud Lacombe wrote: Hi, On Mon, Dec 20, 2010 at 3:08 PM, Stephen Boyd sb...@codeaurora.org wrote: Without marking the asm __dcc_getstatus() volatile my compiler decides [...] What compiler ? That might be a usefull information to know, espectially 5 years from now when tracing code history. There has been similar issue with gcc 4.5 recently. AFAIK, in the same idea, the final change has been to mark the asm volatile. Sure, we can replace my compiler with my compiler (arm-eabi-gcc (GCC) 4.4.0). Compiler version doesn't matter -- this is a simple correctness issue. If an inline asm statement provides an output value then the compiler is free to cache that value in a register, unless the inline asm is marked so that the value may change from one invocation to another. Also, the compiler is free to eliminate the inline asm statement entirely as well if the output value provided by that inline asm is never used... unless if the inline asm is marked as having side effects. In both cases the volatile qualifier does indicate that the returned value may change (new status flag state) and that the asm code therein has side effects (e.g. pop a character off a FIFO). Sometimes the desired effect can be indicated by clever usage of parameter constraints, but in this case the volatile keyword is most appropriate. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 0/4] ARM: Fixing udelay() for SMP and non-SMP systems
These patches fix the udelay() issue pointed out on arm-lkml[1][2]. A quick recap: some SMP machines can scale their CPU frequencies independent of one another. loops_per_jiffy is calibrated globally and used in __const_udelay(). If one CPU is running faster than what the loops_per_jiffy is calculated (or scaled) for, udelay() will be incorrect and not wait long enough (or too long). A similar problem occurs if the cpu frequency is scaled during a udelay() call. We could fix this issue a couple ways, wholesale replacement of __udelay() and __const_udelay() (see [2] for that approach), or replacement of __delay() (this series). Option 1 can fail if anybody uses udelay() before memory is mapped and also duplicates most of the code in asm/delay.h. It also needs to hardcode the timer tick frequency, which can sometimes be inaccurate. The benefit is that loops_per_jiffy stays the same and thus BogoMIPS is unchanged. Option 2 can't fail since the __delay() loop is replaced after memory is mapped in, but it suffers from a low BogoMIPS when timers are clocked slowly. It also more accurately calculates the timer tick frequency through the use of calibrate_delay_direct(). -- Reference -- [1] http://article.gmane.org/gmane.linux.kernel/977567 [2] http://article.gmane.org/gmane.linux.ports.arm.kernel/78496 Changes since v3: * Inlined set_delay_fn() Changes since v2: * Additional patch using the timer based delay Changes since v1: * likely() in delay.c * comment fixup for read_current_timer_delay_loop() * cosmetic improvements to commit text Stephen Boyd (4): ARM: Translate delay.S into (mostly) C ARM: Allow machines to override __delay() ARM: Implement a timer based __delay() loop msm: timer: Migrate to timer based __delay() arch/arm/include/asm/delay.h | 11 - arch/arm/kernel/armksyms.c |4 -- arch/arm/lib/delay.S | 65 - arch/arm/lib/delay.c | 81 arch/arm/mach-msm/include/mach/timex.h |1 + arch/arm/mach-msm/timer.c | 16 ++- 6 files changed, 107 insertions(+), 71 deletions(-) delete mode 100644 arch/arm/lib/delay.S create mode 100644 arch/arm/lib/delay.c -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 1/4] ARM: Translate delay.S into (mostly) C
We want to allow machines to override the __delay() implementation at runtime so they can use a timer based __delay() routine. It's easier to do this using C, so let's write udelay and friends in C. We lose the #if 0 code, which according to Russell is used to make the delay loop more stable and predictable on older CPUs (see http://article.gmane.org/gmane.linux.kernel/67 for more info). We shouldn't be too worried though, since we'll soon add functionality allowing a machine to set the __delay() loop themselves, thus allowing machines to resurrect the commented out code should they need it. Nico expressed concern that fixed lpj cmdlines will break due to compiler optimizations. That doesn't seem to be the case since before and after this patch I get the same lpj value when running my CPU at 19.2 MHz. That should be sufficiently slow enough to cover any machine running Linux. Reviewed-by: Saravana Kannan skan...@codeaurora.org Acked-by: Nicolas Pitre nicolas.pi...@linaro.org Signed-off-by: Stephen Boyd sb...@codeaurora.org --- This will break builds when you switch back and forth without this patch. You need to rm arch/arm/lib/.delay.o.cmd if you ever build a kernel before this patch after you've built with this patch. arch/arm/include/asm/delay.h |2 +- arch/arm/kernel/armksyms.c |4 -- arch/arm/lib/delay.S | 65 -- arch/arm/lib/delay.c | 56 4 files changed, 57 insertions(+), 70 deletions(-) delete mode 100644 arch/arm/lib/delay.S create mode 100644 arch/arm/lib/delay.c diff --git a/arch/arm/include/asm/delay.h b/arch/arm/include/asm/delay.h index b2deda1..ccc5ed5 100644 --- a/arch/arm/include/asm/delay.h +++ b/arch/arm/include/asm/delay.h @@ -8,7 +8,7 @@ #include asm/param.h /* HZ */ -extern void __delay(int loops); +extern void __delay(unsigned long loops); /* * This function intentionally does not exist; if you see references to diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c index e5e1e538..220dce6 100644 --- a/arch/arm/kernel/armksyms.c +++ b/arch/arm/kernel/armksyms.c @@ -52,10 +52,6 @@ extern void fpundefinstr(void); EXPORT_SYMBOL(__backtrace); - /* platform dependent support */ -EXPORT_SYMBOL(__udelay); -EXPORT_SYMBOL(__const_udelay); - /* networking */ EXPORT_SYMBOL(csum_partial); EXPORT_SYMBOL(csum_partial_copy_from_user); diff --git a/arch/arm/lib/delay.S b/arch/arm/lib/delay.S deleted file mode 100644 index 8d6a876..000 --- a/arch/arm/lib/delay.S +++ /dev/null @@ -1,65 +0,0 @@ -/* - * linux/arch/arm/lib/delay.S - * - * Copyright (C) 1995, 1996 Russell King - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ -#include linux/linkage.h -#include asm/assembler.h -#include asm/param.h - .text - -.LC0: .word loops_per_jiffy -.LC1: .word (2199023*HZ)11 - -/* - * r0 = 2000 - * lpj = 0x01ff (max. 3355 bogomips) - * HZ = 1000 - */ - -ENTRY(__udelay) - ldr r2, .LC1 - mul r0, r2, r0 -ENTRY(__const_udelay) @ 0 = r0 = 0x7f06 - ldr r2, .LC0 - ldr r2, [r2]@ max = 0x01ff - mov r0, r0, lsr #14 @ max = 0x0001 - mov r2, r2, lsr #10 @ max = 0x7fff - mul r0, r2, r0 @ max = 2^32-1 - movsr0, r0, lsr #6 - moveq pc, lr - -/* - * loops = r0 * HZ * loops_per_jiffy / 100 - * - * Oh, if only we had a cycle counter... - */ - -@ Delay routine -ENTRY(__delay) - subsr0, r0, #1 -#if 0 - movls pc, lr - subsr0, r0, #1 - movls pc, lr - subsr0, r0, #1 - movls pc, lr - subsr0, r0, #1 - movls pc, lr - subsr0, r0, #1 - movls pc, lr - subsr0, r0, #1 - movls pc, lr - subsr0, r0, #1 - movls pc, lr - subsr0, r0, #1 -#endif - bhi __delay - mov pc, lr -ENDPROC(__udelay) -ENDPROC(__const_udelay) -ENDPROC(__delay) diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c new file mode 100644 index 000..f92aca0 --- /dev/null +++ b/arch/arm/lib/delay.c @@ -0,0 +1,56 @@ +/* + * Originally from linux/arch/arm/lib/delay.S + * + * Copyright (C) 1995, 1996 Russell King + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include linux/module.h +#include linux/delay.h + +/* + * loops = usecs * HZ *
[PATCHv4 3/4] ARM: Implement a timer based __delay() loop
udelay() can be incorrect on SMP machines that scale their CPU
frequencies independently of one another (as pointed out here
http://article.gmane.org/gmane.linux.kernel/977567). The delay
loop can either be too fast or too slow depending on which CPU the
loops_per_jiffy counter is calibrated on and which CPU the delay
loop is running on. udelay() can also be incorrect if the
CPU frequency switches during the __delay() loop, causing the loop
to either terminate too early, or too late.
Forcing udelay() to run on one CPU is unreasonable and taking the
penalty of a rather large loops_per_jiffy in udelay() when the
CPU is actually running slower is bad for performance. Solve the
problem by adding a timer based__delay() loop unaffected by CPU
frequency scaling. Machines should set this loop as their
__delay() implementation by calling set_timer_fn() during their
timer initialization.
The kernel is already prepared for a timer based approach
(evident by the read_current_timer() function). If an arch
implements read_current_timer(), calibrate_delay() will use
calibrate_delay_direct() to calculate loops_per_jiffy (in which
case loops_per_jiffy should really be renamed to
timer_ticks_per_jiffy). Since the loops_per_jiffy will be based
on timer ticks, __delay() should be implemented as a loop around
read_current_timer().
Doing this makes the expensive loops_per_jiffy calculation go
away (saving ~150ms on boot time on my machine) and fixes
udelay() by making it safe in the face of independently scaling
CPUs. The only prerequisite is that read_current_timer() is
monotonically increasing across calls (and doesn't overflow
within ~2000us).
There is a downside to this approach though. BogoMIPS is no
longer accurate in that it reflects the BogoMIPS of the timer
and not the CPU. On most SoC's the timer isn't running anywhere
near as fast as the CPU so BogoMIPS will be ridiculously low (my
timer runs at 4.8 MHz and thus my BogoMIPS is 9.6 compared to my
CPU's 800). This shouldn't be too much of a concern though since
BogoMIPS are bogus anyway (hence the name).
This loop is pretty much a copy of AVR's version.
Reported-and-reviewed-by: Saravana Kannan skan...@codeaurora.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
arch/arm/include/asm/delay.h |2 ++
arch/arm/lib/delay.c | 17 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/delay.h b/arch/arm/include/asm/delay.h
index 82ef82a..91063a3 100644
--- a/arch/arm/include/asm/delay.h
+++ b/arch/arm/include/asm/delay.h
@@ -47,5 +47,7 @@ static inline void set_delay_fn(void (*fn)(unsigned long))
delay_fn = fn;
}
+extern void read_current_timer_delay_loop(unsigned long loops);
+
#endif /* defined(_ARM_DELAY_H) */
diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
index 7468bc6..f24c956 100644
--- a/arch/arm/lib/delay.c
+++ b/arch/arm/lib/delay.c
@@ -9,6 +9,7 @@
*/
#include linux/module.h
#include linux/delay.h
+#include linux/timex.h
/*
* Oh, if only we had a cycle counter...
@@ -23,6 +24,22 @@ static void delay_loop(unsigned long loops)
);
}
+#ifdef ARCH_HAS_READ_CURRENT_TIMER
+/*
+ * Assumes read_current_timer() is monotonically increasing
+ * across calls and wraps at most once within MAX_UDELAY_MS.
+ */
+void read_current_timer_delay_loop(unsigned long loops)
+{
+ unsigned long bclock, now;
+
+ read_current_timer(bclock);
+ do {
+ read_current_timer(now);
+ } while ((now - bclock) loops);
+}
+#endif
+
void (*delay_fn)(unsigned long) = delay_loop;
/*
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 4/4] msm: timer: Migrate to timer based __delay()
We have to provide a dummy set_mode for the DGT since we don't
want it to ever turn off.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
This is more of an illustration patch. This code needs to be
fixed to always leave clocksources running.
arch/arm/mach-msm/include/mach/timex.h |1 +
arch/arm/mach-msm/timer.c | 16 +++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-msm/include/mach/timex.h
b/arch/arm/mach-msm/include/mach/timex.h
index a62e6b2..52b602b 100644
--- a/arch/arm/mach-msm/include/mach/timex.h
+++ b/arch/arm/mach-msm/include/mach/timex.h
@@ -17,5 +17,6 @@
#define __ASM_ARCH_MSM_TIMEX_H
#define CLOCK_TICK_RATE100
+#define ARCH_HAS_READ_CURRENT_TIMER
#endif
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 950100f..9da4908 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -84,6 +84,12 @@ static cycle_t msm_dgt_read(struct clocksource *cs)
return readl(MSM_DGT_BASE + TIMER_COUNT_VAL) MSM_DGT_SHIFT;
}
+int read_current_timer(unsigned long *timer_val)
+{
+ *timer_val = readl(MSM_DGT_BASE + TIMER_COUNT_VAL);
+ return 0;
+}
+
static int msm_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
@@ -122,6 +128,12 @@ static void msm_timer_set_mode(enum clock_event_mode mode,
}
}
+static void msm_timer_set_mode_nop(enum clock_event_mode mode,
+ struct clock_event_device *evt)
+{
+ /* The timer is always ticking so do nothing */
+}
+
static struct msm_clock msm_clocks[] = {
{
.clockevent = {
@@ -157,7 +169,7 @@ static struct msm_clock msm_clocks[] = {
.shift = 32 + MSM_DGT_SHIFT,
.rating = 300,
.set_next_event = msm_timer_set_next_event,
- .set_mode = msm_timer_set_mode,
+ .set_mode = msm_timer_set_mode_nop,
},
.clocksource = {
.name = dg_timer,
@@ -218,6 +230,8 @@ static void __init msm_timer_init(void)
clockevents_register_device(ce);
}
+ writel(TIMER_ENABLE_EN, MSM_DGT_BASE + TIMER_ENABLE);
+ set_delay_fn(read_current_timer_delay_loop);
}
struct sys_timer msm_timer = {
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 2/4] ARM: Allow machines to override __delay()
Some machines want to implement their own __delay() routine based
on fixed rate timers. Expose functionality to set the __delay()
routine at runtime. This should allow two machines with different
__delay() routines to happily co-exist within the same kernel
with minimal overhead.
Russell expressed concern that using a timer based __delay()
would cause problems when an iomapped device isn't mapped in
prior to a delay call being made (see
http://article.gmane.org/gmane.linux.ports.arm.kernel/78543 for
more info). We can sidestep that issue with this approach since
the __delay() routine _should_ only be pointed to a timer based
delay once the timer has been properly mapped. Up until that
point __delay() and udelay() will use delay_loop() which is
always safe to call.
This patch is inspired by x86's delay.c
Reviewed-by: Saravana Kannan skan...@codeaurora.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
Changed to inline set_delay_fn()
arch/arm/include/asm/delay.h |7 +++
arch/arm/lib/delay.c | 14 +++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/delay.h b/arch/arm/include/asm/delay.h
index ccc5ed5..82ef82a 100644
--- a/arch/arm/include/asm/delay.h
+++ b/arch/arm/include/asm/delay.h
@@ -40,5 +40,12 @@ extern void __const_udelay(unsigned long);
__const_udelay((n) * ((2199023U*HZ)11))) :\
__udelay(n))
+extern void (*delay_fn)(unsigned long);
+
+static inline void set_delay_fn(void (*fn)(unsigned long))
+{
+ delay_fn = fn;
+}
+
#endif /* defined(_ARM_DELAY_H) */
diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
index f92aca0..7468bc6 100644
--- a/arch/arm/lib/delay.c
+++ b/arch/arm/lib/delay.c
@@ -11,11 +11,9 @@
#include linux/delay.h
/*
- * loops = usecs * HZ * loops_per_jiffy / 100
- *
* Oh, if only we had a cycle counter...
*/
-void __delay(unsigned long loops)
+static void delay_loop(unsigned long loops)
{
asm volatile(
1: subs %0, %0, #1 \n
@@ -24,6 +22,16 @@ void __delay(unsigned long loops)
: r (loops)
);
}
+
+void (*delay_fn)(unsigned long) = delay_loop;
+
+/*
+ * loops = usecs * HZ * loops_per_jiffy / 100
+ */
+void __delay(unsigned long loops)
+{
+ delay_fn(loops);
+}
EXPORT_SYMBOL(__delay);
/*
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: Update consumer state only after set voltage succeeds.
On 12/20/10 04:39, Mark Brown wrote:
On Fri, Dec 17, 2010 at 02:44:28PM -0800, Saravana Kannan wrote:
static int regulator_check_consumers(struct regulator_dev *rdev,
+struct regulator *ignore,
int *min_uV, int *max_uV)
This feels really invasive, and prone to robustness issues as we're just
randomly not checking one of the consumers on a single call, meaning we
skip some checking some of the time. It's not going to make the code
more maintainable.
I agree it looks a bit odd and I'm willing to do the code reorg if there
is a better way. But I definitely wouldn't call this as randomly
ignoring a consumer. We are just avoiding the consumer that's changing
the range from voting twice. We already send the new request thru
min/max params.
We will also need the option of not including the calling consumer when
computing the min/max for the next patch. See below.
Do you have any suggestions for a better way to compute the min/max
while leaving out a single consumer? I'm very much open to do that.
Would something like below be better?
regulator_check_consumers_except(rdev, ignore, min, max)
{
...
}
regulator_check_consumers(rdev, min, max)
{
regulator_check_consumer(rdev, NULL, min, max);
}
- regulator-min_uV = min_uV;
- regulator-max_uV = max_uV;
-
- ret = regulator_check_consumers(rdev,min_uV,max_uV);
+ ret = regulator_check_consumers(rdev, regulator,min_uV,max_uV);
if (ret 0)
goto out;
ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
+ if (!ret) {
+ regulator-min_uV = min_uV;
+ regulator-max_uV = max_uV;
+ }
If you're going to do something probably unwinding the assignment on
error would cover it.
It would, but the next patch was going to be to optimize out the call to
the regulator driver if the votes of the calling consumer doesn't make a
difference. To do that, we will need to compute the voltage range with
and without the calling consumer's min/max and then figure out if the
change in the calling consumer's min/max makes a difference.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/40] Complete set of clocksource/sched_clock patches
On Mon, Dec 20, 2010 at 11:32:21AM +0800, Eric Miao wrote: On Fri, Dec 17, 2010 at 7:32 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Here is the entire set of clocksource and sched_clock patches which have been previously posted. There's a couple of small tweaks in a few of the patches (such as adding notrace to OMAP clocksource read functions), and this also shows the proper ordering of these patches. Still looking for acks or tested-by's for these patches. Hi Russell, Sorry for late feedback. Tested the branch 'clksrc' on Littleton/PXA3xx, seems to be good. Tested-by: Eric Miao eric.y.m...@gmail.com Ok, I'll add that to the PXA and generic patches, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] mmc: msm: consolidate ifdefs for BUSCLK_PWRSAVE
It's cleaner to have ifdef's consolidated in one specific
area. This change pulls adds one ifdef which will swap
out of the function with a stub function if the ifdef is
false.
Signed-off-by: Daniel Walker dwal...@codeaurora.org
---
drivers/mmc/host/msm_sdcc.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c
index 1290d14..d6ac82c 100644
--- a/drivers/mmc/host/msm_sdcc.c
+++ b/drivers/mmc/host/msm_sdcc.c
@@ -61,7 +61,7 @@ static unsigned int msmsdcc_sdioirq;
#define PIO_SPINMAX 30
#define CMD_SPINMAX 20
-
+#ifdef BUSCLK_PWRSAVE
static inline void
msmsdcc_disable_clocks(struct msmsdcc_host *host, int deferr)
{
@@ -83,6 +83,10 @@ msmsdcc_disable_clocks(struct msmsdcc_host *host, int deferr)
}
}
}
+#else
+static inline void
+msmsdcc_disable_clocks(struct msmsdcc_host *host, int deferr) { }
+#endif
static inline int
msmsdcc_enable_clocks(struct msmsdcc_host *host)
@@ -139,9 +143,8 @@ msmsdcc_request_end(struct msmsdcc_host *host, struct
mmc_request *mrq)
if (mrq-cmd-error == -ETIMEDOUT)
mdelay(5);
-#if BUSCLK_PWRSAVE
msmsdcc_disable_clocks(host, 1);
-#endif
+
/*
* Need to drop the host lock here; mmc_request_done may call
* back into the driver...
@@ -259,9 +262,9 @@ msmsdcc_dma_complete_func(struct msm_dmov_cmd *cmd,
mrq-data-bytes_xfered = host-curr.data_xfered;
spin_unlock_irqrestore(host-lock, flags);
-#if BUSCLK_PWRSAVE
+
msmsdcc_disable_clocks(host, 1);
-#endif
+
mmc_request_done(host-mmc, mrq);
return;
} else
@@ -930,9 +933,9 @@ msmsdcc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
host-pwr = pwr;
msmsdcc_writel(host, pwr, MMCIPOWER);
}
-#if BUSCLK_PWRSAVE
+
msmsdcc_disable_clocks(host, 1);
-#endif
+
spin_unlock_irqrestore(host-lock, flags);
}
@@ -1256,9 +1259,8 @@ msmsdcc_probe(struct platform_device *pdev)
if (host-timer.function)
pr_info(%s: Polling status mode enabled\n, mmc_hostname(mmc));
-#if BUSCLK_PWRSAVE
msmsdcc_disable_clocks(host, 1);
-#endif
+
return 0;
cmd_irq_free:
free_irq(cmd_irqres-start, host);
@@ -1333,9 +1335,9 @@ msmsdcc_resume(struct platform_device *dev)
mmc_resume_host(mmc);
if (host-stat_irq)
enable_irq(host-stat_irq);
-#if BUSCLK_PWRSAVE
+
msmsdcc_disable_clocks(host, 1);
-#endif
+
}
return 0;
}
--
1.7.0.4
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] mmc: msm: fix msmsdcc_disable_clocks spinlock protection
The function msmsdcc_disable_clocks needs to be called with the host lock held. Signed-off-by: Daniel Walker dwal...@codeaurora.org --- drivers/mmc/host/msm_sdcc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c index 01bb684..c64a659 100644 --- a/drivers/mmc/host/msm_sdcc.c +++ b/drivers/mmc/host/msm_sdcc.c @@ -261,10 +261,10 @@ msmsdcc_dma_complete_func(struct msm_dmov_cmd *cmd, host-curr.cmd = NULL; mrq-data-bytes_xfered = host-curr.data_xfered; - spin_unlock_irqrestore(host-lock, flags); - msmsdcc_disable_clocks(host, 1); + spin_unlock_irqrestore(host-lock, flags); + mmc_request_done(host-mmc, mrq); return; } else -- 1.7.0.4 -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] mmc: msm: convert int bools to actual bool type
Many variables in this MMC driver are used like bools but
have int types. It's better to use the actual bool type for
readability and optimization. This converts all these types
of variables to actual the bool type.
Signed-off-by: Daniel Walker dwal...@codeaurora.org
---
drivers/mmc/host/msm_sdcc.c | 28 ++--
drivers/mmc/host/msm_sdcc.h | 10 +-
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c
index d6ac82c..01bb684 100644
--- a/drivers/mmc/host/msm_sdcc.c
+++ b/drivers/mmc/host/msm_sdcc.c
@@ -79,7 +79,7 @@ msmsdcc_disable_clocks(struct msmsdcc_host *host, int deferr)
if (host-clks_on) {
clk_disable(host-clk);
clk_disable(host-pclk);
- host-clks_on = 0;
+ host-clks_on = false;
}
}
}
@@ -106,7 +106,7 @@ msmsdcc_enable_clocks(struct msmsdcc_host *host)
}
udelay(1 + ((3 * USEC_PER_SEC) /
(host-clk_rate ? host-clk_rate : msmsdcc_fmin)));
- host-clks_on = 1;
+ host-clks_on = true;
}
return 0;
}
@@ -158,7 +158,7 @@ static void
msmsdcc_stop_data(struct msmsdcc_host *host)
{
host-curr.data = NULL;
- host-curr.got_dataend = host-curr.got_datablkend = 0;
+ host-curr.got_dataend = host-curr.got_datablkend = false;
}
uint32_t msmsdcc_fifo_addr(struct msmsdcc_host *host)
@@ -188,7 +188,7 @@ msmsdcc_dma_exec_func(struct msm_dmov_cmd *cmd)
(u32) host-cmd_cmd-arg,
(u32) host-cmd_c);
}
- host-dma.active = 1;
+ host-dma.active = true;
}
static void
@@ -203,7 +203,7 @@ msmsdcc_dma_complete_func(struct msm_dmov_cmd *cmd,
struct mmc_request *mrq;
spin_lock_irqsave(host-lock, flags);
- host-dma.active = 0;
+ host-dma.active = false;
mrq = host-curr.mrq;
BUG_ON(!mrq);
@@ -243,7 +243,7 @@ msmsdcc_dma_complete_func(struct msm_dmov_cmd *cmd,
}
host-dma.sg = NULL;
- host-dma.busy = 0;
+ host-dma.busy = false;
if ((host-curr.got_dataend host-curr.got_datablkend)
|| mrq-data-error) {
@@ -452,8 +452,8 @@ msmsdcc_start_data(struct msmsdcc_host *host, struct
mmc_data *data,
host-curr.xfer_size = data-blksz * data-blocks;
host-curr.xfer_remain = host-curr.xfer_size;
host-curr.data_xfered = 0;
- host-curr.got_dataend = 0;
- host-curr.got_datablkend = 0;
+ host-curr.got_dataend = false;
+ host-curr.got_datablkend = false;
memset(host-pio, 0, sizeof(host-pio));
@@ -490,7 +490,7 @@ msmsdcc_start_data(struct msmsdcc_host *host, struct
mmc_data *data,
host-dma.hdr.execute_func = msmsdcc_dma_exec_func;
host-dma.hdr.data = (void *)host;
- host-dma.busy = 1;
+ host-dma.busy = true;
if (cmd) {
msmsdcc_start_command_deferred(host, cmd, c);
@@ -749,10 +749,10 @@ msmsdcc_handle_irq_data(struct msmsdcc_host *host, u32
status,
/* Check for data done */
if (!host-curr.got_dataend (status MCI_DATAEND))
- host-curr.got_dataend = 1;
+ host-curr.got_dataend = true;
if (!host-curr.got_datablkend (status MCI_DATABLOCKEND))
- host-curr.got_datablkend = 1;
+ host-curr.got_datablkend = true;
/*
* If DMA is still in progress, we complete via the completion handler
@@ -789,7 +789,7 @@ msmsdcc_irq(int irq, void *dev_id)
void __iomem*base = host-base;
u32 status;
int ret = 0;
- int cardint = 0;
+ boolcardint = false;
spin_lock(host-lock);
@@ -808,7 +808,7 @@ msmsdcc_irq(int irq, void *dev_id)
msmsdcc_handle_irq_data(host, status, base);
if (status MCI_SDIOINTOPER) {
- cardint = 1;
+ cardint = true;
status = ~MCI_SDIOINTOPER;
}
ret = 1;
@@ -1107,7 +1107,7 @@ msmsdcc_probe(struct platform_device *pdev)
host-mmc = mmc;
host-curr.cmd = NULL;
- host-cmdpoll = 1;
+ host-cmdpoll = true;
host-base = ioremap(memres-start, PAGE_SIZE);
if (!host-base) {
diff --git a/drivers/mmc/host/msm_sdcc.h b/drivers/mmc/host/msm_sdcc.h
index ff2b0f7..57db07f 100644
--- a/drivers/mmc/host/msm_sdcc.h
+++ b/drivers/mmc/host/msm_sdcc.h
@@ -170,8 +170,8 @@ struct msmsdcc_dma_data {
int channel;
struct msmsdcc_host *host;
- int busy; /* Set if
[PATCH 4/5] mmc: msm: fix non-tab spacing
A couple lines have non-tab spacing infront of them. Just replace
them with tabs.
Signed-off-by: Daniel Walker dwal...@codeaurora.org
---
drivers/mmc/host/msm_sdcc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c
index c64a659..3f333b1 100644
--- a/drivers/mmc/host/msm_sdcc.c
+++ b/drivers/mmc/host/msm_sdcc.c
@@ -168,8 +168,8 @@ uint32_t msmsdcc_fifo_addr(struct msmsdcc_host *host)
static inline void
msmsdcc_start_command_exec(struct msmsdcc_host *host, u32 arg, u32 c) {
- msmsdcc_writel(host, arg, MMCIARGUMENT);
- msmsdcc_writel(host, c, MMCICOMMAND);
+ msmsdcc_writel(host, arg, MMCIARGUMENT);
+ msmsdcc_writel(host, c, MMCICOMMAND);
}
static void
@@ -305,7 +305,7 @@ static int msmsdcc_config_dma(struct msmsdcc_host *host,
struct mmc_data *data)
host-dma.sg = data-sg;
host-dma.num_ents = data-sg_len;
- BUG_ON(host-dma.num_ents NR_SG); /* Prevent memory corruption */
+ BUG_ON(host-dma.num_ents NR_SG); /* Prevent memory corruption */
nc = host-dma.nc;
--
1.7.0.4
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] mmc: msm: fix weird spacing
Strange spacing and formatting fixes.
Signed-off-by: Daniel Walker dwal...@codeaurora.org
---
drivers/mmc/host/msm_sdcc.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/msm_sdcc.c b/drivers/mmc/host/msm_sdcc.c
index 3f333b1..c5d1d6a 100644
--- a/drivers/mmc/host/msm_sdcc.c
+++ b/drivers/mmc/host/msm_sdcc.c
@@ -339,12 +339,12 @@ static int msmsdcc_config_dma(struct msmsdcc_host *host,
struct mmc_data *data)
for (i = 0; i host-dma.num_ents; i++) {
box-cmd = CMD_MODE_BOX;
- /* Initialize sg dma address */
- sg-dma_address = page_to_dma(mmc_dev(host-mmc), sg_page(sg))
- + sg-offset;
+ /* Initialize sg dma address */
+ sg-dma_address = page_to_dma(mmc_dev(host-mmc), sg_page(sg))
+ + sg-offset;
- if (i == (host-dma.num_ents - 1))
- box-cmd |= CMD_LC;
+ if (i == (host-dma.num_ents - 1))
+ box-cmd |= CMD_LC;
rows = (sg_dma_len(sg) % MCI_FIFOSIZE) ?
(sg_dma_len(sg) / MCI_FIFOSIZE) + 1 :
(sg_dma_len(sg) / MCI_FIFOSIZE) ;
@@ -479,7 +479,7 @@ msmsdcc_start_data(struct msmsdcc_host *host, struct
mmc_data *data,
clks = (unsigned long long)data-timeout_ns * host-clk_rate;
do_div(clks, NSEC_PER_SEC);
- timeout = data-timeout_clks + (unsigned int)clks*2 ;
+ timeout = data-timeout_clks + (unsigned int)clks*2;
if (datactrl MCI_DPSM_DMAENABLE) {
/* Save parameters for the exec function */
@@ -563,7 +563,7 @@ msmsdcc_pio_read(struct msmsdcc_host *host, char *buffer,
unsigned int remain)
ptr++;
count += sizeof(uint32_t);
- remain -= sizeof(uint32_t);
+ remain -= sizeof(uint32_t);
if (remain == 0)
break;
}
--
1.7.0.4
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dma-mapping: move consistent_init to early_initcall
On 12/17/10 15:14, Saravana Kannan wrote: Catalin Marinas wrote: Russell, I agree with your point about using an API for purpose and not property. But I read Catalin's proposal as, let's treat secure domain as another DMA device. If we make a conscious agreement to do that, then using the DMA API for secure domain would be using it for its purpose and we will make an effort to not break it with future updates. Of course, if we don't agree on that proposal, then we can't use the DMA API for secure domain stuff. If there is no better proposal, I'm for such extension to the DMA API. From the kernel perspecitve, the secure side is just another entity that accesses the RAM directly. It's not a physically separate device indeed but from a direct memory access perspective it can be treated as any other device. In the DMA API we can fall back to the non-coherent ops when a NULL struct device is passed. I assume in your code you already pass a NULL device to dma_alloc_coherent(). Russell, Would the extension of the DMA API as described above be acceptable to you? If not, can you please suggest an alternative that's acceptable to you? Ping... -Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mmc: msm: consolidate ifdefs for BUSCLK_PWRSAVE
On Mon, Dec 20, 2010 at 03:16:47PM -0800, Daniel Walker wrote: It's cleaner to have ifdef's consolidated in one specific area. This change pulls adds one ifdef which will swap out of the function with a stub function if the ifdef is false. It also changes the define from #if checks to #ifdef which changes how it would be used. I this feature even used? It looks like some kind debug feature. David -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mmc: msm: consolidate ifdefs for BUSCLK_PWRSAVE
On Mon, 2010-12-20 at 15:35 -0800, David Brown wrote: On Mon, Dec 20, 2010 at 03:16:47PM -0800, Daniel Walker wrote: It's cleaner to have ifdef's consolidated in one specific area. This change pulls adds one ifdef which will swap out of the function with a stub function if the ifdef is false. It also changes the define from #if checks to #ifdef which changes how it would be used. True, but it's defined in the code. So you have to comment the line out now instead of change it to 0 .. I this feature even used? It looks like some kind debug feature. Yeah it's used, it's default on.. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mmc: msm: consolidate ifdefs for BUSCLK_PWRSAVE
On Mon, Dec 20, 2010 at 03:39:10PM -0800, Daniel Walker wrote: I this feature even used? It looks like some kind debug feature. Yeah it's used, it's default on.. What I meant was is there any reason to be able to turn this off. It looks like something that would be used during development, and doesn't need to be disabled once the driver works. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mmc: msm: consolidate ifdefs for BUSCLK_PWRSAVE
On Mon, 2010-12-20 at 15:42 -0800, David Brown wrote: On Mon, Dec 20, 2010 at 03:39:10PM -0800, Daniel Walker wrote: I this feature even used? It looks like some kind debug feature. Yeah it's used, it's default on.. What I meant was is there any reason to be able to turn this off. It looks like something that would be used during development, and doesn't need to be disabled once the driver works. I have no idea. I'm just doing a clean up here .. It's on, it's got a config to turn it off, as far as I know it's used and useful. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
