From: Sumit Semwal <sumit.semwal@linaro.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Rob Clark <robdclark@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Linaro MM SIG Mailman List <linaro-mm-sig@lists.linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Linaro Kernel Mailman List <linaro-kernel@lists.linaro.org>,
Tomasz Stanislawski <stanislawski.tomasz@googlemail.com>,
Daniel Vetter <daniel@ffwll.ch>,
Robin Murphy <robin.murphy@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
Date: Mon, 2 Feb 2015 11:23:35 +0530 [thread overview]
Message-ID: <CAO_48GGqtYWMnweUx_8_p4HOyf58h2q0PbvehVNN5Wm5p_N00w@mail.gmail.com> (raw)
In-Reply-To: <20150129192610.GE26493@n2100.arm.linux.org.uk>
Hi Russell,
On 30 January 2015 at 00:56, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
>> Quite possibly for some of these edge some of cases, some of the
>> dma-buf exporters are going to need to get more clever (ie. hand off
>> different scatterlists to different clients). Although I think by far
>> the two common cases will be "I can support anything via an iommu/mmu"
>> and "I need phys contig".
>>
>> But that isn't an issue w/ dma-buf itself, so much as it is an issue
>> w/ drivers. I guess there would be more interest in fixing up drivers
>> when actual hw comes along that needs it..
>
> However, validating the attachments is the business of dma-buf. This
> is actual infrastructure, which should ensure some kind of sanity such
> as the issues I've raised.
>
> The whole "we can push it onto our users" is really on - what that
> results in is the users ignoring most of the requirements and just doing
> their own thing, which ultimately ends up with the whole thing turning
> into a disgusting mess - one which becomes very difficult to fix later.
>
> Now, if we're going to do the "more clever" thing you mention above,
> that rather negates the point of this two-part patch set, which is to
> provide the union of the DMA capabilities of all users. A union in
> that case is no longer sane as we'd be tailoring the SG lists to each
> user.
>
> If we aren't going to do the "more clever" thing, then yes, we need this
> code to calculate that union, but we _also_ need it to do sanity checking
> right from the start, and refuse conditions which ultimately break the
> ability to make use of that union - in other words, when the union of
> the DMA capabilities means that the dmabuf can't be represented.
>
> Unless we do that, we'll just end up with random drivers interpreting
> what they want from the DMA capabilities, and we'll have some drivers
> exporting (eg) scatterlists which satisfy the maximum byte size of an
> element, but ignoring the maximum number of entries or vice versa, and
> that'll most probably hide the case of "too small a union".
>
I agree, and I'll add the check for
max_segment_size * max_segment_count < dmabuf->size
and resend; will that be alright with you?
> It really doesn't make sense to do both either: that route is even more
> madness, because we'll end up with two classes of drivers - those which
> use the union approach, and those which don't.
>
> The KISS principle applies here.
>
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
Best regards,
~Sumit.
next prev parent reply other threads:[~2015-02-02 5:53 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-27 8:25 [RFCv3 1/2] device: add dma_params->max_segment_count Sumit Semwal
2015-01-27 8:25 ` [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Sumit Semwal
2015-01-29 14:16 ` Maarten Lankhorst
2015-01-29 14:39 ` Russell King - ARM Linux
2015-01-29 15:30 ` Sumit Semwal
2015-01-29 15:47 ` Russell King - ARM Linux
2015-01-29 16:55 ` Sumit Semwal
2015-01-29 18:52 ` Rob Clark
2015-01-29 19:26 ` Russell King - ARM Linux
2015-01-29 22:18 ` Rob Clark
2015-01-29 22:31 ` Russell King - ARM Linux
2015-01-29 23:19 ` Rob Clark
2015-02-02 16:54 ` Daniel Vetter
2015-02-02 20:30 ` Rob Clark
2015-02-02 21:46 ` Russell King - ARM Linux
2015-02-02 22:36 ` Rob Clark
2015-02-03 7:50 ` Daniel Vetter
2015-02-03 7:46 ` Daniel Vetter
2015-02-03 7:48 ` Daniel Vetter
2015-02-03 12:28 ` Russell King - ARM Linux
2015-02-03 13:00 ` Daniel Vetter
2015-02-03 13:28 ` Christian Gmeiner
2015-02-03 14:32 ` Russell King - ARM Linux
2015-02-03 14:25 ` Rob Clark
2015-02-03 14:04 ` Rob Clark
2015-02-03 14:17 ` Arnd Bergmann
2015-02-03 14:41 ` Russell King - ARM Linux
2015-02-03 14:52 ` Arnd Bergmann
2015-02-03 15:22 ` Russell King - ARM Linux
2015-02-03 15:31 ` [Linaro-mm-sig] " Arnd Bergmann
2015-02-03 15:54 ` Russell King - ARM Linux
2015-02-03 16:12 ` Arnd Bergmann
2015-02-03 16:22 ` Rob Clark
2015-02-03 16:36 ` Arnd Bergmann
2015-02-03 20:04 ` Daniel Vetter
2015-02-03 21:42 ` Arnd Bergmann
2015-02-03 22:07 ` Daniel Vetter
2015-02-04 0:14 ` Russell King - ARM Linux
2015-02-03 17:01 ` Russell King - ARM Linux
2015-02-03 16:58 ` Russell King - ARM Linux
2015-02-03 17:35 ` Rob Clark
2015-02-03 20:08 ` Daniel Vetter
2015-02-03 21:44 ` Arnd Bergmann
2015-02-03 15:25 ` Rob Clark
2015-02-03 15:19 ` Rob Clark
2015-02-03 14:37 ` Russell King - ARM Linux
2015-02-03 14:44 ` Rob Clark
2015-02-03 14:58 ` Russell King - ARM Linux
2015-02-02 5:53 ` Sumit Semwal [this message]
2015-02-11 8:28 ` Marek Szyprowski
2015-02-11 11:12 ` Russell King - ARM Linux
2015-02-11 11:23 ` Rob Clark
2015-02-11 12:56 ` Daniel Vetter
2015-02-11 13:30 ` Rob Clark
2015-02-11 12:20 ` Marek Szyprowski
2015-02-11 16:23 ` Russell King - ARM Linux
2015-05-05 14:41 ` Sumit Semwal
2015-06-03 6:39 ` [Linaro-mm-sig] " Hans Verkuil
2015-06-03 8:41 ` Russell King - ARM Linux
2015-06-03 9:37 ` Hans Verkuil
2015-06-04 5:24 ` Sumit Semwal
2015-01-28 14:09 ` [RFCv3 1/2] device: add dma_params->max_segment_count Marek Szyprowski
2015-06-03 6:13 ` [Linaro-mm-sig] " Hans Verkuil
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=CAO_48GGqtYWMnweUx_8_p4HOyf58h2q0PbvehVNN5Wm5p_N00w@mail.gmail.com \
--to=sumit.semwal@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=stanislawski.tomasz@googlemail.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).