From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Riley Andrews" <riandrews@android.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"Zeng Tao" <prime.zeng@huawei.com>,
"Laura Abbott" <labbott@redhat.com>
Subject: Re: [PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable
Date: Fri, 17 Jul 2015 17:29:36 +0100 [thread overview]
Message-ID: <1437150576.27204.14.camel@linaro.org> (raw)
In-Reply-To: <55A91D5E.9000009@arm.com>
On Fri, 2015-07-17 at 16:21 +0100, Robin Murphy wrote:
> This also begs the question as to what happens if the memory region _is_
> > contiguous but is in highmem or an ioremapped region. Should a device
> > always provide dma_ops for that case? Because I believe the current
> > implementation of dma_common_get_sgtable won't work for those as it uses
> > virt_to_page.
> >
> > I see that this point has been raised before [1] by Zeng Tao, and I
> > myself have been given a different fix to apply to a Linaro kernel tree.
> > However, both solutions looked wrong to me as they treat a dma_addr_t as
> > a physical address, so should at least be using dma_to_phys.
> > So, should we fix dma_common_get_sgtable or mandate that the device
> > has dma_ops? The latter seems to be implied by the commit message which
> > introduced the function:
> >
> > This patch provides a generic implementation based on
> > virt_to_page() call. Architectures which require more
> > sophisticated translation might provide their own get_sgtable()
> > methods.
>
> Given that we're largely here due to having poked this on arm64 systems,
> I'm inclined to think that implementing our own get_sgtable as per
> arch/arm is the right course of action. Since a lot of architectures
> using dma_common_get_sgtable don't even implement dma_to_phys,
I had another check and that seems to be true.
> I don't
> think it would be right to try complicating the common code for a case
> that seems to be all but common.
I'm inclined to agree, however I'm rather new to this area.
> I can spin an arm64 patch if you like.
That would be good. Especially as from what I see on the arm kernel
lists you are already working in that area... And my inbox has just
pinged with that patch from you, so I'll add a reference here [2] so
people coming across this thread can find it easily.
For 32-bit arm my $subject patch should fix ION as that already has the
DMA ops.
--
Tixy
[1] https://lkml.org/lkml/2014/12/1/584
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/357561.html
next prev parent reply other threads:[~2015-07-17 16:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 11:01 [PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable Jon Medhurst (Tixy)
2015-07-17 15:21 ` Robin Murphy
2015-07-17 16:29 ` Jon Medhurst (Tixy) [this message]
2015-07-17 16:50 ` Laura Abbott
2015-07-20 18:30 ` Robin Murphy
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=1437150576.27204.14.camel@linaro.org \
--to=tixy@linaro.org \
--cc=arve@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=prime.zeng@huawei.com \
--cc=riandrews@android.com \
--cc=robin.murphy@arm.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.