On Thu, Oct 27, 2011 at 08:02:13AM +0200, Wolfram Sang wrote:
Even there are some SDHCI hardwares cannot be stable in microseconds, I
think this is also OK since they just need to wait for a few more loops. The
total waiting time is the same as before.
Well, I still think this is curing the
Even there are some SDHCI hardwares cannot be stable in microseconds, I
think this is also OK since they just need to wait for a few more loops. The
total waiting time is the same as before.
Well, I still think this is curing the symptoms not the cause. But will talk
with Chris about it since
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the responsing of the kernel interrupts.
So in this case, using a mdelay will cause unnecessary latency. Our
hardware, in most case will
2011/10/27 Shawn.Dong shawn.dong...@gmail.com:
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the responsing of the kernel interrupts.
So in this case, using a mdelay will cause
Hi,
On Thu, Oct 27, 2011 at 12:18:53PM +0800, Shawn.Dong wrote:
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the responsing of the kernel interrupts.
Yes, so this needs to be
On Thu, Oct 27, 2011 at 07:15:32AM +0200, Wolfram Sang wrote:
Hi,
On Thu, Oct 27, 2011 at 12:18:53PM +0800, Shawn.Dong wrote:
sdhci_set_clock or sdhci_reset or sdhci_send_command may be used in
critical region which is protected by spin_lock_irqsave. Thus, these
functions will delay the
