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

[Thierry Reding]

On Wed, Sep 24, 2014 at 12:08:37PM +0300, Tomi Valkeinen wrote:
> On 23/09/14 17:58, Thierry Reding wrote:
> 
> >> But if a panel driver controls its video source, it makes sense for the
> >> panel driver to get its video source in its probe, and that happens
> >> easiest if the panel has a link to the video source.
> > 
> > That's an orthogonal problem. You speak about the link in software here,
> > whereas the phandles only represent the link in the description of
> > hardware. Now DT describes hardware from the perspective of the CPU, so
> > it's sort of like a cave that you're trying to explore. You start at the
> > top with the address bus, from where a couple of tunnels lead to the
> > various peripherals on the address bus. A display controller might have
> > another tunnel to a panel, etc.
> 
> We don't do that for GPIOs, regulators, etc. either. And for video data
> there are no address buses. Yes, for DSI and similar we have a control
> bus, but that is modeled differently than the video data path.

GPIOs and regulators are just auxiliary devices that some other device
needs to operate. For instance if you want to know how to operate the
GPIO or regulator, the same still applies. You start from the CPU and
look up the GPIO controller and then the index of the GPIO within that
controller. For regulators you'd typically go and look for an I2C bus
that has a PMIC, which will expose the regulator.

Now for a device such as a display panel, what you want to do is control
the display panel. If part of how you control it involves toggling a
GPIO or a regulator, then you get access to those via phandles. And then
controlling the GPIO and regulator becomes the same as above. So it's a
matter of compositing devices in that case.

For the video data you use the phandles to model the path that video
data takes, with all the devices in that path chained together. So while
both approaches use the same mechanism (phandle) to describe the
relationships, the nature of the relationships is quite different.

> Now, I'm fine with starting from the CPU, going outwards. I agree that
> it's probably better to model it in the direction of the data stream,
> even if that would make the SW a bit more complex.
> 
> However, I do think it's not as clear as you make it sound, especially
> if we take cameras/sensors into account as Laurent explained elsewhere
> in this thread.

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.

It isn't so much about following the data stream itself, but rather the
connections between devices that the CPU needs to involve in order to
initiate the data flow.

> > 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.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/51dcebb2/attachment.sig>