[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Tomi Valkeinen]

On 25/09/14 09:23, Thierry Reding wrote:

> How are cameras different? The CPU wants to capture video data from the
> camera, so it needs to go look for a video capture device, which in turn
> needs to involve a sensor.

Let's say we have an XXX-to-YYY encoder. We use that encoder to convert
the SoC's XXX output to YYY, which is then shown on a panel. So, in this
case, the encoder's DT node will have a "panel" or "output" phandle,
pointing to the panel.

We then use the exact same encoder in a setup in which we have a camera
which outputs XXX, which the encoder then converts to YYY, which is then
captured by the SoC. Here the "output" phandle would point to the SoC.

>>> If you go the other way around, how do you detect how things connect?
>>> Where do you get the information about the panel so you can trace back
>>> to the origin?
>>
>> When the panel driver probes, it registers itself as a panel and gets
>> its video source. Similarly a bridge in between gets its video source,
>> which often would be the SoC, i.e. the origin.
> 
> That sounds backwards to me. The device tree serves the purpose of
> supplementing missing information that can't be probed if hardware is
> too stupid. I guess that's one of the primary reasons for structuring it
> the way we do, from the CPU point of view, because it allows the CPU to
> probe via the device tree.
> 
> Probing is always done downstream, so you'd start by looking at some
> type of bus interface and query it for what devices are present on the
> bus. Take for example PCI: the CPU only needs to know how to access the
> host bridge and will then probe devices behind each of the ports on that
> bridge. Some of those devices will be bridges, too, so it will continue
> to probe down the hierarchy.
> 
> Without DT you don't have a means to know that there was a panel before
> you've actually gone and probed your whole hierarchy and found a GPU
> with some sort of output that a panel can be connected to. I think it
> makes a lot of sense to describe things in the same way in DT.

Maybe I don't quite follow, but it sounds to be you are mixing control
and data. For control, all you say is true. The CPU probes the devices
on control busses, either with the aid of HW or the aid of DT, going
downstream.

But the data paths are a different matter. The CPU/SoC may not even be
involved in the whole data path. You could have a sensor on the board
directly connected to a panel. Both are controlled by the CPU, but the
data path goes from the sensor to the panel (or vice versa). There's no
way the data paths can be "CPU centric" in that case.

Also, a difference with the data paths compared to control paths is that
they are not strictly needed for operation. An encoder can generate an
output without enabling its input (test pattern or maybe blank screen,
or maybe a screen with company logo). Or an encoder with two inputs
might only get the second input when the user requests a very high res
mode. So it is possible that the data paths are lazily initialized.

You do know that there is a panel right after the device is probed
according to its control bus. It doesn't mean that the data paths are
there yet. In some cases the user space needs to reconfigure the data
paths before a panel has an input and can be used to show an image from
the SoC's display subsystem.

The point here being that the data path bindings don't really relate to
the probing part. You can probe no matter which way the data path
bindings go, and no matter if there actually exists (yet) a probed
device on the other end of a data path phandle.

While I think having video data connections in DT either way, downstream
or upstream, would work, it has felt most natural for me to have the
phandles from video sinks to video sources.

The reason for that is that I think the video sink has to be in control
of its source. It's the sink that tells the source to start or stop or
reconfigure. So I have had need to get the video source from a video
sink, but I have never had the need to get the video sinks from video
sources.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141006/1ae24950/attachment.sig>