RE: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
Hi Rob, Geert, Laurent,
Thank you for the review comments.
> On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring wrote:
> > On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> >> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> >> > @@ -0,0 +1,136 @@
>
> >> > +Example
> >> > +
> >> > +
> >> > +SoC common dtsi file
> >> > +
> >> > + drif00: rif@e6f4 {
> >> > + compatible = "renesas,r8a7795-drif",
> >> > +"renesas,rcar-gen3-drif";
> >> > + reg = <0 0xe6f4 0 0x64>;
> >> > + interrupts = ;
> >> > + clocks = <&cpg CPG_MOD 515>;
> >> > + clock-names = "fck";
> >> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> >> > + dma-names = "rx", "rx";
> >
> > rx, rx? That doesn't make sense. While we don't explicitly disallow
> > this, I'm thinking we should. I wonder if there's any case this is
> > valid. If not, then a dtc check for this could be added.
>
> The device can be used with either dmac1 or dmac2.
> Which one is used is decided at run time, based on the availability of DMA
> channels per DMAC, which is a limited resource.
>
Yep.
> >> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> >> > + status = "disabled";
> >> > + };
> >> > +
> >> > + drif01: rif@e6f5 {
> >> > + compatible = "renesas,r8a7795-drif",
> >> > +"renesas,rcar-gen3-drif";
> >> > + reg = <0 0xe6f5 0 0x64>;
> >> > + interrupts = ;
> >> > + clocks = <&cpg CPG_MOD 514>;
> >> > + clock-names = "fck";
> >> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> >> > + dma-names = "rx", "rx";
> >> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> >> > + status = "disabled";
> >> > + };
> >> > +
> >> > + drif0: rif@0 {
> >> > + compatible = "renesas,r8a7795-drif",
> >> > +"renesas,rcar-gen3-drif";
> >> > + sub-channels = <&drif00>, <&drif01>;
> >> > + status = "disabled";
> >> > + };
> >>
> >> I'm afraid this really hurts my eyes, especially using the same
> >> compatible string for both the channel and sub-channel nodes.
> >>
> >> We need to decide how to model the hardware in DT. Given that the two
> >> channels are mostly independent having separate DT nodes makes sense
> >> to me. However, as they share the clock and sync signals, somehow
> >> grouping them makes sense. I see three ways to do so, and there might
> be more.
> >>
> >> 1. Adding an extra DT node for the channels group, with phandles to
> >> the two channels. This is what you're proposing here.
> >>
> >> 2. Adding an extra DT node for the channels group, as a parent of the
> >> two channels.
> >>
> >> 3. Adding phandles to the channels, pointing to each other, or
> >> possibly a phandle from channel 0 pointing to channel 1.
> >>
> >> Neither of these options seem perfect to me. I don't like option 1 as
> >> the group DT node really doesn't describe a hardware block. If we
> >> want to use a DT node to convey group information, option 2 seems
> >> better to me. However, it somehow abuses the DT parent-child model
> >> that is supposed to describe relationships from a control bus point
> >> of view. Option 3 has the drawback of not scaling properly, at least
> >> with phandles in both channels pointing to the other one.
> >>
> >> Rob, Geert, tell me you have a fourth idea I haven't thought of that
> >> would solve all those problems :-)
> >
> > What's the purpose/need for grouping them?
> >
> > I'm fine with Option 2, though I want to make sure it is really needed.
>
> Each half of a DRIF pair is basically an SPI slave controller without TX
> capability, sharing clock and chip-select between the two halves.
> Hence you can use either one half to receive 1 bit per clock pulse, or
> both halves to receive 2 bits per clock pulse.
> You cannot use both halves for independent operation due to the signal
> sharing.
Is the below model looks OK? I assume this is Option 2. Any preferences on the
"parent" compatible string please?
-
drif0: rif@0 {
compatible = "renesas,rcar-gen3-drif", "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
status = "disabled";
drif00: rif@e6f4 {
compatible = "renesas,r8a7795-drif",
"renesas,rcar-gen3-drif";
reg = <0 0xe6f4 0 0x64>;
interrupts = ;
clocks = <&cpg CPG_MOD 515>;
clock-names = "fck
Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
Hi Rob,
On Mon, Nov 14, 2016 at 8:52 PM, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
>> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> > @@ -0,0 +1,136 @@
>> > +Example
>> > +
>> > +
>> > +SoC common dtsi file
>> > +
>> > + drif00: rif@e6f4 {
>> > + compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f4 0 0x64>;
>> > + interrupts = ;
>> > + clocks = <&cpg CPG_MOD 515>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
>> > + dma-names = "rx", "rx";
>
> rx, rx? That doesn't make sense. While we don't explicitly disallow
> this, I'm thinking we should. I wonder if there's any case this is
> valid. If not, then a dtc check for this could be added.
The device can be used with either dmac1 or dmac2.
Which one is used is decided at run time, based on the availability of
DMA channels per DMAC, which is a limited resource.
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif01: rif@e6f5 {
>> > + compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > + reg = <0 0xe6f5 0 0x64>;
>> > + interrupts = ;
>> > + clocks = <&cpg CPG_MOD 514>;
>> > + clock-names = "fck";
>> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
>> > + dma-names = "rx", "rx";
>> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
>> > + status = "disabled";
>> > + };
>> > +
>> > + drif0: rif@0 {
>> > + compatible = "renesas,r8a7795-drif",
>> > +"renesas,rcar-gen3-drif";
>> > + sub-channels = <&drif00>, <&drif01>;
>> > + status = "disabled";
>> > + };
>>
>> I'm afraid this really hurts my eyes, especially using the same compatible
>> string for both the channel and sub-channel nodes.
>>
>> We need to decide how to model the hardware in DT. Given that the two
>> channels
>> are mostly independent having separate DT nodes makes sense to me. However,
>> as
>> they share the clock and sync signals, somehow grouping them makes sense. I
>> see three ways to do so, and there might be more.
>>
>> 1. Adding an extra DT node for the channels group, with phandles to the two
>> channels. This is what you're proposing here.
>>
>> 2. Adding an extra DT node for the channels group, as a parent of the two
>> channels.
>>
>> 3. Adding phandles to the channels, pointing to each other, or possibly a
>> phandle from channel 0 pointing to channel 1.
>>
>> Neither of these options seem perfect to me. I don't like option 1 as the
>> group DT node really doesn't describe a hardware block. If we want to use a
>> DT
>> node to convey group information, option 2 seems better to me. However, it
>> somehow abuses the DT parent-child model that is supposed to describe
>> relationships from a control bus point of view. Option 3 has the drawback of
>> not scaling properly, at least with phandles in both channels pointing to the
>> other one.
>>
>> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
>> solve all those problems :-)
>
> What's the purpose/need for grouping them?
>
> I'm fine with Option 2, though I want to make sure it is really needed.
Each half of a DRIF pair is basically an SPI slave controller without TX
capability, sharing clock and chip-select between the two halves.
Hence you can use either one half to receive 1 bit per clock pulse,
or both halves to receive 2 bits per clock pulse.
You cannot use both halves for independent operation due to the signal
sharing.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote: > Hi Ramesh, > > Thank you for the patch. > > On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote: > > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs. > > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF > > device represents a channel and each channel can have one or two > > sub-channels respectively depending on the target board. > > > > DRIF supports only Rx functionality. It receives samples from a RF > > frontend tuner chip it is interfaced with. The combination of DRIF and the > > tuner device, which is registered as a sub-device, determines the receive > > sample rate and format. > > > > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with > > the tuner device, which can be provided by a third party vendor. DRIF acts > > as a slave device and the tuner device acts as a master transmitting the > > samples. The driver allows asynchronous binding of a tuner device that > > is registered as a v4l2 sub-device. The driver can learn about the tuner > > it is interfaced with based on port endpoint properties of the device in > > device tree. The V4L2 SDR device inherits the controls exposed by the > > tuner device. > > > > The device can also be configured to use either one or both of the data > > pins at runtime based on the master (tuner) configuration. > > > > Signed-off-by: Ramesh Shanmugasundaram > > --- > > .../devicetree/bindings/media/renesas,drif.txt | 136 ++ > > drivers/media/platform/Kconfig | 25 + > > drivers/media/platform/Makefile|1 + > > drivers/media/platform/rcar_drif.c | 1574 > > 4 files changed, 1736 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt > > create mode 100644 drivers/media/platform/rcar_drif.c > > > > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt > > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode > > 100644 > > index 000..d65368a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt > > @@ -0,0 +1,136 @@ > > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) > > + > > + > > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master > > +device as shown below > > + > > ++-++-+ > > +| |-SCK--->|CLK | > > +| Master|-SS>|SYNC DRIFn (slave) | > > +| |-SD0--->|D0 | > > +| |-SD1--->|D1 | > > ++-++-+ > > + > > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1). > > +The sub-channels are like two individual channels in itself that share the > > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like > > +irq, dma channels, address space & clock. > > + > > +The device tree model represents the channel and each of it's sub-channel > > +as a separate node. The parent channel ties the sub-channels together with > > +their phandles. > > + > > +Required properties of a sub-channel: > > +- > > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of > > R8A7795 SoC. > > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible > > device. > > + When compatible with the generic version, nodes must list the > > + SoC-specific version corresponding to the platform first > > + followed by the generic version. > > +- reg: offset and length of that sub-channel. > > +- interrupts: associated with that sub-channel. > > +- clocks: phandle and clock specifier of that sub-channel. > > +- clock-names: clock input name string: "fck". > > +- dmas: phandles to the DMA channel of that sub-channel. > > +- dma-names: names of the DMA channel: "rx". > > + > > +Optional properties of a sub-channel: > > +- > > +- power-domains: phandle to the respective power domain. > > + > > +Required properties of a channel: > > +- > > +- pinctrl-0: pin control group to be used for this channel. > > +- pinctrl-names: must be "default". > > +- sub-channels : phandles to the two sub-channels. > > + > > +Optional properties of a channel: > > +- > > +- port: child port node of a channel that defines the local and remote > > +endpoints. The remote endpoint is assumed to be a tuner subdevice > > + endpoint. > > +- renesas,syncmd : sync mode > > +0 (Frame start sync pulse mode. 1-bit width pulse > > + indicates start of a frame) > >
RE: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
Hi Hans, Thanks for the review comments. > Subject: Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support > > On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote: > > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 > SoCs. > > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF > > device represents a channel and each channel can have one or two > > sub-channels respectively depending on the target board. > > > > DRIF supports only Rx functionality. It receives samples from a RF > > frontend tuner chip it is interfaced with. The combination of DRIF and > > the tuner device, which is registered as a sub-device, determines the > > receive sample rate and format. > > > > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with > > the tuner device, which can be provided by a third party vendor. DRIF > > acts as a slave device and the tuner device acts as a master > > transmitting the samples. The driver allows asynchronous binding of a > > tuner device that is registered as a v4l2 sub-device. The driver can > > learn about the tuner it is interfaced with based on port endpoint > > properties of the device in device tree. The V4L2 SDR device inherits > > the controls exposed by the tuner device. > > > > The device can also be configured to use either one or both of the > > data pins at runtime based on the master (tuner) configuration. > > > > Signed-off-by: Ramesh Shanmugasundaram > > > > --- > > .../devicetree/bindings/media/renesas,drif.txt | 136 ++ > > drivers/media/platform/Kconfig | 25 + > > drivers/media/platform/Makefile|1 + > > drivers/media/platform/rcar_drif.c | 1574 > > > 4 files changed, 1736 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/media/renesas,drif.txt > > create mode 100644 drivers/media/platform/rcar_drif.c > > > > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt > > b/Documentation/devicetree/bindings/media/renesas,drif.txt > > new file mode 100644 > > index 000..d65368a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt > > @@ -0,0 +1,136 @@ > > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) > > + > > + > > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master > > +device as shown below > > + > > ++-++-+ > > +| |-SCK--->|CLK | > > +| Master|-SS>|SYNC DRIFn (slave) | > > +| |-SD0--->|D0 | > > +| |-SD1--->|D1 | > > ++-++-+ > > + > > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & > drifn1). > > +The sub-channels are like two individual channels in itself that > > +share the common CLK & SYNC. Each sub-channel has it's own dedicated > > +resources like irq, dma channels, address space & clock. > > + > > +The device tree model represents the channel and each of it's > > +sub-channel as a separate node. The parent channel ties the > > +sub-channels together with their phandles. > > + > > +Required properties of a sub-channel: > > +- > > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of > R8A7795 SoC. > > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible > device. > > + When compatible with the generic version, nodes must list the > > + SoC-specific version corresponding to the platform first > > + followed by the generic version. > > +- reg: offset and length of that sub-channel. > > +- interrupts: associated with that sub-channel. > > +- clocks: phandle and clock specifier of that sub-channel. > > +- clock-names: clock input name string: "fck". > > +- dmas: phandles to the DMA channel of that sub-channel. > > +- dma-names: names of the DMA channel: "rx". > > + > > +Optional properties of a sub-channel: > > +- > > +- power-domains: phandle to the respective power domain. > > + > > +Required properties of a channel: > > +--
Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote: > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs. > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF > device represents a channel and each channel can have one or two > sub-channels respectively depending on the target board. > > DRIF supports only Rx functionality. It receives samples from a RF > frontend tuner chip it is interfaced with. The combination of DRIF and the > tuner device, which is registered as a sub-device, determines the receive > sample rate and format. > > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with > the tuner device, which can be provided by a third party vendor. DRIF acts > as a slave device and the tuner device acts as a master transmitting the > samples. The driver allows asynchronous binding of a tuner device that > is registered as a v4l2 sub-device. The driver can learn about the tuner > it is interfaced with based on port endpoint properties of the device in > device tree. The V4L2 SDR device inherits the controls exposed by the > tuner device. > > The device can also be configured to use either one or both of the data > pins at runtime based on the master (tuner) configuration. > > Signed-off-by: Ramesh Shanmugasundaram > > --- > .../devicetree/bindings/media/renesas,drif.txt | 136 ++ > drivers/media/platform/Kconfig | 25 + > drivers/media/platform/Makefile|1 + > drivers/media/platform/rcar_drif.c | 1574 > > 4 files changed, 1736 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt > create mode 100644 drivers/media/platform/rcar_drif.c > > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt > b/Documentation/devicetree/bindings/media/renesas,drif.txt > new file mode 100644 > index 000..d65368a > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt > @@ -0,0 +1,136 @@ > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) > + > + > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master > +device as shown below > + > ++-++-+ > +| |-SCK--->|CLK | > +| Master|-SS>|SYNC DRIFn (slave) | > +| |-SD0--->|D0 | > +| |-SD1--->|D1 | > ++-++-+ > + > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1). > +The sub-channels are like two individual channels in itself that share the > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like > +irq, dma channels, address space & clock. > + > +The device tree model represents the channel and each of it's sub-channel > +as a separate node. The parent channel ties the sub-channels together with > +their phandles. > + > +Required properties of a sub-channel: > +- > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 > SoC. > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible > device. > + When compatible with the generic version, nodes must list the > + SoC-specific version corresponding to the platform first > + followed by the generic version. > +- reg: offset and length of that sub-channel. > +- interrupts: associated with that sub-channel. > +- clocks: phandle and clock specifier of that sub-channel. > +- clock-names: clock input name string: "fck". > +- dmas: phandles to the DMA channel of that sub-channel. > +- dma-names: names of the DMA channel: "rx". > + > +Optional properties of a sub-channel: > +- > +- power-domains: phandle to the respective power domain. > + > +Required properties of a channel: > +- > +- pinctrl-0: pin control group to be used for this channel. > +- pinctrl-names: must be "default". > +- sub-channels : phandles to the two sub-channels. > + > +Optional properties of a channel: > +- > +- port: child port node of a channel that defines the local and remote > +endpoints. The remote endpoint is assumed to be a tuner subdevice > + endpoint. > +- renesas,syncmd : sync mode > + 0 (Frame start sync pulse mode. 1-bit width pulse > + indicates start of a frame) > + 1 (L/R sync or I2S mode) (default) > +- renesas,lsb-first: empty property indicates lsb bit is received first. > + When not defined msb bit is received first (default) > +- renesas,syncac-pol-high : empty property indicates sync signal polar
Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
Hi Ramesh, Thank you for the patch. On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote: > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs. > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF > device represents a channel and each channel can have one or two > sub-channels respectively depending on the target board. > > DRIF supports only Rx functionality. It receives samples from a RF > frontend tuner chip it is interfaced with. The combination of DRIF and the > tuner device, which is registered as a sub-device, determines the receive > sample rate and format. > > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with > the tuner device, which can be provided by a third party vendor. DRIF acts > as a slave device and the tuner device acts as a master transmitting the > samples. The driver allows asynchronous binding of a tuner device that > is registered as a v4l2 sub-device. The driver can learn about the tuner > it is interfaced with based on port endpoint properties of the device in > device tree. The V4L2 SDR device inherits the controls exposed by the > tuner device. > > The device can also be configured to use either one or both of the data > pins at runtime based on the master (tuner) configuration. > > Signed-off-by: Ramesh Shanmugasundaram > --- > .../devicetree/bindings/media/renesas,drif.txt | 136 ++ > drivers/media/platform/Kconfig | 25 + > drivers/media/platform/Makefile|1 + > drivers/media/platform/rcar_drif.c | 1574 > 4 files changed, 1736 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt > create mode 100644 drivers/media/platform/rcar_drif.c > > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode > 100644 > index 000..d65368a > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt > @@ -0,0 +1,136 @@ > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) > + > + > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master > +device as shown below > + > ++-++-+ > +| |-SCK--->|CLK | > +| Master|-SS>|SYNC DRIFn (slave) | > +| |-SD0--->|D0 | > +| |-SD1--->|D1 | > ++-++-+ > + > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1). > +The sub-channels are like two individual channels in itself that share the > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like > +irq, dma channels, address space & clock. > + > +The device tree model represents the channel and each of it's sub-channel > +as a separate node. The parent channel ties the sub-channels together with > +their phandles. > + > +Required properties of a sub-channel: > +- > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of > R8A7795 SoC. > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible > device. > + When compatible with the generic version, nodes must list the > + SoC-specific version corresponding to the platform first > + followed by the generic version. > +- reg: offset and length of that sub-channel. > +- interrupts: associated with that sub-channel. > +- clocks: phandle and clock specifier of that sub-channel. > +- clock-names: clock input name string: "fck". > +- dmas: phandles to the DMA channel of that sub-channel. > +- dma-names: names of the DMA channel: "rx". > + > +Optional properties of a sub-channel: > +- > +- power-domains: phandle to the respective power domain. > + > +Required properties of a channel: > +- > +- pinctrl-0: pin control group to be used for this channel. > +- pinctrl-names: must be "default". > +- sub-channels : phandles to the two sub-channels. > + > +Optional properties of a channel: > +- > +- port: child port node of a channel that defines the local and remote > +endpoints. The remote endpoint is assumed to be a tuner subdevice > + endpoint. > +- renesas,syncmd : sync mode > + 0 (Frame start sync pulse mode. 1-bit width pulse > + indicates start of a frame) > + 1 (L/R sync or I2S mode) (default) > +- renesas,lsb-first: empty property indicates lsb bit is received > first. > + When not defined msb bit is received first (default) Shouldn't those two properties be
