The following series of patches add support for setting
muxes to route signals from CAN controller to transceiver
by reading the property mux-states from the device tree
node
The following series of patches are dependent on,
- https://lkml.org/lkml/2021/12/2/423
Aswath Govindraju (2):
dt-bindings: phy: ti,tcan104x-can: Document mux-states property
phy: phy-can-transceiver: Add support for setting mux
.../bindings/phy/ti,tcan104x-can.yaml | 13 +++++++++++
drivers/phy/Kconfig | 1 +
drivers/phy/phy-can-transceiver.c | 22 +++++++++++++++++++
3 files changed, 36 insertions(+)
--
2.17.1
On some boards, for routing CAN signals from controller to transceivers,
muxes might need to be set. This can be implemented using mux-states
property. Therefore, document the same in the respective bindings.
Signed-off-by: Aswath Govindraju <[email protected]>
---
.../devicetree/bindings/phy/ti,tcan104x-can.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
index 6107880e5246..5b2b08016635 100644
--- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -37,6 +37,18 @@ properties:
max bit rate supported in bps
minimum: 1
+ mux-states:
+ description:
+ mux controller node to route the signals from controller to
+ transceiver. Depending on the mux chip and the control lines
+ in it, the first and second parameters can be used for
+ representing control line and state. The number of arguments
+ is to be used based on '#mux-state-cells' property in the
+ mux-controller node. If '#mux-state-cells' is equal to
+ one then, then the argument to be used would be the state.
+ If it is set to two, then the first argument is the control
+ line and the second argument would be its corresponding state.
+
required:
- compatible
- '#phy-cells'
@@ -53,4 +65,5 @@ examples:
max-bitrate = <5000000>;
standby-gpios = <&wakeup_gpio1 16 GPIO_ACTIVE_LOW>;
enable-gpios = <&main_gpio1 67 GPIO_ACTIVE_HIGH>;
+ mux-states = <&mux0 1>;
};
--
2.17.1
On some boards, for routing CAN signals from controller to transceiver,
muxes might need to be set. Therefore, add support for setting the mux by
reading the mux-states property from the device tree node.
Signed-off-by: Aswath Govindraju <[email protected]>
---
drivers/phy/Kconfig | 1 +
drivers/phy/phy-can-transceiver.c | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 82b63e60c5a2..300b0f2b5f84 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -64,6 +64,7 @@ config USB_LGM_PHY
config PHY_CAN_TRANSCEIVER
tristate "CAN transceiver PHY"
select GENERIC_PHY
+ select MULTIPLEXER
help
This option enables support for CAN transceivers as a PHY. This
driver provides function for putting the transceivers in various
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 6f3fe37dee0e..cb91d0e94da7 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -10,6 +10,7 @@
#include<linux/module.h>
#include<linux/gpio.h>
#include<linux/gpio/consumer.h>
+#include <linux/mux/consumer.h>
struct can_transceiver_data {
u32 flags;
@@ -21,13 +22,22 @@ struct can_transceiver_phy {
struct phy *generic_phy;
struct gpio_desc *standby_gpio;
struct gpio_desc *enable_gpio;
+ struct mux_state *mux_state;
};
/* Power on function */
static int can_transceiver_phy_power_on(struct phy *phy)
{
+ int ret;
struct can_transceiver_phy *can_transceiver_phy = phy_get_drvdata(phy);
+ if (can_transceiver_phy->mux_state) {
+ ret = mux_state_select(can_transceiver_phy->mux_state);
+ if (ret) {
+ dev_err(&phy->dev, "Failed to select CAN mux: %d\n", ret);
+ return ret;
+ }
+ }
if (can_transceiver_phy->standby_gpio)
gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 0);
if (can_transceiver_phy->enable_gpio)
@@ -45,6 +55,8 @@ static int can_transceiver_phy_power_off(struct phy *phy)
gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 1);
if (can_transceiver_phy->enable_gpio)
gpiod_set_value_cansleep(can_transceiver_phy->enable_gpio, 0);
+ if (can_transceiver_phy->mux_state)
+ mux_state_deselect(can_transceiver_phy->mux_state);
return 0;
}
@@ -95,6 +107,16 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
drvdata = match->data;
+ if (of_property_read_bool(dev->of_node, "mux-states")) {
+ struct mux_state *mux_state;
+
+ mux_state = devm_mux_state_get(dev, NULL);
+ if (IS_ERR(mux_state))
+ return dev_err_probe(&pdev->dev, PTR_ERR(mux_state),
+ "failed to get mux\n");
+ can_transceiver_phy->mux_state = mux_state;
+ }
+
phy = devm_phy_create(dev, dev->of_node,
&can_transceiver_phy_ops);
if (IS_ERR(phy)) {
--
2.17.1
On Thu, Dec 02, 2021 at 06:40:01PM +0530, Aswath Govindraju wrote:
> On some boards, for routing CAN signals from controller to transceivers,
> muxes might need to be set. This can be implemented using mux-states
> property. Therefore, document the same in the respective bindings.
>
> Signed-off-by: Aswath Govindraju <[email protected]>
> ---
> .../devicetree/bindings/phy/ti,tcan104x-can.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> index 6107880e5246..5b2b08016635 100644
> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
> @@ -37,6 +37,18 @@ properties:
> max bit rate supported in bps
> minimum: 1
>
> + mux-states:
> + description:
> + mux controller node to route the signals from controller to
> + transceiver. Depending on the mux chip and the control lines
> + in it, the first and second parameters can be used for
> + representing control line and state. The number of arguments
> + is to be used based on '#mux-state-cells' property in the
> + mux-controller node. If '#mux-state-cells' is equal to
> + one then, then the argument to be used would be the state.
> + If it is set to two, then the first argument is the control
> + line and the second argument would be its corresponding state.
No need to redefine how a common property works here. What you do need
to define is how many entries and what they are for if more than 1.
Rob
Hi Rob,
On 14/12/21 1:49 am, Rob Herring wrote:
> On Thu, Dec 02, 2021 at 06:40:01PM +0530, Aswath Govindraju wrote:
>> On some boards, for routing CAN signals from controller to transceivers,
>> muxes might need to be set. This can be implemented using mux-states
>> property. Therefore, document the same in the respective bindings.
>>
>> Signed-off-by: Aswath Govindraju <[email protected]>
>> ---
>> .../devicetree/bindings/phy/ti,tcan104x-can.yaml | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> index 6107880e5246..5b2b08016635 100644
>> --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
>> @@ -37,6 +37,18 @@ properties:
>> max bit rate supported in bps
>> minimum: 1
>>
>> + mux-states:
>> + description:
>> + mux controller node to route the signals from controller to
>> + transceiver. Depending on the mux chip and the control lines
>> + in it, the first and second parameters can be used for
>> + representing control line and state. The number of arguments
>> + is to be used based on '#mux-state-cells' property in the
>> + mux-controller node. If '#mux-state-cells' is equal to
>> + one then, then the argument to be used would be the state.
>> + If it is set to two, then the first argument is the control
>> + line and the second argument would be its corresponding state.
>
> No need to redefine how a common property works here. What you do need
> to define is how many entries and what they are for if more than 1.
>
Got it. So, I'll remove the common part that describes about the number
of arguments and only include what the arguments would mean given the
number of arguments
mux-states:
description:
mux controller node to route the signals from controller to
transceiver. Two arguments can be present depending on the mux
chip. If mux-states has one argument then it represents the state.
If there are two arguments then the first argument is the control
line and the second argument is its corresponding state.
Thanks,
Aswath
> Rob
>
On 02-12-21, 18:40, Aswath Govindraju wrote:
> On some boards, for routing CAN signals from controller to transceiver,
> muxes might need to be set. Therefore, add support for setting the mux by
> reading the mux-states property from the device tree node.
>
> Signed-off-by: Aswath Govindraju <[email protected]>
> ---
> drivers/phy/Kconfig | 1 +
> drivers/phy/phy-can-transceiver.c | 22 ++++++++++++++++++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 82b63e60c5a2..300b0f2b5f84 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -64,6 +64,7 @@ config USB_LGM_PHY
> config PHY_CAN_TRANSCEIVER
> tristate "CAN transceiver PHY"
> select GENERIC_PHY
> + select MULTIPLEXER
> help
> This option enables support for CAN transceivers as a PHY. This
> driver provides function for putting the transceivers in various
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 6f3fe37dee0e..cb91d0e94da7 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
> @@ -10,6 +10,7 @@
> #include<linux/module.h>
> #include<linux/gpio.h>
> #include<linux/gpio/consumer.h>
> +#include <linux/mux/consumer.h>
>
> struct can_transceiver_data {
> u32 flags;
> @@ -21,13 +22,22 @@ struct can_transceiver_phy {
> struct phy *generic_phy;
> struct gpio_desc *standby_gpio;
> struct gpio_desc *enable_gpio;
> + struct mux_state *mux_state;
> };
>
> /* Power on function */
> static int can_transceiver_phy_power_on(struct phy *phy)
> {
> + int ret;
> struct can_transceiver_phy *can_transceiver_phy = phy_get_drvdata(phy);
reverse christmas tree notation is typically use, so new addition at the
end here please
>
> + if (can_transceiver_phy->mux_state) {
> + ret = mux_state_select(can_transceiver_phy->mux_state);
> + if (ret) {
> + dev_err(&phy->dev, "Failed to select CAN mux: %d\n", ret);
> + return ret;
> + }
> + }
> if (can_transceiver_phy->standby_gpio)
> gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 0);
> if (can_transceiver_phy->enable_gpio)
> @@ -45,6 +55,8 @@ static int can_transceiver_phy_power_off(struct phy *phy)
> gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 1);
> if (can_transceiver_phy->enable_gpio)
> gpiod_set_value_cansleep(can_transceiver_phy->enable_gpio, 0);
> + if (can_transceiver_phy->mux_state)
> + mux_state_deselect(can_transceiver_phy->mux_state);
>
> return 0;
> }
> @@ -95,6 +107,16 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
> drvdata = match->data;
>
> + if (of_property_read_bool(dev->of_node, "mux-states")) {
> + struct mux_state *mux_state;
> +
> + mux_state = devm_mux_state_get(dev, NULL);
> + if (IS_ERR(mux_state))
> + return dev_err_probe(&pdev->dev, PTR_ERR(mux_state),
> + "failed to get mux\n");
> + can_transceiver_phy->mux_state = mux_state;
> + }
> +
> phy = devm_phy_create(dev, dev->of_node,
> &can_transceiver_phy_ops);
> if (IS_ERR(phy)) {
> --
> 2.17.1
--
~Vinod
Hi All,
On 02/12/21 6:40 pm, Aswath Govindraju wrote:
> The following series of patches add support for setting
> muxes to route signals from CAN controller to transceiver
> by reading the property mux-states from the device tree
> node
>
> The following series of patches are dependent on,
> - https://lkml.org/lkml/2021/12/2/423
>
Thank you for the comments. I have posted a respin(v2) for this series
after making the fixes.
Thanks,
Aswath
> Aswath Govindraju (2):
> dt-bindings: phy: ti,tcan104x-can: Document mux-states property
> phy: phy-can-transceiver: Add support for setting mux
>
> .../bindings/phy/ti,tcan104x-can.yaml | 13 +++++++++++
> drivers/phy/Kconfig | 1 +
> drivers/phy/phy-can-transceiver.c | 22 +++++++++++++++++++
> 3 files changed, 36 insertions(+)
>