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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
