Re: [RFC 00/22] OMAPDSS: DT support

Hi Tomi,

On Monday 02 September 2013 11:00:15 Tomi Valkeinen wrote:

On 22/08/13 00:07, Laurent Pinchart wrote:

Thanks for the comments!

You're welcome.

quoted

quoted

The exception to the above are DSI and DBI. DSI and DBI are combined
control and video busses, but the use of the busses for control purposes
is not independent of the video stream. Also, the the busses are, in
practice, one-to-one links. And last, DSI and DBI display entities are
often also controllable via, say, i2c. For these reasons there is no
real Linux bus for DSI and DBI and thus the DSI and DBI devices are
either platform devices or i2c devices.

That's something I'm less convinced about, but I don't have a too strong
feeling. The best implementation should get to mainline, I won't nack this
architecture just for theoretical reasons.

Ok. I posted a response to your DBI bus patch about the issues I see.

I'll reply in that mail thread then.

quoted

quoted

DSI Module ID
=============

On OMAP4 we have two DSI modules. To configure the clock routing and pin
muxing, we need to know the hardware module ID for the DSI device, i.e.
is this Linux platform device DSI1 or DSI2. The same issue exists with
other SoCs with multiple outputs of the same kind.

With non-DT case, we used the platform device's ID directly. With DT,
that doesn't work. I don't currently have a good solution for this, so as
a temporary solution the DSI driver contains a table, from which it can
find the HW module ID by using the device's base address.

You could add two output ports to the DSS, one for each DSI, and link the
DSI modules to the DSS output ports in DT. That would represent the
hardware topology, and would allow the DSI driver to know its ID based on
the DSS output port it's connected to. It's still a bit hackish in the
sense that the DSI driver will use information provided by the DSS (the
output port number), but not more than the current method.

Hmm, yep. That's kind of the same as having an explicit 'module-id'
property in the DSI node. I had implemented that solution at some point,
but considered it too ugly. But I agree that deducing the module-id from
the DSS output port is a bit cleaner, as it doesn't need any special
properties. And it's maybe also better than the address table I have
now, as the address table requires special code for each SoC.

I have to try the V4L2 ports to understand fully how to use them.

Feel free to ask questions :-)

In the end, I hope to get rid of the module-id totally. It's really not
a DSI-thing at all. The DSI hardware does not use the module-id for
anything, it's more about how the DSI module is glued in the DSS/SoC.

quoted

quoted

I have some ideas how to deduce the DSS version by poking to certain DSS
registers, but it is not yet tested so I don't know if it will work.

That might be a stupid question, but can't you just encode the version in
the compatible string of the DSS DT node (the one currently compatible
with "ti,omap[34]-dss") ?

That would require having separate DT files for each revision. For
example, we have Beagle boards with different OMAP reversions.

It's fine to have the version encoded in the compatible string for major
versions, but having all minor revisions encoded there could result in a
mess.

Obviously if you can detect the version at runtime that would be best. Let's 
see if that can be done and then decide on what solution to implement.

quoted

Version information might also need to be split/duplicated in several of
the DSS DT nodes. A quick grep through the driver source code shows that
the version is used by the submodules to infer SoC glue information. For
instance dsi_get_channel() uses the version to find the DSI module
channel ID. That information could possibly be retrieved from the links
between the DSS DT nodes.

Hmm, yes. Well. The DISPC has multiple output channels: LCD, LCD2, LCD3,
TV (depending on the SoC). These outputs go to encoders, and the routing
can be configured. If we consider only DSI encoders on OMAP4, the LCD2
output can be configured to go to DSI1 or DSI2 modules. LCD1 output can
be configured to go to DSI1 (but not to DSI2).

Because the routing has restrictions like mentioned above, it's somewhat
difficult to allocate the DISPC output channels during runtime in a
totally dynamic manner. Say, if we happened to allocate LCD2 for DSI1,
and later we'd want to use DSI2, there would be no DISPC output to use.

That's why we currently have them hardcoded in the driver, and it works
ok in all the use cases we have now. However, some board could need to
setup the channels in some other way for some particular use case.

So, I'm not totally comfortable with hardcoding the DISPC output - DSS
encoder connections in the DT data. While it'd work for most cases, it
doesn't work for all.

Encoding them in the device tree, in the driver(s), or computing them at 
runtime in the kernel are all suboptimal solutions. If the connections are 
configurable we want to expose that to userspace and let userspace configure 
the device. That's not possible yet due to API limitations, so we need to 
handle the situation on the kernel side. I'm thus fine with hardcoding this in 
the driver for now, DT should not encode more than possible connections, it 
shouldn't cary the default configuration.

Then again, if the connections in the DT data would be considered more
like a default set of connections, and they could be changed later from
the kernel/userspace, then it'd be fine.

quoted

quoted

Some of the DSS modules are actually a combination of multiple smaller
modules. For example, the DSI module contains DSI protocol, DSI PHY and
DSI PLL modules, each in their own address space. These could perhaps be
presented as separate DT nodes and Linux devices, but I am not sure if
that is a good approach or not.

What are the chances that one of those block will be upgraded and/or
replaced independently of the others in the future (I know it's a tricky
question) ? It might not be worth it going to a too fine-grained approach
at the moment, but we need to make sure that the DT bindings will allow
an easy path forward if needed.

For DSI, I believe the chances are quite small. But for HDMI, we already
have this case for OMAP4 and OMAP5, and we're currently working on
splitting the HDMI core, PHY and PLL properly. I think it makes sense to
do the same for DSI also at the same time, especially as the PLL for DSI
and HDMI is the same (afaik).

Yes, then it's a good idea.

quoted

quoted

If we shouldn't add the bindings as unstable, when should the bindings be
added? Wait until CDF is in the mainline, and use that?

What about using the CDF bindings, without waiting for CDF to be in
mainline ? I believe the bindings should be upstreamed as unstable to
start with anyway.

Yes, I think that makes sense. And that's what I've been aiming at. I'm
just missing the ports-stuff.

Then again, I see opinions that the old bindings should be supported (e.g.
the mails with Tony in this same thread). If so, using CDF bindings without
CDF being in the mainline is a bit risky, as the bindings could well change.

But it's less risky than using custom bindings, isn't it ? :-)

-- 
Regards,

Laurent Pinchart