From: James Hogan <jhogan@kernel.org>
To: Huacai Chen <chenhc@lemote.com>
Cc: Christoph Hellwig <hch@lst.de>,
Ralf Baechle <ralf@linux-mips.org>,
"Steven J . Hill" <Steven.Hill@cavium.com>,
Linux MIPS Mailing List <linux-mips@linux-mips.org>,
Fuxin Zhang <zhangfx@lemote.com>,
Zhangjin Wu <wuzhangjin@gmail.com>,
Jayachandran C <jchandra@broadcom.com>
Subject: Re: [PATCH 2/2] MIPS: Loongson64: Add cache_sync to loongson_dma_map_ops
Date: Thu, 25 Jan 2018 10:54:49 +0000 [thread overview]
Message-ID: <20180125105449.GL5446@saruman> (raw)
In-Reply-To: <CAAhV-H7i8PZtn7JMgzCW3nseH-rwtcc_H6_9n+pOE4DU5i1KAg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]
On Thu, Jan 25, 2018 at 04:44:36PM +0800, Huacai Chen wrote:
> On Thu, Jan 25, 2018 at 3:55 PM, James Hogan <jhogan@kernel.org> wrote:
> > Hi Huacai,
> >
> > On Thu, Jan 25, 2018 at 03:09:33PM +0800, Huacai Chen wrote:
> >> Hi, James and Christoph,
> >>
> >> We have modified arch/mips/loongson64/common/dma-swiotlb.c to make
> >> Loongson support coherent&non-coherent devices co-exist. You can see
> >> code here:
> >> https://github.com/linux-loongson/linux-loongson/commit/3f212e36b2432a7c4a843649e4b79c9c0837d1d2
> >> When device is non-coherent, we will call dma_cache_sync().
> >>
> >> Then, if dma_cache_sync() is only designed for
> >> DMA_ATTR_NON_CONSISTENT, what can I use?
> >
> > How did you allocate the memory? The appropriate generic API for the
> > type of memory should always be used in drivers over arch specific
> > stuff.
> >
> > AFAIK (see e.g. Documentation/DMA-API.txt):
> > - dma_alloc_coherent() shouldn't require syncing, though it may require
> > flushing of write combiners
> > - dma_alloc_attrs() only requires syncing when DMA_ATTR_NON_CONSISTENT
> > is used, otherwise is the same as dma_alloc_coherent()
> > - guaranteed contiguous memory within PA range (e.g. kmalloc()'d memory
> > with the appropriate GFP_DMA flags) can be synced using the
> > dma_map_*() and dma_unmap_*() functions.
I also see there is a dma_sync_*_for_{cpu,device} to avoid "mapping" and
"unmapping" the same area repeatedly if it is reused.
> Yes, kmalloc()'d memory with the appropriate GFP_DMA flags can be
> synced using the dma_map_*() and dma_unmap_*() functions. So,
> loongson_dma_map_page()/loongson_dma_unmap_page() (which is the
> backend of dma_map_*() and dma_unmap_*()) should call dma_cache_sync()
> for non-coherent devices, right?
Yeh, I suppose thats effectively what it should do (though probably via
an arch specific function rather than dma_cache_sync() itself). Also the
sync_*_for_{cpu,device} callbacks should probably do it too. See all the
calls to __dma_sync() in the MIPS dma-default.c implementation.
Cheers
James
>
> Huacai
>
> >
> > Cheers
> > James
> >
> >> 1, __dma_sync_virtual() and __dma_sync() are both static functions, so
> >> can't be called in other files.
> >> 2, mips_dma_cache_sync() is not static, but I think it isn't designed
> >> to be called directly (So it should be static).
> >> 3, dma_cache_wback(), dma_cache_inv() and dma_cache_wback_inv() does't
> >> take a "direction" argument, so I should determine the direction first
> >> (then I will reimplement __dma_cache_sync for myself).
> >> So, It seems that I can only use dma_cache_sync().
> >>
> >> Huacai
> >>
> >> On Wed, Jan 24, 2018 at 11:29 PM, Christoph Hellwig <hch@lst.de> wrote:
> >> > On Wed, Jan 24, 2018 at 03:03:05PM +0000, James Hogan wrote:
> >> >> I see, that makes sense. Thanks Christoph. I'll assume this patch isn't
> >> >> applicable then unless Huacai adds some explanation.
> >> >
> >> > In addition there also is no driver that can be used on loongsoon
> >> > that actually calls dma_cache_sync either.
> >> >
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-01-25 10:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 8:35 [PATCH 2/2] MIPS: Loongson64: Add cache_sync to loongson_dma_map_ops Huacai Chen
2018-01-24 14:02 ` James Hogan
2018-01-24 14:11 ` Christoph Hellwig
2018-01-24 15:03 ` James Hogan
2018-01-24 15:29 ` Christoph Hellwig
2018-01-25 7:09 ` Huacai Chen
2018-01-25 7:55 ` James Hogan
2018-01-25 8:44 ` Huacai Chen
2018-01-25 10:54 ` James Hogan [this message]
2018-01-25 11:04 ` Huacai Chen
2018-01-25 12:31 ` James Hogan
2018-01-26 7:56 ` Christoph Hellwig
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=20180125105449.GL5446@saruman \
--to=jhogan@kernel.org \
--cc=Steven.Hill@cavium.com \
--cc=chenhc@lemote.com \
--cc=hch@lst.de \
--cc=jchandra@broadcom.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=wuzhangjin@gmail.com \
--cc=zhangfx@lemote.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.