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

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

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.

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.

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

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]