Re: [Patch v5 4/6] soc: qcom: Extend RPMh power controller driver to register warming devices.
From: Bjorn Andersson
Date: Mon Mar 30 2020 - 18:29:41 EST
On Mon 30 Mar 07:53 PDT 2020, Thara Gopinath wrote:
> On 3/27/20 6:53 PM, Bjorn Andersson wrote:
> > On Thu 19 Mar 18:41 PDT 2020, Thara Gopinath wrote:
[..]
> > > +static int __init rpmhpd_init_warming_device(void)
> > > +{
> > > + size_t num_pds;
> > > + struct rpmhpd **rpmhpds;
> > > + int i;
> > > +
> > > + if (!global_desc)
> > > + return -EINVAL;
> > > +
> > > + rpmhpds = global_desc->rpmhpds;
> > > + num_pds = global_desc->num_pds;
> > > +
> > > + if (!of_find_property(rpmhpds[0]->dev->of_node, "#cooling-cells", NULL))
> > > + return 0;
> > > +
> > > + for (i = 0; i < num_pds; i++)
> > > + if (rpmhpds[i]->is_warming_dev)
> > > + of_pd_warming_register(rpmhpds[i]->dev, i);
> > > +
> > > + return 0;
> > > +}
> > > +late_initcall(rpmhpd_init_warming_device);
> >
> > ...why can't this be done in rpmhpd_probe()?
> >
> > In particular with the recent patches from John Stultz to allow rpmhpd
> > to be built as a module I don't think there's any guarantees that
> > rpmh_probe() will have succeeded before rpmhpd_init_warming_device()
> > executes.
>
> It is to take care of boot order.
Understood.
> So this has to happen after the thermal framework is initialized. Thermal
> framework is initialized with core_initcall. Can I move the rpmhpd init as a
> postcore_initcall ? Then I can get rid of this separate function and keep it
> as part of probe.
>
So I presume the problem is that if this is called from probe, you might
of_pd_warming_register(), which ends up in
__thermal_cooling_device_register() before thermal_init() has been
invoked?
Which is bad because e.g. thermal_class is not yet initialized.
I don't want to rely on the order of initcalls for things to work, so
could we make this more robust by having
thermal_of_cooling_device_register() return -EPROBE_DEFER is
thermal_init() isn't done?
Regards,
Bjorn