pci_dma_sync_single

pci_dma_sync_single

[Paul Mackerras]

I'm pretty sure this comment in pci_dma_sync_single in pci.h is wrong:

	/* The bus_to_virt() can't be used here, in case dma_handle
	 * points to something that doesn't have the same cache attributes
	 * as the 1:1 mapped kernel memory.  If we used it, we could
	 * get a cache line alias with the wrong attributes.
	 * Since there isn't any Linux way to get the real VA from a PA,
	 * it is just easier to flush the whole cache.  The code to
	 * determine VA from PA would probably do the same :-).
	 * I don't know why these functions don't pass VA, since the
	 * cache operations use VA and the caller has this information.
	 *	-- Dan
	 */

There are basically two ways to get a dma_handle: through
pci_alloc_consistent, which might map some memory with caching disable
(I'm talking about the non-cache-coherent processors here), or through
mapping some memory with pci_map_single, pci_map_sg, or pci_map_page.

Now in the first instance, which is what the comment seems to be
referring to, we get the consistency by having the uncached mapping,
and you don't need to, and in fact shouldn't, call pci_dma_sync_single.

In the second instance the CPU's mapping of the page would be a
cacheable mapping since the caller would have got the memory via
kmalloc or get_free_page, and so the possibility of cache paradoxes
doesn't arise there either.

So in the absence of highmem it seems to me that pci_dma_sync_single
could just do bus_to_virt quite safely.  With highmem, the (new)
pci_map_page routine lets us do dma to highmem pages directly, and so
bus_to_virt won't work there, but it would be relatively easy to kmap
the page and flush that virtual address.

However, I have just realized that the best way of all is probably to
have a cache-flush routine which just turns off DR and flushes using
physical addresses, which will be identical to the dma addresses
(except for an offset on some platforms).

Thoughts?  Have I got the wrong end of the stick?

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: pci_dma_sync_single

[Ralph Blach]

Paul Mackerras wrote:
>
> I'm pretty sure this comment in pci_dma_sync_single in pci.h is wrong:
>
>         /* The bus_to_virt() can't be used here, in case dma_handle
>          * points to something that doesn't have the same cache attributes
>          * as the 1:1 mapped kernel memory.  If we used it, we could
>          * get a cache line alias with the wrong attributes.
>          * Since there isn't any Linux way to get the real VA from a PA,
>          * it is just easier to flush the whole cache.  The code to
>          * determine VA from PA would probably do the same :-).
>          * I don't know why these functions don't pass VA, since the
>          * cache operations use VA and the caller has this information.
>          *      -- Dan
>          */
>
> There are basically two ways to get a dma_handle: through
> pci_alloc_consistent, which might map some memory with caching disable
> (I'm talking about the non-cache-coherent processors here), or through
> mapping some memory with pci_map_single, pci_map_sg, or pci_map_page.
>
> Now in the first instance, which is what the comment seems to be
> referring to, we get the consistency by having the uncached mapping,
> and you don't need to, and in fact shouldn't, call pci_dma_sync_single.
>
> In the second instance the CPU's mapping of the page would be a
> cacheable mapping since the caller would have got the memory via
> kmalloc or get_free_page, and so the possibility of cache paradoxes
> doesn't arise there either.
>
> So in the absence of highmem it seems to me that pci_dma_sync_single
> could just do bus_to_virt quite safely.  With highmem, the (new)
> pci_map_page routine lets us do dma to highmem pages directly, and so
> bus_to_virt won't work there, but it would be relatively easy to kmap
> the page and flush that virtual address.
>
> However, I have just realized that the best way of all is probably to
> have a cache-flush routine which just turns off DR and flushes using
> physical addresses, which will be identical to the dma addresses
> (except for an offset on some platforms).

This would probably work, except on Book E platforms, where DR off
simpley gets you another translaton and NOT
a physical address.


>
> Thoughts?  Have I got the wrong end of the stick?
>
> Paul.
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: pci_dma_sync_single

[Benjamin Herrenschmidt]

>This would probably work, except on Book E platforms, where DR off
>simpley gets you another translaton and NOT
>a physical address.

Well, the last time we discussed about book E, the idea was to use
1:1 translations with DR off that mimmics a physical addressing
(which has also the nice side effect of beeing able to build those
translations on the fly from the TLB miss handler without having to
dig into the page tables).

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: pci_dma_sync_single

[Paul Mackerras]

Ralph Blach writes:

> This would probably work, except on Book E platforms, where DR off
> simpley gets you another translaton and NOT
> a physical address.

We don't support any Book E platforms at the moment anyway.  When we
do this will be one of the issues we have to address.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: pci_dma_sync_single

[Tom Rini]

On Wed, Oct 17, 2001 at 11:47:56AM +1000, Paul Mackerras wrote:
>
> Ralph Blach writes:
>
> > This would probably work, except on Book E platforms, where DR off
> > simpley gets you another translaton and NOT
> > a physical address.
>
> We don't support any Book E platforms at the moment anyway.  When we
> do this will be one of the issues we have to address.

Eh?  Aren't the 403 and 405 both Book E?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: pci_dma_sync_single

[Ralph Blach]

Tom,

No, the 405 and 403 are not Book E.

Chip

Tom Rini wrote:
>
> On Wed, Oct 17, 2001 at 11:47:56AM +1000, Paul Mackerras wrote:
> >
> > Ralph Blach writes:
> >
> > > This would probably work, except on Book E platforms, where DR off
> > > simpley gets you another translaton and NOT
> > > a physical address.
> >
> > We don't support any Book E platforms at the moment anyway.  When we
> > do this will be one of the issues we have to address.
>
> Eh?  Aren't the 403 and 405 both Book E?
>
> --
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: pci_dma_sync_single

[Dan Malek]

Benjamin Herrenschmidt wrote:

> Well, the last time we discussed about book E,

I'm kinda planning to roll a whole new book E arch tree so we can
take advantage of their features without hacking up the traditional
PowerPC.  There are a variety of options that will be necessary to
fit a wide range of embedded applications for which they are
specifically designed.  While we can make Book E fit into the
traditional PowerPC tree by forcing some fixed rules, it wouldn't
be fair to their flexibility or performance options.

I've got a couple of things to finish up and would like to start
discussing this in the next couple of weeks, as more documentation
and perhaps some hardware arrives on my doorstep.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: pci_dma_sync_single

[Dan Malek]

Paul Mackerras wrote:

> There are basically two ways to get a dma_handle:

Right, and here is what happend....The comment first existed when
we were mapping uncached pages (for any reason, including
pci_alloc_consistent) into a VM space that was not mapped 1:1
with the kernel (it was actually vmalloc()'ed under the covers).
In this case, bus_to_virt() wouldn't work, then I changed it to
use iopa() to scan the page tables, so it worked again, then I
changed pci_alloc_consistent() to just change the attributes on
the individual pages, and now with large pages sizes I have to
allocate the non-1:1 VM space again.  So, the code has changed
a bunch without me changing the comment :-).  I'm going to
settle on large pages with the non-1:1 mapping again, for real,
for the last time.  I'll change the comment to say the right thing.

I think you have the right end of the stick :-).  You shouldn't
have to sync_single on alloc_consistent space, but I couldn't find
consistent use of all of these functions among existing drivers.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/