On Fri, Aug 3, 2012 at 1:01 AM, Semwal, Sumit [off-list ref] wrote:

Hi Rob, Tomi,
On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark [off-list ref] wrote:

quoted

On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen [off-list ref] wrote:

quoted

On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote:

quoted

On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen [off-list ref] wrote:

quoted

On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote:

quoted

On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen [off-list ref] wrote:

quoted

quoted

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.

right.. so we just need to expose the output drivers as separate
entities, and let omapdrm propagate information such as timings
between them

quoted

quoted

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.

ahh, good to know.. so I'm not crazy for wanting to expose this
possibility to userspace

quoted

quoted

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.

hmm, well kms already has a concept of adjusted_timings, which could
perhaps be used here to propagate the timings between crtc->encoder..
although the order is probably backwards from what we want (it comes
from the crtc to the encoder.. and if I understand properly we want it
the other way and actually possibly from the connector).  But that
isn't to say that internally in omapdrm the crtc couldn't get the
adjusted timings from the connector.  So I still think the parameter
flow doesn't need to be 'under the hood' in omapdss.

And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper
fxns, so if the way the core kms handles it isn't what we want, we can
just plug in our own fxn instead of using drm_crtc_helper_set_mode(),
so that isn't really a big problem.

quoted

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 expect we could handle other settings in the same way as the timings.

quoted

quoted

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.

quoted

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.

well, we do have to do state tracking *somewhere*.. I just prefer to
do it only in one layer instead of two ;-)

Let me add a little more to the 'boiling pot' ;) - what about
writeback? Writeback, from DSS perspective, is an integral part of the
DSS offering, is needed for many compelling use cases, and needs to
sync with the overlays and the managers (depending on mode) for state
information.

As such, Omapdss needs to worry about the way writeback is structured,
and the way it interacts with the other entities in the system.

Even though AFAIK DRM doesn't provide a capture mechanism to help
support writeback through omapdrm, we still need to provide a clean
way to use the writeback path with the display ones that we've talked
about here till now.

well, first: all the fancy features in the world don't matter if
fundamental use cases like multi-layer updates don't work.

but that said, writeback doesn't strictly change anything.
Configuring the input side of writeback (ie input to dss) *must* be
done through drm in order to not bypass the authentication mechanism
in drm.  We can't have non-authenticated clients configuring things so
that the contents of the screen get written back to memory, that is a
security hole.  After that, you maybe just need to provide some fxns
for the (presumably v4l capture) interface can configure the output
side of WB.  I guess this is roughly analogous to how hdmi audio
works.  It could be that we register a v4l2 driver within omapdrm, or
that we export some fxns that a v4l2 driver outside of omapdrm can
use.  Probably we should look at how hdmi audio and alsa hook together
in other drivers to see what the right precedent is to follow.

BR,
-R

quoted

BR,
-R

Best,
~Sumit.

quoted

quoted

 Tomi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html