[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86334106-46d3-9d77-4c65-a1437e0454e5@flowbird.group>
Date: Tue, 7 Aug 2018 11:18:26 +0200
From: Martin Fuzzey <martin.fuzzey@...wbird.group>
To: Rob Herring <robh@...nel.org>, Sean Paul <seanpaul@...omium.org>
Cc: Emil Velikov <emil.l.velikov@...il.com>,
Robert Foss <robert.foss@...labora.com>,
David Airlie <airlied@...ux.ie>,
Brian Paul <brianp@...are.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
eric.engestrom@...el.com, Gustavo Padovan <gustavo@...ovan.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
norvez@...omium.org, Tomasz Figa <tfiga@...omium.org>,
Tomeu Vizoso <tomeu.vizoso@...labora.com>
Subject: Re: [RFC] drm: Allow DRM_IOCTL_MODE_MAP_DUMB for render nodes
On 06/08/18 21:05, Rob Herring wrote:
> On Fri, Aug 3, 2018 at 1:50 PM Sean Paul <seanpaul@...omium.org> wrote:
>> Fwiw, I'd lean towards allowing DUMB allocation from the render nodes. I
>> understand it limits use cases that are undesirable, but it is also limiting
>> usecases that are desirable. So, given that people are going to get "creative"
>> regardless of how many safety railings we put up, we shouldn't make things
>> unnecessarily hard on other trying to Get Work Done.
> The problem with using render nodes is what if there isn't one? We
> require VGEM (and make VGEM allow dumb buffers) in that case?
Try to open the render node and fall back to the card node if it doesn't
exist?
AFAICT VGEM doesn't provide contiguous buffers so it won't work for the
imx-drm case.
Regards,
Martin
Powered by blists - more mailing lists