linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@oss.nxp.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Peng Fan <peng.fan@nxp.com>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Saravana Kannan <saravanak@google.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Aisheng Dong <aisheng.dong@nxp.com>,
	Fabio Estevam <festevam@gmail.com>,
	Shawn Guo <shawnguo@kernel.org>, Jacky Bai <ping.bai@nxp.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	"arm-scmi@vger.kernel.org" <arm-scmi@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"imx@lists.linux.dev" <imx@lists.linux.dev>
Subject: Re: [PATCH v2 2/4] firmware: arm_scmi: Add machine_allowlist and machine_blocklist
Date: Wed, 12 Feb 2025 14:25:42 +0800	[thread overview]
Message-ID: <20250212062542.GA15796@localhost.localdomain> (raw)
In-Reply-To: <Z6tw3HjhI8to4c-E@bogus>

On Tue, Feb 11, 2025 at 03:46:36PM +0000, Sudeep Holla wrote:
>On Mon, Feb 10, 2025 at 01:19:14PM +0000, Peng Fan wrote:
>> 
>> I just have a prototype and tested on i.MX95.
>
>You didn't answer me @[1]. How can we disable it for perf/cpufreq if there
>are users already. I will look at the code once I am convince we can do that.
>For now, I am not. I am worried we may break some platform.

The only user in upstream kernel with using the dummy clock is juno-scmi.dtsi.

SCMI_PROTOCOL_PERF is used by two drivers cpufreq-scmi.c, scmi_perf_domain.c.

In cpufreq-scmi.c a dummy clock proviver is created, the gpu node in juno-scmi.dtsi
takes "<&scmi_dvfs 2>" into clocks property. I think this is wrong.

Why not use scmi_clk node? cpufreq created clk provider should only be limited
for cpu device which will not be impacted by fwdevlink.

If wanna to tune gpu performance, the power-domains property should be used,
not clocks property.

It is the juno-scmi.dtsi should be fixed.

If juno-scmi.dtsi will keep as it is, please suggest possible solution
on fixing the issue.

Regards,
Peng

>
>-- 
>Regards,
>Sudeep
>
>[1] https://lore.kernel.org/all/20241227151306.jh2oabc64xd54dms@bogus

  reply	other threads:[~2025-02-12  5:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-20  7:13 [PATCH v2 0/4] scmi: Bypass set fwnode and introduce allow/block list to address devlink issue Peng Fan (OSS)
2025-01-20  7:13 ` [PATCH v2 1/4] firmware: arm_scmi: Bypass setting fwnode for scmi cpufreq Peng Fan (OSS)
2025-02-05 12:45   ` Dan Carpenter
2025-02-06 10:52     ` Peng Fan
2025-02-06 11:31       ` Dan Carpenter
2025-02-06 11:42         ` Cristian Marussi
2025-02-06 11:49           ` Dan Carpenter
2025-02-13  8:17           ` Saravana Kannan
2025-02-13 13:08             ` Cristian Marussi
2025-01-20  7:13 ` [PATCH v2 2/4] firmware: arm_scmi: Add machine_allowlist and machine_blocklist Peng Fan (OSS)
2025-02-06  8:02   ` Dan Carpenter
2025-02-06 11:05     ` Peng Fan
2025-02-06 11:40       ` Dan Carpenter
2025-02-06 11:46         ` Dan Carpenter
2025-02-06 14:15           ` Peng Fan
2025-02-06 12:06   ` Cristian Marussi
2025-02-06 14:12     ` Peng Fan
2025-02-10 13:19     ` Peng Fan
2025-02-11 15:46       ` Sudeep Holla
2025-02-12  6:25         ` Peng Fan [this message]
2025-02-12  6:19           ` Peng Fan
2025-01-20  7:13 ` [PATCH v2 3/4] pinctrl: freescale: scmi: Switch to use machine_allowlist Peng Fan (OSS)
2025-02-13  8:13   ` Saravana Kannan
2025-01-20  7:13 ` [PATCH v2 4/4] pinctrl: scmi: Switch to use machine_blocklist Peng Fan (OSS)
2025-02-13  8:13   ` Saravana Kannan
2025-02-04  3:31 ` [PATCH v2 0/4] scmi: Bypass set fwnode and introduce allow/block list to address devlink issue Peng Fan
2025-02-06  9:07   ` Linus Walleij

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=20250212062542.GA15796@localhost.localdomain \
    --to=peng.fan@oss.nxp.com \
    --cc=aisheng.dong@nxp.com \
    --cc=arm-scmi@vger.kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=ping.bai@nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=saravanak@google.com \
    --cc=shawnguo@kernel.org \
    --cc=sudeep.holla@arm.com \
    /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).