Prev: Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
Next: linux-next: manual merge of the devicetree tree with Linus' tree
From: Paul Mundt on 7 Jun 2010 02:30
On Mon, Jun 07, 2010 at 01:59:48PM +0900, FUJITA Tomonori wrote:
> On Mon, 7 Jun 2010 07:43:19 +0300
> Marin Mitov <mitov(a)issp.bas.bg> wrote:
> > On Monday, June 07, 2010 07:27:49 am FUJITA Tomonori wrote:
> > > On Mon, 7 Jun 2010 07:08:56 +0300
> > > Marin Mitov <mitov(a)issp.bas.bg> wrote:
> > > > On Monday, June 07, 2010 05:30:48 am FUJITA Tomonori wrote:
> > > > > Hmm, if dma_declare_coherent_memory() fails, the driver doesn't use
> > > > > dev->dma_mem. So even if dev->dma_mem points to a freed memory, I'm
> > > > > not sure that it causes a real problem. We could call this patch a
> > > > > cleanup though.
> > > > >
> > > > My understanding of dma_alloc_coherent() is that we first try to allocate from
> > > > per-device coherent memory and we do it using dma_alloc_from_coherent()
> > > > (in drivers/base/dma-coherent.c) if dev->dma_mem is not NULL (and we have
> > > > left it not NULL, here is the problem). If allocation of dev->dma_mem->bitmap
> > > > fails dev->dma_mem must be NULL.
> > >
> > > But are there any driver that can continue when dma_declare_coherent_memory() fails?
> > >
> > I do not know if such a real driver exists.
>
> From a quick look, seems no. There is no fallback for such hardware,
> it's safe assumption, I guess.
>
Most of the devices using dma_declare_coherent_memory() today do so out
of necessity, usually due to addressing limitations and needing to have
DMA buffers allocated from device memory. This doesn't apply to all
devices though, and indeed didn't apply at all when the interface was
used initially (presently this functionality is pushed down to the DMA
flags, anything that needs to be fixed to the device-specific coherent
region uses DMA_MEMORY_EXCLUSIVE).

drivers/scsi/NCR_Q720.c (which was the only in-tree user for the declare
coherent API before we started using it on SH) is an example of one that
supports fallback to non-exclusive memory, and we've largely managed to
avoid usage clashes with the exception of the following:

0609697eab9775564845d4c94f9e3780fb791ffd
cdf57cab27aef72f13a19c86858c6cac9951dc24
58c6d3dfe436eb8cfb451981d8fdc9044eaf42da

I suspect the generic memory fallback path gets a lot less testing than
the exclusive memory one at least.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
Next: linux-next: manual merge of the devicetree tree with Linus' tree