On 23/09/14 08:53, Thierry Reding wrote: >> Yes, it's true we need a mux there. But we still have the complication >> that for panel0 we may need different ps8622 settings than for panel1. > > Yes, and that's why the bridge should be querying the panel for the > information it needs to determine the settings. That only works if the settings to be queried are standard ones. But, for example, let's say that the board is designed in a way that for panel0 the bridge needs to output a bit higher level voltages than for panel1. That's not a property of the panel, so it can't be queried from the panel. That feature (varying the voltage level) is specific to the bridge, and thus the properties should be in the bridge's DT data. So we need two different configurations in the bridge, one for panel0 and one for panel1. This is what endpoints give us. >> If that's the case, then I think we'd need to have two output endpoints >> in ps8622, both going to the mux, and each having the settings for the >> respective panel. > > But we'd be lying in DT. It no longer describes the hardware properly. > The device only has a single input and a single output with no means to > mux anything. Hence the device tree shouldn't be faking multiple inputs > or outputs. No, a port is a single physical output. An endpoint is a logical entity on that single physical output. So a bridge with a single output has one output port, but it may have as many endpoints on that port as needed. Only one endpoint of a port can be active at a time. > I don't think we need to have a common way to describe video devices. In > my opinion DT bindings are much better if they are specifically tailored > towards the device that they describe. We'll provide a driver for that > device anyway, so we should be creating appropriate abstractions at the > OS level to properly handle them. I disagree. If we don't have a common way to describe the connections between video devices, we cannot: - have a common helper library to parse the connections - study the connections before the drivers are loaded - handle the connections anywhere else than the specific driver for the component > To stay with the example of the board/display, I'd think that the final > component of the board DT would implement a bridge. The first component > of the display DT would similarly implement a bridge. Now if we have a > way of chaining bridges and controlling a chain of bridges, then there > is no need for anything more complex than a plain phandle in a property > from the board bridge to the display bridge. Right, that works for many cases. Of course, nothing says there's a bridge on the main board, it could be connected directly to the SoC. >>> Whether this is described using a single phandle to the bridge or a more >>> complicated graph is irrelevant. What matters is that you get a phandle >>> to the bridge. The job of the operating system is to give drivers a way >>> to resolve that phandle to some object and provide an API to access that >>> object. >> >> I agree it's not relevant whether we use a simple phandle or complex >> graph. What matter is that we have a standard way to express the video >> paths, which everybody uses. > > Not necessarily. Consistency is always good, but I think simplicity > trumps consistency. What matters isn't how the phandle is referenced in > the device tree, what matters is that it is referenced and that it makes > sense in the context of the specific device. Anything else is the job of > the OS. > > While there are probably legitimate cases where the video graph is > useful and makes sense, in many cases terms like ports and endpoints are > simply confusing. I again agree that I'd like to have a simpler representation than video graphs for the simpler use cases. But again, I think it's important to have a standard representation for those connections. Why do you think it wouldn't be good to have a standard for the simpler connections (in addition to the video graphs)? What kind of device specific variations do you see that would be needed? Even if the points I gave about why a common way to describe connections is important would not be relevant today, it sounds much safer to have a standard representation in the DT for the connections. I'd only go for device specific custom descriptions if there's a very important reason for that. And I can't come up with any reason. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
