On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: > On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: > >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > > >> > I guess the fact is that DRM concepts do not really match the OMAP DSS > >> > hardware, and we'll have to use whatever gives us least problems. > >> > >> Actually, I think it does map fairly well to the hardware.. at least > >> more so than to omapdss ;-) > > > > Hm, I'm not sure I understand, omapdss concepts map directly to the > > hardware. > > I think it is mainly exposing the encoder and panel as two separate > entities.. which seems to be what Archit is working on I still don't follow =) They are separate entities. Omapdss models the HW quite directly, I think. It doesn't expose everything, though, as the output drivers (dsi.c, dpi.c etc) are used via the panel drivers. > in case of something like DVI bridge from DPI, this seems pretty > straightforward.. only the connector needs to know about DDC stuff, > which i2c to use and that sort of thing. So at kms level we would > have (for example) an omap_dpi_encoder which would be the same for DPI > panel (connector) or DPI->DVI bridge. For HDMI I'm still looking > through the code to see how this would work. Honestly I've looked > less at this part of code and encoder related registers in the TRM, > compared to the ovl/mgr parts, but at least from the 'DSS overview' > picture in the TRM it seems to make sense ;-) > > KMS even exposes the idea that certain crtcs can connect to only > certain encoders. Or that you could you could have certain connectors > switched between encoders. For example if you had a hw w/ DPI out, > and some mux to switch that back and forth between a DPI lcd panel and > a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does > this, but it is in theory possible.) So we could expose possible > video chain topologies to userspace in this way. OMAP3 SDP board has such a setup, with manual switch to select between LCD and DVI. > The other thing is that we don't need to propagate timings from the > panel up to the mgr at the dss level.. kms is already handling this > for us. In my latest version, which I haven't pushed, I removed the > 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. You're thinking only about simple DPI cases. Consider this example, with a DSI-to-DP bridge chip. What we have is the following flow of data: DISPC -> DSI -> DSI-2-DP -> DP monitor The timings you are thinking about are in the DISPC, but here they are only one part of the link. And here the DISPC timings are not actually the timings what the user is interested about. The user wants his timings to be between DSI-2-DP chip and the DP monitor. Timings programmed to DISPC are not the same. The timings for DISPC come from the DSI driver, and they may be very different than the user's timings. With DSI video mode, the DISPC timings would have some resemblance to the user's timings, mainly the time to send one line would be the same. With DSI cmd mode, the DISPC timings would be something totally different, most likely with 0 blank times and as fast pixel clock as possible. What omapdss does currently is that you set the user's timings to the right side of the chain, which propagate back to DSS. This allows the DSI-2-DP bridge use DSI timings that work optimally for the bridge, and DSI driver will use DISPC timings that work optimally for it. And it's not only about timings above, but also other settings related to the busses between the components. Clock dividers, polarities, stuff like that. > I think the problem was there were some cases, like ovl updates before > setting the mgr, where the user_info_dirty flag would be cleared but > the registers not updated. This is what I meant by sequence of Hmm, I'd appreciate more info about this if you can give. Sounds like a bug, that shouldn't happen. So you mean that you have an ovl, with no manager set. And you change the settings of the ovl before assigning it to a mgr? That's something I haven't really tested, so it could bug, true. > operations at KMS level confusing omapdss. This should be fixable > with some debugging. Although getting rid of the state tracking at > omapdss level altogether was a much simpler solution, and is the one I > prefer :-) Yes, I don't prefer the state tracking either (we didn't have it in earlier versions of omapdss), but I still don't see an option to it if we want to support all the stuff we have. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
