Subject: Re: ARM: 2.6.3[45] PCI regression (IXP4xx and PXA?)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: khc@pm.waw.pl, linux@arm.linux.org.uk, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
In-Reply-To: <20100820021915C.fujita.tomonori@lab.ntt.co.jp>
References: <1282213882.22370.360.camel@pasglop>
	 <20100819234835Y.fujita.tomonori@lab.ntt.co.jp>
	 <m38w42sfvx.fsf@intrepid.localdomain>
	 <20100820021915C.fujita.tomonori@lab.ntt.co.jp>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 20 Aug 2010 07:54:28 +1000
Message-ID: <1282254868.22370.370.camel@pasglop>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2647
Lines: 68


> linux/device.h defines that it's the device dma mask.
> 
> Except for ARM, coherent_dma_mask represents the device dma mask.

That's just verbiage in a header file. Nobody cares. The point is, the
device DMA mask per-se is a completely useless piece of information, and
thus there is absolutely no point keeping it around there.

The only thing that matters is the intersection of all the masks on the
way to memory, which defines where memory can be allocated.

Now the mask thing itself might end up not being enough for ARM in the
long run, I wouldn't be surprised if we end up with busses that can DMA
to areas of memory that are not 0 based, but that's a discussion for
another day.

> We sometimes want to know the device dma mask. Moving to your
> definition means that we lose that information.

When ?

Cheers,
Ben.

> > This usually equals device's address space - only because CPU and
> > bridges next to it have wide (logical) address busses. It's not always
> > the case, though, and may be not the case on any arch.
> > 
> > We should make sure we got it right (including drivers), since any
> > reduction of the dma*mask would be irreversible (new masks would be
> > ANDed with the existing masks).
> > 
> > > I think that having the generic place for bus'
> > > dma mask would be better rather than architecture specific
> > > places.
> > 
> > Definitely, if possible. BTW the dmabounce (and equivalent code on other
> > archs, including probably swiotlb on x86-64) could probably be merged as
> > well. I don't know the internals very well, though. At least it may be
> > worth it looking at them.
> 
> btw, swiotlb is used by x86_64, ia64, and powerpc.
> 
> I'm sure that I can convert ARM to use it instead of dmabounce. But
> well, even a bug fix patch for dmabounce haven't been merged so I'm
> not sure that ARM people would accept such change.
> 
> http://marc.info/?l=linux-arm-kernel&m=128047064008554&w=2
> 
> 
> > > Adding a new API to set bus' dma mask would make sense too.
> > 
> > Not sure. Which bus? There could be many :-)
> > In practice - 64-bit PCIe -> 32-bit PCI -> 24-bit ISA - etc.
> > Or, like with IXP/PXA - 26-bit PCI -> 32-bit device.
> 
> Seems that we are not on the same page. As I said before, have you
> seen how POWERPC uses max_direct_dma_addr in dev_archdata struct? I
> was talking about moving it to the generic place and the API to set
> it.


--
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/