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 <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
