+Puneet,+Zel
We will get back to you guys with answers soon.
On Dec 1, 2014 9:28 AM, "Daniel Vetter" <daniel@xxxxxxxx> 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
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
