On Wed, 12 Mar 2014 10:25:56 +0000, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Mon, Mar 10, 2014 at 02:52:53PM +0100, Laurent Pinchart wrote: > > In theory unidirectional links in DT are indeed enough. However, let's not > > forget the following. > > > > - There's no such thing as single start points for graphs. Sure, in some > > simple cases the graph will have a single start point, but that's not a > > generic rule. For instance the camera graphs > > http://ideasonboard.org/media/omap3isp.ps and > > http://ideasonboard.org/media/eyecam.ps have two camera sensors, and thus two > > starting points from a data flow point of view. > > I think we need to stop thinking of a graph linked in terms of data > flow - that's really not useful. > > Consider a display subsystem. The CRTC is the primary interface for > the CPU - this is the "most interesting" interface, it's the interface > which provides access to the picture to be displayed for the CPU. Other > interfaces are secondary to that purpose - reading the I2C DDC bus for > the display information is all secondary to the primary purpose of > displaying a picture. > > For a capture subsystem, the primary interface for the CPU is the frame > grabber (whether it be an already encoded frame or not.) The sensor > devices are all secondary to that. > > So, the primary software interface in each case is where the data for > the primary purpose is transferred. This is the point at which these > graphs should commence since this is where we would normally start > enumeration of the secondary interfaces. > > V4L2 even provides interfaces for this: you open the capture device, > which then allows you to enumerate the capture device's inputs, and > this in turn allows you to enumerate their properties. You don't open > a particular sensor and work back up the tree. > > I believe trying to do this according to the flow of data is just wrong. > You should always describe things from the primary device for the CPU > towards the peripheral devices and never the opposite direction. Agreed. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
