Re: RFC on upstreaming of a Mediatek DRM modesetting driver

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5339 bytes --]

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 drivers
> > >> 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 vendor.
> > >> 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 DRM
> > >> driver model to work, each vendor (in this case Mediatek) will write
> > >> their own DRM driver (supporting modesetting, dumb buffers, GEM, prime,
> > >> etc) and IMG will provide an almost entirely independent component
> > >> driver that adds in GPU support. Until our GPU driver is in a suitable
> > >> 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 component
> > >> 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 very
> > >> welcome.
> > > Rule of thumb is that if it's an externally licensed IP block it should 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 same
> > > IP-block, while linking up with the respective display controller driver.
> > > 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 cares
> > > whether you use component helpers or not.
> > >
> > > Thanks, Daniel
> > 
> > OK, so it seems the consensus is that IMG should provide a separate
> > render-node only DRM driver.
> > 
> > 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?
> 
> 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/

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel