Hi Rob, On Monday 05 Dec 2016 09:57:32 Rob Herring wrote: > On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote: > > On Monday 05 Dec 2016 08:18:34 Rob Herring wrote: > >> On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote: > >>> Hello DT maintainers, > >>> > >>> In one of the Renesas SoCs we have a device called DRIF (Digital Radio > >>> Interface) controller. A DRIF channel contains 4 external pins - SCK, > >>> SYNC, Data pins D0 & D1. > >>> > >>> Internally a DRIF channel is made up of two SPI slave devices (also > >>> called sub-channels here) that share common CLK & SYNC signals but have > >>> their own resource set. The DRIF channel can have either one of the > >>> sub-channel active at a time or both. When both sub-channels are active, > >>> they need to be managed together as one device as they share same CLK & > >>> SYNC. We plan to tie these two sub-channels together with a new property > >>> called "renesas,bonding". > >> > >> Is there no need to describe the master device? No GPIOs, regulators > >> or other sideband controls needed? If that's never needed (which seems > >> doubtful), then I would do something different here probably with the > >> master device as a child of one DRIF and then phandles to master from > >> the other DRIFs. Otherwise, this looks fine to me. > > > > Here's a bit of background. > > > > The DRIF is an SPI receiver. It has three input pins, a clock line, a data > > line and a sync signal. The device is designed to be connected to a > > variety of data sources, usually plain SPI (1 data line), IIS (1 data > > line) but also radio tuners that output I/Q data > > (http://www.ni.com/tutorial/4805/en/) over two data lines. > > > > In the case of IQ each data sample is split in two I and Q values > > (typically 16 to 20 bits each in this case), and the values are > > transmitted serially over one data line each. The synchronization and > > clock signals are common to both data lines. The DRIF is optimized for > > this use case as the DRIF instances in the SoC (each of them having > > independent clocks, interrupts and control registers) are grouped by two, > > and the two instances in a group handle a single data line each but share > > the same clock and sync input. > > > > On the software side we need to group the I and Q values, which are DMA'ed > > to memory by the two DRIF instances, and make them available to > > userspace. The V4L2 API used here in SDR (Software Defined Radio) mode > > supports such use cases and exposes a single device node to userspace > > that allows control of the two DRIF instances as a single device. To be > > able to implement this we need kernel code to be aware of DRIF groups > > and, while binding to the DRIF instances separately, expose only one V4L2 > > device to userspace for each group. > > > > There's no master or slave instance from a hardware point of view, but the > > two instances are not interchangeable as they carry separate information. > > They must thus be identified at the driver level. > > By master, I meant the external master device that generates the IQ > data, not which of the internal DRIF blocks is a master of the other. > So back to my question, does the external master device need to be > described? I worry the answer now for a simple case is no, but then > later people are going to have cases needing to describe more. We need > to answer this question first before we can decide what this binding > should look like. Oh yes the external device certainly needs to be described. As it is controlled through a separate, general-purpose I2C or SPI controller, it should be a child node of that controller. The DRIF handles the data interface only, not the control interface of the external device. > > Back to the DT bindings, the need to expose relationships between (mostly) > > independent devices is quite common nowadays. It has been solved in some > > cases by creating a separate DT node that does not correspond to any > > physical hardware and whose sole purpose is to contain phandles to > > devices that need to be grouped. Drivers then bind to the compatible > > string of that "virtual" DT node. The proposed bonding property is a > > different approach to solve a similar problem. Would it be worth it > > addressing the problem at a more general level and try to design a common > > solution ? > > We already have somewhat standard ways of grouping, but they are per > type of device (display, sound card, etc.). I'm not sure we gain much > standardizing across these devices and to some extent that ship has > sailed. Even within display subsystems, I don't think there is one > style that fits all. Sometimes a parent subsystem node with children > makes sense for the h/w. Sometimes that doesn't make sense and we have > the virtual node with a "ports" property (like sun8i did). I've never > been too happy with that style largely just because it feels like > we're letting DRM define the binding. However, it's generally extra > data that an OS could just ignore. There have also been many display > bindings that started out with a virtual node and we got rid of it. So > it's not something I like to encourage and we need to be clear when it > is okay or not. > > To state the problem more generally (at least when using OF graph), I > think the problem is simply how do we define and group multiple entry > points to an OF graph. Maybe these should be graph nodes themselves > rather than phandles to the nodes with the entry points of the graph. CC'ing Maxime Ripard for the sun8i side. -- Regards, Laurent Pinchart -- 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
