On 20/03/14 19:01, Grant Likely wrote: > I think depending on a generic graph walk is where I have the biggest > concern about the design. I don't think it is a good idea for the master > device to try a generic walk over the graph looking for other devices > that might be components because it cannot know whether or not further > links are relevant, or even if other endpoint nodes in the target > hierarchy actually conform to the graph binding in the same way. > > Consider the example of a system with two video controllers (one > embedded and one discrete), a display mux, and a panel. The display > controller depends on the mux, and the mux depends on the panel. It > would be entirely reasonable to start up the display subsystem with the > embedded controller without the discrete adapter being available, but > the way the current graph pattern is proposed there is no dependency > information between the devices. For some reason I don't understand this master and dependency way of thinking. I just can't twist my brain to it, please help me =). With the setup you describe above, why does the video controller depend on the mux, and why it is the master? Why the DMA engine does not depend on the embedded video controller, and why is the DMA engine not the master? With the setup above, what are we really interested in? It's the display, right? We want to have the display working, with resolution and video timings that work for the display. The mux and the display controllers are just necessary evils to make the display work. The display depends on the mux to provide it a video stream. The mux depends on the two video controllers to provide the mux two video streams. The video controllers depend (possibly) on SoC's DMA, or PCI bus to provide them video data. And if we consider the same setup as above, but the mux has two exclusive outputs, it again works fine with the dependency I described. If you want to enable panel 1, you'll depend on mux and video controllers, but not on panel 2. So you can leave the panel 2 driver out and things still work ok. But note that I don't think this dependency has strict relation to the DT graph representation, see below. > I really do think the dependency direction needs to be explicit so that > a driver knows whether or not a given link is relevant for it to start, I think that comes implicitly from the driver, it doesn't need to be described in the DT. If a device has an input port, and the device is configured to use that input port, the device depends on whatever is on the other side of the input port. The device driver must know that. Somehow a device driver needs to find if the driver behind its input ports are ready. It could use the links in DT directly, if they are supplied in that direction, or it could rely on someone else parsing the DT, and exposing the information via some API. I think it's simpler for the SW to follow the links directly, but that would mean having the links in the opposite direction than the data flow, which feels a bit odd to me. > and there must be driver know that knows how to interpret the target > node. A device that is a master needs to know which links are > dependencies, and which are not. Well, again, I may not quite understand what the master means here. But for me, the display is the master of the pipeline. The driver for the display is the one that has to decide what kind of video signal is acceptable, how the signal must be enabled, and disabled, etc. When someone (the master's master =) tells the panel to enable itself, the panel needs to use an API to configure and enable its input ports. The devices on the other end of the input ports then configure and enable their inputs. And so on. Anyway, I do think this is more of a SW organization topic than how we should describe the hardware. As I see it, the parent-child relationships in the DT describe the control paths and the graph describes the data paths. Having the data paths described in the direction of data flow (or double-linked in case of bi-dir link) sounds logical to me, but I think the inverse could work fine too. But using some kind of CPU centric direction doesn't sound very usable, it makes no sense for cases with peripheral-to-peripheral links, and the control bus already describes the CPU centric direction in cases where there exists a clear CPU-to-peripheral direction. > I'm not even talking about the bi-directional link issue. This issue > remains regardless of whether or not bidirectional links are used. > > I would solve it in one of the following two ways: > > 1) Make masters only look at one level of dependency. Make the component > driver responsible for checking /its/ dependencies. If its dependencies > aren't yet met, then don't register the component as ready. We could > probably make the drivers/base/component code allow components to pull > in additional components as required. This approach shouldn't even > require a change to the binding and eliminates any need for walking the > full graph. > > 2) Give the master node an explicit list of all devices it depends on. I > don't like this solution as much, but it does the job. I'd suggest the first one (without the "masters" part, which I don't quite follow, and presuming the component's inputs are its dependencies...). Each device driver should only check its dependencies. If this happens by using the DT data, then the easiest way is to have the graph links go opposite to data-flow. But I think it should work fine with data-flow direction also. Each driver would register itself, including it's outputs. After that, the components behind the outputs can find their inputs via an API. However, that prevents us from using EPROBE_DEFER to handle missing inputs. However, I do think it could be useful in some cases to observe the whole pipeline, even the components that have not been loaded. It could be used to, say, decide which modules to load when a particular output needs to be enabled. I'm not sure how important such feature is, though. And I don't really see why we should forbid that. If the graph bindings are standard, we can reliably follow the links to form an image of the whole graph. Of course, the component doing that should not look at the properties of the ports or endpoints, as those are private to the node in question, but it could follow the graph and find out if a node has a driver available, and in those cases maybe get more information via an API. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
