From: Sudeep Holla <sudeep.holla@arm.com>
To: Peng Fan <peng.fan@nxp.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
Sudeep Holla <sudeep.holla@arm.com>,
"cristian.marussi@arm.com" <cristian.marussi@arm.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>,
Glen G Wienecke <glen.wienecke@nxp.com>
Subject: Re: Question regarding scmi_perf_domain.c
Date: Tue, 17 Oct 2023 17:24:07 +0100 [thread overview]
Message-ID: <ZS61J7Zt2HD4ZI1u@bogus> (raw)
In-Reply-To: <DU0PR04MB9417FE7E2D1861FF0B4E809F88D6A@DU0PR04MB9417.eurprd04.prod.outlook.com>
On Tue, Oct 17, 2023 at 02:35:49PM +0000, Peng Fan wrote:
> > Subject: Re: Question regarding scmi_perf_domain.c
> >
[...]
> > What is the point in adding it ? You can always hack and test if you need.
>
> I might misunderstand, I thought this was a formal solution.
Not really, it was a proposal which we are discussing the options here.
> >
> > > >
> > > > Maybe a module parameter or Kconfig debug option could be used to
> > > > control this?
> > >
> > > Greg might not be happy for introducing module parameter, I guess.
> > >
> >
> > True. But I don't see point in adding a Kconfig as it needs to be enabled with
> > single (distro) Image.
And figured out both module param and Kconfig are not good options.
> >
> > > >
> > > > In this way an updated DTS with that adds a performance domain to a
> > > > consumer device node (which already has a power-domain), should
> > > > allow the consumer driver to continue to probe successfully.
> > > >
> > > > Peng, would this resolve your concern?
> > >
> > > Actually I am not sure. multiple PD is not a technical issue, it is
> > > just adding more changes to various device drivers, we have
> > > VPU/GPU/DISPLAY/NPU/ HSIO/CAMERA and etc.. so all the drivers need
> > > update, which is not welcomed by driver developers :)
> >
> > Why ? Have you posted the patches ? Any discussions you can point to ?
>
> I mean NXP internal.
>
OK at this point, I really don't care then. I was under the assumption
that we were talking everything upstream here. Downstream always has the
burden of constantly adapting to the upstream changes. This is not a
user ABI. I was pushing Ulf assuming something is needed upstream.
Sorry Ulf, I wasn't aware of this downstream driver business here, my bad.
So, if the genpd has changed the behaviour for multiple agents and has
decided not to support this case, then the drivers need to adapt. I don't
see a way out by working around in the SCMI driver as it may break some
other platforms and we haven't got a way to do it conditionally other
than module param which you have raised right concerns.
iAll I can say is downstream drivers need to adapt. Sorry I know it is
not what you want to hear but it is part and parcel for the downstream
code.
> >
> > > I am still trying to enable multiple PD for saying MMC, and see how it
> > > works after adding performance domain and how device dvfs works in
> > > such case.
> > >
> >
> > Interesting. So MMC domain is presented as perf domain rather than the
> > clock
> > + regulator ? Nice to see that abstraction being used.
>
> MMC IP is inside a block(named mix) which contains several other IPs.
> Current scmi sever perf design only exports MIX level perf, no regulator
> for now.
>
Thanks for the details.
--
Regards,
Sudeep
next prev parent reply other threads:[~2023-10-17 16:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 10:30 Question regarding scmi_perf_domain.c Peng Fan
2023-10-10 10:38 ` Ulf Hansson
2023-10-10 10:55 ` Sudeep Holla
2023-10-10 11:02 ` Ulf Hansson
2023-10-10 12:01 ` Peng Fan
2023-10-10 13:00 ` Sudeep Holla
2023-10-10 13:15 ` Peng Fan
2023-10-10 13:30 ` Sudeep Holla
2023-10-10 13:43 ` Peng Fan
2023-10-10 14:51 ` Sudeep Holla
2023-10-10 15:23 ` Ulf Hansson
2023-10-10 16:23 ` Sudeep Holla
2023-10-10 21:14 ` Ulf Hansson
2023-10-11 0:30 ` Peng Fan
2023-10-11 9:16 ` Sudeep Holla
2023-10-11 9:26 ` Ulf Hansson
2023-10-11 11:52 ` Peng Fan
2023-10-11 14:15 ` Sudeep Holla
2023-10-12 11:53 ` Ulf Hansson
2023-10-16 15:08 ` Ulf Hansson
2023-10-17 9:04 ` Sudeep Holla
2023-10-17 10:46 ` Ulf Hansson
2023-10-17 13:49 ` Sudeep Holla
2023-10-17 13:18 ` Peng Fan
2023-10-17 13:55 ` Sudeep Holla
2023-10-17 14:35 ` Peng Fan
2023-10-17 16:24 ` Sudeep Holla [this message]
2023-10-10 12:48 ` Sudeep Holla
2023-10-10 12:53 ` Peng Fan
2023-10-10 13:02 ` Sudeep Holla
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=ZS61J7Zt2HD4ZI1u@bogus \
--to=sudeep.holla@arm.com \
--cc=cristian.marussi@arm.com \
--cc=glen.wienecke@nxp.com \
--cc=linux-pm@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=ranjani.vaidyanathan@nxp.com \
--cc=ulf.hansson@linaro.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