Messages in this thread | | | Date | Thu, 23 Nov 2006 19:57:57 +0000 | From | Russell King <> | Subject | Re: [PATCH] fix random SD/MMC card recognition failures on ARM Versatile |
| |
On Thu, Nov 23, 2006 at 07:42:36PM +0000, Russell King wrote: > On Thu, Nov 23, 2006 at 10:29:30PM +0300, Vitaly Wool wrote: > > On 11/23/06, Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > >Doubtful. mmci_stop_data() already does this, which will be called > > >immediately prior to mmci_request_end(). So you're doubling up the > > >writes to registers again. > > > > There's the case (mmci_cmd_irq) where mmc_stop_data is not called > > prior to mmci_request_end(), so it's not that simple. > > Ah, I see it. In that case we need to call mmc_stop_data() when > we're ending the initial command due to an error. IOW, like this:
I'll also add that with the way we handle the MMCI, it is highly likely that you _will_ see FIFO errors from time to time on this platform.
The problem is that we don't have DMA up and running on this platform, so we are entirely at the mercy of interrupt-driven PIO. In addition, the MMCI FIFOs must be read _before_ they completely fill to avoid overrun errors. Coupling these two facts together, it's easy to see that interrupt latency is _critical_ to avoiding FIFO overruns (error 3).
In general, if you do _anything_ with the board while it's trying to access MMC cards, you will probably get some FIFO overruns.
There are three solutions:
1. Lower the maximum clock rate that the MMCI will allow, eg: insmod mmci fmax=257816
2. Avoid all other system activity while MMC is being accessed.
3. Someone needs to _sanely_ implement DMA on this platform.
-- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |