Message-ID: <AM6PR04MB49662EB50652F3BC6FE67C9980E00@AM6PR04MB4966.eurprd04.prod.outlook.com>
Date:   Thu, 19 Nov 2020 14:09:42 +0000
From:   Aisheng Dong <aisheng.dong@....com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Saravana Kannan <saravanak@...gle.com>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Stephen Boyd <sboyd@...nel.org>
Subject: RE: [PATCH RESEND] driver core: export device_is_bound() to fix build
 failure

> From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Sent: Thursday, November 19, 2020 9:10 PM
> 
> On Thu, Nov 19, 2020 at 04:13:34AM +0000, Aisheng Dong wrote:
> > > Long story short, either
> > >
> > > * Don't care about the power domain in your clock driver.
> > >
> > > Or,
> > >
> > > * List the power domain in the clock controller's DT node and then
> > > use the normal APIs to get the power domain. And defer like any
> > > other driver if you can't get the power domain.
> > >
> >
> > Yes, I understand those are for normal cases. But our case is a bit
> > different and we don't want
> > imx_clk_scu() API return PROBE_DEFER which is unnecessary for a hundred of
> clocks.
> > Even we want to defer probe, we prefer to defer in imx_clk_scu_init() rather
> than in imx_clk_scu().
> 
> What is wrong with PROBE_DEFER, that is what it is there for.

Yes, we can use PROBE_DEFER, just not want to defer in imx_clk_scu_init() when creating
sub clock devices. Instead, we want to defer at the beginning of clock driver probe which
can save tens of defer probes due to the same reasons that PD driver is not ready.

> 
> > Maybe the things can be simplified as a simple requirement:
> > How users can make Driver A (CLK) to be probed after Driver B (PD)
> > without explicit firmware function dependency description (e.g. phandle in
> DT)?
> >
> > As kernel core does not want to support it, then the left way may be
> > change scu-pd driver Inicall level or provide a private callback to query the
> readiness.
> 
> No, do not mess with that, as it totally breaks when things are built as a module.
> 

Can't this be addressed by proper module dependency? E.g clock module depends
on power domain module. Then clock driver can only be loaded after power domain.

> Rely on the deferred probing, that is what it was designed for, and it should not
> take very long at all, and it keeps you from having to dig into the driver core in
> ways that no one else has to.
> 
> Please just fix up your DT file (sorry I didn't know ordering wouldn't solve this),
> and you should be fine.
> 

Never mind and thank you for bringing me to the new features of fw_devlink which
I believe is good and can help us a lot on boot optimization and driver probes.
We may enable it in the future by default.

For the current problem, the difficulty is i don't know how to do it in standard way
as we can't add power domains property in clock-controller node.
The reason is described here that clock-controller (SCU clock protocol) itself does not
Depends on power domain.
https://www.spinics.net/lists/kernel/msg3742050.html

scu {
        compatible = "fsl,imx-scu";
        ...

        clk: clock-controller {
                compatible = "fsl,imx8qxp-clk";
                #clock-cells = <2>;
                clocks = <&xtal32k &xtal24m>;
                clock-names = "xtal_32KHz", "xtal_24Mhz";
        };

        pd: imx8qx-pd {
                compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
                #power-domain-cells = <1>;
        };
		...
}

Regards
Aisheng

> thanks,
> 
> greg k-h

Powered by blists - more mailing lists