+ devicetree list and Mike T. for the clock aspect
Hi Tomi,
On 3/12/2012 2:45 PM, Tomi Valkeinen wrote:
Hi,
I'm struggling with the design of the DT data for OMAP display subsystem
driver, and any thoughts and ideas are welcome. This mail is a rather
long one, where I'm trying to show the different approaches I've
thought.
So the .dts format would be something like this, taking 4430SDP as an
example. It's just an outline, missing dispc, hwmods,
compatible-properties etc, which are not so relevant here.
ocp {
dss {
dsi1 {
taal {
};
};
};
};
So there we have a Taal panel, connected to DSI1 output interface, which
is part of the OMAP display subsystem.
One thing to note here is that although there's only one panel under
dsi1 in this case, the current SW supports having multiple panels under
one output interface. And while the output can support only one active
panel at a time, we do have boards where two panels are connected to one
output, and there's some kind of HW switch used to select which panel is
enabled.
The first problem here is that I don't know how to manage the switch
part. With current SW we have had the switch handling in the board
files, in functions called when a display is enabled/disabled. I guess
one option is to have the switch related code in their own drivers,
totally apart from the dss code, perhaps offering a sysfs interface or
such. And then, if the switch happens to be in the wrong position, the
panel will fail in some way.
DT is supposed to reflect the HW capability, so if you do have two
panels on a board, then both should be described in the DTS.
I'm just wondering if the multiple panels is something supported by the
DSI protocol or it is a HW hacks done on TI board only?
Maybe in that case the DSI mux HW will have to be represented in the DT
hierarchy as well.
The second problem is about the DT properties. With multiple panels it's
not possible to do this:
dsi1 {
dsi-ddr-clk =<250000000>;
taal {
};
some-other-panel {
};
};
because the panels could require different dsi clock rates. So we need
something like this:
dsi1 {
taal {
dsi-ddr-clk =<250000000>;
};
some-other-panel {
dsi-ddr-clk =<350000000>;
};
};
However, here the problem is that while ultimately we're interested in
the ddr-clk rate, calculation of the rate is non-trivial and may need
customizations at times. So instead of the clock rate we actually need
to define a bunch of dividers/multipliers.
Well, in theory you should not. This is up to the clock provider to
convert the clock rate in the proper n/m value. This is how it is done
for the regular OMAP DPLLs.
But these dividers are OMAP specific things, and do not belong to Taal
driver. So this bring the question: is the general rule about DT node
properties such that only the driver handling the particular node should
read the properties in that node? So, in the example above, should the
dsi driver only read props in the dsi1 and dsi2 nodes, and never look at
props in the taal nodes?
Yes, because the taal parameters should be relative to the Taal HW spec
that should not have a clue about the current DSI bus in used.
This is the clock provider that will have to handle that.
So basically, can we do this:
dsi1 {
taal {
omap-specific-clk-divs =<1 2 3 4 5 6 7>;
};
some-other-panel {
omap-specific-clk-divs =<7 6 5 4 3 2 1>;
};
};
and the Taal driver would ignore those, but dsi driver would use them?
This looks like quite easy solution to this, but also doesn't feel
right. So my current idea is to have clk-div tables in the dsi node,
something like this:
dsi1 {
omap-specific-clk-divs =<
250 1 2 3 4 5 6 7 /* divs that produce 250MHz clk */
350 7 6 5 4 3 2 1 /* divs that produce 350MHz clk */
>;
That's the idea, except that this will represent the clock provider.
taal {
dsi-ddr-clk =<250000000>;
And here you will have a phandle to the clock provider. And use it to
set the proper clock rate.
};
some-other-panel {
dsi-ddr-clk =<350000000>;
};
};
Here the panel drivers would ask the DSI driver to configure DSI DDR clk
of 250/350MHz, and the DSI driver would then use the lookup table to
find the dividers. If the lookup fails, the DSI driver could fail or try
to calculate the dividers itself. Other platforms could handle the DDR
clk configuration however they see best.
Grant was working on the clock device tree binding. I'm not sure it got
merged yet. But that should not there soon.
---
Another thing related to DSI command mode panels is the DSI lane
configuration, and I can't make my mind if they belong to the panel
driver in some way or not.
So, again taking SDP board and Taal as an example, we have 6 pads on
OMAP which are used for communicating with Taal. The pads need to be
muxed to DSI mode like any other OMAP pads. Currently the pad muxing is
not touched by the driver, but I think it's doable in the DSI driver (as
long as the DSI driver knows the required pad config).
However, that's not enough.
DSI uses differential pairs for communication (a "lane" consists of two
wires), and we have always one clock lane, and a number of data lanes.
In Taal's case we have a clock lane and two data lanes, which means 6
pads/wires.
We need to configure which of the OMAPs pads is used for which function,
so, for example, pad x and x+1 are used for clock lane, and x is the
negative pair and x+1 is the positive pair. And this configuration has
to match the wiring going to the panel, so that clk+ from OMAP goes to
clk+ in the panel.
So it dts data we need something, perhaps, like below. Here we define
the pad numbers and polarities in an array, where the first cell-pair is
for clk, then data1, then data2 and so on (if there are more than two
data lanes).
lanes =<
/* pad-pair number, polarity */
1 0 /* DSI pad pair 1 is used for clk, pol +/- */
2 1 /* DSI pad pair 2 is used for data1, pol -/+ */
0 0 /* DSI pad pair 0 is used for data2, pol +/- */
;
Now, I don't quite know where this data should be. If it's in the
dsi-node, it doesn't work with multiple panels.
Is the lane configuration only dependent of the panel?
But then, it's quite
OMAP specific thing. While other platforms probably need some kind of
pad configuration also, it may be something totally different. And so it
doesn't feel right in the taal-node either.
And a look-up table like in the clock case doesn't make much sense
either, as we don't have a key here, as we had in the clock case (the
dsi-ddr-clk).
The lane configuration code will belong to the DSI driver. The data will
belong to the panel. The panel might use some phandle to the various DSI
lane config a provide the needed information.
This look pretty similar to the pinmux device tree binding that is
currently under discussion.
So basically the only option I've come up with is to define the lane
configuration in the panel's data, and let the dsi driver peek there and
configure the HW. And this doesn't feel right.
This is fine, except for the last part. The panel driver should retrieve
the data from the panel node, and call some DSI configuration API using
the DSI phandle retrieved from the panel node as well or using the
parent node directly if the hierarchy is always the same.
You should have a look at pinmux and clock binding discussion. Even the
way GPIO binding is working should give you some hints.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
