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
prev parent 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).