linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions
@ 2024-01-21 11:09 Peng Fan (OSS)
  2024-01-21 11:09 ` [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden Peng Fan (OSS)
  2024-02-22  9:34 ` [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions Sudeep Holla
  0 siblings, 2 replies; 8+ messages in thread
From: Peng Fan (OSS) @ 2024-01-21 11:09 UTC (permalink / raw)
  To: sudeep.holla, cristian.marussi, mturquette, sboyd
  Cc: linux-arm-kernel, linux-clk, linux-kernel, Peng Fan

From: Peng Fan <peng.fan@nxp.com>

ARM SCMI Spec 3.2 introduces Clock Get Permission command. This patch
is to add the support. Add three bool entries to scmi_clock_info to
indicate the operation is forbidden or not. If the CLOCK_GET_PERMISSIONS
command is not supported, the three bool variables will default
set to false, otherwise they will be set according to the return result
of CLOCK_GET_PERMISSIONS.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---

V4:
 Add R-b

V3:
 Rebased on https://lore.kernel.org/linux-arm-kernel/20240110120916.2482603-1-cristian.marussi@arm.com/
 Drop attribute which is no needed
 Use scmi_clock_domain_lookup
 Update patch subject

V2:
 Take Cristian's suggestion, https://lore.kernel.org/all/ZWiqqfQ73tezFmSk@pluto/

 drivers/firmware/arm_scmi/clock.c | 64 +++++++++++++++++++++++++++++++
 include/linux/scmi_protocol.h     |  3 ++
 2 files changed, 67 insertions(+)

diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index 2e4d6479a639..959e48aba1b5 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -28,8 +28,13 @@ enum scmi_clock_protocol_cmd {
 	CLOCK_POSSIBLE_PARENTS_GET = 0xC,
 	CLOCK_PARENT_SET = 0xD,
 	CLOCK_PARENT_GET = 0xE,
+	CLOCK_GET_PERMISSIONS = 0xF,
 };
 
+#define CLOCK_STATE_CONTROL_ALLOWED	BIT(31)
+#define CLOCK_PARENT_CONTROL_ALLOWED	BIT(30)
+#define CLOCK_RATE_CONTROL_ALLOWED	BIT(29)
+
 enum clk_state {
 	CLK_STATE_DISABLE,
 	CLK_STATE_ENABLE,
@@ -49,6 +54,7 @@ struct scmi_msg_resp_clock_attributes {
 #define SUPPORTS_RATE_CHANGE_REQUESTED_NOTIF(x)	((x) & BIT(30))
 #define SUPPORTS_EXTENDED_NAMES(x)		((x) & BIT(29))
 #define SUPPORTS_PARENT_CLOCK(x)		((x) & BIT(28))
+#define SUPPORTS_GET_PERMISSIONS(x)		((x) & BIT(1))
 	u8 name[SCMI_SHORT_NAME_MAX_SIZE];
 	__le32 clock_enable_latency;
 };
@@ -293,6 +299,35 @@ static int scmi_clock_possible_parents(const struct scmi_protocol_handle *ph, u3
 	return ret;
 }
 
+static int
+scmi_clock_get_permissions(const struct scmi_protocol_handle *ph, u32 clk_id,
+			   struct scmi_clock_info *clk)
+{
+	struct scmi_xfer *t;
+	u32 perm;
+	int ret;
+
+	ret = ph->xops->xfer_get_init(ph, CLOCK_GET_PERMISSIONS,
+				      sizeof(clk_id), sizeof(perm), &t);
+	if (ret)
+		return ret;
+
+	put_unaligned_le32(clk_id, t->tx.buf);
+
+	ret = ph->xops->do_xfer(ph, t);
+	if (!ret) {
+		perm = get_unaligned_le32(t->rx.buf);
+
+		clk->state_ctrl_forbidden = !(perm & CLOCK_STATE_CONTROL_ALLOWED);
+		clk->rate_ctrl_forbidden = !(perm & CLOCK_RATE_CONTROL_ALLOWED);
+		clk->parent_ctrl_forbidden = !(perm & CLOCK_PARENT_CONTROL_ALLOWED);
+	}
+
+	ph->xops->xfer_put(ph, t);
+
+	return ret;
+}
+
 static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
 				     u32 clk_id, struct scmi_clock_info *clk,
 				     u32 version)
@@ -339,6 +374,8 @@ static int scmi_clock_attributes_get(const struct scmi_protocol_handle *ph,
 			clk->rate_change_requested_notifications = true;
 		if (SUPPORTS_PARENT_CLOCK(attributes))
 			scmi_clock_possible_parents(ph, clk_id, clk);
+		if (SUPPORTS_GET_PERMISSIONS(attributes))
+			scmi_clock_get_permissions(ph, clk_id, clk);
 	}
 
 	return ret;
@@ -511,6 +548,14 @@ static int scmi_clock_rate_set(const struct scmi_protocol_handle *ph,
 	struct scmi_xfer *t;
 	struct scmi_clock_set_rate *cfg;
 	struct clock_info *ci = ph->get_priv(ph);
+	struct scmi_clock_info *clk;
+
+	clk = scmi_clock_domain_lookup(ci, clk_id);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	if (clk->rate_ctrl_forbidden)
+		return -EACCES;
 
 	ret = ph->xops->xfer_get_init(ph, CLOCK_RATE_SET, sizeof(*cfg), 0, &t);
 	if (ret)
@@ -596,6 +641,9 @@ scmi_clock_set_parent(const struct scmi_protocol_handle *ph, u32 clk_id,
 	if (parent_id >= clk->num_parents)
 		return -EINVAL;
 
+	if (clk->parent_ctrl_forbidden)
+		return -EACCES;
+
 	ret = ph->xops->xfer_get_init(ph, CLOCK_PARENT_SET,
 				      sizeof(*cfg), 0, &t);
 	if (ret)
@@ -679,6 +727,14 @@ static int scmi_clock_enable(const struct scmi_protocol_handle *ph, u32 clk_id,
 			     bool atomic)
 {
 	struct clock_info *ci = ph->get_priv(ph);
+	struct scmi_clock_info *clk;
+
+	clk = scmi_clock_domain_lookup(ci, clk_id);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	if (clk->state_ctrl_forbidden)
+		return -EACCES;
 
 	return ci->clock_config_set(ph, clk_id, CLK_STATE_ENABLE,
 				    NULL_OEM_TYPE, 0, atomic);
@@ -688,6 +744,14 @@ static int scmi_clock_disable(const struct scmi_protocol_handle *ph, u32 clk_id,
 			      bool atomic)
 {
 	struct clock_info *ci = ph->get_priv(ph);
+	struct scmi_clock_info *clk;
+
+	clk = scmi_clock_domain_lookup(ci, clk_id);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	if (clk->state_ctrl_forbidden)
+		return -EACCES;
 
 	return ci->clock_config_set(ph, clk_id, CLK_STATE_DISABLE,
 				    NULL_OEM_TYPE, 0, atomic);
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 659a8e910bfc..98f8c0a58458 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -47,6 +47,9 @@ struct scmi_clock_info {
 	bool rate_discrete;
 	bool rate_changed_notifications;
 	bool rate_change_requested_notifications;
+	bool state_ctrl_forbidden;
+	bool rate_ctrl_forbidden;
+	bool parent_ctrl_forbidden;
 	union {
 		struct {
 			int num_rates;
-- 
2.37.1


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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden
  2024-01-21 11:09 [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions Peng Fan (OSS)
@ 2024-01-21 11:09 ` Peng Fan (OSS)
  2024-01-22 17:17   ` Cristian Marussi
                     ` (2 more replies)
  2024-02-22  9:34 ` [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions Sudeep Holla
  1 sibling, 3 replies; 8+ messages in thread
From: Peng Fan (OSS) @ 2024-01-21 11:09 UTC (permalink / raw)
  To: sudeep.holla, cristian.marussi, mturquette, sboyd
  Cc: linux-arm-kernel, linux-clk, linux-kernel, Peng Fan

From: Peng Fan <peng.fan@nxp.com>

Some clocks may exported to linux, while those clocks are not allowed
to configure by Linux. For example:

SYS_CLK1-----
             \
	     --MUX--->MMC1_CLK
             /
SYS_CLK2-----

MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux,
then the clk propagation will touch SYS_CLK1 or SYS_CLK2.
So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable
the clock of MMC1, adding scmi_no_state_ctrl_clk_ops to use software
enable counter, while not calling scmi api.

Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---

V4:
 Add scmi_no_state_ctrl_clk_ops per Cristian
 Add Cristian's tag

V3:
 Add check in atomic enable

V2:
 New. Take Cristian's suggestion

 drivers/clk/clk-scmi.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index 8cbe24789c24..5747b6d651f0 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -194,6 +194,15 @@ static const struct clk_ops scmi_atomic_clk_ops = {
 	.determine_rate = scmi_clk_determine_rate,
 };
 
+static const struct clk_ops scmi_no_state_ctrl_clk_ops = {
+	.recalc_rate = scmi_clk_recalc_rate,
+	.round_rate = scmi_clk_round_rate,
+	.set_rate = scmi_clk_set_rate,
+	.set_parent = scmi_clk_set_parent,
+	.get_parent = scmi_clk_get_parent,
+	.determine_rate = scmi_clk_determine_rate,
+};
+
 static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk,
 			     const struct clk_ops *scmi_ops)
 {
@@ -290,8 +299,10 @@ static int scmi_clocks_probe(struct scmi_device *sdev)
 		 * specify (or support) an enable_latency associated with a
 		 * clock, we default to use atomic operations mode.
 		 */
-		if (is_atomic &&
-		    sclk->info->enable_latency <= atomic_threshold)
+		if (sclk->info->state_ctrl_forbidden)
+			scmi_ops = &scmi_no_state_ctrl_clk_ops;
+		else if (is_atomic &&
+			 sclk->info->enable_latency <= atomic_threshold)
 			scmi_ops = &scmi_atomic_clk_ops;
 		else
 			scmi_ops = &scmi_clk_ops;
-- 
2.37.1


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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden
  2024-01-21 11:09 ` [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden Peng Fan (OSS)
@ 2024-01-22 17:17   ` Cristian Marussi
  2024-01-23 11:13   ` Sudeep Holla
  2024-02-22  9:41   ` Sudeep Holla
  2 siblings, 0 replies; 8+ messages in thread
From: Cristian Marussi @ 2024-01-22 17:17 UTC (permalink / raw)
  To: Peng Fan (OSS)
  Cc: sudeep.holla, mturquette, sboyd, linux-arm-kernel, linux-clk,
	linux-kernel, Peng Fan

On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> Some clocks may exported to linux, while those clocks are not allowed
> to configure by Linux. For example:
> 
> SYS_CLK1-----
>              \
> 	     --MUX--->MMC1_CLK
>              /
> SYS_CLK2-----
> 
> MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux,
> then the clk propagation will touch SYS_CLK1 or SYS_CLK2.
> So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable
> the clock of MMC1, adding scmi_no_state_ctrl_clk_ops to use software
> enable counter, while not calling scmi api.
> 
> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---

Thanks, LGTM.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>

Cheers,
Cristian

> 
> V4:
>  Add scmi_no_state_ctrl_clk_ops per Cristian
>  Add Cristian's tag
> 
> V3:
>  Add check in atomic enable
> 
> V2:
>  New. Take Cristian's suggestion
> 
>  drivers/clk/clk-scmi.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
> index 8cbe24789c24..5747b6d651f0 100644
> --- a/drivers/clk/clk-scmi.c
> +++ b/drivers/clk/clk-scmi.c
> @@ -194,6 +194,15 @@ static const struct clk_ops scmi_atomic_clk_ops = {
>  	.determine_rate = scmi_clk_determine_rate,
>  };
>  
> +static const struct clk_ops scmi_no_state_ctrl_clk_ops = {
> +	.recalc_rate = scmi_clk_recalc_rate,
> +	.round_rate = scmi_clk_round_rate,
> +	.set_rate = scmi_clk_set_rate,
> +	.set_parent = scmi_clk_set_parent,
> +	.get_parent = scmi_clk_get_parent,
> +	.determine_rate = scmi_clk_determine_rate,
> +};
> +
>  static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk,
>  			     const struct clk_ops *scmi_ops)
>  {
> @@ -290,8 +299,10 @@ static int scmi_clocks_probe(struct scmi_device *sdev)
>  		 * specify (or support) an enable_latency associated with a
>  		 * clock, we default to use atomic operations mode.
>  		 */
> -		if (is_atomic &&
> -		    sclk->info->enable_latency <= atomic_threshold)
> +		if (sclk->info->state_ctrl_forbidden)
> +			scmi_ops = &scmi_no_state_ctrl_clk_ops;
> +		else if (is_atomic &&
> +			 sclk->info->enable_latency <= atomic_threshold)
>  			scmi_ops = &scmi_atomic_clk_ops;
>  		else
>  			scmi_ops = &scmi_clk_ops;
> -- 
> 2.37.1
> 

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden
  2024-01-21 11:09 ` [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden Peng Fan (OSS)
  2024-01-22 17:17   ` Cristian Marussi
@ 2024-01-23 11:13   ` Sudeep Holla
  2024-02-18  2:19     ` Peng Fan
  2024-02-22  9:41   ` Sudeep Holla
  2 siblings, 1 reply; 8+ messages in thread
From: Sudeep Holla @ 2024-01-23 11:13 UTC (permalink / raw)
  To: Peng Fan (OSS), sboyd
  Cc: cristian.marussi, mturquette, Sudeep Holla, linux-arm-kernel,
	linux-clk, linux-kernel, Peng Fan

On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> Some clocks may exported to linux, while those clocks are not allowed
> to configure by Linux. For example:
> 
> SYS_CLK1-----
>              \
> 	     --MUX--->MMC1_CLK
>              /
> SYS_CLK2-----
> 
> MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux,
> then the clk propagation will touch SYS_CLK1 or SYS_CLK2.
> So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable
> the clock of MMC1, adding scmi_no_state_ctrl_clk_ops to use software
> enable counter, while not calling scmi api.
>

I would rewrite the commit message something like:
"
    clk: scmi: Add support for forbidden clock state controls

    Some clocks may be exported to OS agent, while certain configurations/
    access to those clocks are restricted to the OS agent by the SCMI platform
    firmware. For example:

    SYS_CLK1-----
                 \
                 --MUX--->MMC1_CLK
                 /
    SYS_CLK2-----

    MMC1_CLK needs to set parent as part of it initialisation and enabling.
    SYS_CLK1 and SYS_CLK2 are exported to the OS agent. The clk propagation
    will access SYS_CLK1 or SYS_CLK2 based on the configuration. However,
    we need bypass the failure to access SYS_CLK1 or SYS_CLK2 when MMC1_CLK
    is accessed and enabled.

    Add a separate scmi_no_state_ctrl clk_ops where the calls to the SCMI
    platform firmware are avoided if the access is not permitted.
"
No need to repost.

I need Stephen's ack to take this together with scmi clk changes.

--
Regards,
Sudeep

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden
  2024-01-23 11:13   ` Sudeep Holla
@ 2024-02-18  2:19     ` Peng Fan
  0 siblings, 0 replies; 8+ messages in thread
From: Peng Fan @ 2024-02-18  2:19 UTC (permalink / raw)
  To: Sudeep Holla, Peng Fan (OSS), sboyd@kernel.org
  Cc: cristian.marussi@arm.com, mturquette@baylibre.com,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org

> Subject: Re: [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden
> 
> On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Some clocks may exported to linux, while those clocks are not allowed
> > to configure by Linux. For example:
> >
> > SYS_CLK1-----
> >              \
> > 	     --MUX--->MMC1_CLK
> >              /
> > SYS_CLK2-----
> >
> > MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux,
> > then the clk propagation will touch SYS_CLK1 or SYS_CLK2.
> > So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable the
> > clock of MMC1, adding scmi_no_state_ctrl_clk_ops to use software
> > enable counter, while not calling scmi api.
> >
> 
> I would rewrite the commit message something like:
> "
>     clk: scmi: Add support for forbidden clock state controls
> 
>     Some clocks may be exported to OS agent, while certain configurations/
>     access to those clocks are restricted to the OS agent by the SCMI platform
>     firmware. For example:
> 
>     SYS_CLK1-----
>                  \
>                  --MUX--->MMC1_CLK
>                  /
>     SYS_CLK2-----
> 
>     MMC1_CLK needs to set parent as part of it initialisation and enabling.
>     SYS_CLK1 and SYS_CLK2 are exported to the OS agent. The clk propagation
>     will access SYS_CLK1 or SYS_CLK2 based on the configuration. However,
>     we need bypass the failure to access SYS_CLK1 or SYS_CLK2 when
> MMC1_CLK
>     is accessed and enabled.
> 
>     Add a separate scmi_no_state_ctrl clk_ops where the calls to the SCMI
>     platform firmware are avoided if the access is not permitted.
> "
> No need to repost.
> 
> I need Stephen's ack to take this together with scmi clk changes.

Stephen, 

would you please ack if you are ok?

Thanks,
Peng.

> 
> --
> Regards,
> Sudeep

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions
  2024-01-21 11:09 [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions Peng Fan (OSS)
  2024-01-21 11:09 ` [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden Peng Fan (OSS)
@ 2024-02-22  9:34 ` Sudeep Holla
  1 sibling, 0 replies; 8+ messages in thread
From: Sudeep Holla @ 2024-02-22  9:34 UTC (permalink / raw)
  To: cristian.marussi, mturquette, sboyd, Peng Fan (OSS)
  Cc: Sudeep Holla, linux-arm-kernel, linux-clk, linux-kernel, Peng Fan

On Sun, 21 Jan 2024 19:09:00 +0800, Peng Fan (OSS) wrote:
> ARM SCMI Spec 3.2 introduces Clock Get Permission command. This patch
> is to add the support. Add three bool entries to scmi_clock_info to
> indicate the operation is forbidden or not. If the CLOCK_GET_PERMISSIONS
> command is not supported, the three bool variables will default
> set to false, otherwise they will be set according to the return result
> of CLOCK_GET_PERMISSIONS.
> 
> [...]

When I was about to ask for Stephen's ack for 2/2, I noticed an issue
now, will repond to it directly.

Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!

[1/2] firmware: arm_scmi: Implement Clock get permissions
      https://git.kernel.org/sudeep.holla/c/dc36561e1548

--
Regards,
Sudeep


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden
  2024-01-21 11:09 ` [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden Peng Fan (OSS)
  2024-01-22 17:17   ` Cristian Marussi
  2024-01-23 11:13   ` Sudeep Holla
@ 2024-02-22  9:41   ` Sudeep Holla
  2024-02-22  9:55     ` Cristian Marussi
  2 siblings, 1 reply; 8+ messages in thread
From: Sudeep Holla @ 2024-02-22  9:41 UTC (permalink / raw)
  To: Peng Fan (OSS)
  Cc: cristian.marussi, mturquette, sboyd, linux-arm-kernel, linux-clk,
	linux-kernel, Peng Fan

On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> Some clocks may exported to linux, while those clocks are not allowed
> to configure by Linux. For example:
> 
> SYS_CLK1-----
>              \
> 	     --MUX--->MMC1_CLK
>              /
> SYS_CLK2-----
> 
> MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux,
> then the clk propagation will touch SYS_CLK1 or SYS_CLK2.
> So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable
> the clock of MMC1, adding scmi_no_state_ctrl_clk_ops to use software
> enable counter, while not calling scmi api.
> 
> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> 
> V4:
>  Add scmi_no_state_ctrl_clk_ops per Cristian
>  Add Cristian's tag
> 
> V3:
>  Add check in atomic enable
> 
> V2:
>  New. Take Cristian's suggestion
> 
>  drivers/clk/clk-scmi.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
> index 8cbe24789c24..5747b6d651f0 100644
> --- a/drivers/clk/clk-scmi.c
> +++ b/drivers/clk/clk-scmi.c
> @@ -194,6 +194,15 @@ static const struct clk_ops scmi_atomic_clk_ops = {
>  	.determine_rate = scmi_clk_determine_rate,
>  };
>  
> +static const struct clk_ops scmi_no_state_ctrl_clk_ops = {
> +	.recalc_rate = scmi_clk_recalc_rate,
> +	.round_rate = scmi_clk_round_rate,
> +	.set_rate = scmi_clk_set_rate,
> +	.set_parent = scmi_clk_set_parent,
> +	.get_parent = scmi_clk_get_parent,
> +	.determine_rate = scmi_clk_determine_rate,
> +};
> +
>  static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk,
>  			     const struct clk_ops *scmi_ops)
>  {
> @@ -290,8 +299,10 @@ static int scmi_clocks_probe(struct scmi_device *sdev)
>  		 * specify (or support) an enable_latency associated with a
>  		 * clock, we default to use atomic operations mode.
>  		 */
> -		if (is_atomic &&
> -		    sclk->info->enable_latency <= atomic_threshold)
> +		if (sclk->info->state_ctrl_forbidden)
> +			scmi_ops = &scmi_no_state_ctrl_clk_ops;

With this, even if is_atomic and latency matches, we won't allow
atomic operations ? One reason why it gets tricky and as Cristian 
mentioned elsewhere we need dynamic assignment of these ops IMO.
Let me know if I am getting things wrong here ?

-- 
Regards,
Sudeep

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden
  2024-02-22  9:41   ` Sudeep Holla
@ 2024-02-22  9:55     ` Cristian Marussi
  0 siblings, 0 replies; 8+ messages in thread
From: Cristian Marussi @ 2024-02-22  9:55 UTC (permalink / raw)
  To: Sudeep Holla
  Cc: Peng Fan (OSS), mturquette, sboyd, linux-arm-kernel, linux-clk,
	linux-kernel, Peng Fan

On Thu, Feb 22, 2024 at 09:41:53AM +0000, Sudeep Holla wrote:
> On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> > 
> > Some clocks may exported to linux, while those clocks are not allowed
> > to configure by Linux. For example:
> > 
> > SYS_CLK1-----
> >              \
> > 	     --MUX--->MMC1_CLK
> >              /
> > SYS_CLK2-----
> > 
> > MMC1 needs set parent, so SYS_CLK1 and SYS_CLK2 are exported to Linux,
> > then the clk propagation will touch SYS_CLK1 or SYS_CLK2.
> > So we need bypass the failure for SYS_CLK1 or SYS_CLK2 when enable
> > the clock of MMC1, adding scmi_no_state_ctrl_clk_ops to use software
> > enable counter, while not calling scmi api.
> > 
> > Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > 
> > V4:
> >  Add scmi_no_state_ctrl_clk_ops per Cristian
> >  Add Cristian's tag
> > 
> > V3:
> >  Add check in atomic enable
> > 
> > V2:
> >  New. Take Cristian's suggestion
> > 
> >  drivers/clk/clk-scmi.c | 15 +++++++++++++--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
> > index 8cbe24789c24..5747b6d651f0 100644
> > --- a/drivers/clk/clk-scmi.c
> > +++ b/drivers/clk/clk-scmi.c
> > @@ -194,6 +194,15 @@ static const struct clk_ops scmi_atomic_clk_ops = {
> >  	.determine_rate = scmi_clk_determine_rate,
> >  };
> >  
> > +static const struct clk_ops scmi_no_state_ctrl_clk_ops = {
> > +	.recalc_rate = scmi_clk_recalc_rate,
> > +	.round_rate = scmi_clk_round_rate,
> > +	.set_rate = scmi_clk_set_rate,
> > +	.set_parent = scmi_clk_set_parent,
> > +	.get_parent = scmi_clk_get_parent,
> > +	.determine_rate = scmi_clk_determine_rate,
> > +};
> > +
> >  static int scmi_clk_ops_init(struct device *dev, struct scmi_clk *sclk,
> >  			     const struct clk_ops *scmi_ops)
> >  {
> > @@ -290,8 +299,10 @@ static int scmi_clocks_probe(struct scmi_device *sdev)
> >  		 * specify (or support) an enable_latency associated with a
> >  		 * clock, we default to use atomic operations mode.
> >  		 */
> > -		if (is_atomic &&
> > -		    sclk->info->enable_latency <= atomic_threshold)
> > +		if (sclk->info->state_ctrl_forbidden)
> > +			scmi_ops = &scmi_no_state_ctrl_clk_ops;
> 
> With this, even if is_atomic and latency matches, we won't allow
> atomic operations ? One reason why it gets tricky and as Cristian 
> mentioned elsewhere we need dynamic assignment of these ops IMO.
> Let me know if I am getting things wrong here ?

It is fine that we wont allow atomic ops either since state_ctrl_forbidden
means the server will reject any enable/disable action, atomic or
not...what I missed here, though, is that we lost also is_enabled indeed,
which could be provided even if state_ctrl_forbidden BUT only if atomic
is supported...so yes this will need an additional atomic/non_atomic
split of this static ops...and so the need for dynamic allocation I was
saying elsewhere....indeed the is_enabled case is handled correctly
again with my pending clk dynamic allocation of ops patch.

My bad, thanks for spotting this Sudeep!
Cristian

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-02-22  9:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-21 11:09 [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions Peng Fan (OSS)
2024-01-21 11:09 ` [PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden Peng Fan (OSS)
2024-01-22 17:17   ` Cristian Marussi
2024-01-23 11:13   ` Sudeep Holla
2024-02-18  2:19     ` Peng Fan
2024-02-22  9:41   ` Sudeep Holla
2024-02-22  9:55     ` Cristian Marussi
2024-02-22  9:34 ` [PATCH V4 1/2] firmware: arm_scmi: Implement Clock get permissions Sudeep Holla

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).