From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: "hch@lst.de" <hch@lst.de>, Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
"monstr@monstr.eu" <monstr@monstr.eu>,
"linux-snps-arc@lists.infradead.org"
<linux-snps-arc@lists.infradead.org>,
"linux-c6x-dev@linux-c6x.org" <linux-c6x-dev@linux-c6x.org>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"linux-hexagon@vger.kernel.org" <linux-hexagon@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-m68k@lists.linux-m68k.org"
<linux-m68k@lists.linux-m68k.org>,
"openrisc@lists.librecores.org" <openrisc@lists.librecores.org>,
"green.hu@gmail.com" <green.hu@gmail.com>,
"linux-alpha@vger.kernel.org" <linux-alpha@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"nios2-dev@lists.rocketboards.org"
<nios2-dev@lists.rocketboards.org>,
"deanbo422@gmail.com" <deanbo422@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation
Date: Fri, 18 May 2018 10:28:09 -0700 [thread overview]
Message-ID: <482e343c-bc87-9c0e-b6a8-bb69bcbeecda@synopsys.com> (raw)
In-Reply-To: <20180518132731.GA31125@lst.de>
On 05/18/2018 06:23 AM, hch@lst.de wrote:
> Fri, May 18, 2018 at 01:03:46PM +0000, Alexey Brodkin wrote:
>> Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE".
>> I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have DMA_TO_DEVICE which
>> is quite OK for passing to dma_noncoherent_sync_sg_for_device() but in case of reading we'll have
>> DMA_FROM_DEVICE which we'll pass to dma_noncoherent_sync_sg_for_device() in dma_noncoherent_map_sg().
>>
>> I'd say this is not entirely correct because IMHO arch_sync_dma_for_cpu() is supposed to only be used
>> in case of DMA_FROM_DEVICE and arch_sync_dma_for_device() only in case of DMA_TO_DEVICE.
> arc overrides the dir paramter of the dma_sync_single_for_device/
> dma_sync_single_for_cpu calls. My patches dropped that, and I have
> restored that, and audit for the other architectures is pending.
Right, for now lets retain that and do a sweeping audit of @direction - to me it
seems extraneous (as it did 10 years ago), but I'm not an expert in this are so
perhaps it is needed for some device / arches and it would be good to understand
that finally.
> That being said the existing arc code still looks rather odd as it
> didn't do the same thing for the scatterlist versions of the calls.
> I've thrown in a few patches into my new tree to make the sg versions
> make the normal calls, and to clean up the area a bit.
Not calling names or anything here, but it doesn't exist for sg variants, because
I didn't write that code :-)
It was introduced by your commi:
2016-01-20 052c96dbe33b arc: convert to dma_map_ops
prev parent reply other threads:[~2018-05-18 17:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180511075945.16548-1-hch@lst.de>
[not found] ` <20180511075945.16548-3-hch@lst.de>
[not found] ` <bad125dff49f6e49c895e818c9d1abb346a46e8e.camel@synopsys.com>
2018-05-18 17:20 ` dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation) Vineet Gupta
2018-05-18 17:50 ` Russell King - ARM Linux
2018-05-18 19:57 ` Alexey Brodkin
2018-05-18 21:33 ` Russell King - ARM Linux
2018-05-18 20:35 ` Vineet Gupta
2018-05-18 21:55 ` Russell King - ARM Linux
[not found] ` <20180518132731.GA31125@lst.de>
2018-05-18 17:28 ` Vineet Gupta [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=482e343c-bc87-9c0e-b6a8-bb69bcbeecda@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=akpm@linux-foundation.org \
--cc=deanbo422@gmail.com \
--cc=green.hu@gmail.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-c6x-dev@linux-c6x.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=monstr@monstr.eu \
--cc=nios2-dev@lists.rocketboards.org \
--cc=openrisc@lists.librecores.org \
--cc=sparclinux@vger.kernel.org \
/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).