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@xxxxxxxxxxxxxxx/msg09037.html
None of the models discussed are convincing. This new property proposal is closest to option 3 discussed in the thread.
--
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
