| Message ID | 20240819-lpm-v6-10-constraints-pmdomain-v2-0-461325a6008f@baylibre.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | pmdomain: ti_sci: collect and send low-power mode constraints | expand |
On Aug 19, 2024 at 17:00:10 -0700, Kevin Hilman wrote: > The latest (10.x) version of the firmware for the PM co-processor (aka > device manager, or DM) adds support for a "managed" mode, where the DM > firmware will select the specific low power state which is entered > when Linux requests a system-wide suspend. > > In this mode, the DM will always attempt the deepest low-power state > available for the SoC. > > However, Linux (or OSes running on other cores) may want to constrain > the DM for certain use cases. For example, the deepest state may have > a wakeup/resume latency that is too long for certain use cases. Or, > some wakeup-capable devices may potentially be powered off in deep > low-power states, but if one of those devices is enabled as a wakeup > source, it should not be powered off. > > These kinds of constraints are are already known in Linux by the use > of existing APIs such as per-device PM QoS and device wakeup APIs, but > now we need to communicate these constraints to the DM. > > For TI SoCs with TI SCI support, all DM-managed devices will be > connected to a TI SCI PM domain. So the goal of this series is to use > the PM domain driver for TI SCI devices to collect constraints, and > communicate them to the DM via the new TI SCI APIs. > > This is all managed by TI SCI PM domain code. No new APIs are needed > by Linux drivers. Any device that is managed by TI SCI will be > checked for QoS constraints or wakeup capability and the constraints > will be collected and sent to the DM. > > This series depends on the support for the new TI SCI APIs (v10) and > was also tested with this series to update 8250_omap serial support > for AM62x[2]. > > [1] https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com > [2] https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/ > > Signed-off-by: Kevin Hilman <khilman@baylibre.com> > --- Since I applied this series to the v10 TISCI series as well, and tested: For the series, Tested-by: Dhruva Gole <d-gole@ti.com> Logs: https://gist.github.com/DhruvaG2000/658d0d4683b13ab41025df19a8eafc2f Tree with all the patches applied: https://github.com/DhruvaG2000/v-linux/tree/lpm-k3-next
On Tue, 20 Aug 2024 at 02:00, Kevin Hilman <khilman@baylibre.com> wrote: > > The latest (10.x) version of the firmware for the PM co-processor (aka > device manager, or DM) adds support for a "managed" mode, where the DM > firmware will select the specific low power state which is entered > when Linux requests a system-wide suspend. > > In this mode, the DM will always attempt the deepest low-power state > available for the SoC. > > However, Linux (or OSes running on other cores) may want to constrain > the DM for certain use cases. For example, the deepest state may have > a wakeup/resume latency that is too long for certain use cases. Or, > some wakeup-capable devices may potentially be powered off in deep > low-power states, but if one of those devices is enabled as a wakeup > source, it should not be powered off. > > These kinds of constraints are are already known in Linux by the use > of existing APIs such as per-device PM QoS and device wakeup APIs, but > now we need to communicate these constraints to the DM. > > For TI SoCs with TI SCI support, all DM-managed devices will be > connected to a TI SCI PM domain. So the goal of this series is to use > the PM domain driver for TI SCI devices to collect constraints, and > communicate them to the DM via the new TI SCI APIs. > > This is all managed by TI SCI PM domain code. No new APIs are needed > by Linux drivers. Any device that is managed by TI SCI will be > checked for QoS constraints or wakeup capability and the constraints > will be collected and sent to the DM. > > This series depends on the support for the new TI SCI APIs (v10) and > was also tested with this series to update 8250_omap serial support > for AM62x[2]. > > [1] https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com > [2] https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/ > > Signed-off-by: Kevin Hilman <khilman@baylibre.com> > --- > Changes in v2: > > - To simplify this version a bit, drop the pmdomain ->power_off() > changes. Constraints only sent during ->suspend() path. The pmdomain > path was an optimization that may be added back later. > - With the above simplification, drop the extra state variables that > had been added to keep track of constraint status. > - Link to v1: https://lore.kernel.org/r/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com > > --- > Kevin Hilman (3): > pmdomain: ti_sci: add per-device latency constraint management > pmdomain: ti_sci: add wakeup constraint management > pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups > > drivers/pmdomain/ti/ti_sci_pm_domains.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 76 insertions(+) > --- > base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64 > change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449 > > Best regards, > -- > Kevin Hilman <khilman@baylibre.com> Besides a couple of minor things that I have commented on for each patch, this looks okay to me! Taking into account the other series that this depends on, what is the best merging strategy? Is it safe for me to take it through my pmdomain tree? Kind regards Uffe
Ulf Hansson <ulf.hansson@linaro.org> writes: > On Tue, 20 Aug 2024 at 02:00, Kevin Hilman <khilman@baylibre.com> wrote: >> >> The latest (10.x) version of the firmware for the PM co-processor (aka >> device manager, or DM) adds support for a "managed" mode, where the DM >> firmware will select the specific low power state which is entered >> when Linux requests a system-wide suspend. >> >> In this mode, the DM will always attempt the deepest low-power state >> available for the SoC. >> >> However, Linux (or OSes running on other cores) may want to constrain >> the DM for certain use cases. For example, the deepest state may have >> a wakeup/resume latency that is too long for certain use cases. Or, >> some wakeup-capable devices may potentially be powered off in deep >> low-power states, but if one of those devices is enabled as a wakeup >> source, it should not be powered off. >> >> These kinds of constraints are are already known in Linux by the use >> of existing APIs such as per-device PM QoS and device wakeup APIs, but >> now we need to communicate these constraints to the DM. >> >> For TI SoCs with TI SCI support, all DM-managed devices will be >> connected to a TI SCI PM domain. So the goal of this series is to use >> the PM domain driver for TI SCI devices to collect constraints, and >> communicate them to the DM via the new TI SCI APIs. >> >> This is all managed by TI SCI PM domain code. No new APIs are needed >> by Linux drivers. Any device that is managed by TI SCI will be >> checked for QoS constraints or wakeup capability and the constraints >> will be collected and sent to the DM. >> >> This series depends on the support for the new TI SCI APIs (v10) and >> was also tested with this series to update 8250_omap serial support >> for AM62x[2]. >> >> [1] https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com >> [2] https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/ >> >> Signed-off-by: Kevin Hilman <khilman@baylibre.com> >> --- >> Changes in v2: >> >> - To simplify this version a bit, drop the pmdomain ->power_off() >> changes. Constraints only sent during ->suspend() path. The pmdomain >> path was an optimization that may be added back later. >> - With the above simplification, drop the extra state variables that >> had been added to keep track of constraint status. >> - Link to v1: https://lore.kernel.org/r/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com >> >> --- >> Kevin Hilman (3): >> pmdomain: ti_sci: add per-device latency constraint management >> pmdomain: ti_sci: add wakeup constraint management >> pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups >> >> drivers/pmdomain/ti/ti_sci_pm_domains.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 76 insertions(+) >> --- >> base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64 >> change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449 >> >> Best regards, >> -- >> Kevin Hilman <khilman@baylibre.com> > > Besides a couple of minor things that I have commented on for each > patch, this looks okay to me! > > Taking into account the other series that this depends on, what is the > best merging strategy? Is it safe for me to take it through my > pmdomain tree? That other series should be merged shortly, so I will check with Nishanth (on cc) if he can create an immutable branch/tag that you could use in your tree. It has a build-time dependency on that other series, so I think this is the best way. Alternatively, if you don't expect this to clash with other changes in your tree, with your ack/reviewed-by, Nishanth could merge this series via his tree and we could avoid the cross-tree shuffle. Either way will work. Up to you. Kevin
On Fri, 6 Sept 2024 at 00:07, Kevin Hilman <khilman@baylibre.com> wrote: > > Ulf Hansson <ulf.hansson@linaro.org> writes: > > > On Tue, 20 Aug 2024 at 02:00, Kevin Hilman <khilman@baylibre.com> wrote: > >> > >> The latest (10.x) version of the firmware for the PM co-processor (aka > >> device manager, or DM) adds support for a "managed" mode, where the DM > >> firmware will select the specific low power state which is entered > >> when Linux requests a system-wide suspend. > >> > >> In this mode, the DM will always attempt the deepest low-power state > >> available for the SoC. > >> > >> However, Linux (or OSes running on other cores) may want to constrain > >> the DM for certain use cases. For example, the deepest state may have > >> a wakeup/resume latency that is too long for certain use cases. Or, > >> some wakeup-capable devices may potentially be powered off in deep > >> low-power states, but if one of those devices is enabled as a wakeup > >> source, it should not be powered off. > >> > >> These kinds of constraints are are already known in Linux by the use > >> of existing APIs such as per-device PM QoS and device wakeup APIs, but > >> now we need to communicate these constraints to the DM. > >> > >> For TI SoCs with TI SCI support, all DM-managed devices will be > >> connected to a TI SCI PM domain. So the goal of this series is to use > >> the PM domain driver for TI SCI devices to collect constraints, and > >> communicate them to the DM via the new TI SCI APIs. > >> > >> This is all managed by TI SCI PM domain code. No new APIs are needed > >> by Linux drivers. Any device that is managed by TI SCI will be > >> checked for QoS constraints or wakeup capability and the constraints > >> will be collected and sent to the DM. > >> > >> This series depends on the support for the new TI SCI APIs (v10) and > >> was also tested with this series to update 8250_omap serial support > >> for AM62x[2]. > >> > >> [1] https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com > >> [2] https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/ > >> > >> Signed-off-by: Kevin Hilman <khilman@baylibre.com> > >> --- > >> Changes in v2: > >> > >> - To simplify this version a bit, drop the pmdomain ->power_off() > >> changes. Constraints only sent during ->suspend() path. The pmdomain > >> path was an optimization that may be added back later. > >> - With the above simplification, drop the extra state variables that > >> had been added to keep track of constraint status. > >> - Link to v1: https://lore.kernel.org/r/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com > >> > >> --- > >> Kevin Hilman (3): > >> pmdomain: ti_sci: add per-device latency constraint management > >> pmdomain: ti_sci: add wakeup constraint management > >> pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups > >> > >> drivers/pmdomain/ti/ti_sci_pm_domains.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 76 insertions(+) > >> --- > >> base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64 > >> change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449 > >> > >> Best regards, > >> -- > >> Kevin Hilman <khilman@baylibre.com> > > > > Besides a couple of minor things that I have commented on for each > > patch, this looks okay to me! > > > > Taking into account the other series that this depends on, what is the > > best merging strategy? Is it safe for me to take it through my > > pmdomain tree? > > > That other series should be merged shortly, so I will check with > Nishanth (on cc) if he can create an immutable branch/tag that you could > use in your tree. > > It has a build-time dependency on that other series, so I think this is > the best way. > > Alternatively, if you don't expect this to clash with other changes in > your tree, with your ack/reviewed-by, Nishanth could merge this series > via his tree and we could avoid the cross-tree shuffle. At the moment there shouldn't be any clashes I think. Let's use Nishanth's tree and see how it goes. I will ack/review the patches when they are ready. Kind regards Uffe
The latest (10.x) version of the firmware for the PM co-processor (aka device manager, or DM) adds support for a "managed" mode, where the DM firmware will select the specific low power state which is entered when Linux requests a system-wide suspend. In this mode, the DM will always attempt the deepest low-power state available for the SoC. However, Linux (or OSes running on other cores) may want to constrain the DM for certain use cases. For example, the deepest state may have a wakeup/resume latency that is too long for certain use cases. Or, some wakeup-capable devices may potentially be powered off in deep low-power states, but if one of those devices is enabled as a wakeup source, it should not be powered off. These kinds of constraints are are already known in Linux by the use of existing APIs such as per-device PM QoS and device wakeup APIs, but now we need to communicate these constraints to the DM. For TI SoCs with TI SCI support, all DM-managed devices will be connected to a TI SCI PM domain. So the goal of this series is to use the PM domain driver for TI SCI devices to collect constraints, and communicate them to the DM via the new TI SCI APIs. This is all managed by TI SCI PM domain code. No new APIs are needed by Linux drivers. Any device that is managed by TI SCI will be checked for QoS constraints or wakeup capability and the constraints will be collected and sent to the DM. This series depends on the support for the new TI SCI APIs (v10) and was also tested with this series to update 8250_omap serial support for AM62x[2]. [1] https://lore.kernel.org/all/20240801195422.2296347-1-msp@baylibre.com [2] https://lore.kernel.org/all/20240807141227.1093006-1-msp@baylibre.com/ Signed-off-by: Kevin Hilman <khilman@baylibre.com> --- Changes in v2: - To simplify this version a bit, drop the pmdomain ->power_off() changes. Constraints only sent during ->suspend() path. The pmdomain path was an optimization that may be added back later. - With the above simplification, drop the extra state variables that had been added to keep track of constraint status. - Link to v1: https://lore.kernel.org/r/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com --- Kevin Hilman (3): pmdomain: ti_sci: add per-device latency constraint management pmdomain: ti_sci: add wakeup constraint management pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups drivers/pmdomain/ti/ti_sci_pm_domains.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) --- base-commit: ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64 change-id: 20240802-lpm-v6-10-constraints-pmdomain-f33df5aef449 Best regards,