RFC on upstreaming of a Mediatek DRM modesetting driver

[Alberto Martin]

+Puneet,+Zel

We will get back to you guys with answers soon.
On Dec 1, 2014 9:28 AM, "Daniel Vetter" <daniel at ffwll.ch> 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
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/57b1e1c6/attachment-0001.html>