On 2012-10-31 15:13, Laurent Pinchart wrote:
>> OMAP SoC
>> ========
>>
>> So here's first the SoC specific display nodes. OMAP has a DSS (display
>> subsystem) block, which contains the following elements:
>>
>> - DISPC (display controller) reads the pixels from memory and outputs
>> them using specified video timings. DISPC has three outputs, LCD0, LCD1
>> and TV. These are SoC internal outputs, they do not go outside the SoC.
>>
>> - DPI gets its data from DISPC's LCD0, and outputs MIPI DPI (parallel
>> RBG)
>>
>> - Two independent DSI modules, which get their data from LCD0 or LCD1,
>> and output MIPI DSI (a serial two-way video bus)
>>
>> - HDMI, gets data from DISPC's TV output and outputs HDMI
>>
>> / {
>> ocp {
>> dss {
>> dispc {
>> dss-lcd0: output@0 {
>> };
>>
>> dss-lcd1: output@1 {
>> };
>>
>> dss-tv: output@2 {
>> };
>> };
>>
>> dpi: dpi {
>> video-source = <&dss-lcd0>;
>> };
>>
>> dsi0: dsi@0 {
>> video-source = <&dss-lcd0>;
>> };
>>
>> dsi1: dsi@1 {
>> video-source = <&dss-lcd1>;
>> };
>>
>> hdmi: hdmi {
>> video-source = <&dss-tv>;
>> };
>> };
>> };
>> };
>>
>> I have defined all the relevant nodes, and video-source property is used
>> to point to the source for video data. I also define aliases for the SoC
>> outputs so that panels can use them.
>>
>> One thing to note is that the video sources for some of the blocks, like
>> DSI, are not hardcoded in the HW, so dsi0 could get its data from LCD0
>> or LCD1.
>
> What about the source that are hardwired in hardware ? Shouldn't those be
> hardcoded in the driver instead ?
Even if both the DSI and the DISPC are parts of OMAP DSS, and part of
the SoC, they are separate IPs. We should look at them the same way we'd
consider chips that are outside the SoC.
So things that are internal to a device can (and I think should) be
hardcoded in the driver, but integration details, the connections
between the IPs, etc, should be described in the DT data.
Then again, we do have (and need) a driver for the "dss" node in the
above DT data. This dss represents dss_core, a "glue" IP that contains
the rest of the DSS blocks and muxes and such. It could be argued that
this dss_core driver does indeed know the integration details, and thus
there's no need to represent them in the DT data.
However, I do think that we should represent the DISPC outputs with
generic display entities inside CPF, just like DSI and the panels. And
we do need to set the connections between these entities. So the
question is, do we get those connections from the DT data, or are they
hardcoded in the dss_core driver.
I don't currently have strong opinions on either direction. Both make
sense to me. But I think this is SoC driver implementation specific, and
the common panel framework doesn't need to force this to either
direction. Both should be possible from CPF's point of view.
>> However, I don't think they are usually changed during runtime, and the dss
>> driver cannot change them independently for sure (meaning that some upper
>> layer should tell it how to change the config). Thus I specify sane defaults
>> here, but the board dts files can of course override the video sources.
>
> I'm not sure whether default settings like those really belong to the DT. I'm
> no expert on that topic though.
I agree. But I also don't have a good solution how the driver would find
good choices for these settings...
>> Another thing to note is that we have more outputs from OMAP than we have
>> outputs from DISPC. This means that the same video source is used by
>> multiple sinks (LCD0 used by DPI and DSI0). DPI and DSI0 cannot be used at
>> the same time, obviously.
>
> It might not be really obvious, as I don't see what prevents DPI and DSI0 to
> be used at the same time :-) Do they share physical pins ?
I think they do, but even if they didn't, there's just one source for
two outputs. So if the SoC design is such that the only video source for
DPI is LCD0, and the only video source for DSI0 is LCD0, and presuming
you can't send the video data to both destinations, then only one of DPI
and DSI0 can be enabled at the same time.
Even if the LCD0 could send the pixel stream to both DPI and DSI0, it'd
be "interesting", because the original video timings and pixel clock are
programmed in the LCD0 output, and thus both DPI and DSI0 get the same
timings. If DPI would want to use some other mode, DSI would most likely
go nuts.
So my opinion is that we should only allow 1:1 connections between
sources and sinks. If a component has multiple outputs, and even if
those outputs give the exact same data, it should define multiple sources.
>> And third thing to note, DISPC node defines outputs explicitly, as it has
>> multiple outputs, whereas the external outputs do not as they have only one
>> output. Thus the node's output is implicitly the node itself. So, instead of
>> having:
>>
>> ds0: dsi@0 {
>> video-source = <&dss-lcd0>;
>> dsi0-out0: output@0 {
>> };
>> };
>>
>> I have:
>>
>> dsi0: dsi@0 {
>> video-source = <&dss-lcd0>;
>> };
>
> What about defining the data sinks instead of the data sources ? I find it
> more logical for the DSS to get the panel it's connected to than the other way
> around.
Good question. We look at this from different angles. Is the DSS
connected to the panel, or is the panel connected to the DSS? ;)
I see this the same way than, say, regulators. We have a device and a
driver for it, and the driver wants to use a hw resource. If the
resource is a regulator, the DT data for the device will contain a
reference to the regulator. The driver will then get the regulator, and
use it to operate the device.
Similarly for the display devices. We have a driver for a, say, i2c
device. The DT data for that device will contain a reference to the
source for the video data. The driver for the device will then use this
reference to enable/disable/etc the video stream (i.e. operate the device).
The regulators don't even really know anything about the users of the
regulators. Somebody just "gets" a regulator and enables it. The same
should work for display entities also. There's no need for the video
source to know anything about the sink.
So looking at a chain like:
DISPC -> DPI -> Panel
I see the component on the right side using the component on its left.
And thus it makes sense to me to have references from right to left,
i.e. panel has reference to DPI, etc.
Also, it makes sense with DT data files. For example, for omap4 we'll
have omap4.dtsi, which describes common omap4 details. This file would
contain the omap dss nodes. Then we have omap4-panda.dts, which includes
omap4.dtsi. omap4-panda.dts contains data for the displays on this
board. Thus we have something like:
omap4.dtsi:
dss {
dsi0: dsi@0 {
...
};
};
omap4-panda.dts:
/ {
panel {
video-source = <&dsi0>;
};
};
So it comes out quite nicely. If we had the references the other way
around, omap4-panda.dts would need to have the panel definition, and
also override the dsi0 node from omap4.dtsi, and set the sink to the panel.
I have to say we've had this mind-set with omapdss for a long time, so I
may be a bit blind to other alternative. Do you have any practical
examples how linking the other way around would be better?
>> Of this I'm a bit unsure. I believe in most cases there's only one output,
>> so it'd be nice to have a shorter representation, but I'm not sure if it's
>> good to handle the cases for single and multiple outputs differently. Or if
>> it's good to mix control and data busses, as, for example, dsi0 can be used
>> as both control and data bus. Having the output defined explicitly would
>> separate the control and data bus nodes.
>>
>>
>> Simple DPI panel
>> ================
>>
>> Here a board has a DPI panel, which is controlled via i2c. Panel nodes
>> are children of the control bus, so in this case we define the panel
>> under i2c2.
>>
>> &i2c2 {
>> dpi-lcd-panel {
>> video-source = <&dpi>;
>>
>> };
>> };
>>
>>
>> HDMI
>> ====
>>
>> OMAP has a HDMI output, but it cannot be connected directly to an HDMI
>> cable. TI uses tpd12s015 chip in its board, which provides ESD,
>> level-shifting and whatnot (I'm an SW guy, google for the chip to read
>> the details =). tpd12s015 has a few GPIOs and powers that need to be
>> controlled, so we need a driver for it.
>>
>> There's no control bus for the tpd12s015, so it's platform device. Then
>> there's the device for the HDMI monitor, and the DDC lines are connected
>> to OMAP's i2c4, thus the hdmi monitor device is a child of i2c.
>>
>> / {
>> hdmi-connector: tpd12s015 {
>> video-source = <&hdmi>;
>> };
>> };
>>
>> &i2c4 {
>> hdmi-monitor {
>> video-source = <&hdmi-connector>;
>> };
>> };
>
> So this implied we would have the following chain ?
>
> DISPC (on SoC) -> HDMI (on SoC) -> TPD12S015 (on board) -> HDMI monitor (off
> board)
Yes.
Although to be honest, I'm not sure if the TPD12S015 should be part of
the chain, or somehow separate. It's so simple, kinda pass-through IP,
that it would be nicer to have the HDMI monitor connected to the OMAP
HDMI. But this is omap specific question, not really CPF thing.
> Should we then have a driver for the HDMI monitor ?
Yes, that is my opinion:
- It would be strange if for some video chains we would have panel
devices in the end of the chain, and for some we wouldn't. I guess we'd
need some trickery to make them both work the same way if there's no
panel devices for some cases.
- While in 99% of the cases we can use a common, simple HDMI monitor
driver, there could be HDMI monitors with special features. We could
detect this monitor by reading the EDID and if it's this special case,
use a specific driver for it instead of the common HDMI driver. This is
perhaps not very likely with HDMI, but I could imagine eDP panels with
special features.
So I imagine that we could use hot-plug here. The HDMI monitor device
would not exist until a HDMI cable is connected. The SoC's HDMI driver
(or whatever is before the HDMI monitor in the chain) gets a hotplug
interrupt, and it would then add the device, which would then trigger
probe of the corresponding HDMI monitor driver.
Actually, thinking about this, what I said in the above paragraph
wouldn't work. The SoC's HDMI driver can't know what kind of device to
create, unless we have a HDMI bus and HDMI devices. Which, I think, we
shouldn't have, as HDMI monitors are usually controlled via i2c, and
thus the HDMI monitors should be i2c devices.
So I don't really know how this hotplug would work =). It's just an
idea, not a scenario I have at hand.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
