* [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-11 20:17 ` Bhavya Kapoor
0 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-11 20:17 UTC (permalink / raw)
To: linux-kernel, devicetree
Cc: b-kapoor, linux-arm-kernel, conor+dt, krzk+dt, robh, kristo,
vigneshr, nm
CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
brought on the evm through headers J42, J43 and J46 respectively. Thus,
add their respective transceiver's 0, 1 and 2 dt nodes to add support
for these CAN instances.
CAN instance 4 in the main domain is brought on the evm through header
J45. The CAN High and Low lines from the SoC are routed through a mux
on the evm. The select lines need to be set for the CAN signals to
reach to its transceiver on the evm. Therefore, add transceiver 3
dt node to add support for this CAN instance.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
---
rebased to next-20240411
arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index 81fd7afac8c5..e56901973895 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
};
};
};
+
+ transceiver0: can-phy0 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
+ standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
+ };
+
+ transceiver1: can-phy1 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
+ standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ transceiver2: can-phy2 {
+ /* standby pin has been grounded by default */
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ };
+
+ transceiver3: can-phy3 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
+ mux-states = <&mux1 1>;
+ };
+
+ mux1: mux-controller {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
+ };
};
&wkup_gpio0 {
@@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>;
};
+
+ main_mcan4_pins_default: main-mcan4-default-pins {
+ pinctrl-single,pins = <
+ J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
+ J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
+ >;
+ };
+
+ main_mcan16_pins_default: main-mcan16-default-pins {
+ pinctrl-single,pins = <
+ J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
+ J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
+ >;
+ };
};
&wkup_pmx2 {
@@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>;
};
+
+ mcu_mcan0_pins_default: mcu-mcan0-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
+ J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
+ >;
+ };
+
+ mcu_mcan1_pins_default: mcu-mcan1-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
+ J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
+ >;
+ };
+
+ mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
+ >;
+ };
+
+ mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
+ >;
+ };
};
&wkup_pmx1 {
@@ -1105,3 +1184,31 @@ dp0_out: endpoint {
};
};
};
+
+&mcu_mcan0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan0_pins_default>;
+ phys = <&transceiver0>;
+};
+
+&mcu_mcan1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan1_pins_default>;
+ phys = <&transceiver1>;
+};
+
+&main_mcan16 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan16_pins_default>;
+ phys = <&transceiver2>;
+};
+
+&main_mcan4 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan4_pins_default>;
+ phys = <&transceiver3>;
+};
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-11 20:17 ` Bhavya Kapoor
0 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-11 20:17 UTC (permalink / raw)
To: linux-kernel, devicetree
Cc: b-kapoor, linux-arm-kernel, conor+dt, krzk+dt, robh, kristo,
vigneshr, nm
CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
brought on the evm through headers J42, J43 and J46 respectively. Thus,
add their respective transceiver's 0, 1 and 2 dt nodes to add support
for these CAN instances.
CAN instance 4 in the main domain is brought on the evm through header
J45. The CAN High and Low lines from the SoC are routed through a mux
on the evm. The select lines need to be set for the CAN signals to
reach to its transceiver on the evm. Therefore, add transceiver 3
dt node to add support for this CAN instance.
Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
---
rebased to next-20240411
arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index 81fd7afac8c5..e56901973895 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
};
};
};
+
+ transceiver0: can-phy0 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
+ standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
+ };
+
+ transceiver1: can-phy1 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
+ standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ transceiver2: can-phy2 {
+ /* standby pin has been grounded by default */
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ };
+
+ transceiver3: can-phy3 {
+ compatible = "ti,tcan1042";
+ #phy-cells = <0>;
+ max-bitrate = <5000000>;
+ standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
+ mux-states = <&mux1 1>;
+ };
+
+ mux1: mux-controller {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
+ };
};
&wkup_gpio0 {
@@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>;
};
+
+ main_mcan4_pins_default: main-mcan4-default-pins {
+ pinctrl-single,pins = <
+ J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
+ J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
+ >;
+ };
+
+ main_mcan16_pins_default: main-mcan16-default-pins {
+ pinctrl-single,pins = <
+ J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
+ J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
+ >;
+ };
};
&wkup_pmx2 {
@@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>;
};
+
+ mcu_mcan0_pins_default: mcu-mcan0-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
+ J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
+ >;
+ };
+
+ mcu_mcan1_pins_default: mcu-mcan1-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
+ J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
+ >;
+ };
+
+ mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
+ >;
+ };
+
+ mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
+ pinctrl-single,pins = <
+ J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
+ >;
+ };
};
&wkup_pmx1 {
@@ -1105,3 +1184,31 @@ dp0_out: endpoint {
};
};
};
+
+&mcu_mcan0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan0_pins_default>;
+ phys = <&transceiver0>;
+};
+
+&mcu_mcan1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_mcan1_pins_default>;
+ phys = <&transceiver1>;
+};
+
+&main_mcan16 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan16_pins_default>;
+ phys = <&transceiver2>;
+};
+
+&main_mcan4 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan4_pins_default>;
+ phys = <&transceiver3>;
+};
--
2.40.1
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
2024-04-11 20:17 ` Bhavya Kapoor
@ 2024-04-15 5:12 ` Kumar, Udit
-1 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-04-15 5:12 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, u-kumar1
Hello Bhavya,
On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
> brought on the evm through headers J42, J43 and J46 respectively. Thus,
> add their respective transceiver's 0, 1 and 2 dt nodes to add support
> for these CAN instances.
Looking at schematic and board data sheet, it appears, board has 6 CAN
interfaces.
[J41--J46], but we are enabling only 4.
I understand, other interfaces might be used for other purpose.
Vignesh/Nishanth,
Do you think, this make sense to code all available interfaces on board and
mark as reserved, if used for other purpose , similar to what is done
for wkup_uart for this board.
> CAN instance 4 in the main domain is brought on the evm through header
> J45. The CAN High and Low lines from the SoC are routed through a mux
> on the evm. The select lines need to be set for the CAN signals to
> reach to its transceiver on the evm. Therefore, add transceiver 3
> dt node to add support for this CAN instance.
>
> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
> ---
>
> rebased to next-20240411
>
> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> index 81fd7afac8c5..e56901973895 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
> };
> };
> };
> +
> + transceiver0: can-phy0 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
> + };
> +
> + transceiver1: can-phy1 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + transceiver2: can-phy2 {
> + /* standby pin has been grounded by default */
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + };
> +
> + transceiver3: can-phy3 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
> + mux-states = <&mux1 1>;
> + };
> +
> + mux1: mux-controller {
> + compatible = "gpio-mux";
> + #mux-state-cells = <1>;
> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
Could you help here on logic to choose pin 14
As I see for this mux
S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
S1 is Pin 15 is "CANUART_MUX2_SEL1"
S2 is high
So in order to get CAN on mux output
All, S0, S1 and S2 should be high.
IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
> + };
> };
>
> &wkup_gpio0 {
> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
> >;
> };
> +
> + main_mcan4_pins_default: main-mcan4-default-pins {
> + pinctrl-single,pins = <
> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
> + >;
> + };
> +
> + main_mcan16_pins_default: main-mcan16-default-pins {
> + pinctrl-single,pins = <
> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
> + >;
> + };
> };
>
> &wkup_pmx2 {
> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
> >;
> };
> +
> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
> + >;
> + };
> +
> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
> + >;
> + };
> +
> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
> + >;
> + };
> +
> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
> + >;
> + };
> };
>
> &wkup_pmx1 {
> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
> };
> };
> };
> +
> +&mcu_mcan0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan0_pins_default>;
> + phys = <&transceiver0>;
> +};
> +
> +&mcu_mcan1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan1_pins_default>;
> + phys = <&transceiver1>;
> +};
> +
> +&main_mcan16 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan16_pins_default>;
> + phys = <&transceiver2>;
> +};
> +
> +&main_mcan4 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan4_pins_default>;
> + phys = <&transceiver3>;
> +};
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-15 5:12 ` Kumar, Udit
0 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-04-15 5:12 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, u-kumar1
Hello Bhavya,
On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
> brought on the evm through headers J42, J43 and J46 respectively. Thus,
> add their respective transceiver's 0, 1 and 2 dt nodes to add support
> for these CAN instances.
Looking at schematic and board data sheet, it appears, board has 6 CAN
interfaces.
[J41--J46], but we are enabling only 4.
I understand, other interfaces might be used for other purpose.
Vignesh/Nishanth,
Do you think, this make sense to code all available interfaces on board and
mark as reserved, if used for other purpose , similar to what is done
for wkup_uart for this board.
> CAN instance 4 in the main domain is brought on the evm through header
> J45. The CAN High and Low lines from the SoC are routed through a mux
> on the evm. The select lines need to be set for the CAN signals to
> reach to its transceiver on the evm. Therefore, add transceiver 3
> dt node to add support for this CAN instance.
>
> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
> ---
>
> rebased to next-20240411
>
> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> index 81fd7afac8c5..e56901973895 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
> };
> };
> };
> +
> + transceiver0: can-phy0 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
> + };
> +
> + transceiver1: can-phy1 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + transceiver2: can-phy2 {
> + /* standby pin has been grounded by default */
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + };
> +
> + transceiver3: can-phy3 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <5000000>;
> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
> + mux-states = <&mux1 1>;
> + };
> +
> + mux1: mux-controller {
> + compatible = "gpio-mux";
> + #mux-state-cells = <1>;
> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
Could you help here on logic to choose pin 14
As I see for this mux
S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
S1 is Pin 15 is "CANUART_MUX2_SEL1"
S2 is high
So in order to get CAN on mux output
All, S0, S1 and S2 should be high.
IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
> + };
> };
>
> &wkup_gpio0 {
> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
> >;
> };
> +
> + main_mcan4_pins_default: main-mcan4-default-pins {
> + pinctrl-single,pins = <
> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
> + >;
> + };
> +
> + main_mcan16_pins_default: main-mcan16-default-pins {
> + pinctrl-single,pins = <
> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
> + >;
> + };
> };
>
> &wkup_pmx2 {
> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
> >;
> };
> +
> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
> + >;
> + };
> +
> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
> + >;
> + };
> +
> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
> + >;
> + };
> +
> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
> + pinctrl-single,pins = <
> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
> + >;
> + };
> };
>
> &wkup_pmx1 {
> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
> };
> };
> };
> +
> +&mcu_mcan0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan0_pins_default>;
> + phys = <&transceiver0>;
> +};
> +
> +&mcu_mcan1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mcu_mcan1_pins_default>;
> + phys = <&transceiver1>;
> +};
> +
> +&main_mcan16 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan16_pins_default>;
> + phys = <&transceiver2>;
> +};
> +
> +&main_mcan4 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan4_pins_default>;
> + phys = <&transceiver3>;
> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
2024-04-15 5:12 ` Kumar, Udit
@ 2024-04-16 9:22 ` Bhavya Kapoor
-1 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-16 9:22 UTC (permalink / raw)
To: Kumar, Udit, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm
On 15/04/24 10:42, Kumar, Udit wrote:
> Hello Bhavya,
>
> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>> for these CAN instances.
>
> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>
> [J41--J46], but we are enabling only 4.
>
> I understand, other interfaces might be used for other purpose.
>
> Vignesh/Nishanth,
>
> Do you think, this make sense to code all available interfaces on board and
>
> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>
Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
If we turn on the other 2 cans or even mark them as reserved, we will still have to
alter the mux sel lines which will impact the audio.
Thanks.
~B-Kapoor
>
>> CAN instance 4 in the main domain is brought on the evm through header
>> J45. The CAN High and Low lines from the SoC are routed through a mux
>> on the evm. The select lines need to be set for the CAN signals to
>> reach to its transceiver on the evm. Therefore, add transceiver 3
>> dt node to add support for this CAN instance.
>>
>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>> ---
>>
>> rebased to next-20240411
>>
>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> index 81fd7afac8c5..e56901973895 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>> };
>> };
>> };
>> +
>> + transceiver0: can-phy0 {
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + transceiver1: can-phy1 {
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + transceiver2: can-phy2 {
>> + /* standby pin has been grounded by default */
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + };
>> +
>> + transceiver3: can-phy3 {
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>> + mux-states = <&mux1 1>;
>> + };
>> +
>> + mux1: mux-controller {
>> + compatible = "gpio-mux";
>> + #mux-state-cells = <1>;
>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>
> Could you help here on logic to choose pin 14
>
> As I see for this mux
>
> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>
> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>
> S2 is high
>
> So in order to get CAN on mux output
>
> All, S0, S1 and S2 should be high.
>
> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
This was done in the same way as it was done for mux2 for j721s2. mcan 5
Thanks
>
>> + };
>> };
>> &wkup_gpio0 {
>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>> >;
>> };
>> +
>> + main_mcan4_pins_default: main-mcan4-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>> + >;
>> + };
>> +
>> + main_mcan16_pins_default: main-mcan16-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>> + >;
>> + };
>> };
>> &wkup_pmx2 {
>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>> >;
>> };
>> +
>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>> + >;
>> + };
>> +
>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>> + >;
>> + };
>> +
>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>> + >;
>> + };
>> +
>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>> + >;
>> + };
>> };
>> &wkup_pmx1 {
>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>> };
>> };
>> };
>> +
>> +&mcu_mcan0 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>> + phys = <&transceiver0>;
>> +};
>> +
>> +&mcu_mcan1 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>> + phys = <&transceiver1>;
>> +};
>> +
>> +&main_mcan16 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mcan16_pins_default>;
>> + phys = <&transceiver2>;
>> +};
>> +
>> +&main_mcan4 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mcan4_pins_default>;
>> + phys = <&transceiver3>;
>> +};
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-16 9:22 ` Bhavya Kapoor
0 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-16 9:22 UTC (permalink / raw)
To: Kumar, Udit, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm
On 15/04/24 10:42, Kumar, Udit wrote:
> Hello Bhavya,
>
> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>> for these CAN instances.
>
> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>
> [J41--J46], but we are enabling only 4.
>
> I understand, other interfaces might be used for other purpose.
>
> Vignesh/Nishanth,
>
> Do you think, this make sense to code all available interfaces on board and
>
> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>
Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
If we turn on the other 2 cans or even mark them as reserved, we will still have to
alter the mux sel lines which will impact the audio.
Thanks.
~B-Kapoor
>
>> CAN instance 4 in the main domain is brought on the evm through header
>> J45. The CAN High and Low lines from the SoC are routed through a mux
>> on the evm. The select lines need to be set for the CAN signals to
>> reach to its transceiver on the evm. Therefore, add transceiver 3
>> dt node to add support for this CAN instance.
>>
>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>> ---
>>
>> rebased to next-20240411
>>
>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> index 81fd7afac8c5..e56901973895 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>> };
>> };
>> };
>> +
>> + transceiver0: can-phy0 {
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + transceiver1: can-phy1 {
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + transceiver2: can-phy2 {
>> + /* standby pin has been grounded by default */
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + };
>> +
>> + transceiver3: can-phy3 {
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <5000000>;
>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>> + mux-states = <&mux1 1>;
>> + };
>> +
>> + mux1: mux-controller {
>> + compatible = "gpio-mux";
>> + #mux-state-cells = <1>;
>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>
> Could you help here on logic to choose pin 14
>
> As I see for this mux
>
> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>
> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>
> S2 is high
>
> So in order to get CAN on mux output
>
> All, S0, S1 and S2 should be high.
>
> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
This was done in the same way as it was done for mux2 for j721s2. mcan 5
Thanks
>
>> + };
>> };
>> &wkup_gpio0 {
>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>> >;
>> };
>> +
>> + main_mcan4_pins_default: main-mcan4-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>> + >;
>> + };
>> +
>> + main_mcan16_pins_default: main-mcan16-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>> + >;
>> + };
>> };
>> &wkup_pmx2 {
>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>> >;
>> };
>> +
>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>> + >;
>> + };
>> +
>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>> + >;
>> + };
>> +
>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>> + >;
>> + };
>> +
>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>> + pinctrl-single,pins = <
>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>> + >;
>> + };
>> };
>> &wkup_pmx1 {
>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>> };
>> };
>> };
>> +
>> +&mcu_mcan0 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>> + phys = <&transceiver0>;
>> +};
>> +
>> +&mcu_mcan1 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>> + phys = <&transceiver1>;
>> +};
>> +
>> +&main_mcan16 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mcan16_pins_default>;
>> + phys = <&transceiver2>;
>> +};
>> +
>> +&main_mcan4 {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mcan4_pins_default>;
>> + phys = <&transceiver3>;
>> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
2024-04-16 9:22 ` Bhavya Kapoor
@ 2024-04-16 9:54 ` Kumar, Udit
-1 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-04-16 9:54 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm
Hello Bhavya
On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
> On 15/04/24 10:42, Kumar, Udit wrote:
>> Hello Bhavya,
>>
>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>> for these CAN instances.
>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>
>> [J41--J46], but we are enabling only 4.
>>
>> I understand, other interfaces might be used for other purpose.
>>
>> Vignesh/Nishanth,
>>
>> Do you think, this make sense to code all available interfaces on board and
>>
>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>
> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>
> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>
> alter the mux sel lines which will impact the audio.
How it will impact ?
Audio and CAN lines goes to 1B port of mux .
IMO, even CAN or Audio does mux select they are going to select same
port no ?
I refer U58 and U50 MUX of schematic, Hope we are on same page
>
> Thanks.
>
> ~B-Kapoor
>
>>> CAN instance 4 in the main domain is brought on the evm through header
>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>> on the evm. The select lines need to be set for the CAN signals to
>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>> dt node to add support for this CAN instance.
>>>
>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>> ---
>>>
>>> rebased to next-20240411
>>>
>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>> 1 file changed, 107 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> index 81fd7afac8c5..e56901973895 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>> };
>>> };
>>> };
>>> +
>>> + transceiver0: can-phy0 {
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + transceiver1: can-phy1 {
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + transceiver2: can-phy2 {
>>> + /* standby pin has been grounded by default */
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + };
>>> +
>>> + transceiver3: can-phy3 {
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>> + mux-states = <&mux1 1>;
>>> + };
>>> +
>>> + mux1: mux-controller {
>>> + compatible = "gpio-mux";
>>> + #mux-state-cells = <1>;
>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>> Could you help here on logic to choose pin 14
>>
>> As I see for this mux
>>
>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>
>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>
>> S2 is high
>>
>> So in order to get CAN on mux output
>>
>> All, S0, S1 and S2 should be high.
>>
>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>
> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>
> Thanks
May be i was not clear in my previous comment
Looking at schematic
S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO
expander U173
S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
Here all lines high are needed to route CAN correctly out from mux.
So this patch is controlling CANUART_MUX_SEL0 but not controlling
CANUART_MUX2_SEL1.
IMO, CANUART_MUX_SEL0 can be controlled by dip switch and
CANUART_MUX2_SEL1 should be controlled by driver.
>>> + };
>>> };
>>> &wkup_gpio0 {
>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>> >;
>>> };
>>> +
>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>> + >;
>>> + };
>>> +
>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>> + >;
>>> + };
>>> };
>>> &wkup_pmx2 {
>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>> >;
>>> };
>>> +
>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>> + >;
>>> + };
>>> +
>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>> + >;
>>> + };
>>> +
>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>> + >;
>>> + };
>>> +
>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>> + >;
>>> + };
>>> };
>>> &wkup_pmx1 {
>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>> };
>>> };
>>> };
>>> +
>>> +&mcu_mcan0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>> + phys = <&transceiver0>;
>>> +};
>>> +
>>> +&mcu_mcan1 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>> + phys = <&transceiver1>;
>>> +};
>>> +
>>> +&main_mcan16 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>> + phys = <&transceiver2>;
>>> +};
>>> +
>>> +&main_mcan4 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>> + phys = <&transceiver3>;
>>> +};
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-16 9:54 ` Kumar, Udit
0 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-04-16 9:54 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm
Hello Bhavya
On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
> On 15/04/24 10:42, Kumar, Udit wrote:
>> Hello Bhavya,
>>
>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>> for these CAN instances.
>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>
>> [J41--J46], but we are enabling only 4.
>>
>> I understand, other interfaces might be used for other purpose.
>>
>> Vignesh/Nishanth,
>>
>> Do you think, this make sense to code all available interfaces on board and
>>
>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>
> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>
> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>
> alter the mux sel lines which will impact the audio.
How it will impact ?
Audio and CAN lines goes to 1B port of mux .
IMO, even CAN or Audio does mux select they are going to select same
port no ?
I refer U58 and U50 MUX of schematic, Hope we are on same page
>
> Thanks.
>
> ~B-Kapoor
>
>>> CAN instance 4 in the main domain is brought on the evm through header
>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>> on the evm. The select lines need to be set for the CAN signals to
>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>> dt node to add support for this CAN instance.
>>>
>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>> ---
>>>
>>> rebased to next-20240411
>>>
>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>> 1 file changed, 107 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> index 81fd7afac8c5..e56901973895 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>> };
>>> };
>>> };
>>> +
>>> + transceiver0: can-phy0 {
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + transceiver1: can-phy1 {
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + transceiver2: can-phy2 {
>>> + /* standby pin has been grounded by default */
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + };
>>> +
>>> + transceiver3: can-phy3 {
>>> + compatible = "ti,tcan1042";
>>> + #phy-cells = <0>;
>>> + max-bitrate = <5000000>;
>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>> + mux-states = <&mux1 1>;
>>> + };
>>> +
>>> + mux1: mux-controller {
>>> + compatible = "gpio-mux";
>>> + #mux-state-cells = <1>;
>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>> Could you help here on logic to choose pin 14
>>
>> As I see for this mux
>>
>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>
>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>
>> S2 is high
>>
>> So in order to get CAN on mux output
>>
>> All, S0, S1 and S2 should be high.
>>
>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>
> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>
> Thanks
May be i was not clear in my previous comment
Looking at schematic
S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO
expander U173
S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
Here all lines high are needed to route CAN correctly out from mux.
So this patch is controlling CANUART_MUX_SEL0 but not controlling
CANUART_MUX2_SEL1.
IMO, CANUART_MUX_SEL0 can be controlled by dip switch and
CANUART_MUX2_SEL1 should be controlled by driver.
>>> + };
>>> };
>>> &wkup_gpio0 {
>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>> >;
>>> };
>>> +
>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>> + >;
>>> + };
>>> +
>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>> + >;
>>> + };
>>> };
>>> &wkup_pmx2 {
>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>> >;
>>> };
>>> +
>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>> + >;
>>> + };
>>> +
>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>> + >;
>>> + };
>>> +
>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>> + >;
>>> + };
>>> +
>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>> + pinctrl-single,pins = <
>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>> + >;
>>> + };
>>> };
>>> &wkup_pmx1 {
>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>> };
>>> };
>>> };
>>> +
>>> +&mcu_mcan0 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>> + phys = <&transceiver0>;
>>> +};
>>> +
>>> +&mcu_mcan1 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>> + phys = <&transceiver1>;
>>> +};
>>> +
>>> +&main_mcan16 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>> + phys = <&transceiver2>;
>>> +};
>>> +
>>> +&main_mcan4 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>> + phys = <&transceiver3>;
>>> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
2024-04-16 9:54 ` Kumar, Udit
@ 2024-04-19 9:19 ` Bhavya Kapoor
-1 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-19 9:19 UTC (permalink / raw)
To: Kumar, Udit, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm
On 16/04/24 15:24, Kumar, Udit wrote:
> Hello Bhavya
>
> On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
>> On 15/04/24 10:42, Kumar, Udit wrote:
>>> Hello Bhavya,
>>>
>>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>>> for these CAN instances.
>>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>>
>>> [J41--J46], but we are enabling only 4.
>>>
>>> I understand, other interfaces might be used for other purpose.
>>>
>>> Vignesh/Nishanth,
>>>
>>> Do you think, this make sense to code all available interfaces on board and
>>>
>>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>>
>> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>>
>> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>>
>> alter the mux sel lines which will impact the audio.
>
>
> How it will impact ?
>
> Audio and CAN lines goes to 1B port of mux .
>
> IMO, even CAN or Audio does mux select they are going to select same port no ?
>
> I refer U58 and U50 MUX of schematic, Hope we are on same page
>
>
Hi Udit, Thanks for the clarity on muxes number otherwise we would have been in a lot of confusion
I was referring to muxes U112 and U108.
After U58 and UU50 , the signal will pass to U112 and U108 and in these 2 Muxes,
we will either have to select _B1 or _B2 ie from audio or the can signals. And, we
are going for audio signals.
Regards
>>
>> Thanks.
>>
>> ~B-Kapoor
>>
>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>> on the evm. The select lines need to be set for the CAN signals to
>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>> dt node to add support for this CAN instance.
>>>>
>>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>>> ---
>>>>
>>>> rebased to next-20240411
>>>>
>>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>>> 1 file changed, 107 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> index 81fd7afac8c5..e56901973895 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>>> };
>>>> };
>>>> };
>>>> +
>>>> + transceiver0: can-phy0 {
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>>> + };
>>>> +
>>>> + transceiver1: can-phy1 {
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>>> + };
>>>> +
>>>> + transceiver2: can-phy2 {
>>>> + /* standby pin has been grounded by default */
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + };
>>>> +
>>>> + transceiver3: can-phy3 {
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>>> + mux-states = <&mux1 1>;
>>>> + };
>>>> +
>>>> + mux1: mux-controller {
>>>> + compatible = "gpio-mux";
>>>> + #mux-state-cells = <1>;
>>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>>> Could you help here on logic to choose pin 14
>>>
>>> As I see for this mux
>>>
>>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>>
>>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>>
>>> S2 is high
>>>
>>> So in order to get CAN on mux output
>>>
>>> All, S0, S1 and S2 should be high.
>>>
>>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
>> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>>
>> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>>
>> Thanks
>
> May be i was not clear in my previous comment
>
> Looking at schematic
>
> S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO expander U173
>
> S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
>
> S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
>
> Here all lines high are needed to route CAN correctly out from mux.
>
> So this patch is controlling CANUART_MUX_SEL0 but not controlling CANUART_MUX2_SEL1.
>
> IMO, CANUART_MUX_SEL0 can be controlled by dip switch and CANUART_MUX2_SEL1 should be controlled by driver.
Hi Udit, thanks for conveying this in a much more explained way.
What i am trying to say that in the default state as well we are getting s1 signal as high itself.
So, if you want that we should specifically add gpio for that in dts, we can also go ahead with that.
Regards
~B-Kapoor
>
>
>>>> + };
>>>> };
>>>> &wkup_gpio0 {
>>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>>> >;
>>>> };
>>>> +
>>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>>> + >;
>>>> + };
>>>> +
>>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>>> + >;
>>>> + };
>>>> };
>>>> &wkup_pmx2 {
>>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>>> >;
>>>> };
>>>> +
>>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>>> + >;
>>>> + };
>>>> +
>>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>>> + >;
>>>> + };
>>>> +
>>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>>> + >;
>>>> + };
>>>> +
>>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>>> + >;
>>>> + };
>>>> };
>>>> &wkup_pmx1 {
>>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>>> };
>>>> };
>>>> };
>>>> +
>>>> +&mcu_mcan0 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>>> + phys = <&transceiver0>;
>>>> +};
>>>> +
>>>> +&mcu_mcan1 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>>> + phys = <&transceiver1>;
>>>> +};
>>>> +
>>>> +&main_mcan16 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>>> + phys = <&transceiver2>;
>>>> +};
>>>> +
>>>> +&main_mcan4 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>>> + phys = <&transceiver3>;
>>>> +};
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-19 9:19 ` Bhavya Kapoor
0 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-19 9:19 UTC (permalink / raw)
To: Kumar, Udit, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm
On 16/04/24 15:24, Kumar, Udit wrote:
> Hello Bhavya
>
> On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
>> On 15/04/24 10:42, Kumar, Udit wrote:
>>> Hello Bhavya,
>>>
>>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>>> for these CAN instances.
>>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>>
>>> [J41--J46], but we are enabling only 4.
>>>
>>> I understand, other interfaces might be used for other purpose.
>>>
>>> Vignesh/Nishanth,
>>>
>>> Do you think, this make sense to code all available interfaces on board and
>>>
>>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>>
>> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>>
>> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>>
>> alter the mux sel lines which will impact the audio.
>
>
> How it will impact ?
>
> Audio and CAN lines goes to 1B port of mux .
>
> IMO, even CAN or Audio does mux select they are going to select same port no ?
>
> I refer U58 and U50 MUX of schematic, Hope we are on same page
>
>
Hi Udit, Thanks for the clarity on muxes number otherwise we would have been in a lot of confusion
I was referring to muxes U112 and U108.
After U58 and UU50 , the signal will pass to U112 and U108 and in these 2 Muxes,
we will either have to select _B1 or _B2 ie from audio or the can signals. And, we
are going for audio signals.
Regards
>>
>> Thanks.
>>
>> ~B-Kapoor
>>
>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>> on the evm. The select lines need to be set for the CAN signals to
>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>> dt node to add support for this CAN instance.
>>>>
>>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>>> ---
>>>>
>>>> rebased to next-20240411
>>>>
>>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>>> 1 file changed, 107 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> index 81fd7afac8c5..e56901973895 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>>> };
>>>> };
>>>> };
>>>> +
>>>> + transceiver0: can-phy0 {
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>>> + };
>>>> +
>>>> + transceiver1: can-phy1 {
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>>> + };
>>>> +
>>>> + transceiver2: can-phy2 {
>>>> + /* standby pin has been grounded by default */
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + };
>>>> +
>>>> + transceiver3: can-phy3 {
>>>> + compatible = "ti,tcan1042";
>>>> + #phy-cells = <0>;
>>>> + max-bitrate = <5000000>;
>>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>>> + mux-states = <&mux1 1>;
>>>> + };
>>>> +
>>>> + mux1: mux-controller {
>>>> + compatible = "gpio-mux";
>>>> + #mux-state-cells = <1>;
>>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>>> Could you help here on logic to choose pin 14
>>>
>>> As I see for this mux
>>>
>>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>>
>>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>>
>>> S2 is high
>>>
>>> So in order to get CAN on mux output
>>>
>>> All, S0, S1 and S2 should be high.
>>>
>>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
>> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>>
>> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>>
>> Thanks
>
> May be i was not clear in my previous comment
>
> Looking at schematic
>
> S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO expander U173
>
> S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
>
> S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
>
> Here all lines high are needed to route CAN correctly out from mux.
>
> So this patch is controlling CANUART_MUX_SEL0 but not controlling CANUART_MUX2_SEL1.
>
> IMO, CANUART_MUX_SEL0 can be controlled by dip switch and CANUART_MUX2_SEL1 should be controlled by driver.
Hi Udit, thanks for conveying this in a much more explained way.
What i am trying to say that in the default state as well we are getting s1 signal as high itself.
So, if you want that we should specifically add gpio for that in dts, we can also go ahead with that.
Regards
~B-Kapoor
>
>
>>>> + };
>>>> };
>>>> &wkup_gpio0 {
>>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>>> >;
>>>> };
>>>> +
>>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>>> + >;
>>>> + };
>>>> +
>>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>>> + >;
>>>> + };
>>>> };
>>>> &wkup_pmx2 {
>>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>>> >;
>>>> };
>>>> +
>>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>>> + >;
>>>> + };
>>>> +
>>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>>> + >;
>>>> + };
>>>> +
>>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>>> + >;
>>>> + };
>>>> +
>>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>>> + pinctrl-single,pins = <
>>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>>> + >;
>>>> + };
>>>> };
>>>> &wkup_pmx1 {
>>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>>> };
>>>> };
>>>> };
>>>> +
>>>> +&mcu_mcan0 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>>> + phys = <&transceiver0>;
>>>> +};
>>>> +
>>>> +&mcu_mcan1 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>>> + phys = <&transceiver1>;
>>>> +};
>>>> +
>>>> +&main_mcan16 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>>> + phys = <&transceiver2>;
>>>> +};
>>>> +
>>>> +&main_mcan4 {
>>>> + status = "okay";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>>> + phys = <&transceiver3>;
>>>> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
2024-04-19 9:19 ` Bhavya Kapoor
@ 2024-04-19 9:41 ` Kumar, Udit
-1 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-04-19 9:41 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, Jayesh Choudhary
On 4/19/2024 2:49 PM, Bhavya Kapoor wrote:
> On 16/04/24 15:24, Kumar, Udit wrote:
>> Hello Bhavya
>>
>> On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
>>> On 15/04/24 10:42, Kumar, Udit wrote:
>>>> Hello Bhavya,
>>>>
>>>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>>>> for these CAN instances.
>>>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>>>
>>>> [J41--J46], but we are enabling only 4.
>>>>
>>>> I understand, other interfaces might be used for other purpose.
>>>>
>>>> Vignesh/Nishanth,
>>>>
>>>> Do you think, this make sense to code all available interfaces on board and
>>>>
>>>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>>>
>>> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>>>
>>> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>>>
>>> alter the mux sel lines which will impact the audio.
>>
>> How it will impact ?
>>
>> Audio and CAN lines goes to 1B port of mux .
>>
>> IMO, even CAN or Audio does mux select they are going to select same port no ?
>>
>> I refer U58 and U50 MUX of schematic, Hope we are on same page
>>
>>
> Hi Udit, Thanks for the clarity on muxes number otherwise we would have been in a lot of confusion
> I was referring to muxes U112 and U108.
> After U58 and UU50 , the signal will pass to U112 and U108 and in these 2 Muxes,
>
> we will either have to select _B1 or _B2 ie from audio or the can signals. And, we
>
> are going for audio signals.
Then my suggestion will be to have this mux in your series and mark as
reserved.
When audio will come, audio can enable this mux as needed.
>
> Regards
>
>>> Thanks.
>>>
>>> ~B-Kapoor
>>>
>>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>>> on the evm. The select lines need to be set for the CAN signals to
>>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>>> dt node to add support for this CAN instance.
>>>>>
>>>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>>>> ---
>>>>>
>>>>> rebased to next-20240411
>>>>>
>>>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>>>> 1 file changed, 107 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>> index 81fd7afac8c5..e56901973895 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>>>> };
>>>>> };
>>>>> };
>>>>> +
>>>>> + transceiver0: can-phy0 {
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>>>> + };
>>>>> +
>>>>> + transceiver1: can-phy1 {
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>>>> + };
>>>>> +
>>>>> + transceiver2: can-phy2 {
>>>>> + /* standby pin has been grounded by default */
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + };
>>>>> +
>>>>> + transceiver3: can-phy3 {
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>>>> + mux-states = <&mux1 1>;
>>>>> + };
>>>>> +
>>>>> + mux1: mux-controller {
>>>>> + compatible = "gpio-mux";
>>>>> + #mux-state-cells = <1>;
>>>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>>>> Could you help here on logic to choose pin 14
>>>>
>>>> As I see for this mux
>>>>
>>>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>>>
>>>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>>>
>>>> S2 is high
>>>>
>>>> So in order to get CAN on mux output
>>>>
>>>> All, S0, S1 and S2 should be high.
>>>>
>>>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
>>> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>>>
>>> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>>>
>>> Thanks
>> May be i was not clear in my previous comment
>>
>> Looking at schematic
>>
>> S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO expander U173
>>
>> S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
>>
>> S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
>>
>> Here all lines high are needed to route CAN correctly out from mux.
>>
>> So this patch is controlling CANUART_MUX_SEL0 but not controlling CANUART_MUX2_SEL1.
>>
>> IMO, CANUART_MUX_SEL0 can be controlled by dip switch and CANUART_MUX2_SEL1 should be controlled by driver.
> Hi Udit, thanks for conveying this in a much more explained way.
>
> What i am trying to say that in the default state as well we are getting s1 signal as high itself.
>
> So, if you want that we should specifically add gpio for that in dts, we can also go ahead with that.
Just control (S1 which is CANUART_MUX2_SEL1) by your dts files
>
> Regards
>
> ~B-Kapoor
>
>>
>>>>> + };
>>>>> };
>>>>> &wkup_gpio0 {
>>>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>>>> >;
>>>>> };
>>>>> +
>>>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>>>> + >;
>>>>> + };
>>>>> };
>>>>> &wkup_pmx2 {
>>>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>>>> >;
>>>>> };
>>>>> +
>>>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>>>> + >;
>>>>> + };
>>>>> };
>>>>> &wkup_pmx1 {
>>>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>>>> };
>>>>> };
>>>>> };
>>>>> +
>>>>> +&mcu_mcan0 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>>>> + phys = <&transceiver0>;
>>>>> +};
>>>>> +
>>>>> +&mcu_mcan1 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>>>> + phys = <&transceiver1>;
>>>>> +};
>>>>> +
>>>>> +&main_mcan16 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>>>> + phys = <&transceiver2>;
>>>>> +};
>>>>> +
>>>>> +&main_mcan4 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>>>> + phys = <&transceiver3>;
>>>>> +};
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-19 9:41 ` Kumar, Udit
0 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-04-19 9:41 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, Jayesh Choudhary
On 4/19/2024 2:49 PM, Bhavya Kapoor wrote:
> On 16/04/24 15:24, Kumar, Udit wrote:
>> Hello Bhavya
>>
>> On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
>>> On 15/04/24 10:42, Kumar, Udit wrote:
>>>> Hello Bhavya,
>>>>
>>>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>>>> for these CAN instances.
>>>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>>>
>>>> [J41--J46], but we are enabling only 4.
>>>>
>>>> I understand, other interfaces might be used for other purpose.
>>>>
>>>> Vignesh/Nishanth,
>>>>
>>>> Do you think, this make sense to code all available interfaces on board and
>>>>
>>>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>>>
>>> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>>>
>>> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>>>
>>> alter the mux sel lines which will impact the audio.
>>
>> How it will impact ?
>>
>> Audio and CAN lines goes to 1B port of mux .
>>
>> IMO, even CAN or Audio does mux select they are going to select same port no ?
>>
>> I refer U58 and U50 MUX of schematic, Hope we are on same page
>>
>>
> Hi Udit, Thanks for the clarity on muxes number otherwise we would have been in a lot of confusion
> I was referring to muxes U112 and U108.
> After U58 and UU50 , the signal will pass to U112 and U108 and in these 2 Muxes,
>
> we will either have to select _B1 or _B2 ie from audio or the can signals. And, we
>
> are going for audio signals.
Then my suggestion will be to have this mux in your series and mark as
reserved.
When audio will come, audio can enable this mux as needed.
>
> Regards
>
>>> Thanks.
>>>
>>> ~B-Kapoor
>>>
>>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>>> on the evm. The select lines need to be set for the CAN signals to
>>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>>> dt node to add support for this CAN instance.
>>>>>
>>>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>>>> ---
>>>>>
>>>>> rebased to next-20240411
>>>>>
>>>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>>>> 1 file changed, 107 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>> index 81fd7afac8c5..e56901973895 100644
>>>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>>>> };
>>>>> };
>>>>> };
>>>>> +
>>>>> + transceiver0: can-phy0 {
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>>>> + };
>>>>> +
>>>>> + transceiver1: can-phy1 {
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>>>> + };
>>>>> +
>>>>> + transceiver2: can-phy2 {
>>>>> + /* standby pin has been grounded by default */
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + };
>>>>> +
>>>>> + transceiver3: can-phy3 {
>>>>> + compatible = "ti,tcan1042";
>>>>> + #phy-cells = <0>;
>>>>> + max-bitrate = <5000000>;
>>>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>>>> + mux-states = <&mux1 1>;
>>>>> + };
>>>>> +
>>>>> + mux1: mux-controller {
>>>>> + compatible = "gpio-mux";
>>>>> + #mux-state-cells = <1>;
>>>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>>>> Could you help here on logic to choose pin 14
>>>>
>>>> As I see for this mux
>>>>
>>>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>>>
>>>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>>>
>>>> S2 is high
>>>>
>>>> So in order to get CAN on mux output
>>>>
>>>> All, S0, S1 and S2 should be high.
>>>>
>>>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
>>> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>>>
>>> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>>>
>>> Thanks
>> May be i was not clear in my previous comment
>>
>> Looking at schematic
>>
>> S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO expander U173
>>
>> S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
>>
>> S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
>>
>> Here all lines high are needed to route CAN correctly out from mux.
>>
>> So this patch is controlling CANUART_MUX_SEL0 but not controlling CANUART_MUX2_SEL1.
>>
>> IMO, CANUART_MUX_SEL0 can be controlled by dip switch and CANUART_MUX2_SEL1 should be controlled by driver.
> Hi Udit, thanks for conveying this in a much more explained way.
>
> What i am trying to say that in the default state as well we are getting s1 signal as high itself.
>
> So, if you want that we should specifically add gpio for that in dts, we can also go ahead with that.
Just control (S1 which is CANUART_MUX2_SEL1) by your dts files
>
> Regards
>
> ~B-Kapoor
>
>>
>>>>> + };
>>>>> };
>>>>> &wkup_gpio0 {
>>>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>>>> >;
>>>>> };
>>>>> +
>>>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>>>> + >;
>>>>> + };
>>>>> };
>>>>> &wkup_pmx2 {
>>>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>>>> >;
>>>>> };
>>>>> +
>>>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>>>> + >;
>>>>> + };
>>>>> +
>>>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>>>> + pinctrl-single,pins = <
>>>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>>>> + >;
>>>>> + };
>>>>> };
>>>>> &wkup_pmx1 {
>>>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>>>> };
>>>>> };
>>>>> };
>>>>> +
>>>>> +&mcu_mcan0 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>>>> + phys = <&transceiver0>;
>>>>> +};
>>>>> +
>>>>> +&mcu_mcan1 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>>>> + phys = <&transceiver1>;
>>>>> +};
>>>>> +
>>>>> +&main_mcan16 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>>>> + phys = <&transceiver2>;
>>>>> +};
>>>>> +
>>>>> +&main_mcan4 {
>>>>> + status = "okay";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>>>> + phys = <&transceiver3>;
>>>>> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
2024-04-19 9:41 ` Kumar, Udit
@ 2024-04-23 7:05 ` Bhavya Kapoor
-1 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-23 7:05 UTC (permalink / raw)
To: Kumar, Udit, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, Jayesh Choudhary
Hi Udit
On 19/04/24 15:11, Kumar, Udit wrote:
>
> On 4/19/2024 2:49 PM, Bhavya Kapoor wrote:
>> On 16/04/24 15:24, Kumar, Udit wrote:
>>> Hello Bhavya
>>>
>>> On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
>>>> On 15/04/24 10:42, Kumar, Udit wrote:
>>>>> Hello Bhavya,
>>>>>
>>>>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>>>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>>>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>>>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>>>>> for these CAN instances.
>>>>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>>>>
>>>>> [J41--J46], but we are enabling only 4.
>>>>>
>>>>> I understand, other interfaces might be used for other purpose.
>>>>>
>>>>> Vignesh/Nishanth,
>>>>>
>>>>> Do you think, this make sense to code all available interfaces on board and
>>>>>
>>>>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>>>>
>>>> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>>>>
>>>> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>>>>
>>>> alter the mux sel lines which will impact the audio.
>>>
>>> How it will impact ?
>>>
>>> Audio and CAN lines goes to 1B port of mux .
>>>
>>> IMO, even CAN or Audio does mux select they are going to select same port no ?
>>>
>>> I refer U58 and U50 MUX of schematic, Hope we are on same page
>>>
>>>
>> Hi Udit, Thanks for the clarity on muxes number otherwise we would have been in a lot of confusion
>> I was referring to muxes U112 and U108.
>> After U58 and UU50 , the signal will pass to U112 and U108 and in these 2 Muxes,
>>
>> we will either have to select _B1 or _B2 ie from audio or the can signals. And, we
>>
>> are going for audio signals.
>
>
> Then my suggestion will be to have this mux in your series and mark as reserved.
>
> When audio will come, audio can enable this mux as needed.
Let me check if that can be done .
>
>>
>> Regards
>>
>>>> Thanks.
>>>>
>>>> ~B-Kapoor
>>>>
>>>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>>>> on the evm. The select lines need to be set for the CAN signals to
>>>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>>>> dt node to add support for this CAN instance.
>>>>>>
>>>>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>>>>> ---
>>>>>>
>>>>>> rebased to next-20240411
>>>>>>
>>>>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>>>>> 1 file changed, 107 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>>> index 81fd7afac8c5..e56901973895 100644
>>>>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> + transceiver0: can-phy0 {
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>>>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>>>>> + };
>>>>>> +
>>>>>> + transceiver1: can-phy1 {
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>>>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>>>>> + };
>>>>>> +
>>>>>> + transceiver2: can-phy2 {
>>>>>> + /* standby pin has been grounded by default */
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + };
>>>>>> +
>>>>>> + transceiver3: can-phy3 {
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>>>>> + mux-states = <&mux1 1>;
>>>>>> + };
>>>>>> +
>>>>>> + mux1: mux-controller {
>>>>>> + compatible = "gpio-mux";
>>>>>> + #mux-state-cells = <1>;
>>>>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>>>>> Could you help here on logic to choose pin 14
>>>>>
>>>>> As I see for this mux
>>>>>
>>>>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>>>>
>>>>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>>>>
>>>>> S2 is high
>>>>>
>>>>> So in order to get CAN on mux output
>>>>>
>>>>> All, S0, S1 and S2 should be high.
>>>>>
>>>>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
>>>> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>>>>
>>>> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>>>>
>>>> Thanks
>>> May be i was not clear in my previous comment
>>>
>>> Looking at schematic
>>>
>>> S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO expander U173
>>>
>>> S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
>>>
>>> S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
>>>
>>> Here all lines high are needed to route CAN correctly out from mux.
>>>
>>> So this patch is controlling CANUART_MUX_SEL0 but not controlling CANUART_MUX2_SEL1.
>>>
>>> IMO, CANUART_MUX_SEL0 can be controlled by dip switch and CANUART_MUX2_SEL1 should be controlled by driver.
>> Hi Udit, thanks for conveying this in a much more explained way.
>>
>> What i am trying to say that in the default state as well we are getting s1 signal as high itself.
>>
>> So, if you want that we should specifically add gpio for that in dts, we can also go ahead with that.
>
>
> Just control (S1 which is CANUART_MUX2_SEL1) by your dts files
Okay , i will control S1 by dts. And controlling S0 remain as it is how its done now? right ?
>
>>
>> Regards
>>
>> ~B-Kapoor
>>
>>>
>>>>>> + };
>>>>>> };
>>>>>> &wkup_gpio0 {
>>>>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>>>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>>>>> >;
>>>>>> };
>>>>>> +
>>>>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>>>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>>>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>>>>> + >;
>>>>>> + };
>>>>>> };
>>>>>> &wkup_pmx2 {
>>>>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>>>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>>>>> >;
>>>>>> };
>>>>>> +
>>>>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>>>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>>>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>>>>> + >;
>>>>>> + };
>>>>>> };
>>>>>> &wkup_pmx1 {
>>>>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> +&mcu_mcan0 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>>>>> + phys = <&transceiver0>;
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_mcan1 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>>>>> + phys = <&transceiver1>;
>>>>>> +};
>>>>>> +
>>>>>> +&main_mcan16 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>>>>> + phys = <&transceiver2>;
>>>>>> +};
>>>>>> +
>>>>>> +&main_mcan4 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>>>>> + phys = <&transceiver3>;
>>>>>> +};
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-04-23 7:05 ` Bhavya Kapoor
0 siblings, 0 replies; 16+ messages in thread
From: Bhavya Kapoor @ 2024-04-23 7:05 UTC (permalink / raw)
To: Kumar, Udit, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, Jayesh Choudhary
Hi Udit
On 19/04/24 15:11, Kumar, Udit wrote:
>
> On 4/19/2024 2:49 PM, Bhavya Kapoor wrote:
>> On 16/04/24 15:24, Kumar, Udit wrote:
>>> Hello Bhavya
>>>
>>> On 4/16/2024 2:52 PM, Bhavya Kapoor wrote:
>>>> On 15/04/24 10:42, Kumar, Udit wrote:
>>>>> Hello Bhavya,
>>>>>
>>>>> On 4/12/2024 1:47 AM, Bhavya Kapoor wrote:
>>>>>> CAN instances 0 and 1 in the mcu domain and 16 in the main domain are
>>>>>> brought on the evm through headers J42, J43 and J46 respectively. Thus,
>>>>>> add their respective transceiver's 0, 1 and 2 dt nodes to add support
>>>>>> for these CAN instances.
>>>>> Looking at schematic and board data sheet, it appears, board has 6 CAN interfaces.
>>>>>
>>>>> [J41--J46], but we are enabling only 4.
>>>>>
>>>>> I understand, other interfaces might be used for other purpose.
>>>>>
>>>>> Vignesh/Nishanth,
>>>>>
>>>>> Do you think, this make sense to code all available interfaces on board and
>>>>>
>>>>> mark as reserved, if used for other purpose , similar to what is done for wkup_uart for this board.
>>>>>
>>>> Hi Udit, there is a mux that is used between audio and the signal lines of other 2 cans.
>>>>
>>>> If we turn on the other 2 cans or even mark them as reserved, we will still have to
>>>>
>>>> alter the mux sel lines which will impact the audio.
>>>
>>> How it will impact ?
>>>
>>> Audio and CAN lines goes to 1B port of mux .
>>>
>>> IMO, even CAN or Audio does mux select they are going to select same port no ?
>>>
>>> I refer U58 and U50 MUX of schematic, Hope we are on same page
>>>
>>>
>> Hi Udit, Thanks for the clarity on muxes number otherwise we would have been in a lot of confusion
>> I was referring to muxes U112 and U108.
>> After U58 and UU50 , the signal will pass to U112 and U108 and in these 2 Muxes,
>>
>> we will either have to select _B1 or _B2 ie from audio or the can signals. And, we
>>
>> are going for audio signals.
>
>
> Then my suggestion will be to have this mux in your series and mark as reserved.
>
> When audio will come, audio can enable this mux as needed.
Let me check if that can be done .
>
>>
>> Regards
>>
>>>> Thanks.
>>>>
>>>> ~B-Kapoor
>>>>
>>>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>>>> on the evm. The select lines need to be set for the CAN signals to
>>>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>>>> dt node to add support for this CAN instance.
>>>>>>
>>>>>> Signed-off-by: Bhavya Kapoor <b-kapoor@ti.com>
>>>>>> ---
>>>>>>
>>>>>> rebased to next-20240411
>>>>>>
>>>>>> arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 107 +++++++++++++++++++++++
>>>>>> 1 file changed, 107 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>>> index 81fd7afac8c5..e56901973895 100644
>>>>>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
>>>>>> @@ -272,6 +272,45 @@ dp0_connector_in: endpoint {
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> + transceiver0: can-phy0 {
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>;
>>>>>> + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>;
>>>>>> + };
>>>>>> +
>>>>>> + transceiver1: can-phy1 {
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>;
>>>>>> + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>;
>>>>>> + };
>>>>>> +
>>>>>> + transceiver2: can-phy2 {
>>>>>> + /* standby pin has been grounded by default */
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + };
>>>>>> +
>>>>>> + transceiver3: can-phy3 {
>>>>>> + compatible = "ti,tcan1042";
>>>>>> + #phy-cells = <0>;
>>>>>> + max-bitrate = <5000000>;
>>>>>> + standby-gpios = <&exp2 7 GPIO_ACTIVE_HIGH>;
>>>>>> + mux-states = <&mux1 1>;
>>>>>> + };
>>>>>> +
>>>>>> + mux1: mux-controller {
>>>>>> + compatible = "gpio-mux";
>>>>>> + #mux-state-cells = <1>;
>>>>>> + mux-gpios = <&exp2 14 GPIO_ACTIVE_HIGH>;
>>>>> Could you help here on logic to choose pin 14
>>>>>
>>>>> As I see for this mux
>>>>>
>>>>> S0 is CANUART_MUX_SEL0 [Pin 14, which you want to control as high]
>>>>>
>>>>> S1 is Pin 15 is "CANUART_MUX2_SEL1"
>>>>>
>>>>> S2 is high
>>>>>
>>>>> So in order to get CAN on mux output
>>>>>
>>>>> All, S0, S1 and S2 should be high.
>>>>>
>>>>> IMO, you should control both S0 and S1, or just S1 and S0 with dip switch
>>>> Hi Udit, S0 comes at a default Active High State always. Thus, i have kept it the same.
>>>>
>>>> This was done in the same way as it was done for mux2 for j721s2. mcan 5
>>>>
>>>> Thanks
>>> May be i was not clear in my previous comment
>>>
>>> Looking at schematic
>>>
>>> S0 is CANUART_MUX_SEL0 , which is connected with DIP switch and IO expander U173
>>>
>>> S1 is CANUART_MUX2_SEL1, which is connected only IO with expander U173
>>>
>>> S2 is CANUART_MUX_SEL2 is pulled high by hardware itself .
>>>
>>> Here all lines high are needed to route CAN correctly out from mux.
>>>
>>> So this patch is controlling CANUART_MUX_SEL0 but not controlling CANUART_MUX2_SEL1.
>>>
>>> IMO, CANUART_MUX_SEL0 can be controlled by dip switch and CANUART_MUX2_SEL1 should be controlled by driver.
>> Hi Udit, thanks for conveying this in a much more explained way.
>>
>> What i am trying to say that in the default state as well we are getting s1 signal as high itself.
>>
>> So, if you want that we should specifically add gpio for that in dts, we can also go ahead with that.
>
>
> Just control (S1 which is CANUART_MUX2_SEL1) by your dts files
Okay , i will control S1 by dts. And controlling S0 remain as it is how its done now? right ?
>
>>
>> Regards
>>
>> ~B-Kapoor
>>
>>>
>>>>>> + };
>>>>>> };
>>>>>> &wkup_gpio0 {
>>>>>> @@ -336,6 +375,20 @@ J784S4_IOPAD(0x014, PIN_INPUT_PULLUP, 8) /* (AG33) MCAN14_TX.I2C4_SCL */
>>>>>> J784S4_IOPAD(0x010, PIN_INPUT_PULLUP, 8) /* (AH33) MCAN13_RX.I2C4_SDA */
>>>>>> >;
>>>>>> };
>>>>>> +
>>>>>> + main_mcan4_pins_default: main-mcan4-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_IOPAD(0x088, PIN_INPUT, 0) /* (AF36) MCAN4_RX */
>>>>>> + J784S4_IOPAD(0x084, PIN_OUTPUT, 0) /* (AG38) MCAN4_TX */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + main_mcan16_pins_default: main-mcan16-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_IOPAD(0x028, PIN_INPUT, 0) /* (AE33) MCAN16_RX */
>>>>>> + J784S4_IOPAD(0x024, PIN_OUTPUT, 0) /* (AH34) MCAN16_TX */
>>>>>> + >;
>>>>>> + };
>>>>>> };
>>>>>> &wkup_pmx2 {
>>>>>> @@ -415,6 +468,32 @@ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33) MCU_ADC1_AIN6 */
>>>>>> J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36) MCU_ADC1_AIN7 */
>>>>>> >;
>>>>>> };
>>>>>> +
>>>>>> + mcu_mcan0_pins_default: mcu-mcan0-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x050, PIN_OUTPUT, 0) /* (K33) MCU_MCAN0_TX */
>>>>>> + J784S4_WKUP_IOPAD(0x054, PIN_INPUT, 0) /* (F38) MCU_MCAN0_RX */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + mcu_mcan1_pins_default: mcu-mcan1-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x068, PIN_OUTPUT, 0) /* (H35) WKUP_GPIO0_4.MCU_MCAN1_TX */
>>>>>> + J784S4_WKUP_IOPAD(0x06c, PIN_INPUT, 0) /* (K36) WKUP_GPIO0_5.MCU_MCAN1_RX */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + mcu_mcan0_gpio_pins_default: mcu-mcan0-gpio-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x040, PIN_INPUT, 7) /* (J38) MCU_SPI0_D1.WKUP_GPIO0_69 */
>>>>>> + >;
>>>>>> + };
>>>>>> +
>>>>>> + mcu_mcan1_gpio_pins_default: mcu-mcan1-gpio-default-pins {
>>>>>> + pinctrl-single,pins = <
>>>>>> + J784S4_WKUP_IOPAD(0x060, PIN_INPUT, 7) /* (J35) WKUP_GPIO0_2 */
>>>>>> + >;
>>>>>> + };
>>>>>> };
>>>>>> &wkup_pmx1 {
>>>>>> @@ -1105,3 +1184,31 @@ dp0_out: endpoint {
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>> +
>>>>>> +&mcu_mcan0 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan0_pins_default>;
>>>>>> + phys = <&transceiver0>;
>>>>>> +};
>>>>>> +
>>>>>> +&mcu_mcan1 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&mcu_mcan1_pins_default>;
>>>>>> + phys = <&transceiver1>;
>>>>>> +};
>>>>>> +
>>>>>> +&main_mcan16 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&main_mcan16_pins_default>;
>>>>>> + phys = <&transceiver2>;
>>>>>> +};
>>>>>> +
>>>>>> +&main_mcan4 {
>>>>>> + status = "okay";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&main_mcan4_pins_default>;
>>>>>> + phys = <&transceiver3>;
>>>>>> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
2024-04-23 7:05 ` Bhavya Kapoor
@ 2024-05-20 10:29 ` Kumar, Udit
-1 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-05-20 10:29 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, Jayesh Choudhary
Hi Bhavya
On 4/23/2024 12:35 PM, Bhavya Kapoor wrote:
> Hi Udit
>
> On 19/04/24 15:11, Kumar, Udit wrote:
>> [...]
>> Let me check if that can be done .
if you are planning to manage it through overlay then for this patch
LGTM,
>>> Regards
>>>
>>>>> Thanks.
>>>>>
>>>>> ~B-Kapoor
>>>>>
>>>>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>>>>> on the evm. The select lines need to be set for the CAN signals to
>>>>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>>>>> dt node to add support for this CAN instance.
>>>>>>>
>>>>>>> [..]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances
@ 2024-05-20 10:29 ` Kumar, Udit
0 siblings, 0 replies; 16+ messages in thread
From: Kumar, Udit @ 2024-05-20 10:29 UTC (permalink / raw)
To: Bhavya Kapoor, linux-kernel, devicetree, vigneshr
Cc: linux-arm-kernel, conor+dt, krzk+dt, robh, kristo, nm, Jayesh Choudhary
Hi Bhavya
On 4/23/2024 12:35 PM, Bhavya Kapoor wrote:
> Hi Udit
>
> On 19/04/24 15:11, Kumar, Udit wrote:
>> [...]
>> Let me check if that can be done .
if you are planning to manage it through overlay then for this patch
LGTM,
>>> Regards
>>>
>>>>> Thanks.
>>>>>
>>>>> ~B-Kapoor
>>>>>
>>>>>>> CAN instance 4 in the main domain is brought on the evm through header
>>>>>>> J45. The CAN High and Low lines from the SoC are routed through a mux
>>>>>>> on the evm. The select lines need to be set for the CAN signals to
>>>>>>> reach to its transceiver on the evm. Therefore, add transceiver 3
>>>>>>> dt node to add support for this CAN instance.
>>>>>>>
>>>>>>> [..]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-05-20 10:29 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-11 20:17 [PATCH] arm64: dts: ti: k3-j784s4-evm: Add support for multiple CAN instances Bhavya Kapoor
2024-04-11 20:17 ` Bhavya Kapoor
2024-04-15 5:12 ` Kumar, Udit
2024-04-15 5:12 ` Kumar, Udit
2024-04-16 9:22 ` Bhavya Kapoor
2024-04-16 9:22 ` Bhavya Kapoor
2024-04-16 9:54 ` Kumar, Udit
2024-04-16 9:54 ` Kumar, Udit
2024-04-19 9:19 ` Bhavya Kapoor
2024-04-19 9:19 ` Bhavya Kapoor
2024-04-19 9:41 ` Kumar, Udit
2024-04-19 9:41 ` Kumar, Udit
2024-04-23 7:05 ` Bhavya Kapoor
2024-04-23 7:05 ` Bhavya Kapoor
2024-05-20 10:29 ` Kumar, Udit
2024-05-20 10:29 ` Kumar, Udit
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.