From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: RFC on upstreaming of a Mediatek DRM modesetting driver Date: Tue, 2 Dec 2014 21:28:22 +0100 Message-ID: <20141202202821.GA20137@mithrandir> References: <547C3C81.4010804@imgtec.com> <20141201152850.GS32117@phenom.ffwll.local> <547D84AF.5030102@imgtec.com> <20141202151015.GV32117@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2127607926==" Return-path: Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by gabe.freedesktop.org (Postfix) with ESMTP id 7910E6FBCA for ; Tue, 2 Dec 2014 12:28:20 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so18208593wgg.29 for ; Tue, 02 Dec 2014 12:28:19 -0800 (PST) In-Reply-To: <20141202151015.GV32117@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: marcheu@google.com, Chiawen.Lee@mediatek.com, puneetster@google.com, scott.chuang@mediatek.com, dbehr@google.com, cawa.cheng@mediatek.com, dri-devel@lists.freedesktop.org, zelidrag@google.com, piman@google.com, Rufus Hamade , djkurtz@google.com, katierh@google.com, alberto@google.com, Yt.Shen@mediatek.com, =?utf-8?B?IkVkZGllIEh1YW5nICjpu4PmmbrlgpEpIg==?= , =?utf-8?B?Ik5hdGhhbiBDaHVuZyAo5Luy5bSH5a+nKSI=?= List-Id: dri-devel@lists.freedesktop.org --===============2127607926== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 02, 2014 at 04:10:15PM +0100, Daniel Vetter wrote: > On Tue, Dec 02, 2014 at 09:21:51AM +0000, Frank Binns wrote: > > On 01/12/14 15:28, Daniel Vetter wrote: > > > On Mon, Dec 01, 2014 at 10:01:37AM +0000, Frank Binns wrote: > > >> Hi, > > >> > > >> We are currently in negotiations with one of our customers (Mediatek= ) on > > >> a strategy that will allow them to push a DRM modesetting driver into > > >> the upstream kernel. We are writing to get people's opinions and > > >> feedback on our proposed approach. > > >> > > >> Currently, our driver is structured in such a way that the display > > >> driver is more tightly integrated with the GPU driver than we would > > >> like. Although our kernel driver has been shipped with a GPL license= for > > >> a long time, it is not in a form that would be considered acceptable > > >> upstream. Unfortunately, it is going to be a long process to get this > > >> part of the driver into a reasonable state. However, in the meantime= , we > > >> don't want to prevent customer portions of the driver from being > > >> upstreamed. With the work done on recent kernels, and with a willing > > >> partner in Mediatek, we now think that we can restructure our driver= in > > >> such a way as to allow this to happen. > > >> > > >> We see two basic approaches to achieving this: > > >> 1) Two independent DRM drivers, i.e. modesetting and render node dri= vers > > >> 2) A single componentised DRM driver > > >> > > >> Our (IMG's) preferred approach is to have a single componentised DRM > > >> driver. This is due to the following reasons: > > >> > > >> - Existing user space is not fully prepared to handle render nodes. > > >> > > >> - There is concern that any IMG DRM render node driver will need > > >> knowledge about multiple SoCs, each one being from a different vendo= r. > > >> Would this be deemed acceptable? > > >> > > >> - There is a trend, at least for DRM SoC drivers, towards using the > > >> component interface. Although there appears to be very few (one?) > > >> examples of GPU component drivers. > > >> > > >> To give some high level details on how we expect the componentised D= RM > > >> driver model to work, each vendor (in this case Mediatek) will write > > >> their own DRM driver (supporting modesetting, dumb buffers, GEM, pri= me, > > >> etc) and IMG will provide an almost entirely independent component > > >> driver that adds in GPU support. Until our GPU driver is in a suitab= le > > >> state this will most likely necessitate a small kernel patch to wire= up > > >> support, e.g. GPU specific ioctls. > > >> > > >> Cross-device and cross-process memory allocations will be made using= the > > >> DRM driver. In order for this memory to be shared with the GPU compo= nent > > >> driver it will be necessary, at least for the time being, to export = it > > >> via prime and import it via a GPU ioctl. Synchronisation between the > > >> display and GPU will be performed via reservation objects. > > >> > > >> Does this sound like a sane approach? Questions and/or feedback is v= ery > > >> welcome. > > > Rule of thumb is that if it's an externally licensed IP block it shou= ld be > > > a separate driver. Which is the case here. The idea is that the mostly > > > generic IMG driver could be reused on other platforms that ship the s= ame > > > IP-block, while linking up with the respective display controller dri= ver. > > > The end result is 2 drm drivers: > > > - Display block drm driver which expose KMS objects for modesetting, = but > > > only very basic gem (just enough to allocate dumb framebuffers and > > > import/export dma-bufs). > > > - Full-blown gem driver for the img render IP block. > > > > > > For an example look at the tegra/nouveau combo which can run on TK1. > > > > > > Plugggin in an IMG driver into each display block like it's currently= done > > > with all the armsoc stuff on android is imo completely no-go. > > > > > > Note that the component interface is completely irrelevant wrt the > > > interface you expose to userspace. It's just an driver-internal helper > > > library useful in certain situation. Not even the drm core really car= es > > > whether you use component helpers or not. > > > > > > Thanks, Daniel > >=20 > > OK, so it seems the consensus is that IMG should provide a separate > > render-node only DRM driver. > >=20 > > Having not worked directly on the core DRM code I'm not completely > > familiar with it but it seems to me that the DRIVER_MODESET flag has a > > dual meaning. Firstly it means that the driver supports KMS and secondly > > it means that a lot of the legacy stuff isn't supported. It also changes > > the way in which driver initialisation is performed. Would it make sense > > for the DRIVER_RENDER flag to have a similar effect? In other words, > > should it turn off legacy stuff and use the newer method of driver > > initialisation? >=20 > DRIVER_MODESET means you have a modern driver which binds to the device. > We should probably RENAME it to DRIVER_LEGACY and invert it's sense, but > no one has stepped up to the taks. Actually I did[0] a while ago. This is the second time that this has come up within a month, so perhaps I should revive the series. Thierry [0]: http://lwn.net/Articles/588016/ --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUfiDlAAoJEN0jrNd/PrOhw64P/2aU0r7phNXMdE6XVvjSUnt7 zjMSBggyzLA9yeyM2R0UlnZtl1uKW9izbcWzkt5yp6dXtlR/MDcP35fXdSM7SxHb 0GpLtZHUIMcR/sLL2p+nGH56C65r7pwRkl+H9oFcqRxNXPOWo0fXmbxtOac3m6ip 0lrW869ivb9dlF1Og7X98P9Y4stcbFuaj02rJvJUiWypG00VqOfG1GkYM9CRYhIy kAt/O1tibHJUiq6Ww4tgo5U0L7nzxkUsGsGZmowI9JJ0JPlAfnweUbG9B++4lZRl YzBy/LALV4x7e/KKQA0kft9FRQjHiqAG35A/Mle5POdXc9lfa3mA9U+TUIzOJCcR OF40Xwj6Ty18RRgVO31bJ1EqCAKh0fHF+bzIxn/nE8m5HdQZjTpbHL1eu//7G+6S 25n42Rp94dk2FkQf4TnS7TMX6zwOigo7xEDZCmafg+tdjrG/ZkFHNvVJHg8h53rD RzfzPeIAMOJqUbe4Cicrjo4ERgO5LwAAi0iKbr4nJ0sz/6D1Zoia1hHpTvJkXH+j BafH2wpu3WT+CdW3iwzis1xEvsVBoae1ZCyQqzi+BPorDPBZyJArJUEDCrdcJ8wq r/qzs29iKNJ9AjmlL6hQqhNuOPK1s2RaufZ64PMATeCsQ4oAuP/SRalsKGuQehi+ l4imCcicZF8qyL0Mf0yJ =AfBX -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- --===============2127607926== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============2127607926==--