On Fri, 2010-09-03 at 08:31 +0100, Russell King - ARM Linux wrote:
On Thu, Sep 02, 2010 at 03:36:40PM -0700, Daniel Walker wrote:
If no others use it .. We can do this to fix them all. What do you
think?
If no one else implements it, then you can't suspend, nor can you
support kexec. (We
You're using an older submission of gpiolib which doesn't support
dual-edge IRQs. That one has been scrapped in favor of the one from
android's 2.6.35-wip branch. It hasn't been accepted yet, and is
currently being discussed on the mailing lists. If you search the
mailing list archives from
Hi
It's me again
Problem: I'm bit confused.
There are multiple possible patchsets available in the mailbox
More confusing: The ones I tried seem to collide with older patches
from yourself, which are already in codeauroras for-next repo.
Could you please point me to the right patch by subject
On 9/1/2010 2:34 AM, Dmitry Torokhov wrote:
OK, I give up on pursuit of serio solution. Again ;)
Dmitry,
Don't give up yet... I've been talking to Quanta and they are using a
different EC in their new products, which should have better firmware
support for serio over i2c. When I get the
mark gross wrote:
I'll do a patch by monday as an RFC but, I'm wondering if we want it in
the main line vrs an implementation that scales by bus integrated into
the driver model per what Kevin has been talking about
The model Kevin is thinking about will probably need some time and work
In the next patch we're going to allow machines to override the
__delay() implementation at runtime so they can implement a timer
based __delay() routine. It's easier to do this using C, so lets
write udelay and friends in C.
We lose the #if 0 code, which according to Russell is used to
make the
Some machines want to implement their own __delay() routine based
on fixed 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
These patches are another attempt at fixing 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
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
