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
Attachment:
pgpCrX9Zefttv.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
