From: Anson Huang <anson.huang@nxp.com>
To: Stephen Boyd <sboyd@kernel.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mturquette@baylibre.com" <mturquette@baylibre.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
Fabio Estevam <fabio.estevam@nxp.com>,
Jerome Forissier <jerome.forissier@linaro.org>,
Peng Fan <peng.fan@nxp.com>, Rob Herring <robh@kernel.org>
Cc: dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Date: Tue, 16 Oct 2018 04:37:31 +0000 [thread overview]
Message-ID: <AM6PR0402MB39112C0451B6E241AEBAC0D7F5FE0@AM6PR0402MB3911.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <153962195779.5275.17500455384946496344@swboyd.mtv.corp.google.com>
Hi, Stephen
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Tuesday, October 16, 2018 12:46 AM
> To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturquette@baylibre.com; s.hauer@pengutronix.de; shawnguo@kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Anson Huang (2018-10-15 02:33:35)
> > > > > >
> > > > >
> > > > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > > > Then any clks in there can be turned on forever and left enabled
> > > > > by the linux driver?
> > > >
> > > > I did NOT run op-tee with Linux-next kernel before, can you advise more?
> > >
> > > Neither have I, so I can't advise more.
> > >
> > > > And I think if op-tee has such requirement, can we have another
> > > > patch to cover it?
> > >
> > > Yes.
> > >
> > >
> > > > I believe all other i.MX platforms also have same requirements if
> > > > considering op-tee support, so I think it should be another topic,
> > > > what do you
> > > think?
> > > >
> > >
> > > I'm going to drop these patches from my review queue. Please resend
> > > them and please include the op-tee patches too.
> >
> >
> > I do NOT know how to include the op-tee patch to meet special
> > requirement, should the op-tee related patch be added later when someone
> actually add the op-tee support for i.MX7?
> > It should NOT block this patch set, do you think we can add this patch set
> first?
> >
>
> Please resend the two patches. In the commit text for the second patch,
> describe the plan to remove CLK_IS_CRITICAL from these clks by adding an
> OP-TEE device/driver to the kernel to keep these clks enabled. My
> understanding is that there isn't an OP-TEE driver right now, but these clks are
> used by the firmware and can't be turned off in Linux. If in the future we want
> to be able to turn them on and off, we'll need to add them to an OP-TEE device
> node and have that driver manage the clks.
>
> How that will work when a system doesn't enable the OP-TEE driver I'm not
> sure. We may need to develop some system whereby clks like this are handed
> from the clk controller to the consumer driver when it's enabled for further
> power managment, but if they're never handed off, they're kept on forever like
> is done here. Anyway, please resend with a note about why these are marked
> CLK_IS_CRITICAL.
I think there is some misunderstanding here, this patch sets those critical clocks
with CLK_IS_CRITICAL flag to let clock driver keep them always ON, as they are
critical clocks and system (Linux kernel, NOT include op-tee) can NOT run normally
if anyone of them is OFF.
The question about op-tee is, there might be some special clocks needed by op-tee,
for example, currently clk A, B and C are kept always ON for Linux kernel to run normally,
but when op-tee is executing, it might need clk D to be ON, so I think the clk D is needed
ONLY for op-tee, op-tee should have a driver or firmware to runtime ON/OFF clk D as needed.
Since I do NOT know what clocks op-tee needs, so I will leave them to be added by op-tee
owner, whoever enables op-tee, he should consider where to manage its special clocks,
either in clk driver or op-tee driver/firmware.
So do we still need to mention the op-tee related info in commit text? Actually, this patch
is just to replace those always-ON clocks in clks_init_on array with CLK_IS_CRITICAL flag.
Then no need to explicitly enable clocks in clks_init_on array and just rely on common clk
framework which will enable all clocks with CLK_IS_CRITICAL flag set, it will align with all
other i.MX SoCs clk driver.
Anson.
next prev parent reply other threads:[~2018-10-16 4:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-08 4:39 [PATCH 1/2] clk: imx: imx7d: remove unnecessary clocks from clks_init_on array Anson Huang
2018-08-08 4:39 ` [PATCH 2/2] clk: imx: imx7d: remove " Anson Huang
2018-08-08 8:48 ` Peng Fan
2018-08-08 9:00 ` Anson Huang
2018-08-13 1:15 ` Peng Fan
2018-08-14 7:31 ` Anson Huang
2018-08-31 1:29 ` Stephen Boyd
2018-08-31 1:40 ` Anson Huang
2018-08-31 8:01 ` Jerome Forissier
2018-08-31 17:57 ` Stephen Boyd
2018-09-03 7:20 ` Anson Huang
2018-09-10 9:18 ` Anson Huang
2018-10-08 7:40 ` Stephen Boyd
2018-10-08 8:34 ` Anson Huang
2018-10-12 19:48 ` Stephen Boyd
2018-10-15 9:33 ` Anson Huang
2018-10-15 16:45 ` Stephen Boyd
2018-10-16 4:37 ` Anson Huang [this message]
2018-10-16 22:24 ` Stephen Boyd
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=AM6PR0402MB39112C0451B6E241AEBAC0D7F5FE0@AM6PR0402MB3911.eurprd04.prod.outlook.com \
--to=anson.huang@nxp.com \
--cc=fabio.estevam@nxp.com \
--cc=jerome.forissier@linaro.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=peng.fan@nxp.com \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=sboyd@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).