On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > Hi Tomi, > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be > used for non-panel devices (at least in theory). The future mipi-dsi-bus > certainly will.
They are both display busses. So while they could be used for anything, I find it quite unlikely as there are much better alternatives for generic bus needs. > Would you be able to send incremental patches on top of v2 to implement the > solution you have in mind ? It would be neat if you could also implement mipi- > dsi-bus for the OMAP DSS and test the code with a real device :-) Yes, I'd like to try this out on OMAP, both DBI and DSI. However, I fear it'll be quite complex due to the dependencies all around we have in the current driver. We're working on simplifying things so that it'll be easier to try thing like the panel framework, though, so we're going in the right direction. > > Generally about locks, if we define that panel ops may only be called > > exclusively, does it simplify things? I think we can make such > > requirements, as there should be only one display framework that handles > > the panel. Then we don't need locking for things like enable/disable. > > Pushing locking to callers would indeed simplify panel drivers, but we need > to > make sure we won't need to expose a panel to several callers in the future. I have a feeling that would be a bad idea. Display related stuff are quite sensitive to any delays, so any extra transactions over, say, DSI bus could cause a noticeable glitch on the screen. I'm not sure what are all the possible ops that a panel can offer, but I think all that affect the display or could cause delays should be handled by one controlling entity (drm or such). The controlling entity needs to handle locking anyway, so in that sense I don't think it's an extra burden for it. The things that come to my mind that could possibly cause calls to the panel outside drm: debugfs, sysfs, audio, backlight. Of those, I think backlight should go through drm. Audio, no idea. debugfs and sysfs locking needs to be handled by the panel driver, and they are a bit problematic as I guess having them requires full locking. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120820/02d5305e/attachment.pgp>
