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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
