On Thu, Oct 17, 2013 at 02:50:31PM +0300, Tomi Valkeinen wrote: > On 17/10/13 14:05, Thierry Reding wrote: > > >> That's quite similar to how my current out-of-mainline OMAP DSS DT > >> bindings work. The difference is that I have a reference from the panel > >> node to the video source (dsi-controller), instead of the other way > >> around. I just find it more natural. It works the same way as, say, > >> regulators, gpios, etc. > > > > I suppose that depends on the way you look at it. In the above proposal > > I consider the output (DSI controller) to use the panel as a resource > > that provides a certain set of services (query mode timings, provide a > > way to enable or disable the panel). Similarly the panel uses the > > backlight as a resource that provides a certain set of services (such as > > changing the brightness). > > > > The above also follows the natural order of control. The panel has no > > way to control the DSI output. However, it is the output that controls > > when a panel is required and turn it on as appropriate. > > I've discussed this issue to death with other people, and for some > reason I still see this the other way =). > > I see the panel using the DSI controller as a resource. The panel driver > uses the DSI controller to send the video data to the panel device. > Compare this to, say, i2c client driver, which uses i2c master to send > data to the i2c device. > > In the OMAP DSS driver model, the panel driver is in control. The panel > driver tells the DSI controller which kind of video timings to use, or > which bus speed to use, or whether to use low-power or high-speed mode, > when to enable the DSI clock or DSI video stream, etc. > > With a simple panel the model you describe works usually fine. The > reason I went with the different model is that we had rather complex > display peripherals, that needed more specific control of the bus. > > A simple example could be the enable sequence. I presume in your model > the DSI controller's enable would be maybe something like: > > configure_dsi_timings(panel->get_timings()); > enable_dsi_output(); > panel->enable(); > > What if the DSI peripheral requires an enable sequence of, say: > > - enable DSI clock > - use LP mode > - send some config messages > - re-configure DSI clock to higher speed > - send some more config messages > - enable HS mode > - send some more config messages > - enable DSI video stream > > It gets a bit difficult to manage that kind of setup in a generic way in > the DSI controller driver. As I see it, the DSI peripheral driver has to > be in control of the nuances. The same goes for other video buses also, > but DSI is perhaps one of the most complex ones to support. I've briefly gone over this in another subthread, but here it is again for the sake of completeness. The difference in perception I think comes from the fact that the DSI panel *driver* may need to control the DSI bus. However, DT describes the hardware in terms of devices. And from that point of view it is still the DSI _control_ler that _control_s the panel. There's no electrical way that the panel can take possession of the bus. Well, there's BTA, but even that happens under supervision of the DSI controller. Thierry
Attachment:
pgpDZ71yq_jYo.pgp
Description: PGP signature
