.../devicetree/bindings/net/can/bosch,m_can.yaml | 22 ++++ drivers/net/can/m_can/m_can.c | 111 ++++++++++++++++++++- drivers/net/can/m_can/m_can.h | 4 + drivers/net/can/m_can/m_can_pci.c | 4 +- drivers/net/can/m_can/m_can_platform.c | 4 +- drivers/net/can/m_can/tcan4x5x-core.c | 4 +- 6 files changed, 140 insertions(+), 9 deletions(-)
Hi,
This series adds support for wakeup capabilities to the m_can driver, which
is necessary for enabling Partial-IO functionality on am62, am62a, and am62p
SoCs. It implements the wake-on-lan interface for m_can devices and handles
the pinctrl states needed for wakeup functionality.
am62, am62a and am62p support Partial-IO, a low power system state in which
nearly everything is turned off except the pins of the CANUART group. This group
contains mcu_mcan0, mcu_mcan1, wkup_uart0 and mcu_uart0 devices.
To support mcu_mcan0 and mcu_mcan1 wakeup for the mentioned SoCs, the
series introduces a notion of wake-on-lan for m_can. If the user decides
to enable wake-on-lan for a m_can device, the device is set to wakeup
enabled. A 'wakeup' pinctrl state is selected to enable wakeup flags for
the relevant pins. If wake-on-lan is disabled the default pinctrl is
selected.
Partial-IO Overview
------------------
Partial-IO is a low power system state in which nearly everything is
turned off except the pins of the CANUART group (mcu_mcan0, mcu_mcan1,
wkup_uart0 and mcu_uart0). These devices can trigger a wakeup of the system
on pin activity. Note that this does not resume the system as the DDR is
off as well. So this state can be considered a power-off state with wakeup
capabilities.
A documentation can also be found in section 6.2.4 in the TRM:
https://www.ti.com/lit/pdf/spruiv7
Implementation Details
----------------------
The complete Partial-IO feature requires three coordinated series, each handling
a different aspect of the implementation:
1. This series (m_can driver): Implements device-specific wakeup functionality
for m_can devices, allowing them to be set as wakeup sources.
2. Devicetree series: Defines system states and wakeup sources in the
devicetree for am62, am62a and am62p.
https://gitlab.baylibre.com/msp8/linux/-/tree/topic/am62-dt-partialio/v6.15?ref_type=heads
3. TI-SCI firmware series: Implements the firmware interface to enter Partial-IO
mode when appropriate wakeup sources are enabled.
https://gitlab.baylibre.com/msp8/linux/-/tree/topic/tisci-partialio/v6.15?ref_type=heads
Devicetree Bindings
-------------------
The wakeup-source property is used with references to
system-idle-states. This depends on the dt-schema pull request that adds
bindings for system-idle-states and updates the binding for wakeup-source:
https://github.com/devicetree-org/dt-schema/pull/150
Testing
-------
A test branch is available here that includes all patches required to
test Partial-IO:
https://gitlab.baylibre.com/msp8/linux/-/tree/integration/am62-partialio/v6.15?ref_type=heads
After enabling Wake-on-LAN the system can be powered off and will enter
the Partial-IO state in which it can be woken up by activity on the
specific pins:
ethtool -s can0 wol p
ethtool -s can1 wol p
poweroff
I tested these patches on am62-lp-sk.
Best,
Markus
Previous versions:
v1: https://lore.kernel.org/lkml/20240523075347.1282395-1-msp@baylibre.com/
v2: https://lore.kernel.org/lkml/20240729074135.3850634-1-msp@baylibre.com/
v3: https://lore.kernel.org/lkml/20241011-topic-mcan-wakeup-source-v6-12-v3-0-9752c714ad12@baylibre.com
v4: https://lore.kernel.org/r/20241015-topic-mcan-wakeup-source-v6-12-v4-0-fdac1d1e7aa6@baylibre.com
v5: https://lore.kernel.org/r/20241028-topic-mcan-wakeup-source-v6-12-v5-0-33edc0aba629@baylibre.com
v6: https://lore.kernel.org/r/20241219-topic-mcan-wakeup-source-v6-12-v6-0-1356c7f7cfda@baylibre.com
Changes in v7:
- Separate this series from "firmware: ti_sci: Partial-IO support"
again as was requested internally
- All DT changes are now in their own series to avoid conflicts
- wakeup-source definition in the m_can binding is now only an
extension to the dt-schema binding and a pull request was created
Changes in v6:
- Rebased to v6.13-rc1
- After feedback of the other Partial-IO series, I updated this series
and removed all use of regulator-related patches.
- wakeup-source is now not only a boolean property but can also be a
list of power states in which the device is wakeup capable.
Changes in v5:
- Make the check of wol options nicer to read
Changes in v4:
- Remove leftover testing code that always returned -EIO in a specific
- Redesign pincontrol setup to be easier understandable and less nested
- Fix missing parantheses around wol_enable expression
- Remove | from binding description
Changes in v3:
- Rebase to v6.12-rc1
- Change 'wakeup-source' to only 'true'
- Simplify m_can_set_wol by returning early on error
- Add vio-suuply binding and handling of this optional property.
vio-supply is used to reflect the SoC architecture and which power
line powers the m_can unit. This is important as some units are
powered in special low power modes.
Changes in v2:
- Rebase to v6.11-rc1
- Squash these two patches for the binding into one:
dt-bindings: can: m_can: Add wakeup-source property
dt-bindings: can: m_can: Add wakeup pinctrl state
- Add error handling to multiple patches of the m_can driver
- Add error handling in m_can_class_allocate_dev(). This also required
to add a new patch to return error pointers from
m_can_class_allocate_dev().
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
---
Markus Schneider-Pargmann (4):
dt-bindings: can: m_can: Add wakeup properties
can: m_can: Map WoL to device_set_wakeup_enable
can: m_can: Return ERR_PTR on error in allocation
can: m_can: Support pinctrl wakeup state
.../devicetree/bindings/net/can/bosch,m_can.yaml | 22 ++++
drivers/net/can/m_can/m_can.c | 111 ++++++++++++++++++++-
drivers/net/can/m_can/m_can.h | 4 +
drivers/net/can/m_can/m_can_pci.c | 4 +-
drivers/net/can/m_can/m_can_platform.c | 4 +-
drivers/net/can/m_can/tcan4x5x-core.c | 4 +-
6 files changed, 140 insertions(+), 9 deletions(-)
---
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
change-id: 20241009-topic-mcan-wakeup-source-v6-12-8c1d69931bd8
Best regards,
--
Markus Schneider-Pargmann <msp@baylibre.com>
On 21.04.2025 10:10:36, Markus Schneider-Pargmann wrote: [...] > Devicetree Bindings > ------------------- > The wakeup-source property is used with references to > system-idle-states. This depends on the dt-schema pull request that adds > bindings for system-idle-states and updates the binding for wakeup-source: > https://github.com/devicetree-org/dt-schema/pull/150 How can we get an Ack for patch 1 by the DT people? regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
On 03/05/2025 16:03, Marc Kleine-Budde wrote: > On 21.04.2025 10:10:36, Markus Schneider-Pargmann wrote: > > [...] > >> Devicetree Bindings >> ------------------- >> The wakeup-source property is used with references to >> system-idle-states. This depends on the dt-schema pull request that adds >> bindings for system-idle-states and updates the binding for wakeup-source: >> https://github.com/devicetree-org/dt-schema/pull/150 > > How can we get an Ack for patch 1 by the DT people? No ack, because it waits on dtschema changes. I commented there some time ago but there was no response from the author. Best regards, Krzysztof
On Sun May 4, 2025 at 7:01 PM CEST, Krzysztof Kozlowski wrote: > On 03/05/2025 16:03, Marc Kleine-Budde wrote: >> On 21.04.2025 10:10:36, Markus Schneider-Pargmann wrote: >> >> [...] >> >>> Devicetree Bindings >>> ------------------- >>> The wakeup-source property is used with references to >>> system-idle-states. This depends on the dt-schema pull request that adds >>> bindings for system-idle-states and updates the binding for wakeup-source: >>> https://github.com/devicetree-org/dt-schema/pull/150 >> >> How can we get an Ack for patch 1 by the DT people? > > No ack, because it waits on dtschema changes. I commented there some > time ago but there was no response from the author. I wasn't available last week, but there is a response now. Basically I don't know if you would like to have a different name for idle-state-name or a different description. Rest is solved. Best Markus
© 2016 - 2025 Red Hat, Inc.