Message ID | 56120582.1050707@codeaurora.org (mailing list archive) |
---|---|
State | Changes Requested |
Delegated to: | Andy Gross |
Headers | show |
Hi Rajendra,
[auto build test ERROR on next-20151002 -- if it's inappropriate base, please ignore]
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "pm_genpd_add_subdomain" undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Rajendra,
[auto build test ERROR on next-20151002 -- if it's inappropriate base, please ignore]
config: x86_64-randconfig-r0-10051645 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "pm_genpd_add_subdomain" [drivers/clk/qcom/clk-qcom.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On 10/05, Rajendra Nayak wrote: > []... > > >>> It would also be nicer if this parent/child relationship can > >>> somehow be represented in data (struct gdsc) that gets passed to > >>> the gdsc driver which then sets it up, instead of individual > >>> clock drivers doing it. > >> > >> Agreed. I'd rather that we do nothing besides register domains > >> and then let the core code handle hooking up domains and > >> subdomains. > > > > A little closer inspection makes me want to skip this. PM domains > > can have multiple "master" domains, and pm_genpd_init() is the > > only API that would be able to do the linking. That API is mostly > > about initializing things to default values, so it doesn't seem > > like a good fit. I'll send a v2 with the remove part and the > > exports. > > What I was suggesting is that the qcom gdsc driver handle this > instead of the qcom clock drivers. > Something like.. Ah ok. This patch will still need the gdscs to be in a certain order though so that we don't add a subdomain on an uninitialized domain. So I guess some list of pointer pairs to call the function on could be done in the qcom_cc_desc structure if we need to do this more than a couple times.
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c index da9fad8..00edb2d 100644 --- a/drivers/clk/qcom/gdsc.c +++ b/drivers/clk/qcom/gdsc.c @@ -226,6 +226,8 @@ int gdsc_register(struct device *dev, struct gdsc **scs, size_t num, if (ret) return ret; data->domains[i] = &scs[i]->pd; + if (scs[i]->parent) + pm_genpd_add_subdomain(scs[i]->parent, &scs[i]->pd); } return of_genpd_add_provider_onecell(dev->of_node, data); diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h index 5ded268..bc5791f 100644 --- a/drivers/clk/qcom/gdsc.h +++ b/drivers/clk/qcom/gdsc.h @@ -49,6 +49,7 @@ struct gdsc { struct reset_controller_dev *rcdev; unsigned int *resets; unsigned int reset_count; + struct generic_pm_domain *parent; }; #ifdef CONFIG_QCOM_GDSC diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c index fe8320d..51ad8de 100644 --- a/drivers/clk/qcom/mmcc-msm8974.c +++ b/drivers/clk/qcom/mmcc-msm8974.c @@ -2400,6 +2400,7 @@ static struct gdsc oxilicx_gdsc = { .pd = { .name = "oxilicx", }, + .parent = &oxili_gdsc.pd, .pwrsts = PWRSTS_OFF_ON, };