[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070605142548.GD31565@havoc.gtf.org>
Date: Tue, 5 Jun 2007 10:25:48 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>,
Christoph Hellwig <hch@...radead.org>,
David Miller <davem@...emloft.net>, mroos@...ux.ee,
linux-kernel@...r.kernel.org
Subject: Re: libata & no PCI: dma_[un]map_single undefined
On Tue, Jun 05, 2007 at 03:17:14PM +0100, Russell King wrote:
> On Tue, Jun 05, 2007 at 09:56:08AM -0400, Jeff Garzik wrote:
> > On Tue, Jun 05, 2007 at 12:22:18PM +0100, Alan Cox wrote:
> > > > NAK
> > > >
> > > > We have generic devices and generic DMA mapping. libata already uses
> > > > the generic stuff. Now fix the platform...
> > >
> > > Nice theory but your generic helpers rely on the map functions working
> > > even for generic hardware that doesn't need them, so at the very least
> > > there is some clean up required.
> >
> > Sure there is some clean up needed -- on the arch side.
> >
> > Even !PCI dma_xxx wrappers that do nothing more than return a dma
> > mapping error are a valid platform implementation.
>
> If you don't have DMA capabilities, does libata still need ->pad and
> ->pad_dma set?
>
> I had a problem where a pata_platform device which wasn't DMA capable
> failed to initialise because we quite rightfully made dma_alloc_coherent()
> fail (due to the DMA masks not being set.)
>
> It seems odd that libata requires DMA memory for non-DMA capable devices...
Now -that- is a quite valid complaint.
libata needs a bit of work to fall back to PIO-only, if dma_xxx fails.
libata also needs some work to fall back to PIO polling, if IRQ is not
present, or registration fails.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists