[RFC 0/3] solving omapdrm/omapdss layering issues

[Tomi Valkeinen]

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 at ti.com> 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 at ti.com> 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

-------------- 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/20120802/ca1d188c/attachment.pgp>