All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacky Bai <ping.bai@nxp.com>
To: "robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"l.stach@pengutronix.de" <l.stach@pengutronix.de>,
	Aisheng Dong <aisheng.dong@nxp.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"festevam@gmail.com" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [PATCH 0/3] Add power domain driver support for i.mx8m family
Date: Wed, 17 Apr 2019 05:27:24 +0000	[thread overview]
Message-ID: <20190417053211.2195-1-ping.bai@nxp.com> (raw)

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

-- 
2.21.0

WARNING: multiple messages have this Message-ID (diff)
From: Jacky Bai <ping.bai@nxp.com>
To: "robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"l.stach@pengutronix.de" <l.stach@pengutronix.de>,
	Aisheng Dong <aisheng.dong@nxp.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"festevam@gmail.com" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [PATCH 0/3] Add power domain driver support for i.mx8m family
Date: Wed, 17 Apr 2019 05:27:24 +0000	[thread overview]
Message-ID: <20190417053211.2195-1-ping.bai@nxp.com> (raw)

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

-- 
2.21.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2019-04-17  5:27 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17  5:27 Jacky Bai [this message]
2019-04-17  5:27 ` [PATCH 0/3] Add power domain driver support for i.mx8m family Jacky Bai
2019-04-17  5:27 ` [PATCH 1/3] dt-bindings: power: Add power domain binding " Jacky Bai
2019-04-17  5:27   ` Jacky Bai
2019-04-17  5:27 ` [PATCH 2/3] soc: imx: Add power domain driver support " Jacky Bai
2019-04-17  5:27   ` Jacky Bai
2019-04-17  5:27 ` [PATCH 3/3] arm64: dts: freescale: Add power domain nodes for i.mx8mm Jacky Bai
2019-04-17  5:27   ` Jacky Bai
2019-04-17 11:16 ` [PATCH 0/3] Add power domain driver support for i.mx8m family Aisheng Dong
2019-04-17 11:16   ` Aisheng Dong
2019-04-17 12:13   ` Lucas Stach
2019-04-17 12:13     ` Lucas Stach
2019-04-17 12:40     ` Leonard Crestez
2019-04-17 12:40       ` Leonard Crestez
2019-04-17 12:54       ` Lucas Stach
2019-04-17 13:25         ` Sudeep Holla
2019-04-17 12:54       ` Peng Fan
2019-04-17 12:54         ` Peng Fan
2019-04-17 13:33       ` Sudeep Holla
2019-04-17 13:33         ` Sudeep Holla
2019-04-17 16:21         ` Leonard Crestez
2019-04-17 16:21           ` Leonard Crestez
2019-04-18 14:43           ` Sudeep Holla
2019-04-18 14:43             ` Sudeep Holla
2019-11-07 21:28             ` Adam Ford
2019-11-07 21:28               ` Adam Ford
2020-02-13  9:16               ` Schrempf Frieder
2020-02-13  9:16                 ` Schrempf Frieder
2020-02-13  9:21                 ` Jacky Bai
2020-02-13  9:21                   ` Jacky Bai
2020-02-13 10:52                   ` Schrempf Frieder
2020-02-13 10:52                     ` Schrempf Frieder
2020-02-13 11:32                   ` Lucas Stach
2020-02-13 11:32                     ` Lucas Stach
2020-02-13 14:30                     ` Leonard Crestez
2020-02-13 14:30                       ` Leonard Crestez
2020-02-13 14:47                       ` Lucas Stach
2020-02-13 14:47                         ` Lucas Stach
2020-02-13 15:19                         ` Leonard Crestez
2020-02-13 15:19                           ` Leonard Crestez
2020-02-13 15:58                           ` Lucas Stach
2020-02-13 15:58                             ` Lucas Stach
2020-02-13 16:16                             ` Schrempf Frieder
2020-02-13 16:16                               ` Schrempf Frieder
2019-04-17 13:23     ` Sudeep Holla
2019-04-17 13:23       ` Sudeep Holla
2019-04-17 13:36       ` Sudeep Holla
2019-04-17 13:36         ` Sudeep Holla
2019-04-17 12:39 Jacky Bai
2019-04-17 14:30 Jacky Bai
2019-04-17 14:43 ` Sudeep Holla
2019-04-17 14:43   ` Sudeep Holla
2019-04-18  1:54 Jacky Bai
2019-04-20 13:38 Peng Fan
2019-04-23 11:07 ` Sudeep Holla
2019-04-23 11:07   ` Sudeep Holla
2019-04-23 14:02   ` Peng Fan
2019-04-23 14:02     ` Peng Fan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190417053211.2195-1-ping.bai@nxp.com \
    --to=ping.bai@nxp.com \
    --cc=aisheng.dong@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.