From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCHv3 06/30] drm/omap: Add support for render nodes Date: Wed, 29 Mar 2017 11:58:23 +0300 Message-ID: <696c7e28-7c9e-cfd9-cd09-6c4b559c3ecf@ti.com> References: <1490706496-4959-1-git-send-email-tomi.valkeinen@ti.com> <1490706496-4959-7-git-send-email-tomi.valkeinen@ti.com> <2164229.gCdKc2AyjO@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0235711584==" Return-path: Received: from lelnx194.ext.ti.com (lelnx194.ext.ti.com [198.47.27.80]) by gabe.freedesktop.org (Postfix) with ESMTPS id 040766E6EA for ; Wed, 29 Mar 2017 08:58:27 +0000 (UTC) In-Reply-To: <2164229.gCdKc2AyjO@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: Hemant Hariyani , Jyri Sarha , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0235711584== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="en8QWJtl9hj9D0Rni8hMso97vL9MNf46O" --en8QWJtl9hj9D0Rni8hMso97vL9MNf46O Content-Type: multipart/mixed; boundary="oO9gRXe4rSFfM28PEcvLsK0DmnNksPpk0"; protected-headers="v1" From: Tomi Valkeinen To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org, Jyri Sarha , Hemant Hariyani Message-ID: <696c7e28-7c9e-cfd9-cd09-6c4b559c3ecf@ti.com> Subject: Re: [PATCHv3 06/30] drm/omap: Add support for render nodes References: <1490706496-4959-1-git-send-email-tomi.valkeinen@ti.com> <1490706496-4959-7-git-send-email-tomi.valkeinen@ti.com> <2164229.gCdKc2AyjO@avalon> In-Reply-To: <2164229.gCdKc2AyjO@avalon> --oO9gRXe4rSFfM28PEcvLsK0DmnNksPpk0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29/03/17 11:22, Laurent Pinchart wrote: > Hi Tomi, >=20 > Thank you for the patch. >=20 > On Tuesday 28 Mar 2017 16:07:52 Tomi Valkeinen wrote: >> From: Hemant Hariyani >> >> Add support for render nodes in omap driver and allow required >> ioctls to be accessible via render nodes. >=20 > But the OMAP DSS doesn't perform rendering... This seems an abuse of re= nder=20 > 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 --oO9gRXe4rSFfM28PEcvLsK0DmnNksPpk0-- --en8QWJtl9hj9D0Rni8hMso97vL9MNf46O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJY23cvAAoJEPo9qoy8lh71/OIP/0jlLm0YZWX5Ly0LRzkSTM1/ gNezaTLXnZ1uoSAIutpThrUza9z1kpQ594xoPIXe7JCfjgWnw5Ddv4Jt5oJwqUmd OPnOKcINQG4qQ85ztJkMAqn5GsbXxDc5h05GaHHKwP0I+BkaTrx+Gzb1hTH9AEy4 ahTLeyWSUSbheqN+nf1J6sPJfEzeAD5XeI6AG1vMgoNGK3Bimq11QP97vx8qVh2V tpwcLPF6lbxKjVE0zmN7lUKBxrvK5GIeOhWJdu9AYt/15+ig5IQ/ap2Bhe1htvmF lLadEV/rURu6k+9Ad4sgU5pSdJArx/AhnYCK3Xtb9VNuvFtlr9R46GRM3yqUK/ds o5rrz/Kml1leREwoHid4MR14xPhttAE64JUY/bFRiyVyBuf9JYNdnsZTfgnzNHcp BnGLS+vYOqk4OjO6IVzfnqBncOlJwNHb1hSn0HF/1mXIwn+sPyNF29anqSyqTt11 iBaw40g5ch7GPgAT+yK3Cg0CZwQECRUrGxvnPdCBpE/D7UAZUXqK9FAi0sEQLv62 6S2YcZGEcahlILa2Vb+eX3JpbGG6bFPtIb5LFaUHqBzkBHoWV4lPyC9GCPjP+43Y qfwT6n9zTGpZw7o4mDuvfh6JqFHgweCWTu5rEGTmqVH9bZfNDcEy43B4FqH44Bc+ xagnEL2LMLuV1XKtkg0S =9UUm -----END PGP SIGNATURE----- --en8QWJtl9hj9D0Rni8hMso97vL9MNf46O-- --===============0235711584== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0235711584==--