On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
- It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
the plan is to make DRM the core Linux display framework, upon which everything else is built, and fb and v4l2 are changed to use DRM.
I'd like to think we could make DRM the underlying display framework; it already exposes an fb interface, and with overlays, a bit more of the v4l2 stuff is done as well. Certainly eliminating three copies of mode setting infrastructure would be nice...
Ok, sounds good to me. We (as in OMAP display people) are already planning to take DRM into use, so no problem there.
But even if it was done like that, I see that it's combining two separate things: 1) the lower level HW control, and 2) the upper level buffer management, policies and userspace interfaces.
Those are split between the DRM layer and the underlying device driver, which provides both kernel (via fb) and user space interfaces.
I'm not so familiar with DRM, but with device driver you mean a driver for the the hardware which handles display output (gfx cards or whatever it is on that platform)?
I think he is more referring to the DRM core and the individual device drivers..
We are (AFAIK) unique in having a two layer driver, where the DRM part is more of a wrapper (for the KMS parts)... but I see that as more of a transition thing.. eventually we should be able to merge it all into the DRM layer.
If so, it sounds good. That quite well matches what omapdss driver does currently for us. But we still have semi-complex omapdrm between omapdss and the standard drm layer.
Rob, would you say omapdrm is more of a DRM wrapper for omapdss than a real separate entity? If so, then we could possibly in the future (when nobody else uses omapdss) change omapdss to support DRM natively. (or make omapdrm support omap HW natively, which ever way =).
Yeah, I think eventually it would make sense to merge all into one. Although I'm not sure about how best to handle various different custom DSI panels..
BR, -R
- It's missing the panel driver part. This is rather important on
embedded systems, as the panels often are not "dummy" panels, but they need things like custom initialization, sending commands to adjust backlight, etc.
We integrate the panel (and other video output) drivers into the device drivers. With desktop chips, they're not easily separable. None of the desktop output drivers are simple; things like DisplayPort require link training, and everyone needs EDID. We share some of that code in the DRM layer today, and it would be nice to share even more.
I don't think we speak of similar panel drivers. I think there are two different drivers here:
- output drivers, handles the output from the SoC / gfx card. For
example DVI, DisplayPort, MIPI DPI/DBI/DSI.
- panel drivers, handles panel specific things. Each panel may support
custom commands and features, for which we need a dedicated driver. And this driver is not platform specific, but should work with any platform which has the output used with the panel.
As an example, DSI command mode displays can be quite complex:
DSI bus is a half-duplex serial bus, and while it's designed for displays you could use it easily for any communication between the SoC and the peripheral.
The panel could have a feature like content adaptive backlight control, and this would be configured via the DSI bus, sending a particular command to the panel (possibly by first reading something from the panel). The panel driver would accomplish this more or less the same way one uses, say, i2c, so it would use the platform's DSI support to send and receive packets.
Or a more complex scenario (but still a realistic scenario, been there, done that) is sending the image to the panel in multiple parts, and between each part sending configuration commands to the panel. (and still getting it done in time so we avoid tearing).
And to complicate things more, there are DSI bus features like LP mode (low power, basically low speed mode) and HS mode (high speed), virtual channel IDs, and whatnot, which each panel may need to be used in particular manner. Some panels may require initial configuration done in LP, or configuration commands sent to a certain virtual channel ID.
The point is that we cannot have standard "MIPI DSI command mode panel driver" which would work for all DSI cmd mode panels, but we need (in the worst case) separate driver for each panel.
The same goes to lesser extent for other panels also. Some are configured via i2c or spi.
Tomi
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel