Re: [RFC] New Device Tree property - "bonding"

Hi Ramesh,

On Tuesday 06 Dec 2016 15:41:06 Ramesh Shanmugasundaram wrote:

quoted

On Monday 05 Dec 2016 09:57:32 Rob Herring wrote:

quoted

On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart wrote:

quoted

On Monday 05 Dec 2016 08:18:34 Rob Herring wrote:

quoted

On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram wrote:

quoted

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.

Yes, as Laurent mentioned, the external master will be described separately.
The data interface with the master is described through port nodes. E.g.

        port {
                drif0_ep: endpoint {
                     remote-endpoint = <&tuner_ep>;
                };
        };

Do we agree on this model please?

That looks good to me.

quoted

quoted

quoted

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.

Can we use this "bonding" property as another way of grouping similar
devices? Should I make it generic instead of "renesas,bonding"?

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html