On Tue, Oct 03, 2023 at 11:30:28AM +0300, Dmitry Baryshkov wrote:
> On 28/08/2023 21:09, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2023-08-27 04:50:15)
> > > diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
> > > index d787f2ea36d9..45ffb068979d 100644
> > > --- a/drivers/interconnect/icc-clk.c
> > > +++ b/drivers/interconnect/icc-clk.c
> > > @@ -25,12 +28,16 @@ struct icc_clk_provider {
> > > static int icc_clk_set(struct icc_node *src, struct icc_node *dst)
> > > {
> > > struct icc_clk_node *qn = src->data;
> > > + unsigned long rate = icc_units_to_bps(src->peak_bw);
> > > int ret;
> > > if (!qn || !qn->clk)
> > > return 0;
> > > - if (!src->peak_bw) {
> > > + if (qn->opp)
> > > + return dev_pm_opp_set_rate(qn->dev, rate);
> >
> > Just curious how does lockdep do with this? Doesn't OPP call into
> > interconnect code, so lockdep will complain about ABBA?
>
> Unfortunately it does. It seems, the icc-clk is not a proper way to go here.
> I will take a look at reusing set_required_opps for this case.
>
Could you elaborate a bit which locks exactly cause trouble here?
I'm probably missing something here.
>From a quick look at the OPP code I don't see a global lock taken there
for the entire OPP switch sequence, so I'm not sure how this could cause
an ABBA deadlock.
Thanks,
Stephan
