[PATCH V4 2/2] clk: scmi: support state_ctrl_forbidden

Sudeep Holla sudeep.holla at arm.com
Thu Feb 22 01:41:53 PST 2024


On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan at 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 at arm.com>
> Signed-off-by: Cristian Marussi <cristian.marussi at arm.com>
> Signed-off-by: Peng Fan <peng.fan at 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



More information about the linux-arm-kernel mailing list