| Message ID | 20190417053211.2195-1-ping.bai@nxp.com |
|---|---|
| Headers | show |
| Series | Add power domain driver support for i.mx8m family | expand |
> From: Jacky Bai > Sent: Wednesday, April 17, 2019 1:27 PM > > The i.MX8M family is a set of NXP product focus on delivering the latest and > greatest video and audio experience combining state-of-the-art media-specific > features with high-performance processing while optimized for lowest power > consumption. > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to > this family. > > The GPC module is used to manage the PU power domains' power on/off. For > the whole i.MX8M family, different SoC has differnt power domain design. the > power up sequence has significant difference. > all the power sequence must be guaranteed by SW. Some domains' power up > sequence need to access the SRC module or sub-system specific GPR. > the SRC register & SS's register are not in in the GPC's memory range. > > it makes us hard to use the GPCv2 driver to cover all the different power up > requirement. Each time, a new SoC is added, we must modify the GPCv2 driver > to make it resuable for it. a lot of code need to be added in GPCv2 to support it. > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be > self-contained. Accessing the non-driver specific module's register is a bad > practice. Although, the GPC module provided the similar function for PU power > domain, but it is not 100% compatible with GPCv2. > > The most important thing is that the GPC & SRC module is a security critical > resource that security permission must be considered when building the > security system. The GPC module is not only used by PU power domain power > on/off. It is also used by the TF-A PSCI code to do the CPU core power > management. the SRC module control the CPU CORE reset and the CPU reset > vector address. if we give the non-secure world write permission to SRC. > System can be easily induced to malicious code. > Considering the security issue, it looks to me a right direction to move GPC power handling into ATF. It also helps build a more generic driver and ease other OS integration needed by customers (e.g. QNX, Win10). Lucas, How do you think of it? Regards Dong Aisheng > This patchset add a more generic power domain driver that give us the > possibility to use one driver to cover the whole i.MX8M family power domain > in kernel side. kernel side doesn't need to handle the power domain difference > anymore, all the sequence can be abstracted & handled in TF-A side. Most > important, We don't need to care if the GPC & SRC is security protected. > > Jacky Bai (3): > dt-bindings: power: Add power domain binding for i.mx8m family > soc: imx: Add power domain driver support for i.mx8m family > arm64: dts: freescale: Add power domain nodes for i.mx8mm > > .../bindings/power/fsl,imx8m-genpd.txt | 46 ++++ > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 103 ++++++++ > drivers/soc/imx/Kconfig | 6 + > drivers/soc/imx/Makefile | 1 + > drivers/soc/imx/imx8m_pm_domains.c | 224 > ++++++++++++++++++ > include/soc/imx/imx_sip.h | 12 + > 6 files changed, 392 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/power/fsl,imx8m-genpd.txt > create mode 100644 drivers/soc/imx/imx8m_pm_domains.c > create mode 100644 include/soc/imx/imx_sip.h > > -- > 2.21.0
Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: > > From: Jacky Bai > > Sent: Wednesday, April 17, 2019 1:27 PM > > > > The i.MX8M family is a set of NXP product focus on delivering the latest and > > greatest video and audio experience combining state-of-the-art media-specific > > features with high-performance processing while optimized for lowest power > > consumption. > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to > > this family. > > > > The GPC module is used to manage the PU power domains' power on/off. For > > the whole i.MX8M family, different SoC has differnt power domain design. the > > power up sequence has significant difference. > > all the power sequence must be guaranteed by SW. Some domains' power up > > sequence need to access the SRC module or sub-system specific GPR. > > the SRC register & SS's register are not in in the GPC's memory range. > > > > it makes us hard to use the GPCv2 driver to cover all the different power up > > requirement. Each time, a new SoC is added, we must modify the GPCv2 driver > > to make it resuable for it. a lot of code need to be added in GPCv2 to support it. > > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be > > self-contained. Accessing the non-driver specific module's register is a bad > > practice. Although, the GPC module provided the similar function for PU power > > domain, but it is not 100% compatible with GPCv2. > > > > The most important thing is that the GPC & SRC module is a security critical > > resource that security permission must be considered when building the > > security system. The GPC module is not only used by PU power domain power > > on/off. It is also used by the TF-A PSCI code to do the CPU core power > > management. the SRC module control the CPU CORE reset and the CPU reset > > vector address. if we give the non-secure world write permission to SRC. > > System can be easily induced to malicious code. > > > > Considering the security issue, it looks to me a right direction to move GPC > power handling into ATF. > It also helps build a more generic driver and ease other OS integration > needed by customers (e.g. QNX, Win10). > > Lucas, > How do you think of it? I don't yet buy the security argument. There are many more shared parts on the SoC, like the clock controller, that would need to be taken away from the non-secure world if one would want to run an untrusted OS kernel on a i.MX8M system. To properly implement security on any i.MX8M based system the firmware would need to grow something like a full ARM SCPI implementation, so all shared critical peripherals are solely under firmware control. I agree that it might make sense to move some parts into the firmware and have much simpler OS level drivers, but I don't agree on the implementation direction taken here. Growing custom PSCI extension interfaces will only get us so far, without solving the system security issue in a holistic way. It is my strong believe that only a complete rearchitecture of the OS support on top of a ARM SCPI firmware interface can solve this properly. Regards, Lucas
On 4/17/2019 3:13 PM, Lucas Stach wrote: > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: >>> From: Jacky Bai >>> Sent: Wednesday, April 17, 2019 1:27 PM >>> >>> The i.MX8M family is a set of NXP product focus on delivering the latest and >>> greatest video and audio experience combining state-of-the-art media-specific >>> features with high-performance processing while optimized for lowest power >>> consumption. >>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to >>> this family. >>> >>> The GPC module is used to manage the PU power domains' power on/off. For >>> the whole i.MX8M family, different SoC has differnt power domain design. the >>> power up sequence has significant difference. >>> all the power sequence must be guaranteed by SW. Some domains' power up >>> sequence need to access the SRC module or sub-system specific GPR. >>> the SRC register & SS's register are not in in the GPC's memory range. >>> >>> it makes us hard to use the GPCv2 driver to cover all the different power up >>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver >>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it. >>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be >>> self-contained. Accessing the non-driver specific module's register is a bad >>> practice. Although, the GPC module provided the similar function for PU power >>> domain, but it is not 100% compatible with GPCv2. >>> >>> The most important thing is that the GPC & SRC module is a security critical >>> resource that security permission must be considered when building the >>> security system. The GPC module is not only used by PU power domain power >>> on/off. It is also used by the TF-A PSCI code to do the CPU core power >>> management. the SRC module control the CPU CORE reset and the CPU reset >>> vector address. if we give the non-secure world write permission to SRC. >>> System can be easily induced to malicious code. >> >> Considering the security issue, it looks to me a right direction to move GPC >> power handling into ATF. >> It also helps build a more generic driver and ease other OS integration >> needed by customers (e.g. QNX, Win10). >> >> Lucas, >> How do you think of it? > > I don't yet buy the security argument. There are many more shared parts > on the SoC, like the clock controller, that would need to be taken away > from the non-secure world if one would want to run an untrusted OS > kernel on a i.MX8M system. > > To properly implement security on any i.MX8M based system the firmware > would need to grow something like a full ARM SCPI implementation, so > all shared critical peripherals are solely under firmware control. It might be possible to rework this to use some form of SCMI-over-SMC instead of vendor-specific SMCCC SIP calls +SCMI maintainer > I agree that it might make sense to move some parts into the firmware > and have much simpler OS level drivers, but I don't agree on the > implementation direction taken here. Growing custom PSCI extension > interfaces will only get us so far, without solving the system security > issue in a holistic way. It is my strong believe that only a complete > rearchitecture of the OS support on top of a ARM SCPI firmware > interface can solve this properly. Hiding everything critical for security (especially CCM) behind a SCMI interface would be a large amount of work but introducing SCMI incrementally (starting with imx8mm power) would be useful by itself because it simplifies OS implementation. Many at NXP have attempted to evaluate SCMI and their conclusion has always been that "many extensions are required". -- Regards, Leonard
Am Mittwoch, den 17.04.2019, 12:40 +0000 schrieb Leonard Crestez: > On 4/17/2019 3:13 PM, Lucas Stach wrote: > > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: > > > > From: Jacky Bai > > > > Sent: Wednesday, April 17, 2019 1:27 PM > > > > > > > > The i.MX8M family is a set of NXP product focus on delivering the latest and > > > > greatest video and audio experience combining state-of-the-art media-specific > > > > features with high-performance processing while optimized for lowest power > > > > consumption. > > > > i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to > > > > this family. > > > > > > > > The GPC module is used to manage the PU power domains' power on/off. For > > > > the whole i.MX8M family, different SoC has differnt power domain design. the > > > > power up sequence has significant difference. > > > > all the power sequence must be guaranteed by SW. Some domains' power up > > > > sequence need to access the SRC module or sub-system specific GPR. > > > > the SRC register & SS's register are not in in the GPC's memory range. > > > > > > > > it makes us hard to use the GPCv2 driver to cover all the different power up > > > > requirement. Each time, a new SoC is added, we must modify the GPCv2 driver > > > > to make it resuable for it. a lot of code need to be added in GPCv2 to support it. > > > > we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be > > > > self-contained. Accessing the non-driver specific module's register is a bad > > > > practice. Although, the GPC module provided the similar function for PU power > > > > domain, but it is not 100% compatible with GPCv2. > > > > > > > > The most important thing is that the GPC & SRC module is a security critical > > > > resource that security permission must be considered when building the > > > > security system. The GPC module is not only used by PU power domain power > > > > on/off. It is also used by the TF-A PSCI code to do the CPU core power > > > > management. the SRC module control the CPU CORE reset and the CPU reset > > > > vector address. if we give the non-secure world write permission to SRC. > > > > System can be easily induced to malicious code. > > > > > > Considering the security issue, it looks to me a right direction to move GPC > > > power handling into ATF. > > > It also helps build a more generic driver and ease other OS integration > > > needed by customers (e.g. QNX, Win10). > > > > > > Lucas, > > > How do you think of it? > > > > I don't yet buy the security argument. There are many more shared parts > > on the SoC, like the clock controller, that would need to be taken away > > from the non-secure world if one would want to run an untrusted OS > > kernel on a i.MX8M system. > > > > To properly implement security on any i.MX8M based system the firmware > > would need to grow something like a full ARM SCPI implementation, so > > all shared critical peripherals are solely under firmware control. > > It might be possible to rework this to use some form of SCMI-over-SMC > instead of vendor-specific SMCCC SIP calls > > +SCMI maintainer > > > I agree that it might make sense to move some parts into the firmware > > and have much simpler OS level drivers, but I don't agree on the > > implementation direction taken here. Growing custom PSCI extension > > interfaces will only get us so far, without solving the system security > > issue in a holistic way. It is my strong believe that only a complete > > rearchitecture of the OS support on top of a ARM SCPI firmware > > interface can solve this properly. > > Hiding everything critical for security (especially CCM) behind a SCMI > interface would be a large amount of work but introducing SCMI > incrementally (starting with imx8mm power) would be useful by itself > because it simplifies OS implementation. I'm totally on-board with baby steps if it gets us into the right direction, so what you propose makes sense to me. What I'm not okay with is tying the upstream kernel into an ad-hoc firmware interface in the name of system security, if there is no chance that proper security will ever be able to be achieved with the ad-hoc interface. Having dependencies between the OS kernel and system firmware is a burden on system integrators and I'm only willing to accept that burden if it's clear that there is some real value to it. Regards, Lucas
> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family > > On 4/17/2019 3:13 PM, Lucas Stach wrote: > > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: > >>> From: Jacky Bai > >>> Sent: Wednesday, April 17, 2019 1:27 PM > >>> > >>> The i.MX8M family is a set of NXP product focus on delivering the > >>> latest and greatest video and audio experience combining > >>> state-of-the-art media-specific features with high-performance > >>> processing while optimized for lowest power consumption. > >>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong > >>> to this family. > >>> > >>> The GPC module is used to manage the PU power domains' power on/off. > >>> For the whole i.MX8M family, different SoC has differnt power domain > >>> design. the power up sequence has significant difference. > >>> all the power sequence must be guaranteed by SW. Some domains' > power > >>> up sequence need to access the SRC module or sub-system specific GPR. > >>> the SRC register & SS's register are not in in the GPC's memory range. > >>> > >>> it makes us hard to use the GPCv2 driver to cover all the different > >>> power up requirement. Each time, a new SoC is added, we must modify > >>> the GPCv2 driver to make it resuable for it. a lot of code need to be added > in GPCv2 to support it. > >>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT > >>> be self-contained. Accessing the non-driver specific module's > >>> register is a bad practice. Although, the GPC module provided the > >>> similar function for PU power domain, but it is not 100% compatible with > GPCv2. > >>> > >>> The most important thing is that the GPC & SRC module is a security > >>> critical resource that security permission must be considered when > >>> building the security system. The GPC module is not only used by PU > >>> power domain power on/off. It is also used by the TF-A PSCI code to > >>> do the CPU core power management. the SRC module control the CPU > >>> CORE reset and the CPU reset vector address. if we give the non-secure > world write permission to SRC. > >>> System can be easily induced to malicious code. > >> > >> Considering the security issue, it looks to me a right direction to > >> move GPC power handling into ATF. > >> It also helps build a more generic driver and ease other OS > >> integration needed by customers (e.g. QNX, Win10). > >> > >> Lucas, > >> How do you think of it? > > > > I don't yet buy the security argument. There are many more shared > > parts on the SoC, like the clock controller, that would need to be > > taken away from the non-secure world if one would want to run an > > untrusted OS kernel on a i.MX8M system. > > > > To properly implement security on any i.MX8M based system the firmware > > would need to grow something like a full ARM SCPI implementation, so > > all shared critical peripherals are solely under firmware control. > > It might be possible to rework this to use some form of SCMI-over-SMC > instead of vendor-specific SMCCC SIP calls Whether SCMI or just SIP, it will make it easy to support virtualization(partition) or TEE. > > +SCMI maintainer We need implement firmware in ATF, and use SMC as the mailbox. I have taken Andre's previous patch to support smc mailbox and addressed some comments, and trying integrate with SCMI. The major issue is SCMI spec does not include SMC support. Sudeep, do you have any suggestions? Thanks, Peng. > > > I agree that it might make sense to move some parts into the firmware > > and have much simpler OS level drivers, but I don't agree on the > > implementation direction taken here. Growing custom PSCI extension > > interfaces will only get us so far, without solving the system > > security issue in a holistic way. It is my strong believe that only a > > complete rearchitecture of the OS support on top of a ARM SCPI > > firmware interface can solve this properly. > Hiding everything critical for security (especially CCM) behind a SCMI > interface would be a large amount of work but introducing SCMI > incrementally (starting with imx8mm power) would be useful by itself because > it simplifies OS implementation. > > Many at NXP have attempted to evaluate SCMI and their conclusion has > always been that "many extensions are required". > > -- > Regards, > Leonard
On 17/04/2019 13:13, Lucas Stach wrote: > Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: >>> From: Jacky Bai >>> Sent: Wednesday, April 17, 2019 1:27 PM >>> >>> The i.MX8M family is a set of NXP product focus on delivering the latest and >>> greatest video and audio experience combining state-of-the-art media-specific >>> features with high-performance processing while optimized for lowest power >>> consumption. >>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to >>> this family. >>> >>> The GPC module is used to manage the PU power domains' power on/off. For >>> the whole i.MX8M family, different SoC has differnt power domain design. the >>> power up sequence has significant difference. >>> all the power sequence must be guaranteed by SW. Some domains' power up >>> sequence need to access the SRC module or sub-system specific GPR. >>> the SRC register & SS's register are not in in the GPC's memory range. >>> >>> it makes us hard to use the GPCv2 driver to cover all the different power up >>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver >>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it. >>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be >>> self-contained. Accessing the non-driver specific module's register is a bad >>> practice. Although, the GPC module provided the similar function for PU power >>> domain, but it is not 100% compatible with GPCv2. >>> >>> The most important thing is that the GPC & SRC module is a security critical >>> resource that security permission must be considered when building the >>> security system. The GPC module is not only used by PU power domain power >>> on/off. It is also used by the TF-A PSCI code to do the CPU core power >>> management. the SRC module control the CPU CORE reset and the CPU reset >>> vector address. if we give the non-secure world write permission to SRC. >>> System can be easily induced to malicious code. >>> >> >> Considering the security issue, it looks to me a right direction to move GPC >> power handling into ATF. >> It also helps build a more generic driver and ease other OS integration >> needed by customers (e.g. QNX, Win10). >> >> Lucas, >> How do you think of it? > > I don't yet buy the security argument. There are many more shared parts > on the SoC, like the clock controller, that would need to be taken away > from the non-secure world if one would want to run an untrusted OS > kernel on a i.MX8M system. > > To properly implement security on any i.MX8M based system the firmware > would need to grow something like a full ARM SCPI implementation, so > all shared critical peripherals are solely under firmware control. > > I agree that it might make sense to move some parts into the firmware > and have much simpler OS level drivers, but I don't agree on the > implementation direction taken here. Growing custom PSCI extension > interfaces will only get us so far, without solving the system security > issue in a holistic way. It is my strong believe that only a complete > rearchitecture of the OS support on top of a ARM SCPI firmware > interface can solve this properly. > +1 for all the above. For me, though the intention looks good, this implementation is half cooked and just creating more mess with lots of custom SMC extensions. You can use them in products, but I would not like in upstream which is more focused on long term maintenance. -- Regards, Sudeep -- Regards, Sudeep IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 17/04/2019 13:54, Lucas Stach wrote: > Am Mittwoch, den 17.04.2019, 12:40 +0000 schrieb Leonard Crestez: >> On 4/17/2019 3:13 PM, Lucas Stach wrote: >>> Am Mittwoch, den 17.04.2019, 11:16 +0000 schrieb Aisheng Dong: >>>>> From: Jacky Bai >>>>> Sent: Wednesday, April 17, 2019 1:27 PM >>>>> >>>>> The i.MX8M family is a set of NXP product focus on delivering the latest and >>>>> greatest video and audio experience combining state-of-the-art media-specific >>>>> features with high-performance processing while optimized for lowest power >>>>> consumption. >>>>> i.MX8MQ, i.MX8MM, i.MX8MN, even the furture i.MX8MP are all belong to >>>>> this family. >>>>> >>>>> The GPC module is used to manage the PU power domains' power on/off. For >>>>> the whole i.MX8M family, different SoC has differnt power domain design. the >>>>> power up sequence has significant difference. >>>>> all the power sequence must be guaranteed by SW. Some domains' power up >>>>> sequence need to access the SRC module or sub-system specific GPR. >>>>> the SRC register & SS's register are not in in the GPC's memory range. >>>>> >>>>> it makes us hard to use the GPCv2 driver to cover all the different power up >>>>> requirement. Each time, a new SoC is added, we must modify the GPCv2 driver >>>>> to make it resuable for it. a lot of code need to be added in GPCv2 to support it. >>>>> we need to access the SRC & SS' GPR, then the GPCv2 driver can NOT be >>>>> self-contained. Accessing the non-driver specific module's register is a bad >>>>> practice. Although, the GPC module provided the similar function for PU power >>>>> domain, but it is not 100% compatible with GPCv2. >>>>> >>>>> The most important thing is that the GPC & SRC module is a security critical >>>>> resource that security permission must be considered when building the >>>>> security system. The GPC module is not only used by PU power domain power >>>>> on/off. It is also used by the TF-A PSCI code to do the CPU core power >>>>> management. the SRC module control the CPU CORE reset and the CPU reset >>>>> vector address. if we give the non-secure world write permission to SRC. >>>>> System can be easily induced to malicious code. >>>> >>>> Considering the security issue, it looks to me a right direction to move GPC >>>> power handling into ATF. >>>> It also helps build a more generic driver and ease other OS integration >>>> needed by customers (e.g. QNX, Win10). >>>> >>>> Lucas, >>>> How do you think of it? >>> >>> I don't yet buy the security argument. There are many more shared parts >>> on the SoC, like the clock controller, that would need to be taken away >>> from the non-secure world if one would want to run an untrusted OS >>> kernel on a i.MX8M system. >>> >>> To properly implement security on any i.MX8M based system the firmware >>> would need to grow something like a full ARM SCPI implementation, so >>> all shared critical peripherals are solely under firmware control. >> >> It might be possible to rework this to use some form of SCMI-over-SMC >> instead of vendor-specific SMCCC SIP calls >> >> +SCMI maintainer >> >>> I agree that it might make sense to move some parts into the firmware >>> and have much simpler OS level drivers, but I don't agree on the >>> implementation direction taken here. Growing custom PSCI extension >>> interfaces will only get us so far, without solving the system security >>> issue in a holistic way. It is my strong believe that only a complete >>> rearchitecture of the OS support on top of a ARM SCPI firmware >>> interface can solve this properly. >> >> Hiding everything critical for security (especially CCM) behind a SCMI >> interface would be a large amount of work but introducing SCMI >> incrementally (starting with imx8mm power) would be useful by itself >> because it simplifies OS implementation. > > I'm totally on-board with baby steps if it gets us into the right > direction, so what you propose makes sense to me. > > What I'm not okay with is tying the upstream kernel into an ad-hoc > firmware interface in the name of system security, Exactly, sorry I should have read through the thread. I just responded in other email with similar thoughts/concerns.
On 17/04/2019 13:40, Leonard Crestez wrote: > On 4/17/2019 3:13 PM, Lucas Stach wrote: [...] >> >> I don't yet buy the security argument. There are many more shared parts >> on the SoC, like the clock controller, that would need to be taken away >> from the non-secure world if one would want to run an untrusted OS >> kernel on a i.MX8M system. >> >> To properly implement security on any i.MX8M based system the firmware >> would need to grow something like a full ARM SCPI implementation, so >> all shared critical peripherals are solely under firmware control. > > It might be possible to rework this to use some form of SCMI-over-SMC > instead of vendor-specific SMCCC SIP calls > Sounds feasible and good if all the custom IDs/calls/..etc are well hidden in the firmware(TF-A in this case) behind the existing abstraction in Linux kernel. > +SCMI maintainer > Thanks for including. >> I agree that it might make sense to move some parts into the firmware >> and have much simpler OS level drivers, but I don't agree on the >> implementation direction taken here. Growing custom PSCI extension >> interfaces will only get us so far, without solving the system security >> issue in a holistic way. It is my strong believe that only a complete >> rearchitecture of the OS support on top of a ARM SCPI firmware >> interface can solve this properly. +1 again, just to re-iterate the emphasis on the above and the degree to which I align with it. > Hiding everything critical for security (especially CCM) behind a SCMI > interface would be a large amount of work but introducing SCMI > incrementally (starting with imx8mm power) would be useful by itself > because it simplifies OS implementation. > Agreed, but not at the expense of introducing and maintaining *random* *one-off* *custom* SMC extensions. Sorry, that's not open to debate. > Many at NXP have attempted to evaluate SCMI and their conclusion has > always been that "many extensions are required". > I would like to hear the evaluation. Don't assume that you need to implement something similar to ARM SCMI reference design. All OSPM like Linux kernel cares is conformance to the interface, what/how you implement on the other side is left to you.
On Wed, Apr 17, 2019 at 2:23 PM Sudeep Holla <Sudeep.Holla@arm.com> wrote: > [...] > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. Sorry, the above disclaimer was completely unintentional. I must have done something by mistake for this to happen once in series of replies on this thread.
On 4/17/2019 4:33 PM, Sudeep Holla wrote: >>> I don't yet buy the security argument. There are many more shared parts >>> on the SoC, like the clock controller, that would need to be taken away >>> from the non-secure world if one would want to run an untrusted OS >>> kernel on a i.MX8M system. >>> >>> To properly implement security on any i.MX8M based system the firmware >>> would need to grow something like a full ARM SCPI implementation, so >>> all shared critical peripherals are solely under firmware control. >> >> It might be possible to rework this to use some form of SCMI-over-SMC >> instead of vendor-specific SMCCC SIP calls > > Sounds feasible and good if all the custom IDs/calls/..etc are well > hidden in the firmware(TF-A in this case) behind the existing > abstraction in Linux kernel. >> Hiding everything critical for security (especially CCM) behind a SCMI >> interface would be a large amount of work but introducing SCMI >> incrementally (starting with imx8mm power) would be useful by itself >> because it simplifies OS implementation. > > Agreed, but not at the expense of introducing and maintaining *random* > *one-off* *custom* SMC extensions. Sorry, that's not open to debate. > >> Many at NXP have attempted to evaluate SCMI and their conclusion has >> always been that "many extensions are required". > > I would like to hear the evaluation. Don't assume that you need to > implement something similar to ARM SCMI reference design. All OSPM like > Linux kernel cares is conformance to the interface, what/how you > implement on the other side is left to you. Brief summary from some attempts at nudging NXP devs towards SCMI: There is no SCMI-over-SMC support specified? This would make it possible to use SCMI as a purely software solution on platforms which did not take SCMI into account at hardware design time or which don't have a dedicated SCP inside the SOC. This applies to all imx. Peng has been looking at some out-of-tree arm-smc-mailbox patches so it's not just NXP which would like the option of implementing SCMI vendor side in ATF. Like this: https://lwn.net/Articles/726861/ Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI message in EL2; checking if the guest is allowed to use that resource and then either forward to EL3 or return an error. SCMI clock protocol does not cover muxes? On imx the clk hierarchy is very intricate and it relies on many clk core features (including notifiers) and occasional assigned-clocks-parents properties to control muxes from linux. Moving all that to firmware would be a huge amount of effort. If SCMI included a generic clk mux and allowed keeping the clk hierarchy inside linux then the effort required for hiding the CCM would still be large, but more approachable. It would not "simplify the rich OS" but it would still improve security. Last point is that SCMI does not cover pinctrl? This is a large chunk of firmware functionality on some imx and security control over individual pins is desirable. -- Regards, Leonard
On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: > On 4/17/2019 4:33 PM, Sudeep Holla wrote: > >>> I don't yet buy the security argument. There are many more shared parts > >>> on the SoC, like the clock controller, that would need to be taken away > >>> from the non-secure world if one would want to run an untrusted OS > >>> kernel on a i.MX8M system. > >>> > >>> To properly implement security on any i.MX8M based system the firmware > >>> would need to grow something like a full ARM SCPI implementation, so > >>> all shared critical peripherals are solely under firmware control. > >> > >> It might be possible to rework this to use some form of SCMI-over-SMC > >> instead of vendor-specific SMCCC SIP calls > > > > Sounds feasible and good if all the custom IDs/calls/..etc are well > > hidden in the firmware(TF-A in this case) behind the existing > > abstraction in Linux kernel. > > >> Hiding everything critical for security (especially CCM) behind a SCMI > >> interface would be a large amount of work but introducing SCMI > >> incrementally (starting with imx8mm power) would be useful by itself > >> because it simplifies OS implementation. > > > > Agreed, but not at the expense of introducing and maintaining *random* > > *one-off* *custom* SMC extensions. Sorry, that's not open to debate. > > > >> Many at NXP have attempted to evaluate SCMI and their conclusion has > >> always been that "many extensions are required". > > > > I would like to hear the evaluation. Don't assume that you need to > > implement something similar to ARM SCMI reference design. All OSPM like > > Linux kernel cares is conformance to the interface, what/how you > > implement on the other side is left to you. > > Brief summary from some attempts at nudging NXP devs towards SCMI: > Thanks for providing the evaluation details. > > There is no SCMI-over-SMC support specified? This would make it possible > to use SCMI as a purely software solution on platforms which did not > take SCMI into account at hardware design time or which don't have a > dedicated SCP inside the SOC. This applies to all imx. > While I admit, the section of SCMI specification that touches transport is quite lean, I would view it as done intentionally as the specification is mainly concentrated on it's subject matter which is protocol and not the transport itself. So did the evaluation attempted to consider/try SMC as transport retaining protocol as is ? I can't see any issues with that and hence I am asking it loud here. > Peng has been looking at some out-of-tree arm-smc-mailbox patches so > it's not just NXP which would like the option of implementing SCMI > vendor side in ATF. Like this: https://lwn.net/Articles/726861/ > OK, any inputs from that study ? > Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI > message in EL2; checking if the guest is allowed to use that resource > and then either forward to EL3 or return an error. > Why are you mixing virtualisation and EL2 here ? Yes we need them but it should be optional and if a platform doesn't need it, it should be possible to skip it. > > SCMI clock protocol does not cover muxes? On imx the clk hierarchy is > very intricate and it relies on many clk core features (including > notifiers) and occasional assigned-clocks-parents properties to control > muxes from linux. Moving all that to firmware would be a huge amount of > effort. > Yes it may be huge amount of work. But is it completely safe as claimed ? Giving access to mux controls in OSPM is no so safe/secure in the modern world. So you either make it safe with that extra huge effort needed or just keep everything in OSPM. But IMO anything in between is not worth it. > If SCMI included a generic clk mux and allowed keeping the clk hierarchy > inside linux then the effort required for hiding the CCM would still be > large, but more approachable. It would not "simplify the rich OS" but it > would still improve security. > Why do you need to keep the clk hierarchy in Linux ? > > Last point is that SCMI does not cover pinctrl? This is a large chunk of > firmware functionality on some imx and security control over individual > pins is desirable. > Yes but is that something available at runtime ? Can't that be one-off firmware setting. Will Linux need to configure it differently on each boot ? Just trying to understand. You say security control here and is it really safe to give OS access to control those ? In short, if you had a full blown protocol like few other platforms, the push back would have been minimal. Instead, i.MX chose to implement a solution which doesn't have a design thought before and custom SMC APIs added on fly whenever a new request is raised by OSPM to control things that it thinks it should. I am sure, the very next platform will have it's own set of requirements and custom SMC APIs/interface and no one has even bothered about long term maintenance of these. So assuming that trend, I would NACK this as it stands. -- Regards, Sudeep
On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: > > On 4/17/2019 4:33 PM, Sudeep Holla wrote: > > >>> I don't yet buy the security argument. There are many more shared parts > > >>> on the SoC, like the clock controller, that would need to be taken away > > >>> from the non-secure world if one would want to run an untrusted OS > > >>> kernel on a i.MX8M system. > > >>> > > >>> To properly implement security on any i.MX8M based system the firmware > > >>> would need to grow something like a full ARM SCPI implementation, so > > >>> all shared critical peripherals are solely under firmware control. > > >> > > >> It might be possible to rework this to use some form of SCMI-over-SMC > > >> instead of vendor-specific SMCCC SIP calls I was just curious to know if there is any progress being made on this. The i.mx8mm-evk is missing functionality upstream and I think the power domain support would help enable some of these features. thanks adam > > > > > > Sounds feasible and good if all the custom IDs/calls/..etc are well > > > hidden in the firmware(TF-A in this case) behind the existing > > > abstraction in Linux kernel. > > > > >> Hiding everything critical for security (especially CCM) behind a SCMI > > >> interface would be a large amount of work but introducing SCMI > > >> incrementally (starting with imx8mm power) would be useful by itself > > >> because it simplifies OS implementation. > > > > > > Agreed, but not at the expense of introducing and maintaining *random* > > > *one-off* *custom* SMC extensions. Sorry, that's not open to debate. > > > > > >> Many at NXP have attempted to evaluate SCMI and their conclusion has > > >> always been that "many extensions are required". > > > > > > I would like to hear the evaluation. Don't assume that you need to > > > implement something similar to ARM SCMI reference design. All OSPM like > > > Linux kernel cares is conformance to the interface, what/how you > > > implement on the other side is left to you. > > > > Brief summary from some attempts at nudging NXP devs towards SCMI: > > > > Thanks for providing the evaluation details. > > > > > There is no SCMI-over-SMC support specified? This would make it possible > > to use SCMI as a purely software solution on platforms which did not > > take SCMI into account at hardware design time or which don't have a > > dedicated SCP inside the SOC. This applies to all imx. > > > > While I admit, the section of SCMI specification that touches transport > is quite lean, I would view it as done intentionally as the specification > is mainly concentrated on it's subject matter which is protocol and not > the transport itself. So did the evaluation attempted to consider/try > SMC as transport retaining protocol as is ? > > I can't see any issues with that and hence I am asking it loud here. > > > Peng has been looking at some out-of-tree arm-smc-mailbox patches so > > it's not just NXP which would like the option of implementing SCMI > > vendor side in ATF. Like this: https://lwn.net/Articles/726861/ > > > > OK, any inputs from that study ? > > > Blessing SCMI-over-SMC would allow stuff like intercepting a SCMI > > message in EL2; checking if the guest is allowed to use that resource > > and then either forward to EL3 or return an error. > > > > Why are you mixing virtualisation and EL2 here ? Yes we need them but > it should be optional and if a platform doesn't need it, it should be > possible to skip it. > > > > > SCMI clock protocol does not cover muxes? On imx the clk hierarchy is > > very intricate and it relies on many clk core features (including > > notifiers) and occasional assigned-clocks-parents properties to control > > muxes from linux. Moving all that to firmware would be a huge amount of > > effort. > > > > Yes it may be huge amount of work. But is it completely safe as claimed ? > Giving access to mux controls in OSPM is no so safe/secure in the modern > world. So you either make it safe with that extra huge effort needed or > just keep everything in OSPM. But IMO anything in between is not worth it. > > > If SCMI included a generic clk mux and allowed keeping the clk hierarchy > > inside linux then the effort required for hiding the CCM would still be > > large, but more approachable. It would not "simplify the rich OS" but it > > would still improve security. > > > > Why do you need to keep the clk hierarchy in Linux ? > > > > > Last point is that SCMI does not cover pinctrl? This is a large chunk of > > firmware functionality on some imx and security control over individual > > pins is desirable. > > > > Yes but is that something available at runtime ? Can't that be one-off > firmware setting. Will Linux need to configure it differently on each boot ? > Just trying to understand. You say security control here and is it really > safe to give OS access to control those ? > > In short, if you had a full blown protocol like few other platforms, the > push back would have been minimal. Instead, i.MX chose to implement a > solution which doesn't have a design thought before and custom SMC APIs > added on fly whenever a new request is raised by OSPM to control things > that it thinks it should. I am sure, the very next platform will have it's > own set of requirements and custom SMC APIs/interface and no one has even > bothered about long term maintenance of these. > > So assuming that trend, I would NACK this as it stands. > > -- > Regards, > Sudeep > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi, On 07.11.19 22:28, Adam Ford wrote: > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> wrote: >> >> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: >>> On 4/17/2019 4:33 PM, Sudeep Holla wrote: >>>>>> I don't yet buy the security argument. There are many more shared parts >>>>>> on the SoC, like the clock controller, that would need to be taken away >>>>>> from the non-secure world if one would want to run an untrusted OS >>>>>> kernel on a i.MX8M system. >>>>>> >>>>>> To properly implement security on any i.MX8M based system the firmware >>>>>> would need to grow something like a full ARM SCPI implementation, so >>>>>> all shared critical peripherals are solely under firmware control. >>>>> >>>>> It might be possible to rework this to use some form of SCMI-over-SMC >>>>> instead of vendor-specific SMCCC SIP calls > > I was just curious to know if there is any progress being made on > this. The i.mx8mm-evk is missing functionality upstream and I think > the power domain support would help enable some of these features. > Has there been any decision or action taken in this topic? Will the power domain driver as proposed in this patch be upstreamed at some time, or rather not? I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) and I integrated display and graphics support from the downstream NXP kernel. While most things already work fine, there's the issue of how to handle the power domains. Currently I need to ungate some clocks in the TF-A BL31 to get for example the GPU running. If I understand this correctly the proposed power domain driver could handle this in Linux otherwise. Thanks, Frieder
> -----Original Message----- > From: Schrempf Frieder <frieder.schrempf@kontron.de> > Sent: Thursday, February 13, 2020 5:16 PM > To: Adam Ford <aford173@gmail.com>; Sudeep Holla > <sudeep.holla@arm.com> > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng > Fan <peng.fan@nxp.com>; Souvik Chakravarty > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family > > Hi, > > On 07.11.19 22:28, Adam Ford wrote: > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> > wrote: > >> > >> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: > >>> On 4/17/2019 4:33 PM, Sudeep Holla wrote: > >>>>>> I don't yet buy the security argument. There are many more shared > >>>>>> parts on the SoC, like the clock controller, that would need to > >>>>>> be taken away from the non-secure world if one would want to run > >>>>>> an untrusted OS kernel on a i.MX8M system. > >>>>>> > >>>>>> To properly implement security on any i.MX8M based system the > >>>>>> firmware would need to grow something like a full ARM SCPI > >>>>>> implementation, so all shared critical peripherals are solely under > firmware control. > >>>>> > >>>>> It might be possible to rework this to use some form of > >>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls > > > > I was just curious to know if there is any progress being made on > > this. The i.mx8mm-evk is missing functionality upstream and I think > > the power domain support would help enable some of these features. > > > > Has there been any decision or action taken in this topic? > Will the power domain driver as proposed in this patch be upstreamed at > some time, or rather not? > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) > and I integrated display and graphics support from the downstream NXP > kernel. > > While most things already work fine, there's the issue of how to handle the > power domains. Currently I need to ungate some clocks in the TF-A > BL31 to get for example the GPU running. If I understand this correctly the > proposed power domain driver could handle this in Linux otherwise. > the SCMI over SMC is still under review BR Jacky Bai > Thanks, > Frieder
On 13.02.20 10:21, Jacky Bai wrote: >> -----Original Message----- >> From: Schrempf Frieder <frieder.schrempf@kontron.de> >> Sent: Thursday, February 13, 2020 5:16 PM >> To: Adam Ford <aford173@gmail.com>; Sudeep Holla >> <sudeep.holla@arm.com> >> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng >> Fan <peng.fan@nxp.com>; Souvik Chakravarty >> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; >> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; >> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; >> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara >> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; >> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; >> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> >> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family >> >> Hi, >> >> On 07.11.19 22:28, Adam Ford wrote: >>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> >> wrote: >>>> >>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: >>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote: >>>>>>>> I don't yet buy the security argument. There are many more shared >>>>>>>> parts on the SoC, like the clock controller, that would need to >>>>>>>> be taken away from the non-secure world if one would want to run >>>>>>>> an untrusted OS kernel on a i.MX8M system. >>>>>>>> >>>>>>>> To properly implement security on any i.MX8M based system the >>>>>>>> firmware would need to grow something like a full ARM SCPI >>>>>>>> implementation, so all shared critical peripherals are solely under >> firmware control. >>>>>>> >>>>>>> It might be possible to rework this to use some form of >>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls >>> >>> I was just curious to know if there is any progress being made on >>> this. The i.mx8mm-evk is missing functionality upstream and I think >>> the power domain support would help enable some of these features. >>> >> >> Has there been any decision or action taken in this topic? >> Will the power domain driver as proposed in this patch be upstreamed at >> some time, or rather not? >> >> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) >> and I integrated display and graphics support from the downstream NXP >> kernel. >> >> While most things already work fine, there's the issue of how to handle the >> power domains. Currently I need to ungate some clocks in the TF-A >> BL31 to get for example the GPU running. If I understand this correctly the >> proposed power domain driver could handle this in Linux otherwise. >> > > the SCMI over SMC is still under review > Ok, I see. Thanks for the information. Once the SCMI over SMC driver is available in Linux, what else needs to be done to handle the example case given above (GPU root clock ungate)? I guess this would need an imx-specific handler in the TF-A. Is this interface already available in mainline TF-A?
On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote: > > -----Original Message----- > > From: Schrempf Frieder <frieder.schrempf@kontron.de> > > Sent: Thursday, February 13, 2020 5:16 PM > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla > > <sudeep.holla@arm.com> > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng > > Fan <peng.fan@nxp.com>; Souvik Chakravarty > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family > > > > Hi, > > > > On 07.11.19 22:28, Adam Ford wrote: > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> > > wrote: > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote: > > > > > > > > I don't yet buy the security argument. There are many more shared > > > > > > > > parts on the SoC, like the clock controller, that would need to > > > > > > > > be taken away from the non-secure world if one would want to run > > > > > > > > an untrusted OS kernel on a i.MX8M system. > > > > > > > > > > > > > > > > To properly implement security on any i.MX8M based system the > > > > > > > > firmware would need to grow something like a full ARM SCPI > > > > > > > > implementation, so all shared critical peripherals are solely under > > firmware control. > > > > > > > It might be possible to rework this to use some form of > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls > > > > > > I was just curious to know if there is any progress being made on > > > this. The i.mx8mm-evk is missing functionality upstream and I think > > > the power domain support would help enable some of these features. > > > > > > > Has there been any decision or action taken in this topic? > > Will the power domain driver as proposed in this patch be upstreamed at > > some time, or rather not? > > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) > > and I integrated display and graphics support from the downstream NXP > > kernel. > > > > While most things already work fine, there's the issue of how to handle the > > power domains. Currently I need to ungate some clocks in the TF-A > > BL31 to get for example the GPU running. If I understand this correctly the > > proposed power domain driver could handle this in Linux otherwise. > > > > the SCMI over SMC is still under review Even if the SCMI over SMC is ready at some point, it's still unclear to me how you intend to abstract the GPC behind the SCMI interface in the TF-A. The power domains have dependencies both into the regulator and the clock framework. Both are currently under exclusive control of the rich OS. How do you intend to allow the TF-A to control the power supplies and necessary reset clocks without messing up any state in the rich OS? Regards, Lucas
On 13.02.2020 13:32, Lucas Stach wrote: > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote: >>> -----Original Message----- >>> From: Schrempf Frieder <frieder.schrempf@kontron.de> >>> Sent: Thursday, February 13, 2020 5:16 PM >>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla >>> <sudeep.holla@arm.com> >>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng >>> Fan <peng.fan@nxp.com>; Souvik Chakravarty >>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; >>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; >>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; >>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara >>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; >>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; >>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> >>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family >>> >>> Hi, >>> >>> On 07.11.19 22:28, Adam Ford wrote: >>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> >>> wrote: >>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: >>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote: >>>>>>>>> I don't yet buy the security argument. There are many more shared >>>>>>>>> parts on the SoC, like the clock controller, that would need to >>>>>>>>> be taken away from the non-secure world if one would want to run >>>>>>>>> an untrusted OS kernel on a i.MX8M system. >>>>>>>>> >>>>>>>>> To properly implement security on any i.MX8M based system the >>>>>>>>> firmware would need to grow something like a full ARM SCPI >>>>>>>>> implementation, so all shared critical peripherals are solely under >>> firmware control. >>>>>>>> It might be possible to rework this to use some form of >>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls >>>> >>>> I was just curious to know if there is any progress being made on >>>> this. The i.mx8mm-evk is missing functionality upstream and I think >>>> the power domain support would help enable some of these features. >>>> >>> >>> Has there been any decision or action taken in this topic? >>> Will the power domain driver as proposed in this patch be upstreamed at >>> some time, or rather not? >>> >>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) >>> and I integrated display and graphics support from the downstream NXP >>> kernel. >>> >>> While most things already work fine, there's the issue of how to handle the >>> power domains. Currently I need to ungate some clocks in the TF-A >>> BL31 to get for example the GPU running. If I understand this correctly the >>> proposed power domain driver could handle this in Linux otherwise. >>> >> >> the SCMI over SMC is still under review > > Even if the SCMI over SMC is ready at some point, it's still unclear to > me how you intend to abstract the GPC behind the SCMI interface in the > TF-A. The power domains have dependencies both into the regulator and > the clock framework. Both are currently under exclusive control of the > rich OS. How do you intend to allow the TF-A to control the power > supplies and necessary reset clocks without messing up any state in the > rich OS? This is indeed difficult, SCMI assumes that the responder has sufficient control over clocks to fully implement power domain handling, including over clocks and regulators. Perhaps it might be possible to modify current gpcv2 driver to send SCMI messages for power only and keep handling regulators itself? It could switch based on whether it has a reference to a scmi channel as a DT property. A full scmi-based implementation might use entirely very different bindings and take a long time. If people want to support their chips by implementing power domain support in the rich OS we shouldn't block them. So it would be good to accept gpcv2 enhancement for 8mm and similar. -- Regards, Leonard
On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote: > On 13.02.2020 13:32, Lucas Stach wrote: > > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote: > > > > -----Original Message----- > > > > From: Schrempf Frieder <frieder.schrempf@kontron.de> > > > > Sent: Thursday, February 13, 2020 5:16 PM > > > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla > > > > <sudeep.holla@arm.com> > > > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng > > > > Fan <peng.fan@nxp.com>; Souvik Chakravarty > > > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; > > > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; > > > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; > > > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara > > > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; > > > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; > > > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> > > > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family > > > > > > > > Hi, > > > > > > > > On 07.11.19 22:28, Adam Ford wrote: > > > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> > > > > wrote: > > > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: > > > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote: > > > > > > > > > > I don't yet buy the security argument. There are many more shared > > > > > > > > > > parts on the SoC, like the clock controller, that would need to > > > > > > > > > > be taken away from the non-secure world if one would want to run > > > > > > > > > > an untrusted OS kernel on a i.MX8M system. > > > > > > > > > > > > > > > > > > > > To properly implement security on any i.MX8M based system the > > > > > > > > > > firmware would need to grow something like a full ARM SCPI > > > > > > > > > > implementation, so all shared critical peripherals are solely under > > > > firmware control. > > > > > > > > > It might be possible to rework this to use some form of > > > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls > > > > > > > > > > I was just curious to know if there is any progress being made on > > > > > this. The i.mx8mm-evk is missing functionality upstream and I think > > > > > the power domain support would help enable some of these features. > > > > > > > > > > > > > Has there been any decision or action taken in this topic? > > > > Will the power domain driver as proposed in this patch be upstreamed at > > > > some time, or rather not? > > > > > > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) > > > > and I integrated display and graphics support from the downstream NXP > > > > kernel. > > > > > > > > While most things already work fine, there's the issue of how to handle the > > > > power domains. Currently I need to ungate some clocks in the TF-A > > > > BL31 to get for example the GPU running. If I understand this correctly the > > > > proposed power domain driver could handle this in Linux otherwise. > > > > > > > > > > the SCMI over SMC is still under review > > > > Even if the SCMI over SMC is ready at some point, it's still unclear to > > me how you intend to abstract the GPC behind the SCMI interface in the > > TF-A. The power domains have dependencies both into the regulator and > > the clock framework. Both are currently under exclusive control of the > > rich OS. How do you intend to allow the TF-A to control the power > > supplies and necessary reset clocks without messing up any state in the > > rich OS? > > This is indeed difficult, SCMI assumes that the responder has sufficient > control over clocks to fully implement power domain handling, including > over clocks and regulators. > > Perhaps it might be possible to modify current gpcv2 driver to send SCMI > messages for power only and keep handling regulators itself? It could > switch based on whether it has a reference to a scmi channel as a DT > property. With such a split implementation I feel like we are getting worst of both worlds: more complexity as the implementation is split across multiple components (TF-A and kernel) and still the rich OS is able to mess up the power supply of a domain that it might not even own. This doesn't sound really enticing. IMHO it only makes sense to push this functionality down into TF-A if it allows to abstract all the implementation details behind a standard interface like SCMI. But then the needed changes are much more invasive than just pushing down the GPC implementation. > A full scmi-based implementation might use entirely very different > bindings and take a long time. If people want to support their chips by > implementing power domain support in the rich OS we shouldn't block them. > > So it would be good to accept gpcv2 enhancement for 8mm and similar. I fully agree. For a full SCMI based implementation I expect that much more than just the GPC functionality needs to be pushed down into the TF-A. Right now I see clocks, i2c and regulator handling, maybe there is more that escapes my mind. We should not block a Linux based implementation of this functionality on the basis that we might want to replace this with a SCMI based one at a later point in time. Regards, Lucas
On 13.02.2020 16:47, Lucas Stach wrote: > On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote: >> On 13.02.2020 13:32, Lucas Stach wrote: >>> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote: >>>>> -----Original Message----- >>>>> From: Schrempf Frieder <frieder.schrempf@kontron.de> >>>>> Sent: Thursday, February 13, 2020 5:16 PM >>>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla >>>>> <sudeep.holla@arm.com> >>>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng >>>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty >>>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; >>>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; >>>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; >>>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara >>>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; >>>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; >>>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> >>>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family >>>>> >>>>> Hi, >>>>> >>>>> On 07.11.19 22:28, Adam Ford wrote: >>>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> >>>>> wrote: >>>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: >>>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote: >>>>>>>>>>> I don't yet buy the security argument. There are many more shared >>>>>>>>>>> parts on the SoC, like the clock controller, that would need to >>>>>>>>>>> be taken away from the non-secure world if one would want to run >>>>>>>>>>> an untrusted OS kernel on a i.MX8M system. >>>>>>>>>>> >>>>>>>>>>> To properly implement security on any i.MX8M based system the >>>>>>>>>>> firmware would need to grow something like a full ARM SCPI >>>>>>>>>>> implementation, so all shared critical peripherals are solely under >>>>> firmware control. >>>>>>>>>> It might be possible to rework this to use some form of >>>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls >>>>>> >>>>>> I was just curious to know if there is any progress being made on >>>>>> this. The i.mx8mm-evk is missing functionality upstream and I think >>>>>> the power domain support would help enable some of these features. >>>>>> >>>>> >>>>> Has there been any decision or action taken in this topic? >>>>> Will the power domain driver as proposed in this patch be upstreamed at >>>>> some time, or rather not? >>>>> >>>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) >>>>> and I integrated display and graphics support from the downstream NXP >>>>> kernel. >>>>> >>>>> While most things already work fine, there's the issue of how to handle the >>>>> power domains. Currently I need to ungate some clocks in the TF-A >>>>> BL31 to get for example the GPU running. If I understand this correctly the >>>>> proposed power domain driver could handle this in Linux otherwise. >>>>> >>>> >>>> the SCMI over SMC is still under review >>> >>> Even if the SCMI over SMC is ready at some point, it's still unclear to >>> me how you intend to abstract the GPC behind the SCMI interface in the >>> TF-A. The power domains have dependencies both into the regulator and >>> the clock framework. Both are currently under exclusive control of the >>> rich OS. How do you intend to allow the TF-A to control the power >>> supplies and necessary reset clocks without messing up any state in the >>> rich OS? >> >> This is indeed difficult, SCMI assumes that the responder has sufficient >> control over clocks to fully implement power domain handling, including >> over clocks and regulators. >> >> Perhaps it might be possible to modify current gpcv2 driver to send SCMI >> messages for power only and keep handling regulators itself? It could >> switch based on whether it has a reference to a scmi channel as a DT >> property. > > With such a split implementation I feel like we are getting worst of > both worlds: more complexity as the implementation is split across > multiple components (TF-A and kernel) and still the rich OS is able to > mess up the power supply of a domain that it might not even own. This > doesn't sound really enticing. > > IMHO it only makes sense to push this functionality down into TF-A if > it allows to abstract all the implementation details behind a standard > interface like SCMI. But then the needed changes are much more invasive > than just pushing down the GPC implementation. > >> A full scmi-based implementation might use entirely very different >> bindings and take a long time. If people want to support their chips by >> implementing power domain support in the rich OS we shouldn't block them. >> >> So it would be good to accept gpcv2 enhancement for 8mm and similar. > > I fully agree. > > For a full SCMI based implementation I expect that much more than just > the GPC functionality needs to be pushed down into the TF-A. Right now > I see clocks, i2c and regulator handling, maybe there is more that > escapes my mind. I2C regulator handling inside TF-A sounds very difficult. Not only would upstream TF-A likely object but on imx8m EVK boards the i2c bus for regulators is shared with other devices (like camera). So if we do this maybe SCMI dt bindings could be expanded to at least allow regulators on a per-domain basis? > We should not block a Linux based implementation of this functionality > on the basis that we might want to replace this with a SCMI based one > at a later point in time.
On Do, 2020-02-13 at 15:19 +0000, Leonard Crestez wrote: > On 13.02.2020 16:47, Lucas Stach wrote: > > On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote: > > > On 13.02.2020 13:32, Lucas Stach wrote: > > > > On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote: > > > > > > -----Original Message----- > > > > > > From: Schrempf Frieder <frieder.schrempf@kontron.de> > > > > > > Sent: Thursday, February 13, 2020 5:16 PM > > > > > > To: Adam Ford <aford173@gmail.com>; Sudeep Holla > > > > > > <sudeep.holla@arm.com> > > > > > > Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng > > > > > > Fan <peng.fan@nxp.com>; Souvik Chakravarty > > > > > > <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; > > > > > > devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; > > > > > > s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; > > > > > > dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara > > > > > > <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; > > > > > > Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; > > > > > > linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> > > > > > > Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family > > > > > > > > > > > > Hi, > > > > > > > > > > > > On 07.11.19 22:28, Adam Ford wrote: > > > > > > > On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> > > > > > > wrote: > > > > > > > > On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: > > > > > > > > > On 4/17/2019 4:33 PM, Sudeep Holla wrote: > > > > > > > > > > > > I don't yet buy the security argument. There are many more shared > > > > > > > > > > > > parts on the SoC, like the clock controller, that would need to > > > > > > > > > > > > be taken away from the non-secure world if one would want to run > > > > > > > > > > > > an untrusted OS kernel on a i.MX8M system. > > > > > > > > > > > > > > > > > > > > > > > > To properly implement security on any i.MX8M based system the > > > > > > > > > > > > firmware would need to grow something like a full ARM SCPI > > > > > > > > > > > > implementation, so all shared critical peripherals are solely under > > > > > > firmware control. > > > > > > > > > > > It might be possible to rework this to use some form of > > > > > > > > > > > SCMI-over-SMC instead of vendor-specific SMCCC SIP calls > > > > > > > > > > > > > > I was just curious to know if there is any progress being made on > > > > > > > this. The i.mx8mm-evk is missing functionality upstream and I think > > > > > > > the power domain support would help enable some of these features. > > > > > > > > > > > > > > > > > > > Has there been any decision or action taken in this topic? > > > > > > Will the power domain driver as proposed in this patch be upstreamed at > > > > > > some time, or rather not? > > > > > > > > > > > > I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) > > > > > > and I integrated display and graphics support from the downstream NXP > > > > > > kernel. > > > > > > > > > > > > While most things already work fine, there's the issue of how to handle the > > > > > > power domains. Currently I need to ungate some clocks in the TF-A > > > > > > BL31 to get for example the GPU running. If I understand this correctly the > > > > > > proposed power domain driver could handle this in Linux otherwise. > > > > > > > > > > > > > > > > the SCMI over SMC is still under review > > > > > > > > Even if the SCMI over SMC is ready at some point, it's still unclear to > > > > me how you intend to abstract the GPC behind the SCMI interface in the > > > > TF-A. The power domains have dependencies both into the regulator and > > > > the clock framework. Both are currently under exclusive control of the > > > > rich OS. How do you intend to allow the TF-A to control the power > > > > supplies and necessary reset clocks without messing up any state in the > > > > rich OS? > > > > > > This is indeed difficult, SCMI assumes that the responder has sufficient > > > control over clocks to fully implement power domain handling, including > > > over clocks and regulators. > > > > > > Perhaps it might be possible to modify current gpcv2 driver to send SCMI > > > messages for power only and keep handling regulators itself? It could > > > switch based on whether it has a reference to a scmi channel as a DT > > > property. > > > > With such a split implementation I feel like we are getting worst of > > both worlds: more complexity as the implementation is split across > > multiple components (TF-A and kernel) and still the rich OS is able to > > mess up the power supply of a domain that it might not even own. This > > doesn't sound really enticing. > > > > IMHO it only makes sense to push this functionality down into TF-A if > > it allows to abstract all the implementation details behind a standard > > interface like SCMI. But then the needed changes are much more invasive > > than just pushing down the GPC implementation. > > > > > A full scmi-based implementation might use entirely very different > > > bindings and take a long time. If people want to support their chips by > > > implementing power domain support in the rich OS we shouldn't block them. > > > > > > So it would be good to accept gpcv2 enhancement for 8mm and similar. > > > > I fully agree. > > > > For a full SCMI based implementation I expect that much more than just > > the GPC functionality needs to be pushed down into the TF-A. Right now > > I see clocks, i2c and regulator handling, maybe there is more that > > escapes my mind. > > I2C regulator handling inside TF-A sounds very difficult. Not only would > upstream TF-A likely object but on imx8m EVK boards the i2c bus for > regulators is shared with other devices (like camera). And that's exactly the point where trying to push things into lower layers starts to crumble. It only really makes sense if you manage to establish a nice abstraction of what is happening in those lower layers. If you need to punch through those abstractions due to system design limitations, the benefit of those abstractions is wiped away. The only thing you gain is more complexity due to more components being involved in a specific task. If you want to be able to partition the system (and as far as I understand it that's the main motivation for pushing GPC functionality into TF-A) you need to design the system (starting on the HW level) to make this possible. Trying to force such a model on a system that hasn't really been designed for this is IMHO doomed to fail. > So if we do this maybe SCMI dt bindings could be expanded to at least > allow regulators on a per-domain basis? Maybe that is what needs to be done to allow at least a partial implementation of SCMI on the existing i.MX8M designs. However it doesn't really provide much of the benefits of SCMI. So I'm all for having a pure Linux based implementation of the functionality, instead of waiting for the SCMI based implementation that may provide only questionable benefit. Regards, Lucas
On 13.02.20 16:58, Lucas Stach wrote: > On Do, 2020-02-13 at 15:19 +0000, Leonard Crestez wrote: >> On 13.02.2020 16:47, Lucas Stach wrote: >>> On Do, 2020-02-13 at 14:30 +0000, Leonard Crestez wrote: >>>> On 13.02.2020 13:32, Lucas Stach wrote: >>>>> On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote: >>>>>>> -----Original Message----- >>>>>>> From: Schrempf Frieder <frieder.schrempf@kontron.de> >>>>>>> Sent: Thursday, February 13, 2020 5:16 PM >>>>>>> To: Adam Ford <aford173@gmail.com>; Sudeep Holla >>>>>>> <sudeep.holla@arm.com> >>>>>>> Cc: Aisheng Dong <aisheng.dong@nxp.com>; mark.rutland@arm.com; Peng >>>>>>> Fan <peng.fan@nxp.com>; Souvik Chakravarty >>>>>>> <Souvik.Chakravarty@arm.com>; Jacky Bai <ping.bai@nxp.com>; >>>>>>> devicetree@vger.kernel.org; Clément Faure <clement.faure@nxp.com>; >>>>>>> s.hauer@pengutronix.de; shawnguo@kernel.org; robh+dt@kernel.org; >>>>>>> dl-linux-imx <linux-imx@nxp.com>; kernel@pengutronix.de; Andre Przywara >>>>>>> <andre.przywara@arm.com>; Silvano Di Ninno <silvano.dininno@nxp.com>; >>>>>>> Leonard Crestez <leonard.crestez@nxp.com>; festevam@gmail.com; >>>>>>> linux-arm-kernel@lists.infradead.org; Lucas Stach <l.stach@pengutronix.de> >>>>>>> Subject: Re: [PATCH 0/3] Add power domain driver support for i.mx8m family >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 07.11.19 22:28, Adam Ford wrote: >>>>>>>> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <sudeep.holla@arm.com> >>>>>>> wrote: >>>>>>>>> On Wed, Apr 17, 2019 at 04:21:55PM +0000, Leonard Crestez wrote: >>>>>>>>>> On 4/17/2019 4:33 PM, Sudeep Holla wrote: >>>>>>>>>>>>> I don't yet buy the security argument. There are many more shared >>>>>>>>>>>>> parts on the SoC, like the clock controller, that would need to >>>>>>>>>>>>> be taken away from the non-secure world if one would want to run >>>>>>>>>>>>> an untrusted OS kernel on a i.MX8M system. >>>>>>>>>>>>> >>>>>>>>>>>>> To properly implement security on any i.MX8M based system the >>>>>>>>>>>>> firmware would need to grow something like a full ARM SCPI >>>>>>>>>>>>> implementation, so all shared critical peripherals are solely under >>>>>>> firmware control. >>>>>>>>>>>> It might be possible to rework this to use some form of >>>>>>>>>>>> SCMI-over-SMC instead of vendor-specific SMCCC SIP calls >>>>>>>> >>>>>>>> I was just curious to know if there is any progress being made on >>>>>>>> this. The i.mx8mm-evk is missing functionality upstream and I think >>>>>>>> the power domain support would help enable some of these features. >>>>>>>> >>>>>>> >>>>>>> Has there been any decision or action taken in this topic? >>>>>>> Will the power domain driver as proposed in this patch be upstreamed at >>>>>>> some time, or rather not? >>>>>>> >>>>>>> I try to build a mainline BSP for i.MX8MM (ML U-Boot, ML TF-A, ML Linux) >>>>>>> and I integrated display and graphics support from the downstream NXP >>>>>>> kernel. >>>>>>> >>>>>>> While most things already work fine, there's the issue of how to handle the >>>>>>> power domains. Currently I need to ungate some clocks in the TF-A >>>>>>> BL31 to get for example the GPU running. If I understand this correctly the >>>>>>> proposed power domain driver could handle this in Linux otherwise. >>>>>>> >>>>>> >>>>>> the SCMI over SMC is still under review >>>>> >>>>> Even if the SCMI over SMC is ready at some point, it's still unclear to >>>>> me how you intend to abstract the GPC behind the SCMI interface in the >>>>> TF-A. The power domains have dependencies both into the regulator and >>>>> the clock framework. Both are currently under exclusive control of the >>>>> rich OS. How do you intend to allow the TF-A to control the power >>>>> supplies and necessary reset clocks without messing up any state in the >>>>> rich OS? >>>> >>>> This is indeed difficult, SCMI assumes that the responder has sufficient >>>> control over clocks to fully implement power domain handling, including >>>> over clocks and regulators. >>>> >>>> Perhaps it might be possible to modify current gpcv2 driver to send SCMI >>>> messages for power only and keep handling regulators itself? It could >>>> switch based on whether it has a reference to a scmi channel as a DT >>>> property. >>> >>> With such a split implementation I feel like we are getting worst of >>> both worlds: more complexity as the implementation is split across >>> multiple components (TF-A and kernel) and still the rich OS is able to >>> mess up the power supply of a domain that it might not even own. This >>> doesn't sound really enticing. >>> >>> IMHO it only makes sense to push this functionality down into TF-A if >>> it allows to abstract all the implementation details behind a standard >>> interface like SCMI. But then the needed changes are much more invasive >>> than just pushing down the GPC implementation. >>> >>>> A full scmi-based implementation might use entirely very different >>>> bindings and take a long time. If people want to support their chips by >>>> implementing power domain support in the rich OS we shouldn't block them. >>>> >>>> So it would be good to accept gpcv2 enhancement for 8mm and similar. >>> >>> I fully agree. >>> >>> For a full SCMI based implementation I expect that much more than just >>> the GPC functionality needs to be pushed down into the TF-A. Right now >>> I see clocks, i2c and regulator handling, maybe there is more that >>> escapes my mind. >> >> I2C regulator handling inside TF-A sounds very difficult. Not only would >> upstream TF-A likely object but on imx8m EVK boards the i2c bus for >> regulators is shared with other devices (like camera). > > And that's exactly the point where trying to push things into lower > layers starts to crumble. It only really makes sense if you manage to > establish a nice abstraction of what is happening in those lower > layers. If you need to punch through those abstractions due to system > design limitations, the benefit of those abstractions is wiped away. > The only thing you gain is more complexity due to more components being > involved in a specific task. > > If you want to be able to partition the system (and as far as I > understand it that's the main motivation for pushing GPC functionality > into TF-A) you need to design the system (starting on the HW level) to > make this possible. Trying to force such a model on a system that > hasn't really been designed for this is IMHO doomed to fail. > >> So if we do this maybe SCMI dt bindings could be expanded to at least >> allow regulators on a per-domain basis? > > Maybe that is what needs to be done to allow at least a partial > implementation of SCMI on the existing i.MX8M designs. However it > doesn't really provide much of the benefits of SCMI. > > So I'm all for having a pure Linux based implementation of the > functionality, instead of waiting for the SCMI based implementation > that may provide only questionable benefit. After reading through the thread and other resources - with still very limited knowledge - I tend to support Lucas' argument. We want to provide a mainline BSP for our i.MX8MM hardware and it seems like pushing more and more functionality from Linux into firmware will increase complexity even further and also delay or block the upstreaming of missing components, that would otherwise be rather easy to get running.