From: Peng Fan <[email protected]>
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 <[email protected]>
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
---
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
On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Cristian Marussi <[email protected]>
> Signed-off-by: Peng Fan <[email protected]>
> ---
Thanks, LGTM.
Reviewed-by: Cristian Marussi <[email protected]>
Tested-by: Cristian Marussi <[email protected]>
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
>
On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> 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
> 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 <[email protected]>
> >
> > 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
On Sun, Jan 21, 2024 at 07:09:01PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Cristian Marussi <[email protected]>
> Signed-off-by: Peng Fan <[email protected]>
> ---
>
> 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
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 <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Cristian Marussi <[email protected]>
> > Signed-off-by: Peng Fan <[email protected]>
> > ---
> >
> > 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