From: Jacky Bai <ping.bai@nxp.com>
To: "robh+dt@kernel.org" <robh+dt@kernel.org>,
"l.stach@pengutronix.de" <l.stach@pengutronix.de>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"festevam@gmail.com" <festevam@gmail.com>,
Leonard Crestez <leonard.crestez@nxp.com>,
Aisheng Dong <aisheng.dong@nxp.com>, Peng Fan <peng.fan@nxp.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: [RESEND PATCH 0/3] Add power domain driver support for imx8m family
Date: Tue, 2 Jul 2019 10:03:35 +0000 [thread overview]
Message-ID: <20190702100832.29718-1-ping.bai@nxp.com> (raw)
I just resend this patchset again to let us rethink & find out a quick way enable
the power domain support in mainline to help other modules upstream.
The GPC module is used for system power management for CPU core & peripheral's
power domain. For the whole i.MX8M family, different SOC has different power
domain design. Some power domains need special on/off flow(need to access the
register out of the GPC module).
It makes us hard to reuse the GPCv2 driver to cover all the different power
up sequence. Each time a new SOC is added, we must modify the GPCv2 power domain
driver to make it resuable for it. We need to add a lot of code for each new chip.
We need to access the SRC & SS's GPR in GPCv2 power domain driver, it is
burden to maintain the GPCv2 power domain driver. For example, in the future
i.MX8MP, there are ~20 power domains, some of the power domain need some special
handling only for this specific chip, same situation on i.MX8MM & i.MX8MN.
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 driver don't need to handle the power domain difference time to time.
All the power domain on/off sequence can be abstracted & handled in TF-A side.
it can simplify the power domain handling in kernel side. All the power domain
details can be hiden to TF-A side. TF-A image is SOC specific, we don't need
to care more about the one image principle.
I know some guys suggest to use SCMI to implement the power domains, but it is
a long way, need more time to investigate. especially, for the current SCMI power
domain, it can not meet all our requirement for power domain management. On i.MX8M,
some of the power domain on/off need to handle clock and external regulators, it is
not a generic handling for other SOC vendors, I think.
Additonally, the SiP Service Calls provide interfaces to SoC implementation specific
services on this platform. For example, Secure platform initialization, configuration
and some power control. I don't think it can not be used for specific SOC.
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
next reply other threads:[~2019-07-02 10:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 10:03 Jacky Bai [this message]
2019-07-02 10:03 ` [RESEND PATCH 1/3] dt-bindings: power: Add power domain binding for i.mx8m family Jacky Bai
2019-07-22 23:09 ` Rob Herring
2019-07-02 10:03 ` [RESEND PATCH 2/3] soc: imx: Add power domain driver support " Jacky Bai
2019-07-02 11:06 ` Sudeep Holla
2019-07-03 1:15 ` Jacky Bai
2019-07-02 10:03 ` [RESEND PATCH 3/3] arm64: dts: freescale: Add power domain nodes for i.mx8mm Jacky Bai
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=20190702100832.29718-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=leonard.crestez@nxp.com \
--cc=linux-imx@nxp.com \
--cc=peng.fan@nxp.com \
--cc=robh+dt@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).