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@xxxxxx> >> >> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
