[0/3] Add power domain driver support for i.mx8m family

Message

Jacky Bai April 17, 2019, 5:27 a.m. UTC

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.

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

Comments

Aisheng Dong April 17, 2019, 11:16 a.m. UTC | #1

> 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

Lucas Stach April 17, 2019, 12:13 p.m. UTC | #2

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

Leonard Crestez April 17, 2019, 12:40 p.m. UTC | #3

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

Lucas Stach April 17, 2019, 12:54 p.m. UTC | #4

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

Peng Fan April 17, 2019, 12:54 p.m. UTC | #5

> 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

Sudeep Holla April 17, 2019, 1:23 p.m. UTC | #6

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.

Sudeep Holla April 17, 2019, 1:25 p.m. UTC | #7

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.

Sudeep Holla April 17, 2019, 1:33 p.m. UTC | #8

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.

Sudeep Holla April 17, 2019, 1:36 p.m. UTC | #9

On Wed, Apr 17, 2019 at 2:23 PM Sudeep Holla <[e-mail]> 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.

Leonard Crestez April 17, 2019, 4:21 p.m. UTC | #10

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

Sudeep Holla April 18, 2019, 2:43 p.m. UTC | #11

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

Adam Ford Nov. 7, 2019, 9:28 p.m. UTC | #12

On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <[e-mail]> 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
> [e-mail]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Frieder Schrempf Feb. 13, 2020, 9:16 a.m. UTC | #13

Hi,

On 07.11.19 22:28, Adam Ford wrote:
> On Thu, Apr 18, 2019 at 9:43 AM Sudeep Holla <[e-mail]> 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

Jacky Bai Feb. 13, 2020, 9:21 a.m. UTC | #14

> -----Original Message-----
> From: Schrempf Frieder <[e-mail]>
> Sent: Thursday, February 13, 2020 5:16 PM
> To: Adam Ford <[e-mail]>; Sudeep Holla
> <[e-mail]>
> Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
> Fan <[e-mail]>; Souvik Chakravarty
> <[e-mail]>; Jacky Bai <[e-mail]>;
> [e-mail]; Clément Faure <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
> <[e-mail]>; Silvano Di Ninno <[e-mail]>;
> Leonard Crestez <[e-mail]>; [e-mail];
> [e-mail]; Lucas Stach <[e-mail]>
> 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 <[e-mail]>
> 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

Frieder Schrempf Feb. 13, 2020, 10:52 a.m. UTC | #15

On 13.02.20 10:21, Jacky Bai wrote:
>> -----Original Message-----
>> From: Schrempf Frieder <[e-mail]>
>> Sent: Thursday, February 13, 2020 5:16 PM
>> To: Adam Ford <[e-mail]>; Sudeep Holla
>> <[e-mail]>
>> Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
>> Fan <[e-mail]>; Souvik Chakravarty
>> <[e-mail]>; Jacky Bai <[e-mail]>;
>> [e-mail]; Clément Faure <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail];
>> dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
>> <[e-mail]>; Silvano Di Ninno <[e-mail]>;
>> Leonard Crestez <[e-mail]>; [e-mail];
>> [e-mail]; Lucas Stach <[e-mail]>
>> 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 <[e-mail]>
>> 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?

Lucas Stach Feb. 13, 2020, 11:32 a.m. UTC | #16

On Do, 2020-02-13 at 09:21 +0000, Jacky Bai wrote:
> > -----Original Message-----
> > From: Schrempf Frieder <[e-mail]>
> > Sent: Thursday, February 13, 2020 5:16 PM
> > To: Adam Ford <[e-mail]>; Sudeep Holla
> > <[e-mail]>
> > Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
> > Fan <[e-mail]>; Souvik Chakravarty
> > <[e-mail]>; Jacky Bai <[e-mail]>;
> > [e-mail]; Clément Faure <[e-mail]>;
> > [e-mail]; [e-mail]; [e-mail];
> > dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
> > <[e-mail]>; Silvano Di Ninno <[e-mail]>;
> > Leonard Crestez <[e-mail]>; [e-mail];
> > [e-mail]; Lucas Stach <[e-mail]>
> > 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 <[e-mail]>
> > 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

Leonard Crestez Feb. 13, 2020, 2:30 p.m. UTC | #17

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 <[e-mail]>
>>> Sent: Thursday, February 13, 2020 5:16 PM
>>> To: Adam Ford <[e-mail]>; Sudeep Holla
>>> <[e-mail]>
>>> Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
>>> Fan <[e-mail]>; Souvik Chakravarty
>>> <[e-mail]>; Jacky Bai <[e-mail]>;
>>> [e-mail]; Clément Faure <[e-mail]>;
>>> [e-mail]; [e-mail]; [e-mail];
>>> dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
>>> <[e-mail]>; Silvano Di Ninno <[e-mail]>;
>>> Leonard Crestez <[e-mail]>; [e-mail];
>>> [e-mail]; Lucas Stach <[e-mail]>
>>> 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 <[e-mail]>
>>> 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

Lucas Stach Feb. 13, 2020, 2:47 p.m. UTC | #18

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 <[e-mail]>
> > > > Sent: Thursday, February 13, 2020 5:16 PM
> > > > To: Adam Ford <[e-mail]>; Sudeep Holla
> > > > <[e-mail]>
> > > > Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
> > > > Fan <[e-mail]>; Souvik Chakravarty
> > > > <[e-mail]>; Jacky Bai <[e-mail]>;
> > > > [e-mail]; Clément Faure <[e-mail]>;
> > > > [e-mail]; [e-mail]; [e-mail];
> > > > dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
> > > > <[e-mail]>; Silvano Di Ninno <[e-mail]>;
> > > > Leonard Crestez <[e-mail]>; [e-mail];
> > > > [e-mail]; Lucas Stach <[e-mail]>
> > > > 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 <[e-mail]>
> > > > 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

Leonard Crestez Feb. 13, 2020, 3:19 p.m. UTC | #19

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 <[e-mail]>
>>>>> Sent: Thursday, February 13, 2020 5:16 PM
>>>>> To: Adam Ford <[e-mail]>; Sudeep Holla
>>>>> <[e-mail]>
>>>>> Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
>>>>> Fan <[e-mail]>; Souvik Chakravarty
>>>>> <[e-mail]>; Jacky Bai <[e-mail]>;
>>>>> [e-mail]; Clément Faure <[e-mail]>;
>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>> dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
>>>>> <[e-mail]>; Silvano Di Ninno <[e-mail]>;
>>>>> Leonard Crestez <[e-mail]>; [e-mail];
>>>>> [e-mail]; Lucas Stach <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>> 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.

Lucas Stach Feb. 13, 2020, 3:58 p.m. UTC | #20

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 <[e-mail]>
> > > > > > Sent: Thursday, February 13, 2020 5:16 PM
> > > > > > To: Adam Ford <[e-mail]>; Sudeep Holla
> > > > > > <[e-mail]>
> > > > > > Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
> > > > > > Fan <[e-mail]>; Souvik Chakravarty
> > > > > > <[e-mail]>; Jacky Bai <[e-mail]>;
> > > > > > [e-mail]; Clément Faure <[e-mail]>;
> > > > > > [e-mail]; [e-mail]; [e-mail];
> > > > > > dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
> > > > > > <[e-mail]>; Silvano Di Ninno <[e-mail]>;
> > > > > > Leonard Crestez <[e-mail]>; [e-mail];
> > > > > > [e-mail]; Lucas Stach <[e-mail]>
> > > > > > 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 <[e-mail]>
> > > > > > 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

Frieder Schrempf Feb. 13, 2020, 4:16 p.m. UTC | #21

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 <[e-mail]>
>>>>>>> Sent: Thursday, February 13, 2020 5:16 PM
>>>>>>> To: Adam Ford <[e-mail]>; Sudeep Holla
>>>>>>> <[e-mail]>
>>>>>>> Cc: Aisheng Dong <[e-mail]>; [e-mail]; Peng
>>>>>>> Fan <[e-mail]>; Souvik Chakravarty
>>>>>>> <[e-mail]>; Jacky Bai <[e-mail]>;
>>>>>>> [e-mail]; Clément Faure <[e-mail]>;
>>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>>> dl-linux-imx <[e-mail]>; [e-mail]; Andre Przywara
>>>>>>> <[e-mail]>; Silvano Di Ninno <[e-mail]>;
>>>>>>> Leonard Crestez <[e-mail]>; [e-mail];
>>>>>>> [e-mail]; Lucas Stach <[e-mail]>
>>>>>>> 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 <[e-mail]>
>>>>>>> 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.