linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Remi Machet <rmachet@slac.stanford.edu>
To: benh@kernel.crashing.org
Cc: Scott Wood <scottwood@freescale.com>,
	Linux PPC <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] dma: add new dma_mapping_ops API sync_page
Date: Fri, 10 Oct 2008 09:16:15 -0700	[thread overview]
Message-ID: <1223655376.374.12.camel@pcds-ts102.slac.stanford.edu> (raw)
In-Reply-To: <1223610362.8157.139.camel@pasglop>

On Fri, 2008-10-10 at 14:46 +1100, Benjamin Herrenschmidt wrote: 
> > > A virtual address will typically be needed to perform the flush; why 
> > > pass the bus address?
> 
> > Because it is a sync API. You want to make sure that a physical memory
> > area is in sync with the caches, not the virtual address. This
> > distinction can become important in the event where the page is mapped
> > multiple times in the memory and the architecture does not take care of
> > synchronizing the multiple mapping, the dma_mapping_ops code should be
> > able to synchronize the multiple mapping. In most case it would be easy
> > of course to go from virtual address to the page address, but not if the
> > page is in high memory ...
> 
> Well, not really. IE, you are right that a dma_addr_t or a struct page
> is the way to go but for the wrong reasons :-)
> 
> All mappings should be coherent. The powerpc architecture is pretty
> strict with that. The only known violation is the instruction cache on
> 44x but that's irrelevant to your problem.
> 
> Thus, -any- virtual address will do.
Good! That certainly simplify the code.

> However, you may not have a virtual address. You may get into a
> situation where the page isn't in the linear mapping and needs to be
> kmap'ed for the sync to happen.
> 
> Now, using PCI_DRAM_OFFSET in bus_to_page() is incorrect here with
> Becky's new set of changes. You need to get the offset properly using
> the accessor she provides (I don't have the name off the top of my
> head).
> 
Totally agree with that. In the last set of patch I committed (which I
need to re-commit because I need to use vmalloc in dma-noncoherent.c) I
removed most of the reference to PCI_DRAM_OFFSET. The only reference to
it remaining is in virt_to_bus which is called by dma_cache_sync.

I did not see an accessor that can be used in dma-mapping.h (the
accessor API I have seen is private to dma.c and dma-noncoherent.c), I
would be happy to use it if there really is one though. I could add
another 2 APIs to dma_mapping_ops which converts a page to/from its bus
address, what do you think?

Remi

      reply	other threads:[~2008-10-10 16:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-01 22:03 [PATCH] dma: add new dma_mapping_ops API sync_page Remi Machet
2008-10-03 16:33 ` Remi Machet
2008-10-06 16:30   ` Scott Wood
2008-10-06 17:38     ` Remi Machet
2008-10-10  3:46       ` Benjamin Herrenschmidt
2008-10-10 16:16         ` Remi Machet [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1223655376.374.12.camel@pcds-ts102.slac.stanford.edu \
    --to=rmachet@slac.stanford.edu \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).