[PATCHv3 06/30] drm/omap: Add support for render nodes

[Tomi Valkeinen]

On 29/03/17 11:22, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Tuesday 28 Mar 2017 16:07:52 Tomi Valkeinen wrote:
>> From: Hemant Hariyani <hemanthariyani at ti.com>
>>
>> Add support for render nodes in omap driver and allow required
>> ioctls to be accessible via render nodes.
> 
> But the OMAP DSS doesn't perform rendering... This seems an abuse of render 
> nodes, I think the API should instead be implemented by the GPU driver.

I agree that the GPU use case described in the patch sounds a bit odd.
Why not allocate from the GPU driver instead. But here a particular
issue is that to get TILER buffers we need to ask them from the omapdrm.
Probably TILER should not be part of omapdrm, but then, where should it
be...

We also have writeback in DSS, which can function as a memory to memory
or capture device. That's not supported in the mainline, but we have
support in the TI kernel.

And how about a case where you have the privileged process as KMS
master, and another process wants to draw to a buffer with the CPU, and
then give the buffer to the privileged process for displaying.

So, yes, DSS is not a renderer (well, WB is kind of rendering), but
isn't it a valid use case to allocate a buffer from omapdrm?

Also, where should a buffer be allocated from, generally? I usually
think that if a buffer is going to DSS, I allocate it from omapdrm. Then
again, getting it from the source sounds ok also, i.e. from a v4l2
capture driver... But if we get it from the source, it may not be usable
by all the components in the processing pipeline (e.g, SGX requires 32
pixel aligned buffers).

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170329/35a17dd3/attachment.sig>