This series adds driver patches to support MCAN in TI's AM654x-idk.
v2: Model the sandby line to the transceiver as a regulator.
Faiz Abbas (3):
dt-bindings: m_can: Add Documentation for transceiver regulator
can: m_can: m_can_platform: Add support for enabling transceiver
arm64: defconfig: Add Support for Bosch M_CAN controllers
Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
arch/arm64/configs/defconfig | 3 +++
drivers/net/can/m_can/m_can_platform.c | 6 ++++++
3 files changed, 12 insertions(+)
--
2.19.2
Enable configs for supporting Bosch M_CAN controllers.
Signed-off-by: Faiz Abbas <[email protected]>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 905109f6814f..b25bbcf691b6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -161,6 +161,9 @@ CONFIG_QRTR=m
CONFIG_QRTR_SMD=m
CONFIG_QRTR_TUN=m
CONFIG_BPF_JIT=y
+CONFIG_CAN=m
+CONFIG_CAN_M_CAN=m
+CONFIG_CAN_M_CAN_PLATFORM=m
CONFIG_BT=m
CONFIG_BT_HIDP=m
# CONFIG_BT_HS is not set
--
2.19.2
CAN transceivers on some boards have a standby line which can be
toggled to enable/disable the transceiver. Model this as an optional
fixed xceiver regulator.
Signed-off-by: Faiz Abbas <[email protected]>
Acked-by: Sriram Dash <[email protected]>
---
drivers/net/can/m_can/m_can_platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
index 38ea5e600fb8..719468fab507 100644
--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -6,6 +6,7 @@
// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include "m_can.h"
@@ -57,6 +58,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
{
struct m_can_classdev *mcan_class;
struct m_can_plat_priv *priv;
+ struct regulator *reg_xceiver;
struct resource *res;
void __iomem *addr;
void __iomem *mram_addr;
@@ -111,6 +113,10 @@ static int m_can_plat_probe(struct platform_device *pdev)
m_can_init_ram(mcan_class);
+ reg_xceiver = devm_regulator_get_optional(&pdev->dev, "xceiver");
+ if (PTR_ERR(reg_xceiver) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
ret = m_can_class_register(mcan_class);
failed_ret:
--
2.19.2
Some CAN transceivers have a standby line that needs to be asserted
before they can be used. Model this GPIO lines as an optional
fixed-regulator node. Document bindings for the same.
Signed-off-by: Faiz Abbas <[email protected]>
---
Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
index ed614383af9c..f17e2a5207dc 100644
--- a/Documentation/devicetree/bindings/net/can/m_can.txt
+++ b/Documentation/devicetree/bindings/net/can/m_can.txt
@@ -48,6 +48,9 @@ Optional Subnode:
that can be used for CAN/CAN-FD modes. See
Documentation/devicetree/bindings/net/can/can-transceiver.txt
for details.
+
+- xceiver-supply: Regulator that powers the CAN transceiver.
+
Example:
SoC dtsi:
m_can1: can@20e8000 {
--
2.19.2
Faiz
On 2/17/20 8:28 AM, Faiz Abbas wrote:
> CAN transceivers on some boards have a standby line which can be
> toggled to enable/disable the transceiver. Model this as an optional
> fixed xceiver regulator.
>
> Signed-off-by: Faiz Abbas <[email protected]>
> Acked-by: Sriram Dash <[email protected]>
> ---
> drivers/net/can/m_can/m_can_platform.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
> index 38ea5e600fb8..719468fab507 100644
> --- a/drivers/net/can/m_can/m_can_platform.c
> +++ b/drivers/net/can/m_can/m_can_platform.c
> @@ -6,6 +6,7 @@
> // Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
>
> #include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
>
> #include "m_can.h"
>
> @@ -57,6 +58,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
> {
> struct m_can_classdev *mcan_class;
> struct m_can_plat_priv *priv;
> + struct regulator *reg_xceiver;
> struct resource *res;
> void __iomem *addr;
> void __iomem *mram_addr;
> @@ -111,6 +113,10 @@ static int m_can_plat_probe(struct platform_device *pdev)
>
> m_can_init_ram(mcan_class);
>
> + reg_xceiver = devm_regulator_get_optional(&pdev->dev, "xceiver");
> + if (PTR_ERR(reg_xceiver) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
Where is this regulator enabled?
Shouldn't the regulator be managed by runtime PM as well?
Dan
On Mon, Feb 17, 2020 at 07:58:34PM +0530, Faiz Abbas wrote:
> Some CAN transceivers have a standby line that needs to be asserted
> before they can be used. Model this GPIO lines as an optional
> fixed-regulator node. Document bindings for the same.
>
> Signed-off-by: Faiz Abbas <[email protected]>
> ---
> Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
> 1 file changed, 3 insertions(+)
This has moved to DT schema in my tree, so please adjust it and resend.
> diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
> index ed614383af9c..f17e2a5207dc 100644
> --- a/Documentation/devicetree/bindings/net/can/m_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/m_can.txt
> @@ -48,6 +48,9 @@ Optional Subnode:
> that can be used for CAN/CAN-FD modes. See
> Documentation/devicetree/bindings/net/can/can-transceiver.txt
> for details.
> +
> +- xceiver-supply: Regulator that powers the CAN transceiver.
The supply for a transceiver should go in the transceiver node.
> +
> Example:
> SoC dtsi:
> m_can1: can@20e8000 {
> --
> 2.19.2
>
Hi Rob,
On 20/02/20 2:05 am, Rob Herring wrote:
> On Mon, Feb 17, 2020 at 07:58:34PM +0530, Faiz Abbas wrote:
>> Some CAN transceivers have a standby line that needs to be asserted
>> before they can be used. Model this GPIO lines as an optional
>> fixed-regulator node. Document bindings for the same.
>>
>> Signed-off-by: Faiz Abbas <[email protected]>
>> ---
>> Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>
> This has moved to DT schema in my tree, so please adjust it and resend.
Ok.
>
>> diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
>> index ed614383af9c..f17e2a5207dc 100644
>> --- a/Documentation/devicetree/bindings/net/can/m_can.txt
>> +++ b/Documentation/devicetree/bindings/net/can/m_can.txt
>> @@ -48,6 +48,9 @@ Optional Subnode:
>> that can be used for CAN/CAN-FD modes. See
>> Documentation/devicetree/bindings/net/can/can-transceiver.txt
>> for details.
>> +
>> +- xceiver-supply: Regulator that powers the CAN transceiver.
>
> The supply for a transceiver should go in the transceiver node.
>
Marc, while I have you here, do you agree with this?
Thanks,
Faiz
On 2/21/20 9:31 AM, Faiz Abbas wrote:
> Hi Rob,
>
> On 20/02/20 2:05 am, Rob Herring wrote:
>> On Mon, Feb 17, 2020 at 07:58:34PM +0530, Faiz Abbas wrote:
>>> Some CAN transceivers have a standby line that needs to be asserted
>>> before they can be used. Model this GPIO lines as an optional
>>> fixed-regulator node. Document bindings for the same.
>>>
>>> Signed-off-by: Faiz Abbas <[email protected]>
>>> ---
>>> Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
>>> 1 file changed, 3 insertions(+)
>>
>> This has moved to DT schema in my tree, so please adjust it and resend.
>
> Ok.
>>
>>> diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
>>> index ed614383af9c..f17e2a5207dc 100644
>>> --- a/Documentation/devicetree/bindings/net/can/m_can.txt
>>> +++ b/Documentation/devicetree/bindings/net/can/m_can.txt
>>> @@ -48,6 +48,9 @@ Optional Subnode:
>>> that can be used for CAN/CAN-FD modes. See
>>> Documentation/devicetree/bindings/net/can/can-transceiver.txt
>>> for details.
>>> +
>>> +- xceiver-supply: Regulator that powers the CAN transceiver.
>>
>> The supply for a transceiver should go in the transceiver node.
>>
>
> Marc, while I have you here, do you agree with this?
I'll look into the details later today.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 2/21/20 8:54 AM, Faiz Abbas wrote:
> Hi Dan,
>
> On 17/02/20 8:40 pm, Dan Murphy wrote:
>> Faiz
>>
>> On 2/17/20 8:28 AM, Faiz Abbas wrote:
>>> CAN transceivers on some boards have a standby line which can be
>>> toggled to enable/disable the transceiver. Model this as an optional
>>> fixed xceiver regulator.
>>>
>>> Signed-off-by: Faiz Abbas <[email protected]>
>>> Acked-by: Sriram Dash <[email protected]>
>>> ---
>>> drivers/net/can/m_can/m_can_platform.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/net/can/m_can/m_can_platform.c
>>> b/drivers/net/can/m_can/m_can_platform.c
>>> index 38ea5e600fb8..719468fab507 100644
>>> --- a/drivers/net/can/m_can/m_can_platform.c
>>> +++ b/drivers/net/can/m_can/m_can_platform.c
>>> @@ -6,6 +6,7 @@
>>> // Copyright (C) 2018-19 Texas Instruments Incorporated -
>>> http://www.ti.com/
>>> #include <linux/platform_device.h>
>>> +#include <linux/regulator/consumer.h>
>>> #include "m_can.h"
>>> @@ -57,6 +58,7 @@ static int m_can_plat_probe(struct platform_device
>>> *pdev)
>>> {
>>> struct m_can_classdev *mcan_class;
>>> struct m_can_plat_priv *priv;
>>> + struct regulator *reg_xceiver;
>>> struct resource *res;
>>> void __iomem *addr;
>>> void __iomem *mram_addr;
>>> @@ -111,6 +113,10 @@ static int m_can_plat_probe(struct
>>> platform_device *pdev)
>>> m_can_init_ram(mcan_class);
>>> + reg_xceiver = devm_regulator_get_optional(&pdev->dev, "xceiver");
>>> + if (PTR_ERR(reg_xceiver) == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> +
>>
>> Where is this regulator enabled?
>
> I have set regulator-boot-on flag in the dt so this didn't require an
> enable.
Please don't do this, please handle it properly.
>> Shouldn't the regulator be managed by runtime PM as well?
If so, then make the runtime pm kconfig option mandatory.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hi Dan,
On 17/02/20 8:40 pm, Dan Murphy wrote:
> Faiz
>
> On 2/17/20 8:28 AM, Faiz Abbas wrote:
>> CAN transceivers on some boards have a standby line which can be
>> toggled to enable/disable the transceiver. Model this as an optional
>> fixed xceiver regulator.
>>
>> Signed-off-by: Faiz Abbas <[email protected]>
>> Acked-by: Sriram Dash <[email protected]>
>> ---
>> drivers/net/can/m_can/m_can_platform.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/net/can/m_can/m_can_platform.c
>> b/drivers/net/can/m_can/m_can_platform.c
>> index 38ea5e600fb8..719468fab507 100644
>> --- a/drivers/net/can/m_can/m_can_platform.c
>> +++ b/drivers/net/can/m_can/m_can_platform.c
>> @@ -6,6 +6,7 @@
>> // Copyright (C) 2018-19 Texas Instruments Incorporated -
>> http://www.ti.com/
>> #include <linux/platform_device.h>
>> +#include <linux/regulator/consumer.h>
>> #include "m_can.h"
>> @@ -57,6 +58,7 @@ static int m_can_plat_probe(struct platform_device
>> *pdev)
>> {
>> struct m_can_classdev *mcan_class;
>> struct m_can_plat_priv *priv;
>> + struct regulator *reg_xceiver;
>> struct resource *res;
>> void __iomem *addr;
>> void __iomem *mram_addr;
>> @@ -111,6 +113,10 @@ static int m_can_plat_probe(struct
>> platform_device *pdev)
>> m_can_init_ram(mcan_class);
>> + reg_xceiver = devm_regulator_get_optional(&pdev->dev, "xceiver");
>> + if (PTR_ERR(reg_xceiver) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> +
>
> Where is this regulator enabled?
I have set regulator-boot-on flag in the dt so this didn't require an
enable.
> Shouldn't the regulator be managed by runtime PM as well?
>
Let me try this out.
Thanks,
Faiz
Hi Marc,
On 21/02/20 2:01 pm, Marc Kleine-Budde wrote:
> On 2/21/20 9:31 AM, Faiz Abbas wrote:
>> Hi Rob,
>>
>> On 20/02/20 2:05 am, Rob Herring wrote:
>>> On Mon, Feb 17, 2020 at 07:58:34PM +0530, Faiz Abbas wrote:
>>>> Some CAN transceivers have a standby line that needs to be asserted
>>>> before they can be used. Model this GPIO lines as an optional
>>>> fixed-regulator node. Document bindings for the same.
>>>>
>>>> Signed-off-by: Faiz Abbas <[email protected]>
>>>> ---
>>>> Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>
>>> This has moved to DT schema in my tree, so please adjust it and resend.
>>
>> Ok.
>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
>>>> index ed614383af9c..f17e2a5207dc 100644
>>>> --- a/Documentation/devicetree/bindings/net/can/m_can.txt
>>>> +++ b/Documentation/devicetree/bindings/net/can/m_can.txt
>>>> @@ -48,6 +48,9 @@ Optional Subnode:
>>>> that can be used for CAN/CAN-FD modes. See
>>>> Documentation/devicetree/bindings/net/can/can-transceiver.txt
>>>> for details.
>>>> +
>>>> +- xceiver-supply: Regulator that powers the CAN transceiver.
>>>
>>> The supply for a transceiver should go in the transceiver node.
>>>
>>
>> Marc, while I have you here, do you agree with this?
>
> I'll look into the details later today.
>
Sure. Be sure to take another look at my attempt to use the transceiver
with a phy driver some time ago.
https://lore.kernel.org/patchwork/patch/1006238/
Thanks,
Faiz
Marc,
On 26/02/20 2:40 pm, Faiz Abbas wrote:
> Hi Marc,
>
> On 21/02/20 2:01 pm, Marc Kleine-Budde wrote:
>> On 2/21/20 9:31 AM, Faiz Abbas wrote:
>>> Hi Rob,
>>>
>>> On 20/02/20 2:05 am, Rob Herring wrote:
>>>> On Mon, Feb 17, 2020 at 07:58:34PM +0530, Faiz Abbas wrote:
>>>>> Some CAN transceivers have a standby line that needs to be asserted
>>>>> before they can be used. Model this GPIO lines as an optional
>>>>> fixed-regulator node. Document bindings for the same.
>>>>>
>>>>> Signed-off-by: Faiz Abbas <[email protected]>
>>>>> ---
>>>>> Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> This has moved to DT schema in my tree, so please adjust it and resend.
>>>
>>> Ok.
>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
>>>>> index ed614383af9c..f17e2a5207dc 100644
>>>>> --- a/Documentation/devicetree/bindings/net/can/m_can.txt
>>>>> +++ b/Documentation/devicetree/bindings/net/can/m_can.txt
>>>>> @@ -48,6 +48,9 @@ Optional Subnode:
>>>>> that can be used for CAN/CAN-FD modes. See
>>>>> Documentation/devicetree/bindings/net/can/can-transceiver.txt
>>>>> for details.
>>>>> +
>>>>> +- xceiver-supply: Regulator that powers the CAN transceiver.
>>>>
>>>> The supply for a transceiver should go in the transceiver node.
>>>>
>>>
>>> Marc, while I have you here, do you agree with this?
>>
>> I'll look into the details later today.
>>
>
> Sure. Be sure to take another look at my attempt to use the transceiver
> with a phy driver some time ago.
>
> https://lore.kernel.org/patchwork/patch/1006238/
>
Do you have any comments?
Thanks,
Faiz
Hi Marc,
On 02/03/20 1:46 pm, Faiz Abbas wrote:
> Marc,
>
> On 26/02/20 2:40 pm, Faiz Abbas wrote:
>> Hi Marc,
>>
>> On 21/02/20 2:01 pm, Marc Kleine-Budde wrote:
>>> On 2/21/20 9:31 AM, Faiz Abbas wrote:
>>>> Hi Rob,
>>>>
>>>> On 20/02/20 2:05 am, Rob Herring wrote:
>>>>> On Mon, Feb 17, 2020 at 07:58:34PM +0530, Faiz Abbas wrote:
>>>>>> Some CAN transceivers have a standby line that needs to be asserted
>>>>>> before they can be used. Model this GPIO lines as an optional
>>>>>> fixed-regulator node. Document bindings for the same.
>>>>>>
>>>>>> Signed-off-by: Faiz Abbas <[email protected]>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/net/can/m_can.txt | 3 +++
>>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> This has moved to DT schema in my tree, so please adjust it and resend.
>>>>
>>>> Ok.
>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt b/Documentation/devicetree/bindings/net/can/m_can.txt
>>>>>> index ed614383af9c..f17e2a5207dc 100644
>>>>>> --- a/Documentation/devicetree/bindings/net/can/m_can.txt
>>>>>> +++ b/Documentation/devicetree/bindings/net/can/m_can.txt
>>>>>> @@ -48,6 +48,9 @@ Optional Subnode:
>>>>>> that can be used for CAN/CAN-FD modes. See
>>>>>> Documentation/devicetree/bindings/net/can/can-transceiver.txt
>>>>>> for details.
>>>>>> +
>>>>>> +- xceiver-supply: Regulator that powers the CAN transceiver.
>>>>>
>>>>> The supply for a transceiver should go in the transceiver node.
>>>>>
>>>>
>>>> Marc, while I have you here, do you agree with this?
>>>
>>> I'll look into the details later today.
>>>
>>
>> Sure. Be sure to take another look at my attempt to use the transceiver
>> with a phy driver some time ago.
>>
>> https://lore.kernel.org/patchwork/patch/1006238/
>>
>
> Do you have any comments?
>
Gentle ping.
Thanks,
Faiz