On Sun, 2011-09-18 at 23:53 -0700, Keith Packard wrote: > On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > > I think it's a bit more complex than that. True, there are MIPI > > standards, for the video there are DPI, DBI, DSI, and for the commands > > there is DCS. And, as you mentioned, many panels need custom > > initialization, or support only parts of the DCS, or have other > > quirks. > > So DSI is more like i2c than the DisplayPort aux channel or DDC. That Well, not quite. DSI is like DisplayPort and DisplayPort aux combined; there's only one bus, DSI, which is used to transfer video data and commands. For DSI video mode, the transfer is somewhat like traditional displays, and video data is send according to a pixel clock as a constant stream. However, before the video stream is enabled the bus can be used in bi-directional communication. And even when the video stream is enabled, there can be other communication in the blanking periods. For DSI command mode the transfer is a bit like high speed i2c; messages are sent when needed (when the userspace gives the command to update), without any strict timings. In practice this means that the peripheral needs to have a framebuffer memory of its own, which it uses to refresh the actual panel (or send the pixels forward to another peripheral). As the use patterns of these two types of displays are quite different, we have the terms auto-update and manual-update displays for them. > seems fine; you can create a DSI infrastructure like the i2c > infrastructure and then just have your display drivers use it to talk to > the panel. We might eventually end up with some shared DRM code to deal > with common DSI functions for display devices, like the EDID code > today, but that doesn't need to happen before you can write your first > DSI-using display driver. One difference with i2c and DSI is that i2c is independent of the video path, so it's easy to keep that separate from DRM. But for DSI the data is produced by the video hardware using the overlays, encoders etc. I don't quite see how we could have an i2c-like separate DSI API, which wasn't part of DRM. And even in simpler case MIPI DPI, which is a traditional parallel RGB interface, a panel may need custom configuration via, say, i2c or spi. We can, of course, create a i2c device driver for the panel, but how is that then connected to DRM? The i2c driver may need to know things like when the display is enabled/disabled, about backlight changes, or any other display related event. Is there a way for the i2c driver to get these events, and add new properties to the DRM (say, if the panel has a feature configured via i2c, but we'd like it to be visible to the userspace via the DRM driver)? Tomi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
