* [PATCH 0/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-17 13:09 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer This series adds the possibility to add supplies to the rockchip power domains. This is a bit more complicated then it should be as we can get a regulator from a device node only when a device is attached to it, so this series starts by moving the power domains into a device. Overall this series makes the clock handling nicer because we no longer have to use of_clk_get(), but can use a plain devm_clk_bulk_get_all() to retrieve the domain clocks. All this is needed for the RK3568-EVB board where the power domain of the GPU is supplied by an external regulator. Sascha Hauer (4): soc: rockchip: power-domain: register device for each domain soc: rockchip: power-domain: Use devm_clk_bulk_get_all() soc: rockchip: power-domain: Add regulator support dt-bindings: power: rockchip: Add power-supply to domain nodes .../power/rockchip,power-controller.yaml | 6 + drivers/soc/rockchip/pm_domains.c | 322 ++++++++---------- 2 files changed, 157 insertions(+), 171 deletions(-) -- 2.30.2 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 0/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-17 13:09 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer This series adds the possibility to add supplies to the rockchip power domains. This is a bit more complicated then it should be as we can get a regulator from a device node only when a device is attached to it, so this series starts by moving the power domains into a device. Overall this series makes the clock handling nicer because we no longer have to use of_clk_get(), but can use a plain devm_clk_bulk_get_all() to retrieve the domain clocks. All this is needed for the RK3568-EVB board where the power domain of the GPU is supplied by an external regulator. Sascha Hauer (4): soc: rockchip: power-domain: register device for each domain soc: rockchip: power-domain: Use devm_clk_bulk_get_all() soc: rockchip: power-domain: Add regulator support dt-bindings: power: rockchip: Add power-supply to domain nodes .../power/rockchip,power-controller.yaml | 6 + drivers/soc/rockchip/pm_domains.c | 322 ++++++++---------- 2 files changed, 157 insertions(+), 171 deletions(-) -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 1/4] soc: rockchip: power-domain: register device for each domain 2021-12-17 13:09 ` Sascha Hauer @ 2021-12-17 13:09 ` Sascha Hauer -1 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer This patch prepares the rockchip power domain driver for regulator support. When a switchable regulator supplies a power domain the logical place to put the regulator is into the device node of that domain. In Linux we can get a regulator from a device node only when a device is attached to it. With this patch we register a device for each domain. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/soc/rockchip/pm_domains.c | 275 ++++++++++++++---------------- 1 file changed, 127 insertions(+), 148 deletions(-) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c index 0868b7d406fba..d2f71437c73a9 100644 --- a/drivers/soc/rockchip/pm_domains.c +++ b/drivers/soc/rockchip/pm_domains.c @@ -29,6 +29,8 @@ #include <dt-bindings/power/rk3399-power.h> #include <dt-bindings/power/rk3568-power.h> +struct rockchip_pmu; + struct rockchip_domain_info { const char *name; int pwr_mask; @@ -39,6 +41,10 @@ struct rockchip_domain_info { bool active_wakeup; int pwr_w_mask; int req_w_mask; + + struct rockchip_pmu *pmu; + struct generic_pm_domain *parent_domain; + int id; }; struct rockchip_pmu_info { @@ -81,6 +87,7 @@ struct rockchip_pmu { struct regmap *regmap; const struct rockchip_pmu_info *info; struct mutex mutex; /* mutex lock for pmu */ + atomic_t missing; struct genpd_onecell_data genpd_data; struct generic_pm_domain *domains[]; }; @@ -387,12 +394,11 @@ static void rockchip_pd_detach_dev(struct generic_pm_domain *genpd, } static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, - struct device_node *node) + struct device_node *node, + struct generic_pm_domain *parent_domain) { - const struct rockchip_domain_info *pd_info; - struct rockchip_pm_domain *pd; - struct device_node *qos_node; - int i, j; + struct platform_device *pd_pdev; + struct rockchip_domain_info *domain_info; u32 id; int error; @@ -410,28 +416,98 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, return -EINVAL; } - pd_info = &pmu->info->domain_info[id]; - if (!pd_info) { - dev_err(pmu->dev, "%pOFn: undefined domain id %d\n", - node, id); - return -EINVAL; + pd_pdev = platform_device_alloc("rk-power-domain", id); + if (!pd_pdev) { + dev_err(pmu->dev, "Failed to allocate platform device\n"); + return -ENOMEM; } - pd = devm_kzalloc(pmu->dev, sizeof(*pd), GFP_KERNEL); + error = platform_device_add_data(pd_pdev, + &pmu->info->domain_info[id], + sizeof(pmu->info->domain_info[id])); + if (error) + goto err_put; + + domain_info = pd_pdev->dev.platform_data; + domain_info->parent_domain = parent_domain; + domain_info->pmu = pmu; + domain_info->id = id; + + pd_pdev->dev.parent = pmu->dev; + pd_pdev->dev.of_node = node; + + atomic_inc(&pmu->missing); + + error = platform_device_add(pd_pdev); + if (error) + goto err_put; + + return 0; + +err_put: + platform_device_put(pd_pdev); + + return error; +} + +static void rockchip_pm_add_domains(struct rockchip_pmu *pmu, + struct device_node *parent, + struct generic_pm_domain *parent_domain) +{ + struct device_node *np; + int error; + + /* + * We may only register the genpd provider when we have registered all + * domains that are specified in the device tree. We count the missing + * domains in rockchip_pmu::missing. + * The rockchip pm_domains may have subdomains which means we can be + * called here recursively. Give it one extra count here to prevent + * the counter dropping to zero when we are called recursively. + */ + atomic_inc(&pmu->missing); + + for_each_child_of_node(parent, np) { + error = rockchip_pm_add_one_domain(pmu, np, parent_domain); + if (error) + dev_err(pmu->dev, "failed to handle node %pOFn: %d\n", + np, error); + } + + if (!atomic_dec_and_test(&pmu->missing)) + return; + + error = of_genpd_add_provider_onecell(pmu->dev->of_node, &pmu->genpd_data); + if (error) + dev_err(pmu->dev, "failed to add provider: %d\n", error); +} + +static int rockchip_domain_probe(struct platform_device *pdev) +{ + struct rockchip_domain_info *pd_info = pdev->dev.platform_data; + struct rockchip_pm_domain *pd; + struct device_node *node = pdev->dev.of_node; + struct device_node *qos_node; + struct rockchip_pmu *pmu = pd_info->pmu; + struct generic_pm_domain *parent_domain; + int i, j; + int error; + + pd = devm_kzalloc(&pdev->dev, sizeof(*pd), GFP_KERNEL); if (!pd) return -ENOMEM; pd->info = pd_info; - pd->pmu = pmu; + pd->pmu = pd_info->pmu; pd->num_clks = of_clk_get_parent_count(node); if (pd->num_clks > 0) { - pd->clks = devm_kcalloc(pmu->dev, pd->num_clks, + pd->clks = devm_kcalloc(&pdev->dev, pd->num_clks, sizeof(*pd->clks), GFP_KERNEL); if (!pd->clks) return -ENOMEM; } else { - dev_dbg(pmu->dev, "%pOFn: doesn't have clocks: %d\n", + dev_dbg(&pdev->dev, "%pOFn: doesn't have clocks: %d\n", node, pd->num_clks); pd->num_clks = 0; } @@ -440,7 +516,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, pd->clks[i].clk = of_clk_get(node, i); if (IS_ERR(pd->clks[i].clk)) { error = PTR_ERR(pd->clks[i].clk); - dev_err(pmu->dev, + dev_err(&pdev->dev, "%pOFn: failed to get clk at index %d: %d\n", node, i, error); return error; @@ -455,7 +531,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, NULL); if (pd->num_qos > 0) { - pd->qos_regmap = devm_kcalloc(pmu->dev, pd->num_qos, + pd->qos_regmap = devm_kcalloc(&pdev->dev, pd->num_qos, sizeof(*pd->qos_regmap), GFP_KERNEL); if (!pd->qos_regmap) { @@ -464,7 +540,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, } for (j = 0; j < MAX_QOS_REGS_NUM; j++) { - pd->qos_save_regs[j] = devm_kcalloc(pmu->dev, + pd->qos_save_regs[j] = devm_kcalloc(&pdev->dev, pd->num_qos, sizeof(u32), GFP_KERNEL); @@ -490,7 +566,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, } } - error = rockchip_pd_power(pd, true); + error = rockchip_pd_power_on(&pd->genpd); if (error) { dev_err(pmu->dev, "failed to power on domain '%pOFn': %d\n", @@ -507,13 +583,33 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, pd->genpd.attach_dev = rockchip_pd_attach_dev; pd->genpd.detach_dev = rockchip_pd_detach_dev; pd->genpd.flags = GENPD_FLAG_PM_CLK; - if (pd_info->active_wakeup) + if (pd->info->active_wakeup) pd->genpd.flags |= GENPD_FLAG_ACTIVE_WAKEUP; pm_genpd_init(&pd->genpd, NULL, false); - pmu->genpd_data.domains[id] = &pd->genpd; + parent_domain = pd_info->parent_domain; + if (parent_domain) { + error = pm_genpd_add_subdomain(parent_domain, &pd->genpd); + if (error) { + dev_err(pmu->dev, "%s failed to add subdomain %s: %d\n", + parent_domain->name, pd->genpd.name, error); + goto out_genpd_remove; + } else { + dev_dbg(pmu->dev, "%s add subdomain: %s\n", + parent_domain->name, pd->genpd.name); + } + } + + pmu->genpd_data.domains[pd->info->id] = &pd->genpd; + + atomic_dec(&pmu->missing); + + rockchip_pm_add_domains(pmu, node, &pd->genpd); + return 0; +out_genpd_remove: + pm_genpd_remove(&pd->genpd); err_unprepare_clocks: clk_bulk_unprepare(pd->num_clks, pd->clks); err_put_clocks: @@ -521,46 +617,19 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, return error; } -static void rockchip_pm_remove_one_domain(struct rockchip_pm_domain *pd) +static int rockchip_domain_remove(struct platform_device *pdev) { - int ret; - - /* - * We're in the error cleanup already, so we only complain, - * but won't emit another error on top of the original one. - */ - ret = pm_genpd_remove(&pd->genpd); - if (ret < 0) - dev_err(pd->pmu->dev, "failed to remove domain '%s' : %d - state may be inconsistent\n", - pd->genpd.name, ret); - - clk_bulk_unprepare(pd->num_clks, pd->clks); - clk_bulk_put(pd->num_clks, pd->clks); - - /* protect the zeroing of pm->num_clks */ - mutex_lock(&pd->pmu->mutex); - pd->num_clks = 0; - mutex_unlock(&pd->pmu->mutex); - - /* devm will free our memory */ + return 0; } -static void rockchip_pm_domain_cleanup(struct rockchip_pmu *pmu) -{ - struct generic_pm_domain *genpd; - struct rockchip_pm_domain *pd; - int i; - - for (i = 0; i < pmu->genpd_data.num_domains; i++) { - genpd = pmu->genpd_data.domains[i]; - if (genpd) { - pd = to_rockchip_pd(genpd); - rockchip_pm_remove_one_domain(pd); - } - } - - /* devm will free our memory */ -} +static struct platform_driver rockchip_domain_driver = { + .driver = { + .name = "rk-power-domain", + }, + .probe = rockchip_domain_probe, + .remove = rockchip_domain_remove, +}; +builtin_platform_driver(rockchip_domain_driver) static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu, u32 domain_reg_offset, @@ -572,71 +641,14 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu, regmap_write(pmu->regmap, domain_reg_offset + 4, count); } -static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu, - struct device_node *parent) -{ - struct device_node *np; - struct generic_pm_domain *child_domain, *parent_domain; - int error; - - for_each_child_of_node(parent, np) { - u32 idx; - - error = of_property_read_u32(parent, "reg", &idx); - if (error) { - dev_err(pmu->dev, - "%pOFn: failed to retrieve domain id (reg): %d\n", - parent, error); - goto err_out; - } - parent_domain = pmu->genpd_data.domains[idx]; - - error = rockchip_pm_add_one_domain(pmu, np); - if (error) { - dev_err(pmu->dev, "failed to handle node %pOFn: %d\n", - np, error); - goto err_out; - } - - error = of_property_read_u32(np, "reg", &idx); - if (error) { - dev_err(pmu->dev, - "%pOFn: failed to retrieve domain id (reg): %d\n", - np, error); - goto err_out; - } - child_domain = pmu->genpd_data.domains[idx]; - - error = pm_genpd_add_subdomain(parent_domain, child_domain); - if (error) { - dev_err(pmu->dev, "%s failed to add subdomain %s: %d\n", - parent_domain->name, child_domain->name, error); - goto err_out; - } else { - dev_dbg(pmu->dev, "%s add subdomain: %s\n", - parent_domain->name, child_domain->name); - } - - rockchip_pm_add_subdomain(pmu, np); - } - - return 0; - -err_out: - of_node_put(np); - return error; -} - static int rockchip_pm_domain_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct device_node *np = dev->of_node; - struct device_node *node; struct device *parent; struct rockchip_pmu *pmu; const struct of_device_id *match; const struct rockchip_pmu_info *pmu_info; - int error; if (!np) { dev_err(dev, "device tree node not found\n"); @@ -688,42 +700,9 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev) rockchip_configure_pd_cnt(pmu, pmu_info->gpu_pwrcnt_offset, pmu_info->gpu_power_transition_time); - error = -ENODEV; - - for_each_available_child_of_node(np, node) { - error = rockchip_pm_add_one_domain(pmu, node); - if (error) { - dev_err(dev, "failed to handle node %pOFn: %d\n", - node, error); - of_node_put(node); - goto err_out; - } - - error = rockchip_pm_add_subdomain(pmu, node); - if (error < 0) { - dev_err(dev, "failed to handle subdomain node %pOFn: %d\n", - node, error); - of_node_put(node); - goto err_out; - } - } - - if (error) { - dev_dbg(dev, "no power domains defined\n"); - goto err_out; - } - - error = of_genpd_add_provider_onecell(np, &pmu->genpd_data); - if (error) { - dev_err(dev, "failed to add provider: %d\n", error); - goto err_out; - } + rockchip_pm_add_domains(pmu, np, NULL); return 0; - -err_out: - rockchip_pm_domain_cleanup(pmu); - return error; } static const struct rockchip_domain_info px30_pm_domains[] = { -- 2.30.2 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH 1/4] soc: rockchip: power-domain: register device for each domain @ 2021-12-17 13:09 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer This patch prepares the rockchip power domain driver for regulator support. When a switchable regulator supplies a power domain the logical place to put the regulator is into the device node of that domain. In Linux we can get a regulator from a device node only when a device is attached to it. With this patch we register a device for each domain. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/soc/rockchip/pm_domains.c | 275 ++++++++++++++---------------- 1 file changed, 127 insertions(+), 148 deletions(-) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c index 0868b7d406fba..d2f71437c73a9 100644 --- a/drivers/soc/rockchip/pm_domains.c +++ b/drivers/soc/rockchip/pm_domains.c @@ -29,6 +29,8 @@ #include <dt-bindings/power/rk3399-power.h> #include <dt-bindings/power/rk3568-power.h> +struct rockchip_pmu; + struct rockchip_domain_info { const char *name; int pwr_mask; @@ -39,6 +41,10 @@ struct rockchip_domain_info { bool active_wakeup; int pwr_w_mask; int req_w_mask; + + struct rockchip_pmu *pmu; + struct generic_pm_domain *parent_domain; + int id; }; struct rockchip_pmu_info { @@ -81,6 +87,7 @@ struct rockchip_pmu { struct regmap *regmap; const struct rockchip_pmu_info *info; struct mutex mutex; /* mutex lock for pmu */ + atomic_t missing; struct genpd_onecell_data genpd_data; struct generic_pm_domain *domains[]; }; @@ -387,12 +394,11 @@ static void rockchip_pd_detach_dev(struct generic_pm_domain *genpd, } static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, - struct device_node *node) + struct device_node *node, + struct generic_pm_domain *parent_domain) { - const struct rockchip_domain_info *pd_info; - struct rockchip_pm_domain *pd; - struct device_node *qos_node; - int i, j; + struct platform_device *pd_pdev; + struct rockchip_domain_info *domain_info; u32 id; int error; @@ -410,28 +416,98 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, return -EINVAL; } - pd_info = &pmu->info->domain_info[id]; - if (!pd_info) { - dev_err(pmu->dev, "%pOFn: undefined domain id %d\n", - node, id); - return -EINVAL; + pd_pdev = platform_device_alloc("rk-power-domain", id); + if (!pd_pdev) { + dev_err(pmu->dev, "Failed to allocate platform device\n"); + return -ENOMEM; } - pd = devm_kzalloc(pmu->dev, sizeof(*pd), GFP_KERNEL); + error = platform_device_add_data(pd_pdev, + &pmu->info->domain_info[id], + sizeof(pmu->info->domain_info[id])); + if (error) + goto err_put; + + domain_info = pd_pdev->dev.platform_data; + domain_info->parent_domain = parent_domain; + domain_info->pmu = pmu; + domain_info->id = id; + + pd_pdev->dev.parent = pmu->dev; + pd_pdev->dev.of_node = node; + + atomic_inc(&pmu->missing); + + error = platform_device_add(pd_pdev); + if (error) + goto err_put; + + return 0; + +err_put: + platform_device_put(pd_pdev); + + return error; +} + +static void rockchip_pm_add_domains(struct rockchip_pmu *pmu, + struct device_node *parent, + struct generic_pm_domain *parent_domain) +{ + struct device_node *np; + int error; + + /* + * We may only register the genpd provider when we have registered all + * domains that are specified in the device tree. We count the missing + * domains in rockchip_pmu::missing. + * The rockchip pm_domains may have subdomains which means we can be + * called here recursively. Give it one extra count here to prevent + * the counter dropping to zero when we are called recursively. + */ + atomic_inc(&pmu->missing); + + for_each_child_of_node(parent, np) { + error = rockchip_pm_add_one_domain(pmu, np, parent_domain); + if (error) + dev_err(pmu->dev, "failed to handle node %pOFn: %d\n", + np, error); + } + + if (!atomic_dec_and_test(&pmu->missing)) + return; + + error = of_genpd_add_provider_onecell(pmu->dev->of_node, &pmu->genpd_data); + if (error) + dev_err(pmu->dev, "failed to add provider: %d\n", error); +} + +static int rockchip_domain_probe(struct platform_device *pdev) +{ + struct rockchip_domain_info *pd_info = pdev->dev.platform_data; + struct rockchip_pm_domain *pd; + struct device_node *node = pdev->dev.of_node; + struct device_node *qos_node; + struct rockchip_pmu *pmu = pd_info->pmu; + struct generic_pm_domain *parent_domain; + int i, j; + int error; + + pd = devm_kzalloc(&pdev->dev, sizeof(*pd), GFP_KERNEL); if (!pd) return -ENOMEM; pd->info = pd_info; - pd->pmu = pmu; + pd->pmu = pd_info->pmu; pd->num_clks = of_clk_get_parent_count(node); if (pd->num_clks > 0) { - pd->clks = devm_kcalloc(pmu->dev, pd->num_clks, + pd->clks = devm_kcalloc(&pdev->dev, pd->num_clks, sizeof(*pd->clks), GFP_KERNEL); if (!pd->clks) return -ENOMEM; } else { - dev_dbg(pmu->dev, "%pOFn: doesn't have clocks: %d\n", + dev_dbg(&pdev->dev, "%pOFn: doesn't have clocks: %d\n", node, pd->num_clks); pd->num_clks = 0; } @@ -440,7 +516,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, pd->clks[i].clk = of_clk_get(node, i); if (IS_ERR(pd->clks[i].clk)) { error = PTR_ERR(pd->clks[i].clk); - dev_err(pmu->dev, + dev_err(&pdev->dev, "%pOFn: failed to get clk at index %d: %d\n", node, i, error); return error; @@ -455,7 +531,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, NULL); if (pd->num_qos > 0) { - pd->qos_regmap = devm_kcalloc(pmu->dev, pd->num_qos, + pd->qos_regmap = devm_kcalloc(&pdev->dev, pd->num_qos, sizeof(*pd->qos_regmap), GFP_KERNEL); if (!pd->qos_regmap) { @@ -464,7 +540,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, } for (j = 0; j < MAX_QOS_REGS_NUM; j++) { - pd->qos_save_regs[j] = devm_kcalloc(pmu->dev, + pd->qos_save_regs[j] = devm_kcalloc(&pdev->dev, pd->num_qos, sizeof(u32), GFP_KERNEL); @@ -490,7 +566,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, } } - error = rockchip_pd_power(pd, true); + error = rockchip_pd_power_on(&pd->genpd); if (error) { dev_err(pmu->dev, "failed to power on domain '%pOFn': %d\n", @@ -507,13 +583,33 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, pd->genpd.attach_dev = rockchip_pd_attach_dev; pd->genpd.detach_dev = rockchip_pd_detach_dev; pd->genpd.flags = GENPD_FLAG_PM_CLK; - if (pd_info->active_wakeup) + if (pd->info->active_wakeup) pd->genpd.flags |= GENPD_FLAG_ACTIVE_WAKEUP; pm_genpd_init(&pd->genpd, NULL, false); - pmu->genpd_data.domains[id] = &pd->genpd; + parent_domain = pd_info->parent_domain; + if (parent_domain) { + error = pm_genpd_add_subdomain(parent_domain, &pd->genpd); + if (error) { + dev_err(pmu->dev, "%s failed to add subdomain %s: %d\n", + parent_domain->name, pd->genpd.name, error); + goto out_genpd_remove; + } else { + dev_dbg(pmu->dev, "%s add subdomain: %s\n", + parent_domain->name, pd->genpd.name); + } + } + + pmu->genpd_data.domains[pd->info->id] = &pd->genpd; + + atomic_dec(&pmu->missing); + + rockchip_pm_add_domains(pmu, node, &pd->genpd); + return 0; +out_genpd_remove: + pm_genpd_remove(&pd->genpd); err_unprepare_clocks: clk_bulk_unprepare(pd->num_clks, pd->clks); err_put_clocks: @@ -521,46 +617,19 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu, return error; } -static void rockchip_pm_remove_one_domain(struct rockchip_pm_domain *pd) +static int rockchip_domain_remove(struct platform_device *pdev) { - int ret; - - /* - * We're in the error cleanup already, so we only complain, - * but won't emit another error on top of the original one. - */ - ret = pm_genpd_remove(&pd->genpd); - if (ret < 0) - dev_err(pd->pmu->dev, "failed to remove domain '%s' : %d - state may be inconsistent\n", - pd->genpd.name, ret); - - clk_bulk_unprepare(pd->num_clks, pd->clks); - clk_bulk_put(pd->num_clks, pd->clks); - - /* protect the zeroing of pm->num_clks */ - mutex_lock(&pd->pmu->mutex); - pd->num_clks = 0; - mutex_unlock(&pd->pmu->mutex); - - /* devm will free our memory */ + return 0; } -static void rockchip_pm_domain_cleanup(struct rockchip_pmu *pmu) -{ - struct generic_pm_domain *genpd; - struct rockchip_pm_domain *pd; - int i; - - for (i = 0; i < pmu->genpd_data.num_domains; i++) { - genpd = pmu->genpd_data.domains[i]; - if (genpd) { - pd = to_rockchip_pd(genpd); - rockchip_pm_remove_one_domain(pd); - } - } - - /* devm will free our memory */ -} +static struct platform_driver rockchip_domain_driver = { + .driver = { + .name = "rk-power-domain", + }, + .probe = rockchip_domain_probe, + .remove = rockchip_domain_remove, +}; +builtin_platform_driver(rockchip_domain_driver) static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu, u32 domain_reg_offset, @@ -572,71 +641,14 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu, regmap_write(pmu->regmap, domain_reg_offset + 4, count); } -static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu, - struct device_node *parent) -{ - struct device_node *np; - struct generic_pm_domain *child_domain, *parent_domain; - int error; - - for_each_child_of_node(parent, np) { - u32 idx; - - error = of_property_read_u32(parent, "reg", &idx); - if (error) { - dev_err(pmu->dev, - "%pOFn: failed to retrieve domain id (reg): %d\n", - parent, error); - goto err_out; - } - parent_domain = pmu->genpd_data.domains[idx]; - - error = rockchip_pm_add_one_domain(pmu, np); - if (error) { - dev_err(pmu->dev, "failed to handle node %pOFn: %d\n", - np, error); - goto err_out; - } - - error = of_property_read_u32(np, "reg", &idx); - if (error) { - dev_err(pmu->dev, - "%pOFn: failed to retrieve domain id (reg): %d\n", - np, error); - goto err_out; - } - child_domain = pmu->genpd_data.domains[idx]; - - error = pm_genpd_add_subdomain(parent_domain, child_domain); - if (error) { - dev_err(pmu->dev, "%s failed to add subdomain %s: %d\n", - parent_domain->name, child_domain->name, error); - goto err_out; - } else { - dev_dbg(pmu->dev, "%s add subdomain: %s\n", - parent_domain->name, child_domain->name); - } - - rockchip_pm_add_subdomain(pmu, np); - } - - return 0; - -err_out: - of_node_put(np); - return error; -} - static int rockchip_pm_domain_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct device_node *np = dev->of_node; - struct device_node *node; struct device *parent; struct rockchip_pmu *pmu; const struct of_device_id *match; const struct rockchip_pmu_info *pmu_info; - int error; if (!np) { dev_err(dev, "device tree node not found\n"); @@ -688,42 +700,9 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev) rockchip_configure_pd_cnt(pmu, pmu_info->gpu_pwrcnt_offset, pmu_info->gpu_power_transition_time); - error = -ENODEV; - - for_each_available_child_of_node(np, node) { - error = rockchip_pm_add_one_domain(pmu, node); - if (error) { - dev_err(dev, "failed to handle node %pOFn: %d\n", - node, error); - of_node_put(node); - goto err_out; - } - - error = rockchip_pm_add_subdomain(pmu, node); - if (error < 0) { - dev_err(dev, "failed to handle subdomain node %pOFn: %d\n", - node, error); - of_node_put(node); - goto err_out; - } - } - - if (error) { - dev_dbg(dev, "no power domains defined\n"); - goto err_out; - } - - error = of_genpd_add_provider_onecell(np, &pmu->genpd_data); - if (error) { - dev_err(dev, "failed to add provider: %d\n", error); - goto err_out; - } + rockchip_pm_add_domains(pmu, np, NULL); return 0; - -err_out: - rockchip_pm_domain_cleanup(pmu); - return error; } static const struct rockchip_domain_info px30_pm_domains[] = { -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH 2/4] soc: rockchip: power-domain: Use devm_clk_bulk_get_all() 2021-12-17 13:09 ` Sascha Hauer @ 2021-12-17 13:09 ` Sascha Hauer -1 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer Now that each power domain has its own device we no longer have to use of_clk_get(), but can instead simplify retrieving the clocks by using devm_clk_bulk_get_all(). Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/soc/rockchip/pm_domains.c | 31 +++++-------------------------- 1 file changed, 5 insertions(+), 26 deletions(-) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c index d2f71437c73a9..dcfd3db649f58 100644 --- a/drivers/soc/rockchip/pm_domains.c +++ b/drivers/soc/rockchip/pm_domains.c @@ -490,7 +490,7 @@ static int rockchip_domain_probe(struct platform_device *pdev) struct device_node *qos_node; struct rockchip_pmu *pmu = pd_info->pmu; struct generic_pm_domain *parent_domain; - int i, j; + int j; int error; pd = devm_kzalloc(&pdev->dev, sizeof(*pd), GFP_KERNEL); @@ -500,32 +500,13 @@ static int rockchip_domain_probe(struct platform_device *pdev) pd->info = pd_info; pd->pmu = pd_info->pmu; - pd->num_clks = of_clk_get_parent_count(node); - if (pd->num_clks > 0) { - pd->clks = devm_kcalloc(&pdev->dev, pd->num_clks, - sizeof(*pd->clks), GFP_KERNEL); - if (!pd->clks) - return -ENOMEM; - } else { - dev_dbg(&pdev->dev, "%pOFn: doesn't have clocks: %d\n", - node, pd->num_clks); - pd->num_clks = 0; - } - - for (i = 0; i < pd->num_clks; i++) { - pd->clks[i].clk = of_clk_get(node, i); - if (IS_ERR(pd->clks[i].clk)) { - error = PTR_ERR(pd->clks[i].clk); - dev_err(&pdev->dev, - "%pOFn: failed to get clk at index %d: %d\n", - node, i, error); - return error; - } - } + pd->num_clks = devm_clk_bulk_get_all(&pdev->dev, &pd->clks); + if (pd->num_clks < 0) + return pd->num_clks; error = clk_bulk_prepare(pd->num_clks, pd->clks); if (error) - goto err_put_clocks; + return error; pd->num_qos = of_count_phandle_with_args(node, "pm_qos", NULL); @@ -612,8 +593,6 @@ static int rockchip_domain_probe(struct platform_device *pdev) pm_genpd_remove(&pd->genpd); err_unprepare_clocks: clk_bulk_unprepare(pd->num_clks, pd->clks); -err_put_clocks: - clk_bulk_put(pd->num_clks, pd->clks); return error; } -- 2.30.2 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH 2/4] soc: rockchip: power-domain: Use devm_clk_bulk_get_all() @ 2021-12-17 13:09 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer Now that each power domain has its own device we no longer have to use of_clk_get(), but can instead simplify retrieving the clocks by using devm_clk_bulk_get_all(). Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/soc/rockchip/pm_domains.c | 31 +++++-------------------------- 1 file changed, 5 insertions(+), 26 deletions(-) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c index d2f71437c73a9..dcfd3db649f58 100644 --- a/drivers/soc/rockchip/pm_domains.c +++ b/drivers/soc/rockchip/pm_domains.c @@ -490,7 +490,7 @@ static int rockchip_domain_probe(struct platform_device *pdev) struct device_node *qos_node; struct rockchip_pmu *pmu = pd_info->pmu; struct generic_pm_domain *parent_domain; - int i, j; + int j; int error; pd = devm_kzalloc(&pdev->dev, sizeof(*pd), GFP_KERNEL); @@ -500,32 +500,13 @@ static int rockchip_domain_probe(struct platform_device *pdev) pd->info = pd_info; pd->pmu = pd_info->pmu; - pd->num_clks = of_clk_get_parent_count(node); - if (pd->num_clks > 0) { - pd->clks = devm_kcalloc(&pdev->dev, pd->num_clks, - sizeof(*pd->clks), GFP_KERNEL); - if (!pd->clks) - return -ENOMEM; - } else { - dev_dbg(&pdev->dev, "%pOFn: doesn't have clocks: %d\n", - node, pd->num_clks); - pd->num_clks = 0; - } - - for (i = 0; i < pd->num_clks; i++) { - pd->clks[i].clk = of_clk_get(node, i); - if (IS_ERR(pd->clks[i].clk)) { - error = PTR_ERR(pd->clks[i].clk); - dev_err(&pdev->dev, - "%pOFn: failed to get clk at index %d: %d\n", - node, i, error); - return error; - } - } + pd->num_clks = devm_clk_bulk_get_all(&pdev->dev, &pd->clks); + if (pd->num_clks < 0) + return pd->num_clks; error = clk_bulk_prepare(pd->num_clks, pd->clks); if (error) - goto err_put_clocks; + return error; pd->num_qos = of_count_phandle_with_args(node, "pm_qos", NULL); @@ -612,8 +593,6 @@ static int rockchip_domain_probe(struct platform_device *pdev) pm_genpd_remove(&pd->genpd); err_unprepare_clocks: clk_bulk_unprepare(pd->num_clks, pd->clks); -err_put_clocks: - clk_bulk_put(pd->num_clks, pd->clks); return error; } -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-17 13:09 ` Sascha Hauer @ 2021-12-17 13:09 ` Sascha Hauer -1 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer This patch allows to let a domain be supplied by a regulator which is needed for the GPU on the rk3568-EVB board. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/soc/rockchip/pm_domains.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c index dcfd3db649f58..e7db888cc226c 100644 --- a/drivers/soc/rockchip/pm_domains.c +++ b/drivers/soc/rockchip/pm_domains.c @@ -15,6 +15,7 @@ #include <linux/of_platform.h> #include <linux/clk.h> #include <linux/regmap.h> +#include <linux/regulator/consumer.h> #include <linux/mfd/syscon.h> #include <dt-bindings/power/px30-power.h> #include <dt-bindings/power/rk3036-power.h> @@ -80,6 +81,7 @@ struct rockchip_pm_domain { u32 *qos_save_regs[MAX_QOS_REGS_NUM]; int num_clks; struct clk_bulk_data *clks; + struct regulator *regulator; }; struct rockchip_pmu { @@ -344,6 +346,14 @@ static int rockchip_pd_power(struct rockchip_pm_domain *pd, bool power_on) static int rockchip_pd_power_on(struct generic_pm_domain *domain) { struct rockchip_pm_domain *pd = to_rockchip_pd(domain); + struct rockchip_pmu *pmu = pd->pmu; + int ret; + + ret = regulator_enable(pd->regulator); + if (ret) { + dev_err(pmu->dev, "failed to enable regulator: %d\n", ret); + return ret; + } return rockchip_pd_power(pd, true); } @@ -351,8 +361,15 @@ static int rockchip_pd_power_on(struct generic_pm_domain *domain) static int rockchip_pd_power_off(struct generic_pm_domain *domain) { struct rockchip_pm_domain *pd = to_rockchip_pd(domain); + int ret; - return rockchip_pd_power(pd, false); + ret = rockchip_pd_power(pd, false); + if (ret) + return ret; + + regulator_disable(pd->regulator); + + return 0; } static int rockchip_pd_attach_dev(struct generic_pm_domain *genpd, @@ -500,6 +517,11 @@ static int rockchip_domain_probe(struct platform_device *pdev) pd->info = pd_info; pd->pmu = pd_info->pmu; + pd->regulator = devm_regulator_get(&pdev->dev, "power"); + + if (IS_ERR(pd->regulator)) + return PTR_ERR(pd->regulator); + pd->num_clks = devm_clk_bulk_get_all(&pdev->dev, &pd->clks); if (pd->num_clks < 0) return pd->num_clks; -- 2.30.2 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-17 13:09 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer This patch allows to let a domain be supplied by a regulator which is needed for the GPU on the rk3568-EVB board. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- drivers/soc/rockchip/pm_domains.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c index dcfd3db649f58..e7db888cc226c 100644 --- a/drivers/soc/rockchip/pm_domains.c +++ b/drivers/soc/rockchip/pm_domains.c @@ -15,6 +15,7 @@ #include <linux/of_platform.h> #include <linux/clk.h> #include <linux/regmap.h> +#include <linux/regulator/consumer.h> #include <linux/mfd/syscon.h> #include <dt-bindings/power/px30-power.h> #include <dt-bindings/power/rk3036-power.h> @@ -80,6 +81,7 @@ struct rockchip_pm_domain { u32 *qos_save_regs[MAX_QOS_REGS_NUM]; int num_clks; struct clk_bulk_data *clks; + struct regulator *regulator; }; struct rockchip_pmu { @@ -344,6 +346,14 @@ static int rockchip_pd_power(struct rockchip_pm_domain *pd, bool power_on) static int rockchip_pd_power_on(struct generic_pm_domain *domain) { struct rockchip_pm_domain *pd = to_rockchip_pd(domain); + struct rockchip_pmu *pmu = pd->pmu; + int ret; + + ret = regulator_enable(pd->regulator); + if (ret) { + dev_err(pmu->dev, "failed to enable regulator: %d\n", ret); + return ret; + } return rockchip_pd_power(pd, true); } @@ -351,8 +361,15 @@ static int rockchip_pd_power_on(struct generic_pm_domain *domain) static int rockchip_pd_power_off(struct generic_pm_domain *domain) { struct rockchip_pm_domain *pd = to_rockchip_pd(domain); + int ret; - return rockchip_pd_power(pd, false); + ret = rockchip_pd_power(pd, false); + if (ret) + return ret; + + regulator_disable(pd->regulator); + + return 0; } static int rockchip_pd_attach_dev(struct generic_pm_domain *genpd, @@ -500,6 +517,11 @@ static int rockchip_domain_probe(struct platform_device *pdev) pd->info = pd_info; pd->pmu = pd_info->pmu; + pd->regulator = devm_regulator_get(&pdev->dev, "power"); + + if (IS_ERR(pd->regulator)) + return PTR_ERR(pd->regulator); + pd->num_clks = devm_clk_bulk_get_all(&pdev->dev, &pd->clks); if (pd->num_clks < 0) return pd->num_clks; -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-17 13:09 ` Sascha Hauer @ 2021-12-20 9:44 ` Sascha Hauer -1 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-20 9:44 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Robin Murphy, Mark Brown On Fri, Dec 17, 2021 at 02:09:18PM +0100, Sascha Hauer wrote: > This patch allows to let a domain be supplied by a regulator which > is needed for the GPU on the rk3568-EVB board. > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > drivers/soc/rockchip/pm_domains.c | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > + > + regulator_disable(pd->regulator); > + > + return 0; > } > > static int rockchip_pd_attach_dev(struct generic_pm_domain *genpd, > @@ -500,6 +517,11 @@ static int rockchip_domain_probe(struct platform_device *pdev) > pd->info = pd_info; > pd->pmu = pd_info->pmu; > > + pd->regulator = devm_regulator_get(&pdev->dev, "power"); I was told that I should use this function instead of devm_regulator_get_optional() when the regulator is not optional and also I can drop the if (pd->regulator) dance when enabling the regulator because I get a dummy regulator here when using devm_regulator_get(). Well, all true and on one specific board the regulator is indeed not optional. However, on all other power domains that don't need a regulator and all other boards and all other SoCs this driver is used we now get: [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator [ 0.186036] rk-power-domain rk-power-domain.9: supply power not found, using dummy regulator [ 0.186459] rk-power-domain rk-power-domain.10: supply power not found, using dummy regulator [ 0.187039] rk-power-domain rk-power-domain.11: supply power not found, using dummy regulator [ 0.187333] rk-power-domain rk-power-domain.13: supply power not found, using dummy regulator [ 0.187644] rk-power-domain rk-power-domain.14: supply power not found, using dummy regulator [ 0.188042] rk-power-domain rk-power-domain.15: supply power not found, using dummy regulator I wonder if devm_regulator_get() is really the right function here. Or should the message be dropped? Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-20 9:44 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-20 9:44 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Robin Murphy, Mark Brown On Fri, Dec 17, 2021 at 02:09:18PM +0100, Sascha Hauer wrote: > This patch allows to let a domain be supplied by a regulator which > is needed for the GPU on the rk3568-EVB board. > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > drivers/soc/rockchip/pm_domains.c | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > + > + regulator_disable(pd->regulator); > + > + return 0; > } > > static int rockchip_pd_attach_dev(struct generic_pm_domain *genpd, > @@ -500,6 +517,11 @@ static int rockchip_domain_probe(struct platform_device *pdev) > pd->info = pd_info; > pd->pmu = pd_info->pmu; > > + pd->regulator = devm_regulator_get(&pdev->dev, "power"); I was told that I should use this function instead of devm_regulator_get_optional() when the regulator is not optional and also I can drop the if (pd->regulator) dance when enabling the regulator because I get a dummy regulator here when using devm_regulator_get(). Well, all true and on one specific board the regulator is indeed not optional. However, on all other power domains that don't need a regulator and all other boards and all other SoCs this driver is used we now get: [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator [ 0.186036] rk-power-domain rk-power-domain.9: supply power not found, using dummy regulator [ 0.186459] rk-power-domain rk-power-domain.10: supply power not found, using dummy regulator [ 0.187039] rk-power-domain rk-power-domain.11: supply power not found, using dummy regulator [ 0.187333] rk-power-domain rk-power-domain.13: supply power not found, using dummy regulator [ 0.187644] rk-power-domain rk-power-domain.14: supply power not found, using dummy regulator [ 0.188042] rk-power-domain rk-power-domain.15: supply power not found, using dummy regulator I wonder if devm_regulator_get() is really the right function here. Or should the message be dropped? Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-20 9:44 ` Sascha Hauer @ 2021-12-20 10:46 ` Robin Murphy -1 siblings, 0 replies; 35+ messages in thread From: Robin Murphy @ 2021-12-20 10:46 UTC (permalink / raw) To: Sascha Hauer, linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Mark Brown On 2021-12-20 09:44, Sascha Hauer wrote: > On Fri, Dec 17, 2021 at 02:09:18PM +0100, Sascha Hauer wrote: >> This patch allows to let a domain be supplied by a regulator which >> is needed for the GPU on the rk3568-EVB board. >> >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> >> --- >> drivers/soc/rockchip/pm_domains.c | 24 +++++++++++++++++++++++- >> 1 file changed, 23 insertions(+), 1 deletion(-) >> >> + >> + regulator_disable(pd->regulator); >> + >> + return 0; >> } >> >> static int rockchip_pd_attach_dev(struct generic_pm_domain *genpd, >> @@ -500,6 +517,11 @@ static int rockchip_domain_probe(struct platform_device *pdev) >> pd->info = pd_info; >> pd->pmu = pd_info->pmu; >> >> + pd->regulator = devm_regulator_get(&pdev->dev, "power"); > > I was told that I should use this function instead of > devm_regulator_get_optional() when the regulator is not optional and > also I can drop the if (pd->regulator) dance when enabling the regulator > because I get a dummy regulator here when using devm_regulator_get(). > > Well, all true and on one specific board the regulator is indeed not > optional. However, on all other power domains that don't need a > regulator and all other boards and all other SoCs this driver is used we > now get: > > [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator > [ 0.186036] rk-power-domain rk-power-domain.9: supply power not found, using dummy regulator > [ 0.186459] rk-power-domain rk-power-domain.10: supply power not found, using dummy regulator > [ 0.187039] rk-power-domain rk-power-domain.11: supply power not found, using dummy regulator > [ 0.187333] rk-power-domain rk-power-domain.13: supply power not found, using dummy regulator > [ 0.187644] rk-power-domain rk-power-domain.14: supply power not found, using dummy regulator > [ 0.188042] rk-power-domain rk-power-domain.15: supply power not found, using dummy regulator > > I wonder if devm_regulator_get() is really the right function here. Or > should the message be dropped? Since the power domains are hierarchical and none of them really represent the physical owner of a supply, I'm not sure there's really a correct answer to the regulator question either way in this context. FWIW I reckon it would make sense to model things properly and teach the driver about the voltage domains that actually own the input supplies (maybe with a binding more like I/O domains where we just have explicitly-named supply properties for each one on the power controller?) - it's a little more work up-front, but seems like it should be relatively straightforward to fit into the genpd hierarchy, and be more robust in the long term. Robin. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-20 10:46 ` Robin Murphy 0 siblings, 0 replies; 35+ messages in thread From: Robin Murphy @ 2021-12-20 10:46 UTC (permalink / raw) To: Sascha Hauer, linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Mark Brown On 2021-12-20 09:44, Sascha Hauer wrote: > On Fri, Dec 17, 2021 at 02:09:18PM +0100, Sascha Hauer wrote: >> This patch allows to let a domain be supplied by a regulator which >> is needed for the GPU on the rk3568-EVB board. >> >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> >> --- >> drivers/soc/rockchip/pm_domains.c | 24 +++++++++++++++++++++++- >> 1 file changed, 23 insertions(+), 1 deletion(-) >> >> + >> + regulator_disable(pd->regulator); >> + >> + return 0; >> } >> >> static int rockchip_pd_attach_dev(struct generic_pm_domain *genpd, >> @@ -500,6 +517,11 @@ static int rockchip_domain_probe(struct platform_device *pdev) >> pd->info = pd_info; >> pd->pmu = pd_info->pmu; >> >> + pd->regulator = devm_regulator_get(&pdev->dev, "power"); > > I was told that I should use this function instead of > devm_regulator_get_optional() when the regulator is not optional and > also I can drop the if (pd->regulator) dance when enabling the regulator > because I get a dummy regulator here when using devm_regulator_get(). > > Well, all true and on one specific board the regulator is indeed not > optional. However, on all other power domains that don't need a > regulator and all other boards and all other SoCs this driver is used we > now get: > > [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator > [ 0.186036] rk-power-domain rk-power-domain.9: supply power not found, using dummy regulator > [ 0.186459] rk-power-domain rk-power-domain.10: supply power not found, using dummy regulator > [ 0.187039] rk-power-domain rk-power-domain.11: supply power not found, using dummy regulator > [ 0.187333] rk-power-domain rk-power-domain.13: supply power not found, using dummy regulator > [ 0.187644] rk-power-domain rk-power-domain.14: supply power not found, using dummy regulator > [ 0.188042] rk-power-domain rk-power-domain.15: supply power not found, using dummy regulator > > I wonder if devm_regulator_get() is really the right function here. Or > should the message be dropped? Since the power domains are hierarchical and none of them really represent the physical owner of a supply, I'm not sure there's really a correct answer to the regulator question either way in this context. FWIW I reckon it would make sense to model things properly and teach the driver about the voltage domains that actually own the input supplies (maybe with a binding more like I/O domains where we just have explicitly-named supply properties for each one on the power controller?) - it's a little more work up-front, but seems like it should be relatively straightforward to fit into the genpd hierarchy, and be more robust in the long term. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-20 10:46 ` Robin Murphy @ 2021-12-20 12:56 ` Mark Brown -1 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-20 12:56 UTC (permalink / raw) To: Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel [-- Attachment #1.1: Type: text/plain, Size: 833 bytes --] On Mon, Dec 20, 2021 at 10:46:34AM +0000, Robin Murphy wrote: > to the regulator question either way in this context. FWIW I reckon it would > make sense to model things properly and teach the driver about the voltage > domains that actually own the input supplies (maybe with a binding more like > I/O domains where we just have explicitly-named supply properties for each > one on the power controller?) - it's a little more work up-front, but seems > like it should be relatively straightforward to fit into the genpd > hierarchy, and be more robust in the long term. This is what I would expect too, I don't see how it is possible to implement sensible and robust usage of the regulator API (or other provider APIs like the clock API for that matter) if the consumer is unaware of what resources it is supposed to be managing. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-20 12:56 ` Mark Brown 0 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-20 12:56 UTC (permalink / raw) To: Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel [-- Attachment #1.1: Type: text/plain, Size: 833 bytes --] On Mon, Dec 20, 2021 at 10:46:34AM +0000, Robin Murphy wrote: > to the regulator question either way in this context. FWIW I reckon it would > make sense to model things properly and teach the driver about the voltage > domains that actually own the input supplies (maybe with a binding more like > I/O domains where we just have explicitly-named supply properties for each > one on the power controller?) - it's a little more work up-front, but seems > like it should be relatively straightforward to fit into the genpd > hierarchy, and be more robust in the long term. This is what I would expect too, I don't see how it is possible to implement sensible and robust usage of the regulator API (or other provider APIs like the clock API for that matter) if the consumer is unaware of what resources it is supposed to be managing. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-20 9:44 ` Sascha Hauer @ 2021-12-20 12:53 ` Mark Brown -1 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-20 12:53 UTC (permalink / raw) To: Sascha Hauer Cc: linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Robin Murphy [-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --] On Mon, Dec 20, 2021 at 10:44:35AM +0100, Sascha Hauer wrote: > Well, all true and on one specific board the regulator is indeed not > optional. However, on all other power domains that don't need a > regulator and all other boards and all other SoCs this driver is used we > now get: This seems unlikely to be board specific, if the chip requires power the chip requires power. If there are power domains that don't take external supplies then they shouldn't be requesting any regulators and should be fixed. > [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator It seems vanishingly unlikely that the SoC takes a single supply called "power" shared by everything in the SoC but that is what the code appears to be requesting - the power domains should be requesting the supplies they actually use, and as ever the supplies should be named such that someone looking at the schematic can hook them up. The general recommendation is to use the names used in the datasheet. > I wonder if devm_regulator_get() is really the right function here. Or > should the message be dropped? No, the issue is that the client driver is badly written and needs to be fixed. In general it's probably better to have error handling than not. If you're getting lots of warnings about problems it's probably due to there being problems. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-20 12:53 ` Mark Brown 0 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-20 12:53 UTC (permalink / raw) To: Sascha Hauer Cc: linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Robin Murphy [-- Attachment #1.1: Type: text/plain, Size: 1369 bytes --] On Mon, Dec 20, 2021 at 10:44:35AM +0100, Sascha Hauer wrote: > Well, all true and on one specific board the regulator is indeed not > optional. However, on all other power domains that don't need a > regulator and all other boards and all other SoCs this driver is used we > now get: This seems unlikely to be board specific, if the chip requires power the chip requires power. If there are power domains that don't take external supplies then they shouldn't be requesting any regulators and should be fixed. > [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator It seems vanishingly unlikely that the SoC takes a single supply called "power" shared by everything in the SoC but that is what the code appears to be requesting - the power domains should be requesting the supplies they actually use, and as ever the supplies should be named such that someone looking at the schematic can hook them up. The general recommendation is to use the names used in the datasheet. > I wonder if devm_regulator_get() is really the right function here. Or > should the message be dropped? No, the issue is that the client driver is badly written and needs to be fixed. In general it's probably better to have error handling than not. If you're getting lots of warnings about problems it's probably due to there being problems. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-20 12:53 ` Mark Brown @ 2021-12-22 10:40 ` Sascha Hauer -1 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-22 10:40 UTC (permalink / raw) To: Mark Brown Cc: linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Robin Murphy On Mon, Dec 20, 2021 at 12:53:58PM +0000, Mark Brown wrote: > On Mon, Dec 20, 2021 at 10:44:35AM +0100, Sascha Hauer wrote: > > > Well, all true and on one specific board the regulator is indeed not > > optional. However, on all other power domains that don't need a > > regulator and all other boards and all other SoCs this driver is used we > > now get: > > This seems unlikely to be board specific, if the chip requires power the > chip requires power. If there are power domains that don't take > external supplies then they shouldn't be requesting any regulators and > should be fixed. > > > [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator > > It seems vanishingly unlikely that the SoC takes a single supply called > "power" shared by everything in the SoC but that is what the code > appears to be requesting - the power domains should be requesting the > supplies they actually use, and as ever the supplies should be named > such that someone looking at the schematic can hook them up. The > general recommendation is to use the names used in the datasheet. Ok. I'll change the patch in a way that only for the GPU power domain on rk3568 a supply is requested. That's the one power domain I know that a regulator is needed. I'm sure there are more, if not on rk3568 then probably on other SoCs the driver handles. Once we notice that other domains need a supply we'll have to add the supply name to driver data for that domain. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-22 10:40 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-22 10:40 UTC (permalink / raw) To: Mark Brown Cc: linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Robin Murphy On Mon, Dec 20, 2021 at 12:53:58PM +0000, Mark Brown wrote: > On Mon, Dec 20, 2021 at 10:44:35AM +0100, Sascha Hauer wrote: > > > Well, all true and on one specific board the regulator is indeed not > > optional. However, on all other power domains that don't need a > > regulator and all other boards and all other SoCs this driver is used we > > now get: > > This seems unlikely to be board specific, if the chip requires power the > chip requires power. If there are power domains that don't take > external supplies then they shouldn't be requesting any regulators and > should be fixed. > > > [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator > > It seems vanishingly unlikely that the SoC takes a single supply called > "power" shared by everything in the SoC but that is what the code > appears to be requesting - the power domains should be requesting the > supplies they actually use, and as ever the supplies should be named > such that someone looking at the schematic can hook them up. The > general recommendation is to use the names used in the datasheet. Ok. I'll change the patch in a way that only for the GPU power domain on rk3568 a supply is requested. That's the one power domain I know that a regulator is needed. I'm sure there are more, if not on rk3568 then probably on other SoCs the driver handles. Once we notice that other domains need a supply we'll have to add the supply name to driver data for that domain. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 10:40 ` Sascha Hauer @ 2021-12-22 12:54 ` Robin Murphy -1 siblings, 0 replies; 35+ messages in thread From: Robin Murphy @ 2021-12-22 12:54 UTC (permalink / raw) To: Sascha Hauer, Mark Brown Cc: linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel On 2021-12-22 10:40, Sascha Hauer wrote: > On Mon, Dec 20, 2021 at 12:53:58PM +0000, Mark Brown wrote: >> On Mon, Dec 20, 2021 at 10:44:35AM +0100, Sascha Hauer wrote: >> >>> Well, all true and on one specific board the regulator is indeed not >>> optional. However, on all other power domains that don't need a >>> regulator and all other boards and all other SoCs this driver is used we >>> now get: >> >> This seems unlikely to be board specific, if the chip requires power the >> chip requires power. If there are power domains that don't take >> external supplies then they shouldn't be requesting any regulators and >> should be fixed. >> >>> [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator >> >> It seems vanishingly unlikely that the SoC takes a single supply called >> "power" shared by everything in the SoC but that is what the code >> appears to be requesting - the power domains should be requesting the >> supplies they actually use, and as ever the supplies should be named >> such that someone looking at the schematic can hook them up. The >> general recommendation is to use the names used in the datasheet. > > Ok. I'll change the patch in a way that only for the GPU power domain on > rk3568 a supply is requested. That's the one power domain I know that a > regulator is needed. I'm sure there are more, if not on rk3568 then > probably on other SoCs the driver handles. Once we notice that other > domains need a supply we'll have to add the supply name to driver data > for that domain. Certainly RK3399 (and I guess RK3288 too) suffers from the same priority-inversion issue of being unaware that VD_GPU needs power before PD_GPU can be successfully turned on to probe the GPU to claim and enable the regulator (via "mali-supply" for DVFS purposes) that needed to be on in the first place. Currently all the boards are bodging around this with "regulator-always-on" (e.g. commit 06b2818678d9). Thanks, Robin. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-22 12:54 ` Robin Murphy 0 siblings, 0 replies; 35+ messages in thread From: Robin Murphy @ 2021-12-22 12:54 UTC (permalink / raw) To: Sascha Hauer, Mark Brown Cc: linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel On 2021-12-22 10:40, Sascha Hauer wrote: > On Mon, Dec 20, 2021 at 12:53:58PM +0000, Mark Brown wrote: >> On Mon, Dec 20, 2021 at 10:44:35AM +0100, Sascha Hauer wrote: >> >>> Well, all true and on one specific board the regulator is indeed not >>> optional. However, on all other power domains that don't need a >>> regulator and all other boards and all other SoCs this driver is used we >>> now get: >> >> This seems unlikely to be board specific, if the chip requires power the >> chip requires power. If there are power domains that don't take >> external supplies then they shouldn't be requesting any regulators and >> should be fixed. >> >>> [ 0.185588] rk-power-domain rk-power-domain.8: supply power not found, using dummy regulator >> >> It seems vanishingly unlikely that the SoC takes a single supply called >> "power" shared by everything in the SoC but that is what the code >> appears to be requesting - the power domains should be requesting the >> supplies they actually use, and as ever the supplies should be named >> such that someone looking at the schematic can hook them up. The >> general recommendation is to use the names used in the datasheet. > > Ok. I'll change the patch in a way that only for the GPU power domain on > rk3568 a supply is requested. That's the one power domain I know that a > regulator is needed. I'm sure there are more, if not on rk3568 then > probably on other SoCs the driver handles. Once we notice that other > domains need a supply we'll have to add the supply name to driver data > for that domain. Certainly RK3399 (and I guess RK3288 too) suffers from the same priority-inversion issue of being unaware that VD_GPU needs power before PD_GPU can be successfully turned on to probe the GPU to claim and enable the regulator (via "mali-supply" for DVFS purposes) that needed to be on in the first place. Currently all the boards are bodging around this with "regulator-always-on" (e.g. commit 06b2818678d9). Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 12:54 ` Robin Murphy @ 2021-12-22 13:00 ` Mark Brown -1 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-22 13:00 UTC (permalink / raw) To: Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel [-- Attachment #1.1: Type: text/plain, Size: 807 bytes --] On Wed, Dec 22, 2021 at 12:54:06PM +0000, Robin Murphy wrote: > Certainly RK3399 (and I guess RK3288 too) suffers from the same > priority-inversion issue of being unaware that VD_GPU needs power before > PD_GPU can be successfully turned on to probe the GPU to claim and enable > the regulator (via "mali-supply" for DVFS purposes) that needed to be on in > the first place. Currently all the boards are bodging around this with > "regulator-always-on" (e.g. commit 06b2818678d9). Does the SoC actually support the supply being completely off in operation? A lot of devices want everything powered even if idle during full operation since keeping voltage differentials smaller makes it a lot easier to design to avoid leakage current type issues at the points where the different power domains connect. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-22 13:00 ` Mark Brown 0 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-22 13:00 UTC (permalink / raw) To: Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel [-- Attachment #1.1: Type: text/plain, Size: 807 bytes --] On Wed, Dec 22, 2021 at 12:54:06PM +0000, Robin Murphy wrote: > Certainly RK3399 (and I guess RK3288 too) suffers from the same > priority-inversion issue of being unaware that VD_GPU needs power before > PD_GPU can be successfully turned on to probe the GPU to claim and enable > the regulator (via "mali-supply" for DVFS purposes) that needed to be on in > the first place. Currently all the boards are bodging around this with > "regulator-always-on" (e.g. commit 06b2818678d9). Does the SoC actually support the supply being completely off in operation? A lot of devices want everything powered even if idle during full operation since keeping voltage differentials smaller makes it a lot easier to design to avoid leakage current type issues at the points where the different power domains connect. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 13:00 ` Mark Brown @ 2021-12-22 13:19 ` Robin Murphy -1 siblings, 0 replies; 35+ messages in thread From: Robin Murphy @ 2021-12-22 13:19 UTC (permalink / raw) To: Mark Brown Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel On 2021-12-22 13:00, Mark Brown wrote: > On Wed, Dec 22, 2021 at 12:54:06PM +0000, Robin Murphy wrote: > >> Certainly RK3399 (and I guess RK3288 too) suffers from the same >> priority-inversion issue of being unaware that VD_GPU needs power before >> PD_GPU can be successfully turned on to probe the GPU to claim and enable >> the regulator (via "mali-supply" for DVFS purposes) that needed to be on in >> the first place. Currently all the boards are bodging around this with >> "regulator-always-on" (e.g. commit 06b2818678d9). > > Does the SoC actually support the supply being completely off in > operation? A lot of devices want everything powered even if idle during > full operation since keeping voltage differentials smaller makes it a > lot easier to design to avoid leakage current type issues at the points > where the different power domains connect. I don't know TBH - the available documentation doesn't seem to go into quite that much detail. Robin. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-22 13:19 ` Robin Murphy 0 siblings, 0 replies; 35+ messages in thread From: Robin Murphy @ 2021-12-22 13:19 UTC (permalink / raw) To: Mark Brown Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel On 2021-12-22 13:00, Mark Brown wrote: > On Wed, Dec 22, 2021 at 12:54:06PM +0000, Robin Murphy wrote: > >> Certainly RK3399 (and I guess RK3288 too) suffers from the same >> priority-inversion issue of being unaware that VD_GPU needs power before >> PD_GPU can be successfully turned on to probe the GPU to claim and enable >> the regulator (via "mali-supply" for DVFS purposes) that needed to be on in >> the first place. Currently all the boards are bodging around this with >> "regulator-always-on" (e.g. commit 06b2818678d9). > > Does the SoC actually support the supply being completely off in > operation? A lot of devices want everything powered even if idle during > full operation since keeping voltage differentials smaller makes it a > lot easier to design to avoid leakage current type issues at the points > where the different power domains connect. I don't know TBH - the available documentation doesn't seem to go into quite that much detail. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 13:19 ` Robin Murphy @ 2021-12-22 13:25 ` Mark Brown -1 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-22 13:25 UTC (permalink / raw) To: Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel [-- Attachment #1.1: Type: text/plain, Size: 804 bytes --] On Wed, Dec 22, 2021 at 01:19:23PM +0000, Robin Murphy wrote: > On 2021-12-22 13:00, Mark Brown wrote: > > Does the SoC actually support the supply being completely off in > > operation? A lot of devices want everything powered even if idle during > > full operation since keeping voltage differentials smaller makes it a > > lot easier to design to avoid leakage current type issues at the points > > where the different power domains connect. > I don't know TBH - the available documentation doesn't seem to go into quite > that much detail. In that case I would tend to assume that unless otherwise stated it's safer to keep the supply enabled when everything else is enabled. It's the default thing and so is more likely to be what was designed for and less likely to result in nasty surprises. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-22 13:25 ` Mark Brown 0 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-22 13:25 UTC (permalink / raw) To: Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel [-- Attachment #1.1: Type: text/plain, Size: 804 bytes --] On Wed, Dec 22, 2021 at 01:19:23PM +0000, Robin Murphy wrote: > On 2021-12-22 13:00, Mark Brown wrote: > > Does the SoC actually support the supply being completely off in > > operation? A lot of devices want everything powered even if idle during > > full operation since keeping voltage differentials smaller makes it a > > lot easier to design to avoid leakage current type issues at the points > > where the different power domains connect. > I don't know TBH - the available documentation doesn't seem to go into quite > that much detail. In that case I would tend to assume that unless otherwise stated it's safer to keep the supply enabled when everything else is enabled. It's the default thing and so is more likely to be what was designed for and less likely to result in nasty surprises. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 13:25 ` Mark Brown @ 2021-12-22 13:29 ` Michael Riesch -1 siblings, 0 replies; 35+ messages in thread From: Michael Riesch @ 2021-12-22 13:29 UTC (permalink / raw) To: Mark Brown, Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, kernel Hi Robin and Mark, On 12/22/21 2:25 PM, Mark Brown wrote: > On Wed, Dec 22, 2021 at 01:19:23PM +0000, Robin Murphy wrote: >> On 2021-12-22 13:00, Mark Brown wrote: > >>> Does the SoC actually support the supply being completely off in >>> operation? A lot of devices want everything powered even if idle during >>> full operation since keeping voltage differentials smaller makes it a >>> lot easier to design to avoid leakage current type issues at the points >>> where the different power domains connect. > >> I don't know TBH - the available documentation doesn't seem to go into quite >> that much detail. > > In that case I would tend to assume that unless otherwise stated it's > safer to keep the supply enabled when everything else is enabled. It's > the default thing and so is more likely to be what was designed for and > less likely to result in nasty surprises. Based on my experience with the RK3568 EVB1 the vdd_gpu supply turns after startup if it is unused and the SoC works fine. Let's take the energy efficient route here :-) Best regards, Michael _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-22 13:29 ` Michael Riesch 0 siblings, 0 replies; 35+ messages in thread From: Michael Riesch @ 2021-12-22 13:29 UTC (permalink / raw) To: Mark Brown, Robin Murphy Cc: Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, kernel Hi Robin and Mark, On 12/22/21 2:25 PM, Mark Brown wrote: > On Wed, Dec 22, 2021 at 01:19:23PM +0000, Robin Murphy wrote: >> On 2021-12-22 13:00, Mark Brown wrote: > >>> Does the SoC actually support the supply being completely off in >>> operation? A lot of devices want everything powered even if idle during >>> full operation since keeping voltage differentials smaller makes it a >>> lot easier to design to avoid leakage current type issues at the points >>> where the different power domains connect. > >> I don't know TBH - the available documentation doesn't seem to go into quite >> that much detail. > > In that case I would tend to assume that unless otherwise stated it's > safer to keep the supply enabled when everything else is enabled. It's > the default thing and so is more likely to be what was designed for and > less likely to result in nasty surprises. Based on my experience with the RK3568 EVB1 the vdd_gpu supply turns after startup if it is unused and the SoC works fine. Let's take the energy efficient route here :-) Best regards, Michael _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 13:29 ` Michael Riesch (?) @ 2021-12-22 13:37 ` Michael Riesch -1 siblings, 0 replies; 35+ messages in thread From: Michael Riesch @ 2021-12-22 13:37 UTC (permalink / raw) To: linux-rockchip On 12/22/21 2:29 PM, Michael Riesch wrote: > Hi Robin and Mark, > > On 12/22/21 2:25 PM, Mark Brown wrote: >> On Wed, Dec 22, 2021 at 01:19:23PM +0000, Robin Murphy wrote: >>> On 2021-12-22 13:00, Mark Brown wrote: >> >>>> Does the SoC actually support the supply being completely off in >>>> operation? A lot of devices want everything powered even if idle during >>>> full operation since keeping voltage differentials smaller makes it a >>>> lot easier to design to avoid leakage current type issues at the points >>>> where the different power domains connect. >> >>> I don't know TBH - the available documentation doesn't seem to go into quite >>> that much detail. >> >> In that case I would tend to assume that unless otherwise stated it's >> safer to keep the supply enabled when everything else is enabled. It's >> the default thing and so is more likely to be what was designed for and >> less likely to result in nasty surprises. > > Based on my experience with the RK3568 EVB1 the vdd_gpu supply turns [edit] turns off, of course Best regards, Michael > after startup if it is unused and the SoC works fine. Let's take the > energy efficient route here :-) > > Best regards, > Michael > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 13:29 ` Michael Riesch @ 2021-12-22 13:40 ` Mark Brown -1 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-22 13:40 UTC (permalink / raw) To: Michael Riesch Cc: Robin Murphy, Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, kernel [-- Attachment #1.1: Type: text/plain, Size: 821 bytes --] On Wed, Dec 22, 2021 at 02:29:23PM +0100, Michael Riesch wrote: > On 12/22/21 2:25 PM, Mark Brown wrote: > > In that case I would tend to assume that unless otherwise stated it's > > safer to keep the supply enabled when everything else is enabled. It's > > the default thing and so is more likely to be what was designed for and > > less likely to result in nasty surprises. > Based on my experience with the RK3568 EVB1 the vdd_gpu supply turns > after startup if it is unused and the SoC works fine. Let's take the > energy efficient route here :-) One of the issues is that it may not actually be energy efficient if it ends up leaking current through the SoC from the other supplies (and long term that leakage probably won't do any good for hardware). A very lightly loaded regulator can be the better option. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 170 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2021-12-22 13:40 ` Mark Brown 0 siblings, 0 replies; 35+ messages in thread From: Mark Brown @ 2021-12-22 13:40 UTC (permalink / raw) To: Michael Riesch Cc: Robin Murphy, Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, kernel [-- Attachment #1.1: Type: text/plain, Size: 821 bytes --] On Wed, Dec 22, 2021 at 02:29:23PM +0100, Michael Riesch wrote: > On 12/22/21 2:25 PM, Mark Brown wrote: > > In that case I would tend to assume that unless otherwise stated it's > > safer to keep the supply enabled when everything else is enabled. It's > > the default thing and so is more likely to be what was designed for and > > less likely to result in nasty surprises. > Based on my experience with the RK3568 EVB1 the vdd_gpu supply turns > after startup if it is unused and the SoC works fine. Let's take the > energy efficient route here :-) One of the issues is that it may not actually be energy efficient if it ends up leaking current through the SoC from the other supplies (and long term that leakage probably won't do any good for hardware). A very lightly loaded regulator can be the better option. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support 2021-12-22 13:40 ` Mark Brown @ 2022-02-23 8:51 ` Michael Riesch -1 siblings, 0 replies; 35+ messages in thread From: Michael Riesch @ 2022-02-23 8:51 UTC (permalink / raw) To: Mark Brown Cc: Robin Murphy, Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, kernel Hi Mark, Sorry for the long pause! On 12/22/21 14:40, Mark Brown wrote: > On Wed, Dec 22, 2021 at 02:29:23PM +0100, Michael Riesch wrote: >> On 12/22/21 2:25 PM, Mark Brown wrote: > >>> In that case I would tend to assume that unless otherwise stated it's >>> safer to keep the supply enabled when everything else is enabled. It's >>> the default thing and so is more likely to be what was designed for and >>> less likely to result in nasty surprises. > >> Based on my experience with the RK3568 EVB1 the vdd_gpu supply turns >> after startup if it is unused and the SoC works fine. Let's take the >> energy efficient route here :-) > > One of the issues is that it may not actually be energy efficient if it > ends up leaking current through the SoC from the other supplies (and > long term that leakage probably won't do any good for hardware). A very > lightly loaded regulator can be the better option. OK, I see. So in summary we don't know the behavior of the SoC and should go for the safe route (set the GPU regulator to always on)? I'll submit a patch for the RK3568 EVB1 -- the other boards enable this regulator always as well. Best regards, Michael _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH 3/4] soc: rockchip: power-domain: Add regulator support @ 2022-02-23 8:51 ` Michael Riesch 0 siblings, 0 replies; 35+ messages in thread From: Michael Riesch @ 2022-02-23 8:51 UTC (permalink / raw) To: Mark Brown Cc: Robin Murphy, Sascha Hauer, linux-rockchip, linux-arm-kernel, Heiko Stuebner, kernel Hi Mark, Sorry for the long pause! On 12/22/21 14:40, Mark Brown wrote: > On Wed, Dec 22, 2021 at 02:29:23PM +0100, Michael Riesch wrote: >> On 12/22/21 2:25 PM, Mark Brown wrote: > >>> In that case I would tend to assume that unless otherwise stated it's >>> safer to keep the supply enabled when everything else is enabled. It's >>> the default thing and so is more likely to be what was designed for and >>> less likely to result in nasty surprises. > >> Based on my experience with the RK3568 EVB1 the vdd_gpu supply turns >> after startup if it is unused and the SoC works fine. Let's take the >> energy efficient route here :-) > > One of the issues is that it may not actually be energy efficient if it > ends up leaking current through the SoC from the other supplies (and > long term that leakage probably won't do any good for hardware). A very > lightly loaded regulator can be the better option. OK, I see. So in summary we don't know the behavior of the SoC and should go for the safe route (set the GPU regulator to always on)? I'll submit a patch for the RK3568 EVB1 -- the other boards enable this regulator always as well. Best regards, Michael _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH 4/4] dt-bindings: power: rockchip: Add power-supply to domain nodes 2021-12-17 13:09 ` Sascha Hauer @ 2021-12-17 13:09 ` Sascha Hauer -1 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- .../bindings/power/rockchip,power-controller.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml index 9b9d710874663..f7e4b95fb6feb 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -71,6 +71,8 @@ patternProperties: "#size-cells": const: 0 + power-supply: true + patternProperties: "^power-domain@[0-9a-f]+$": @@ -85,6 +87,8 @@ patternProperties: "#size-cells": const: 0 + power-supply: true + patternProperties: "^power-domain@[0-9a-f]+$": @@ -96,6 +100,8 @@ patternProperties: "#power-domain-cells": const: 0 + power-supply: true + $defs: pd-node: type: object -- 2.30.2 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH 4/4] dt-bindings: power: rockchip: Add power-supply to domain nodes @ 2021-12-17 13:09 ` Sascha Hauer 0 siblings, 0 replies; 35+ messages in thread From: Sascha Hauer @ 2021-12-17 13:09 UTC (permalink / raw) To: linux-rockchip Cc: linux-arm-kernel, Heiko Stuebner, Michael Riesch, kernel, Sascha Hauer Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> --- .../bindings/power/rockchip,power-controller.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml index 9b9d710874663..f7e4b95fb6feb 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -71,6 +71,8 @@ patternProperties: "#size-cells": const: 0 + power-supply: true + patternProperties: "^power-domain@[0-9a-f]+$": @@ -85,6 +87,8 @@ patternProperties: "#size-cells": const: 0 + power-supply: true + patternProperties: "^power-domain@[0-9a-f]+$": @@ -96,6 +100,8 @@ patternProperties: "#power-domain-cells": const: 0 + power-supply: true + $defs: pd-node: type: object -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 35+ messages in thread
end of thread, other threads:[~2022-02-23 8:53 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-17 13:09 [PATCH 0/4] soc: rockchip: power-domain: Add regulator support Sascha Hauer 2021-12-17 13:09 ` Sascha Hauer 2021-12-17 13:09 ` [PATCH 1/4] soc: rockchip: power-domain: register device for each domain Sascha Hauer 2021-12-17 13:09 ` Sascha Hauer 2021-12-17 13:09 ` [PATCH 2/4] soc: rockchip: power-domain: Use devm_clk_bulk_get_all() Sascha Hauer 2021-12-17 13:09 ` Sascha Hauer 2021-12-17 13:09 ` [PATCH 3/4] soc: rockchip: power-domain: Add regulator support Sascha Hauer 2021-12-17 13:09 ` Sascha Hauer 2021-12-20 9:44 ` Sascha Hauer 2021-12-20 9:44 ` Sascha Hauer 2021-12-20 10:46 ` Robin Murphy 2021-12-20 10:46 ` Robin Murphy 2021-12-20 12:56 ` Mark Brown 2021-12-20 12:56 ` Mark Brown 2021-12-20 12:53 ` Mark Brown 2021-12-20 12:53 ` Mark Brown 2021-12-22 10:40 ` Sascha Hauer 2021-12-22 10:40 ` Sascha Hauer 2021-12-22 12:54 ` Robin Murphy 2021-12-22 12:54 ` Robin Murphy 2021-12-22 13:00 ` Mark Brown 2021-12-22 13:00 ` Mark Brown 2021-12-22 13:19 ` Robin Murphy 2021-12-22 13:19 ` Robin Murphy 2021-12-22 13:25 ` Mark Brown 2021-12-22 13:25 ` Mark Brown 2021-12-22 13:29 ` Michael Riesch 2021-12-22 13:29 ` Michael Riesch 2021-12-22 13:37 ` Michael Riesch 2021-12-22 13:40 ` Mark Brown 2021-12-22 13:40 ` Mark Brown 2022-02-23 8:51 ` Michael Riesch 2022-02-23 8:51 ` Michael Riesch 2021-12-17 13:09 ` [PATCH 4/4] dt-bindings: power: rockchip: Add power-supply to domain nodes Sascha Hauer 2021-12-17 13:09 ` Sascha Hauer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.