[RFC] New Device Tree property - "bonding"

[RFC] New Device Tree property - "bonding"

[Ramesh Shanmugasundaram]

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".

We would appreciate your feedback on this regard. Below is an example usage of this property. 

SoC common dtsi file:
---------------------
"renesas,bonding" - phandles to similar devices that are part of the bond. A bond between devices implies that they need to be managed together and cannot operate independently when more than one member of the bond needs to be active. 

                drif00: rif@e6f40000 {
                        compatible = "renesas,r8a7795-drif",
                                     "renesas,rcar-gen3-drif";
                        reg = <0 0xe6f40000 0 0x64>;
                        interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
                        clocks = <&cpg CPG_MOD 515>;
                        clock-names = "fck";
                        dmas = <&dmac1 0x20>, <&dmac2 0x20>;
                        dma-names = "rx", "rx";
                        renesas,bonding = <&drif01>;
                        power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
                        status = "disabled";

                };

                drif01: rif@e6f50000 {
                        compatible = "renesas,r8a7795-drif",
                                     "renesas,rcar-gen3-drif";
                        reg = <0 0xe6f50000 0 0x64>;
                        interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
                        clocks = <&cpg CPG_MOD 514>;
                        clock-names = "fck";
                        dmas = <&dmac1 0x22>, <&dmac2 0x22>;
                        dma-names = "rx", "rx";
                        renesas,bonding = <&drif00>;
                        power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
                        status = "disabled";
                };

Board specific dts file:
-------------------------
- When more than one member of the "bonding" property are available, another keyword ("primary" or "bonded" or ??) is expected on any one of the members. This "primary" member controls/accepts properties common to all members.

- When only a single member of the bond needs to be active, the "bonding" property has no effect.

Note: "primary" keyword is found in "http://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf" Page 103, Line 10. It looks like a generic property but documentation is not available. 

E.g.
1) Both channels enabled case:
------------------------------------
&drif00 {
        pinctrl-0 = <&drif0_pins>;
        pinctrl-names = "default";
        renesas,syncac-pol-high;
        status = "okay";

        primary; /* This can be changed to "renesas,primary or renesas,bonded or ??" */

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

&drif01 {
        status = "okay";
};

2) Single channel enabled case:
-------------------------------
&drif01 {
        pinctrl-0 = <&drif0_pins>;
        pinctrl-names = "default";
        status = "okay";

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


Thanks,
Ramesh.

Note 1:
--------
Below is a pictorial representation of E.g. (1) and (2)

A DRIF channel can interface with a Master device like this

1) Master with two data pins - both sub-channels used
+---------------------+                +---------------------+
|                     |-----SCK------->|CLK                  |   
|       Master        |-----SS-------->|SYNC  DRIFn (slave)  |
|                     |-----SD0------->|D0                   |   
|                     |-----SD1------->|D1                   |   
+---------------------+                +---------------------+

2) Master with one data pin - sub-channel0 or 1 can be used based on the board.
Below is e.g. where sub-channel1 alone is used. D0 pin is unused.

+---------------------+                +---------------------+
|                     |-----SCK------->|CLK                  |   
|       Master        |-----SS-------->|SYNC  DRIFn (slave)  |
|                     |-----SD0------->|D1                   |   
|                     |                |                     |   
+---------------------+                +---------------------+

Note 2:
--------
This topic is discussed as part of the driver submission. The latest on that is here - 
https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg09037.html

None of the models discussed are convincing. This new property proposal is closest to option 3 discussed in the thread.

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

[Rob Herring]

On Fri, Nov 25, 2016 at 10:55 AM, Ramesh Shanmugasundaram
<ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> 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.

Rob
--
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

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

[Laurent Pinchart]

Hi Rob,

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.

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 ?

-- 
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

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

[Rob Herring]

On Mon, Dec 5, 2016 at 8:40 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Rob,
>
> 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.

> 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.

Rob

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

[Laurent Pinchart]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ramesh Shanmugasundaram]

Hi Rob, Laurent,

Thanks for the response.

> 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.

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?

>
> > > 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"?

Thanks,
Ramesh


[https://www2.renesas.eu/media/email/unicef.gif]

This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
--
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

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

[Rob Herring]

On Tue, Dec 6, 2016 at 9:41 AM, Ramesh Shanmugasundaram
<ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> wrote:
> Hi Rob, Laurent,
>
> Thanks for the response.
>
>> 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.
>
> 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?

Well, that's not complete as you should have both DRIF0 and DRIF1
having connections to the tuner. Then you can walk the graph and find
everything, and you then don't need the bonding property.

Rob
--
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

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

[Ramesh Shanmugasundaram]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 6188 bytes --]

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.
> >
> > 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?
>
> Well, that's not complete as you should have both DRIF0 and DRIF1 having
> connections to the tuner. Then you can walk the graph and find everything,
> and you then don't need the bonding property.

Assuming the third party tuner exposes it's two data lines as two endpoints, it seems possible with of_graph.h apis to walk through tuner end points and get the phandle of the other DRIF device. However, there are couple of points coming to mind.

- The ctrl pins shared between two DRIFs needs to be enabled in one of the DRIF device. Do we choose this device arbitrarily? Do we expose the CTRL signal properties (msb/lsb first, polarity etc) on both DRIF devices? Should we think about scalability?

- It mandates the third party tuner device to expose it's two data lines as two endpoints. It assumes that a single third party master device controls both the data lines coming to each DRIF device.

The bonding property looks a bit cleaner on these aspects because it describes only the DRIF device.

Thanks,
Ramesh





[https://www2.renesas.eu/media/email/unicef.gif]

This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i

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

[Geert Uytterhoeven]

On Tue, Dec 6, 2016 at 6:45 PM, Ramesh Shanmugasundaram
<ramesh.shanmugasundaram@bp.renesas.com> wrote:
>> >> 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.
>> >
>> > 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?
>>
>> Well, that's not complete as you should have both DRIF0 and DRIF1 having
>> connections to the tuner. Then you can walk the graph and find everything,
>> and you then don't need the bonding property.
>
> Assuming the third party tuner exposes it's two data lines as two endpoints, it seems possible with of_graph.h apis to walk through tuner end points and get the phandle of the other DRIF device. However, there are couple of points coming to mind.
>
> - The ctrl pins shared between two DRIFs needs to be enabled in one of the DRIF device. Do we choose this device arbitrarily? Do we expose the CTRL signal properties (msb/lsb first, polarity etc) on both DRIF devices? Should we think about scalability?
>
> - It mandates the third party tuner device to expose it's two data lines as two endpoints. It assumes that a single third party master device controls both the data lines coming to each DRIF device.
>
> The bonding property looks a bit cleaner on these aspects because it describes only the DRIF device.

Does of_graph and endpoints need to be mandatory?

I can easily imagine using a single DRIF device as a receive-only MSIOF SPI
slave, without a tuner connected.

Cfr. spi-slave-system-control from my SPI skave mode support series
(https://lwn.net/Articles/700433/).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Ramesh Shanmugasundaram]

Hello 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.
> > >
> > > 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?
> >
> > Well, that's not complete as you should have both DRIF0 and DRIF1
> > having connections to the tuner. Then you can walk the graph and find
> > everything, and you then don't need the bonding property.
> 
> Assuming the third party tuner exposes it's two data lines as two
> endpoints, it seems possible with of_graph.h apis to walk through tuner
> end points and get the phandle of the other DRIF device. However, there
> are couple of points coming to mind.
> 
> - The ctrl pins shared between two DRIFs needs to be enabled in one of the
> DRIF device. Do we choose this device arbitrarily? Do we expose the CTRL
> signal properties (msb/lsb first, polarity etc) on both DRIF devices?
> Should we think about scalability?
> 
> - It mandates the third party tuner device to expose it's two data lines
> as two endpoints. It assumes that a single third party master device
> controls both the data lines coming to each DRIF device.
> 
> The bonding property looks a bit cleaner on these aspects because it
> describes only the DRIF device.

Shall we please conclude on the model? Are you happy with the use of "renesas,bonding" property if the concern is on pushing this as a generic property?

I would appreciate your feedback.

Thanks,
Ramesh

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

[Laurent Pinchart]

Hi Ramesh,

On Tuesday 06 Dec 2016 15:41:06 Ramesh Shanmugasundaram wrote:
> > 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.
> 
> 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.

> >>> 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