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 thi
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 developm
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 ifde
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 #if
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
Strange spacing and formatting fixes.
Signed-off-by: Daniel Walker
---
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/
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
---
drivers/mmc/host/msm_sdcc.c | 28
A couple lines have non-tab spacing infront of them. Just replace
them with tabs.
Signed-off-by: Daniel Walker
---
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..3f
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
---
drivers/mmc/host/msm_sdcc.c | 24 +---
1 files changed, 13 inser
The function msmsdcc_disable_clocks needs to be called with
the host lock held.
Signed-off-by: Daniel Walker
---
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..c64a65
Remove the SMC91x platform and resource data from initdata. These
will continue to be accessed after init, and must remain available.
Signed-off-by: Stephen Boyd
---
arch/arm/mach-msm/board-qsd8x50.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-msm/b
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
> 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 (su
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)
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
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
---
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/t
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
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
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 calcula
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 wrote:
> >> Without marking the asm __dcc_getstatus() volatile my compiler
> >> decides [...]
> > What compiler ? That might be a usefull informat
On 12/20/2010 01:49 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Mon, Dec 20, 2010 at 3:08 PM, Stephen Boyd 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
Hi,
On Mon, Dec 20, 2010 at 3:08 PM, Stephen Boyd 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
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 th
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
>
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)c
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
Signed-off-by: Stephen Boy
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
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 p
On Mon, Dec 20, 2010 at 11:33:44AM -0800, me...@codeaurora.org wrote:
> > 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 d
> 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 stre
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 m
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 lat
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
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
On Tue, Dec 07, 2010 at 08:17:01AM +, Russell King - ARM Linux wrote:
> On Mon, Dec 06, 2010 at 10:56:14AM +0100, Thomas Gleixner wrote:
> > On Sun, 5 Dec 2010, Jeff Ohlstein wrote:
> > > +#ifdef CONFIG_HOTPLUG_CPU
> > > +void __cpuexit local_timer_stop(void)
> > > +{
> > > + local_clock_event-
34 matches
Mail list logo
