[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

[Pawel Moll]

On Thu, 2013-07-25 at 19:21 +0100, Rob Clark wrote:
> >  * Only supports 640x480 mode, which is hard-coded. We intend to
> >    rebase on top of CDF once it is merged, which hopefully will
> >    handle a lot of the EDID parsing & mode setting for us (once
> >    Pawel's CDF patches for VExpress also land).
> 
> note that drm core already handles EDID parsing quite nicely.. I'm not
> entirely sure why CDF would be needed for this?
>
> What is the dependency on CDF?  Is there an external encoder/bridge
> that could be shared between platforms?

By all means. The platform we have here at ARM - Versatile Express - has
a pretty generic idea of "multimedia bus", carrying a set of RGB pixel
data and digital audio. There are three possible source of those: an
FPGA on the motherboard and two daughterboards which can take random
combination of FPGAs or test chips. In other words: the pixel data can
be generated by anything. And some of those things can be driven by
existing fbdev drivers. Now Tom is trying to make the most modern driver
for the oldest of the things ;-)

So that's about sources. All of them are connected to yet another FPGA
which acts as a muxer (switch if you wish). And from there things are
fed to SiI9022 HDMI/DVI formatter which is pretty common in the
"embedded world". In other words: loads of other fbdev-driven display
controllers are driving them as well (googling for sii9022 reveals at
least 3 different more or less custom drivers for it). And this chip is
also a reason Tom mentioned EDID. In order to get (just access, not even
parse) it we must jump through hoops - the chip acts as a I2C master
itself and must be kindly asked to switch into a sort of I2C bridge
mode.

So yes, the display pipeline is exactly straight-forward...

> btw, I think that having some share-able KMS objects is a good idea.
> I'm not entirely sure that the directions that the current CDF
> proposals are headed is necessarily the right way forward.  I'd prefer
> to see small/incremental evolution of KMS (ie. add drm_bridge and
> drm_panel, and refactor the existing encoder-slave).  Keeping it
> inside drm means that we can evolve it more easily, and avoid layers
> of glue code for no good reason.

To keep the story short - I'm a great enthusiast of CDF because it
caters for both DRM *and* fbdev. Today. I'm looking forward to the day
when the last fbdev driver is kicked off the kernel, but it doesn't look
like happening soon. At the same time I couldn't care less about naming,
so if you prefer to call it drm_panel (but keep the API abstract enough
so non-DRM drivers can use them as well) - it's fine for me :-) There
are already generic mode/timing structures and DT bidnings available
(with helpers for the interesting parties), so this doesn't seem like a
unreasonable request?

Cheers!

Pawel