Changes in v3:
- Aligned on terminology, now using "PM domain" in comments and commit
- messages/headers.
- Improved English and grammar in comments and commit messages/headers.
- Adopted proposal from Geert, to have compile-time-check wrapper
functions for the API that adds xlate_simple and xlate_onecell
providers.
- Renamed "domain_num" to "num_domains", in genpd_onecell_data struct.
- Handle non-contiguous arrays for onecell PM domain providers.
- Rebased the Exynos patch to follow the new genpd API changes.
Changes in v2:
- Fix the ACPI patch, it didn't even compile for CONFIG_ACPI.
- Updated some comments in code and in commit messages.
- Fixed the dev_pm_domain_attach API to handle EPROBE_DEFER properly.
- Rebased the ARM Exynos patch.
- Added some Tested-by tags.
This patchset has a bit of a history and some parts of it has been posted
earlier.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262725.html
In the first revision I intentially didn't increase version number of the
patches, since I think it would have cause more confusion than clarity.
A summary of changes in V1 and since the last patchset, from the link above:
- Instead of letting driver core handling the device to power domain
binding/unbinding, follow the behavior of how the ACPI power domain
is handled.
This is a summary of what these patches are intended to do:
1)
Add generic power domain OF-based support which also includes APIs to handle
attach/detach of generic power domains to devices.
2)
Adding a common API to attach/detach power domains and include support for the
ACPI and the generic power domain in there.
3)
From subsystem level code, at probe/remove, convert from invoking the ACPI
specific power domain attach/detach functions to the new common attach/detach
APIs.
4)
Add support for the AMBA bus to attach/detach power domains, using the new
common APIs.
5)
Convert Exynos to use the new generic power domain OF support.
Obviously, there are dependencies througout this patchset, which means if they
get accepted the all need to go together. It might also be convenient to share
them through an immutable branch.
Tomasz Figa (2):
PM / Domains: Add generic OF-based PM domain look-up
ARM: exynos: Move to generic PM domain DT bindings
Ulf Hansson (7):
ACPI / PM: Let acpi_dev_pm_detach() return an error code
PM / Domains: Add APIs to attach/detach a PM domain for a device
drivercore / platform: Convert to dev_pm_domain_attach|detach()
i2c: core: Convert to dev_pm_domain_attach|detach()
mmc: sdio: Convert to dev_pm_domain_attach|detach()
spi: core: Convert to dev_pm_domain_attach|detach()
amba: Add support for attach/detach of PM domains
.../bindings/arm/exynos/power_domain.txt | 13 +-
.../devicetree/bindings/power/power_domain.txt | 49 ++++
arch/arm/mach-exynos/pm_domains.c | 78 +-----
drivers/acpi/device_pm.c | 8 +-
drivers/amba/bus.c | 10 +-
drivers/base/platform.c | 15 +-
drivers/base/power/common.c | 56 ++++
drivers/base/power/domain.c | 291 +++++++++++++++++++++
drivers/i2c/i2c-core.c | 13 +-
drivers/mmc/core/sdio_bus.c | 4 +-
drivers/spi/spi.c | 12 +-
include/linux/acpi.h | 7 +-
include/linux/pm.h | 14 +
include/linux/pm_domain.h | 57 ++++
kernel/power/Kconfig | 4 +
15 files changed, 524 insertions(+), 107 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
--
1.9.1
From: Pavel Machek <hidden> Date: 2014-08-23 22:45:15
On Thu 2014-09-04 15:52:28, Ulf Hansson wrote:
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/acpi/device_pm.c | 8 +++++++-
include/linux/acpi.h | 7 +++++--
2 files changed, 12 insertions(+), 3 deletions(-)
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
Signed-off-by: Tomasz Figa <redacted>
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Added attach|detach functions, fixed review comments]
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
---
.../devicetree/bindings/power/power_domain.txt | 49 ++++
drivers/base/power/domain.c | 291 +++++++++++++++++++++
include/linux/pm_domain.h | 57 ++++
kernel/power/Kconfig | 4 +
4 files changed, 401 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,49 @@+* Generic PM domains++System on chip designs are often divided into multiple PM domains that can be+used for power gating of selected IP blocks for power saving by reduced leakage+current.++This device tree binding can be used to bind PM domain consumer devices with+their PM domains provided by PM domain providers. A PM domain provider can be+represented by any node in the device tree and can provide one or more PM+domains. A consumer node can refer to the provider by a phandle and a set of+phandle arguments (so called PM domain specifiers) of length specified by the+#power-domain-cells property in the PM domain provider node.++==PM domain providers==++Required properties:+ - #power-domain-cells : Number of cells in a PM domain specifier;+ Typically 0 for nodes representing a single PM domain and 1 for nodes+ providing multiple PM domains (e.g. power controllers), but can be any value+ as specified by device tree binding documentation of particular provider.++Example:++ power: power-controller at 12340000 {+ compatible = "foo,power-controller";+ reg = <0x12340000 0x1000>;+ #power-domain-cells = <1>;+ };++The node above defines a power controller that is a PM domain provider and+expects one cell as its phandle argument.++==PM domain consumers==++Required properties:+ - power-domains : A phandle and PM domain specifier as defined by bindings of+ the power controller specified by phandle.++Example:++ leaky-device at 12350000 {+ compatible = "foo,i-leak-current";+ reg = <0x12350000 0x1000>;+ power-domains = <&power 0>;+ };++The node above defines a typical PM domain consumer device, which is located+inside a PM domain with index 0 of a power controller represented by a node+with the label "power".
@@ -2189,3 +2190,293 @@ void pm_genpd_init(struct generic_pm_domain *genpd,list_add(&genpd->gpd_list_node,&gpd_list);mutex_unlock(&gpd_list_lock);}++#ifdef CONFIG_PM_GENERIC_DOMAINS_OF+/*+*DeviceTreebasedPMdomainproviders.+*+*ThecodebelowimplementsgenericdevicetreebasedPMdomainprovidersthat+*binddevicetreenodeswithgenericPMdomainsregisteredinthesystem.+*+*AnydriverthatregistersgenericPMdomainsandneedstosupportbindingof+*devicestothesedomainsissupposedtoregisteraPMdomainprovider,which+*mapsaPMdomainspecifierretrievedfromthedevicetreetoaPMdomain.+*+*Twosimplemappingfunctionshavebeenprovidedforconvenience:+*-__of_genpd_xlate_simple()for1:1devicetreenodetoPMdomainmapping.+*-__of_genpd_xlate_onecell()formappingofmultiplePMdomainspernodeby+*index.+*/++/**+*structof_genpd_provider-PMdomainproviderregistrationstructure+*@link:EntryingloballistofPMdomainproviders+*@node:PointertodevicetreenodeofPMdomainprovider+*@xlate:Provider-specificxlatecallbackmappingasetofspecifiercells+*intoaPMdomain.+*@data:contextpointertobepassedinto@xlatecallback+*/+structof_genpd_provider{+structlist_headlink;+structdevice_node*node;+genpd_xlate_txlate;+void*data;+};++/* List of registered PM domain providers. */+staticLIST_HEAD(of_genpd_providers);+/* Mutex to protect the list above. */+staticDEFINE_MUTEX(of_genpd_mutex);++/**+*__of_genpd_xlate_simple()-Xlatefunctionfordirectnode-domainmapping+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgeneric_pm_domain+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelPMdomainsthat+*havetheirowndevicetreenodes.Theprivatedataofxlatefunctionneeds+*tobeavalidpointertostructgeneric_pm_domain.+*/+structgeneric_pm_domain*__of_genpd_xlate_simple(+structof_phandle_args*genpdspec,+void*data)+{+if(genpdspec->args_count!=0)+returnERR_PTR(-EINVAL);+returndata;+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_simple);++/**+*__of_genpd_xlate_onecell()-Xlatefunctionusingasingleindex.+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgenpd_onecell_data+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelsimplePMdomain+*controllersthathaveonedevicetreenodeandprovidemultiplePMdomains.+*AsinglecellisusedasanindexintoanarrayofPMdomainsspecifiedin+*thegenpd_onecell_datastructwhenregisteringtheprovider.+*/+structgeneric_pm_domain*__of_genpd_xlate_onecell(+structof_phandle_args*genpdspec,+void*data)+{+structgenpd_onecell_data*genpd_data=data;+unsignedintidx=genpdspec->args[0];++if(genpdspec->args_count!=1)+returnERR_PTR(-EINVAL);++if(idx>=genpd_data->num_domains){+pr_err("%s: invalid domain index %u\n",__func__,idx);+returnERR_PTR(-EINVAL);+}++if(!genpd_data->domains[idx])+returnERR_PTR(-ENOENT);++returngenpd_data->domains[idx];+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_onecell);++/**+*__of_genpd_add_provider()-RegisteraPMdomainproviderforanode+*@np:DevicenodepointerassociatedwiththePMdomainprovider.+*@xlate:CallbackfordecodingPMdomainfromphandlearguments.+*@data:Contextpointerfor@xlatecallback.+*/+int__of_genpd_add_provider(structdevice_node*np,genpd_xlate_txlate,+void*data)+{+structof_genpd_provider*cp;++cp=kzalloc(sizeof(*cp),GFP_KERNEL);+if(!cp)+return-ENOMEM;++cp->node=of_node_get(np);+cp->data=data;+cp->xlate=xlate;++mutex_lock(&of_genpd_mutex);+list_add(&cp->link,&of_genpd_providers);+mutex_unlock(&of_genpd_mutex);+pr_debug("Added domain provider from %s\n",np->full_name);++return0;+}+EXPORT_SYMBOL_GPL(__of_genpd_add_provider);++/**+*of_genpd_del_provider()-RemoveapreviouslyregisteredPMdomainprovider+*@np:DevicenodepointerassociatedwiththePMdomainprovider+*/+voidof_genpd_del_provider(structdevice_node*np)+{+structof_genpd_provider*cp;++mutex_lock(&of_genpd_mutex);+list_for_each_entry(cp,&of_genpd_providers,link){+if(cp->node==np){+list_del(&cp->link);+of_node_put(cp->node);+kfree(cp);+break;+}+}+mutex_unlock(&of_genpd_mutex);+}+EXPORT_SYMBOL_GPL(of_genpd_del_provider);++/**+*of_genpd_get_from_provider()-Look-upPMdomain+*@genpdspec:OFphandleargstouseforlook-up+*+*LooksforaPMdomainproviderunderthenodespecifiedby@genpdspecandif+*found,usesxlatefunctionoftheprovidertomapphandleargstoaPM+*domain.+*+*Returnsavalidpointertostructgeneric_pm_domainonsuccessorERR_PTR()+*onfailure.+*/+staticstructgeneric_pm_domain*of_genpd_get_from_provider(+structof_phandle_args*genpdspec)+{+structgeneric_pm_domain*genpd=ERR_PTR(-ENOENT);+structof_genpd_provider*provider;++mutex_lock(&of_genpd_mutex);++/* Check if we have such a provider in our array */+list_for_each_entry(provider,&of_genpd_providers,link){+if(provider->node==genpdspec->np)+genpd=provider->xlate(genpdspec,provider->data);+if(!IS_ERR(genpd))+break;+}++mutex_unlock(&of_genpd_mutex);++returngenpd;+}++/**+*genpd_dev_pm_attach-AttachadevicetoitsPMdomainusingDT.+*@dev:Devicetoattach.+*+*Parsedevice'sOFnodetofindaPMdomainspecifier.Ifsuchisfound,+*attachesthedevicetoretrievedpm_domainops.+*+*BothgenericandlegacySamsung-specificDTbindingsaresupportedtokeep+*backwardscompatibilitywithexistingDTBs.+*+*Returns0onsuccessfullyattachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_attach(structdevice*dev)+{+structof_phandle_argspd_args;+structgeneric_pm_domain*pd;+intret;++if(!dev->of_node)+return-ENODEV;++if(dev->pm_domain)+return-EEXIST;++ret=of_parse_phandle_with_args(dev->of_node,"power-domains",+"#power-domain-cells",0,&pd_args);+if(ret<0){+if(ret!=-ENOENT)+returnret;++/*+*TrylegacySamsung-specificbindings+*(forbackwardscompatibilityofDTABI)+*/+pd_args.args_count=0;+pd_args.np=of_parse_phandle(dev->of_node,+"samsung,power-domain",0);+if(!pd_args.np)+return-ENOENT;+}++pd=of_genpd_get_from_provider(&pd_args);+if(IS_ERR(pd)){+dev_dbg(dev,"%s() failed to find PM domain: %ld\n",+__func__,PTR_ERR(pd));+of_node_put(dev->of_node);+returnPTR_ERR(pd);+}++dev_dbg(dev,"adding to PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_add_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to add to PM domain %s: %d",+pd->name,ret);+of_node_put(dev->of_node);+returnret;+}++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);++/**+*genpd_dev_pm_detach-DetachadevicefromitsPMdomain.+*@dev:Devicetoattach.+*+*TrytolocateacorrespondinggenericPMdomain,whichthedevicewas+*attachedtopreviously.Ifsuchisfound,thedeviceisdetachedfromit.+*+*Returns0onsuccessfullydetachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_detach(structdevice*dev)+{+structgeneric_pm_domain*pd=NULL,*gpd;+intret=0;++if(!dev->pm_domain)+return-ENODEV;++mutex_lock(&gpd_list_lock);+list_for_each_entry(gpd,&gpd_list,gpd_list_node){+if(&gpd->domain==dev->pm_domain){+pd=gpd;+break;+}+}+mutex_unlock(&gpd_list_lock);++if(!pd)+return-ENOENT;++dev_dbg(dev,"removing from PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_remove_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to remove from PM domain %s: %d",+pd->name,ret);+returnret;+}++/* Check if PM domain can be powered off after removing this device. */+genpd_queue_power_off_work(pd);++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_detach);+#endif
To maintain scalability let's add common methods to attach and detach
a PM domain for a device, dev_pm_domain_attach|detach().
Typically dev_pm_domain_attach() shall be invoked from subsystem level
code at the probe phase to try to attach a device to its PM domain.
The reversed actions may be done a the remove phase and then by invoking
dev_pm_domain_detach().
The supported PM domains at this point are the ACPI and the generic
PM domains.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/base/power/common.c | 56 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm.h | 14 ++++++++++++
2 files changed, 70 insertions(+)
Previously only the ACPI PM domain was supported by the platform bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/base/platform.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Previously only the ACPI PM domain was supported by the i2c bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Cc: linux-i2c at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
---
drivers/i2c/i2c-core.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
Previously only the ACPI PM domain was supported by the sdio bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
---
drivers/mmc/core/sdio_bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Previously only the ACPI PM domain was supported by the spi bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Cc: linux-spi at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
---
drivers/spi/spi.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
AMBA devices may on some SoCs resides in PM domains. To be able to
manage these devices from there, let's try to attach devices to their
corresponding PM domain during the probe phase.
To reverse these actions at the remove phase, we try to detach the
device from its PM domain.
Signed-off-by: Ulf Hansson <redacted>
---
drivers/amba/bus.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
From: Tomasz Figa <redacted>
This patch moves Exynos PM domain code to use the new generic PM domain
look-up framework introduced in previous patches, thus also allowing
the new code to be compiled with CONFIG_ARCH_EXYNOS.
Signed-off-by: Tomasz Figa <redacted>
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Rebased and resolved conflicts]
---
.../bindings/arm/exynos/power_domain.txt | 13 ++--
arch/arm/mach-exynos/pm_domains.c | 78 +---------------------
kernel/power/Kconfig | 2 +-
3 files changed, 8 insertions(+), 85 deletions(-)
@@ -8,6 +8,8 @@ Required Properties: * samsung,exynos4210-pd - for exynos4210 type power domain. - reg: physical base address of the controller and length of memory mapped region.+- #power-domain-cells: number of cells in power domain specifier;+ must be 0. Optional Properties: - clocks: List of clock handles. The parent clocks of the input clocks to the
@@ -105,78 +105,6 @@ static int exynos_pd_power_off(struct generic_pm_domain *domain)returnexynos_pd_power(domain,false);}-staticvoidexynos_add_device_to_domain(structexynos_pm_domain*pd,-structdevice*dev)-{-intret;--dev_dbg(dev,"adding to power domain %s\n",pd->pd.name);--while(1){-ret=pm_genpd_add_device(&pd->pd,dev);-if(ret!=-EAGAIN)-break;-cond_resched();-}--pm_genpd_dev_need_restore(dev,true);-}--staticvoidexynos_remove_device_from_domain(structdevice*dev)-{-structgeneric_pm_domain*genpd=dev_to_genpd(dev);-intret;--dev_dbg(dev,"removing from power domain %s\n",genpd->name);--while(1){-ret=pm_genpd_remove_device(genpd,dev);-if(ret!=-EAGAIN)-break;-cond_resched();-}-}--staticvoidexynos_read_domain_from_dt(structdevice*dev)-{-structplatform_device*pd_pdev;-structexynos_pm_domain*pd;-structdevice_node*node;--node=of_parse_phandle(dev->of_node,"samsung,power-domain",0);-if(!node)-return;-pd_pdev=of_find_device_by_node(node);-if(!pd_pdev)-return;-pd=platform_get_drvdata(pd_pdev);-exynos_add_device_to_domain(pd,dev);-}--staticintexynos_pm_notifier_call(structnotifier_block*nb,-unsignedlongevent,void*data)-{-structdevice*dev=data;--switch(event){-caseBUS_NOTIFY_BIND_DRIVER:-if(dev->of_node)-exynos_read_domain_from_dt(dev);--break;--caseBUS_NOTIFY_UNBOUND_DRIVER:-exynos_remove_device_from_domain(dev);--break;-}-returnNOTIFY_DONE;-}--staticstructnotifier_blockplatform_nb={-.notifier_call=exynos_pm_notifier_call,-};-static__initintexynos4_pm_init_power_domain(void){structplatform_device*pdev;
@@ -202,7 +130,6 @@ static __init int exynos4_pm_init_power_domain(void)pd->base=of_iomap(np,0);pd->pd.power_off=exynos_pd_power_off;pd->pd.power_on=exynos_pd_power_on;-pd->pd.of_node=np;pd->oscclk=clk_get(dev,"oscclk");if(IS_ERR(pd->oscclk))
@@ -228,15 +155,12 @@ static __init int exynos4_pm_init_power_domain(void)clk_put(pd->oscclk);no_clk:-platform_set_drvdata(pdev,pd);-on=__raw_readl(pd->base+0x4)&INT_LOCAL_PWR_EN;pm_genpd_init(&pd->pd,NULL,!on);+of_genpd_add_provider_simple(np,&pd->pd);}-bus_register_notifier(&platform_bus_type,&platform_nb);-return0;}arch_initcall(exynos4_pm_init_power_domain);
From: Rafael J. Wysocki <hidden> Date: 2014-09-07 22:12:04
On Thursday, September 04, 2014 03:52:28 PM Ulf Hansson wrote:
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
I can take this patch alone for 3.8 if that helps.
From: Rafael J. Wysocki <hidden> Date: 2014-09-07 22:13:36
On Thursday, September 04, 2014 03:52:29 PM Ulf Hansson wrote:
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
Signed-off-by: Tomasz Figa <redacted>
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Added attach|detach functions, fixed review comments]
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
However, for this one (and consequently the rest) I need an ACK from the
people who maintain the bindings.
@@ -0,0 +1,49 @@+* Generic PM domains++System on chip designs are often divided into multiple PM domains that can be+used for power gating of selected IP blocks for power saving by reduced leakage+current.++This device tree binding can be used to bind PM domain consumer devices with+their PM domains provided by PM domain providers. A PM domain provider can be+represented by any node in the device tree and can provide one or more PM+domains. A consumer node can refer to the provider by a phandle and a set of+phandle arguments (so called PM domain specifiers) of length specified by the+#power-domain-cells property in the PM domain provider node.++==PM domain providers==++Required properties:+ - #power-domain-cells : Number of cells in a PM domain specifier;+ Typically 0 for nodes representing a single PM domain and 1 for nodes+ providing multiple PM domains (e.g. power controllers), but can be any value+ as specified by device tree binding documentation of particular provider.++Example:++ power: power-controller at 12340000 {+ compatible = "foo,power-controller";+ reg = <0x12340000 0x1000>;+ #power-domain-cells = <1>;+ };++The node above defines a power controller that is a PM domain provider and+expects one cell as its phandle argument.++==PM domain consumers==++Required properties:+ - power-domains : A phandle and PM domain specifier as defined by bindings of+ the power controller specified by phandle.++Example:++ leaky-device at 12350000 {+ compatible = "foo,i-leak-current";+ reg = <0x12350000 0x1000>;+ power-domains = <&power 0>;+ };++The node above defines a typical PM domain consumer device, which is located+inside a PM domain with index 0 of a power controller represented by a node+with the label "power".
@@ -2189,3 +2190,293 @@ void pm_genpd_init(struct generic_pm_domain *genpd,list_add(&genpd->gpd_list_node,&gpd_list);mutex_unlock(&gpd_list_lock);}++#ifdef CONFIG_PM_GENERIC_DOMAINS_OF+/*+*DeviceTreebasedPMdomainproviders.+*+*ThecodebelowimplementsgenericdevicetreebasedPMdomainprovidersthat+*binddevicetreenodeswithgenericPMdomainsregisteredinthesystem.+*+*AnydriverthatregistersgenericPMdomainsandneedstosupportbindingof+*devicestothesedomainsissupposedtoregisteraPMdomainprovider,which+*mapsaPMdomainspecifierretrievedfromthedevicetreetoaPMdomain.+*+*Twosimplemappingfunctionshavebeenprovidedforconvenience:+*-__of_genpd_xlate_simple()for1:1devicetreenodetoPMdomainmapping.+*-__of_genpd_xlate_onecell()formappingofmultiplePMdomainspernodeby+*index.+*/++/**+*structof_genpd_provider-PMdomainproviderregistrationstructure+*@link:EntryingloballistofPMdomainproviders+*@node:PointertodevicetreenodeofPMdomainprovider+*@xlate:Provider-specificxlatecallbackmappingasetofspecifiercells+*intoaPMdomain.+*@data:contextpointertobepassedinto@xlatecallback+*/+structof_genpd_provider{+structlist_headlink;+structdevice_node*node;+genpd_xlate_txlate;+void*data;+};++/* List of registered PM domain providers. */+staticLIST_HEAD(of_genpd_providers);+/* Mutex to protect the list above. */+staticDEFINE_MUTEX(of_genpd_mutex);++/**+*__of_genpd_xlate_simple()-Xlatefunctionfordirectnode-domainmapping+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgeneric_pm_domain+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelPMdomainsthat+*havetheirowndevicetreenodes.Theprivatedataofxlatefunctionneeds+*tobeavalidpointertostructgeneric_pm_domain.+*/+structgeneric_pm_domain*__of_genpd_xlate_simple(+structof_phandle_args*genpdspec,+void*data)+{+if(genpdspec->args_count!=0)+returnERR_PTR(-EINVAL);+returndata;+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_simple);++/**+*__of_genpd_xlate_onecell()-Xlatefunctionusingasingleindex.+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgenpd_onecell_data+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelsimplePMdomain+*controllersthathaveonedevicetreenodeandprovidemultiplePMdomains.+*AsinglecellisusedasanindexintoanarrayofPMdomainsspecifiedin+*thegenpd_onecell_datastructwhenregisteringtheprovider.+*/+structgeneric_pm_domain*__of_genpd_xlate_onecell(+structof_phandle_args*genpdspec,+void*data)+{+structgenpd_onecell_data*genpd_data=data;+unsignedintidx=genpdspec->args[0];++if(genpdspec->args_count!=1)+returnERR_PTR(-EINVAL);++if(idx>=genpd_data->num_domains){+pr_err("%s: invalid domain index %u\n",__func__,idx);+returnERR_PTR(-EINVAL);+}++if(!genpd_data->domains[idx])+returnERR_PTR(-ENOENT);++returngenpd_data->domains[idx];+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_onecell);++/**+*__of_genpd_add_provider()-RegisteraPMdomainproviderforanode+*@np:DevicenodepointerassociatedwiththePMdomainprovider.+*@xlate:CallbackfordecodingPMdomainfromphandlearguments.+*@data:Contextpointerfor@xlatecallback.+*/+int__of_genpd_add_provider(structdevice_node*np,genpd_xlate_txlate,+void*data)+{+structof_genpd_provider*cp;++cp=kzalloc(sizeof(*cp),GFP_KERNEL);+if(!cp)+return-ENOMEM;++cp->node=of_node_get(np);+cp->data=data;+cp->xlate=xlate;++mutex_lock(&of_genpd_mutex);+list_add(&cp->link,&of_genpd_providers);+mutex_unlock(&of_genpd_mutex);+pr_debug("Added domain provider from %s\n",np->full_name);++return0;+}+EXPORT_SYMBOL_GPL(__of_genpd_add_provider);++/**+*of_genpd_del_provider()-RemoveapreviouslyregisteredPMdomainprovider+*@np:DevicenodepointerassociatedwiththePMdomainprovider+*/+voidof_genpd_del_provider(structdevice_node*np)+{+structof_genpd_provider*cp;++mutex_lock(&of_genpd_mutex);+list_for_each_entry(cp,&of_genpd_providers,link){+if(cp->node==np){+list_del(&cp->link);+of_node_put(cp->node);+kfree(cp);+break;+}+}+mutex_unlock(&of_genpd_mutex);+}+EXPORT_SYMBOL_GPL(of_genpd_del_provider);++/**+*of_genpd_get_from_provider()-Look-upPMdomain+*@genpdspec:OFphandleargstouseforlook-up+*+*LooksforaPMdomainproviderunderthenodespecifiedby@genpdspecandif+*found,usesxlatefunctionoftheprovidertomapphandleargstoaPM+*domain.+*+*Returnsavalidpointertostructgeneric_pm_domainonsuccessorERR_PTR()+*onfailure.+*/+staticstructgeneric_pm_domain*of_genpd_get_from_provider(+structof_phandle_args*genpdspec)+{+structgeneric_pm_domain*genpd=ERR_PTR(-ENOENT);+structof_genpd_provider*provider;++mutex_lock(&of_genpd_mutex);++/* Check if we have such a provider in our array */+list_for_each_entry(provider,&of_genpd_providers,link){+if(provider->node==genpdspec->np)+genpd=provider->xlate(genpdspec,provider->data);+if(!IS_ERR(genpd))+break;+}++mutex_unlock(&of_genpd_mutex);++returngenpd;+}++/**+*genpd_dev_pm_attach-AttachadevicetoitsPMdomainusingDT.+*@dev:Devicetoattach.+*+*Parsedevice'sOFnodetofindaPMdomainspecifier.Ifsuchisfound,+*attachesthedevicetoretrievedpm_domainops.+*+*BothgenericandlegacySamsung-specificDTbindingsaresupportedtokeep+*backwardscompatibilitywithexistingDTBs.+*+*Returns0onsuccessfullyattachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_attach(structdevice*dev)+{+structof_phandle_argspd_args;+structgeneric_pm_domain*pd;+intret;++if(!dev->of_node)+return-ENODEV;++if(dev->pm_domain)+return-EEXIST;++ret=of_parse_phandle_with_args(dev->of_node,"power-domains",+"#power-domain-cells",0,&pd_args);+if(ret<0){+if(ret!=-ENOENT)+returnret;++/*+*TrylegacySamsung-specificbindings+*(forbackwardscompatibilityofDTABI)+*/+pd_args.args_count=0;+pd_args.np=of_parse_phandle(dev->of_node,+"samsung,power-domain",0);+if(!pd_args.np)+return-ENOENT;+}++pd=of_genpd_get_from_provider(&pd_args);+if(IS_ERR(pd)){+dev_dbg(dev,"%s() failed to find PM domain: %ld\n",+__func__,PTR_ERR(pd));+of_node_put(dev->of_node);+returnPTR_ERR(pd);+}++dev_dbg(dev,"adding to PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_add_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to add to PM domain %s: %d",+pd->name,ret);+of_node_put(dev->of_node);+returnret;+}++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);++/**+*genpd_dev_pm_detach-DetachadevicefromitsPMdomain.+*@dev:Devicetoattach.+*+*TrytolocateacorrespondinggenericPMdomain,whichthedevicewas+*attachedtopreviously.Ifsuchisfound,thedeviceisdetachedfromit.+*+*Returns0onsuccessfullydetachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_detach(structdevice*dev)+{+structgeneric_pm_domain*pd=NULL,*gpd;+intret=0;++if(!dev->pm_domain)+return-ENODEV;++mutex_lock(&gpd_list_lock);+list_for_each_entry(gpd,&gpd_list,gpd_list_node){+if(&gpd->domain==dev->pm_domain){+pd=gpd;+break;+}+}+mutex_unlock(&gpd_list_lock);++if(!pd)+return-ENOENT;++dev_dbg(dev,"removing from PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_remove_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to remove from PM domain %s: %d",+pd->name,ret);+returnret;+}++/* Check if PM domain can be powered off after removing this device. */+genpd_queue_power_off_work(pd);++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_detach);+#endif
On 8 September 2014 00:13, Rafael J. Wysocki [off-list ref] wrote:
On Thursday, September 04, 2014 03:52:29 PM Ulf Hansson wrote:
quoted
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
Signed-off-by: Tomasz Figa <redacted>
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Added attach|detach functions, fixed review comments]
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
However, for this one (and consequently the rest) I need an ACK from the
people who maintain the bindings.
These DT bindings have been discussed between Tomasz and devicetree
maintainers previously. So I think there are fine.
Also, when browsing the mail-archives, I found an ack from Rob Herrring:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/237989.html
I realize that I didn't put the DT maintainers on the to-line when
posting this patch, but just the devicetree list. I have now included
them on this reply, but maybe I should repost instead. What do you
think? Are you happy with the above ack from Rob?
Kind regards
Uffe
@@ -0,0 +1,49 @@+* Generic PM domains++System on chip designs are often divided into multiple PM domains that can be+used for power gating of selected IP blocks for power saving by reduced leakage+current.++This device tree binding can be used to bind PM domain consumer devices with+their PM domains provided by PM domain providers. A PM domain provider can be+represented by any node in the device tree and can provide one or more PM+domains. A consumer node can refer to the provider by a phandle and a set of+phandle arguments (so called PM domain specifiers) of length specified by the+#power-domain-cells property in the PM domain provider node.++==PM domain providers==++Required properties:+ - #power-domain-cells : Number of cells in a PM domain specifier;+ Typically 0 for nodes representing a single PM domain and 1 for nodes+ providing multiple PM domains (e.g. power controllers), but can be any value+ as specified by device tree binding documentation of particular provider.++Example:++ power: power-controller at 12340000 {+ compatible = "foo,power-controller";+ reg = <0x12340000 0x1000>;+ #power-domain-cells = <1>;+ };++The node above defines a power controller that is a PM domain provider and+expects one cell as its phandle argument.++==PM domain consumers==++Required properties:+ - power-domains : A phandle and PM domain specifier as defined by bindings of+ the power controller specified by phandle.++Example:++ leaky-device at 12350000 {+ compatible = "foo,i-leak-current";+ reg = <0x12350000 0x1000>;+ power-domains = <&power 0>;+ };++The node above defines a typical PM domain consumer device, which is located+inside a PM domain with index 0 of a power controller represented by a node+with the label "power".
@@ -2189,3 +2190,293 @@ void pm_genpd_init(struct generic_pm_domain *genpd,list_add(&genpd->gpd_list_node,&gpd_list);mutex_unlock(&gpd_list_lock);}++#ifdef CONFIG_PM_GENERIC_DOMAINS_OF+/*+*DeviceTreebasedPMdomainproviders.+*+*ThecodebelowimplementsgenericdevicetreebasedPMdomainprovidersthat+*binddevicetreenodeswithgenericPMdomainsregisteredinthesystem.+*+*AnydriverthatregistersgenericPMdomainsandneedstosupportbindingof+*devicestothesedomainsissupposedtoregisteraPMdomainprovider,which+*mapsaPMdomainspecifierretrievedfromthedevicetreetoaPMdomain.+*+*Twosimplemappingfunctionshavebeenprovidedforconvenience:+*-__of_genpd_xlate_simple()for1:1devicetreenodetoPMdomainmapping.+*-__of_genpd_xlate_onecell()formappingofmultiplePMdomainspernodeby+*index.+*/++/**+*structof_genpd_provider-PMdomainproviderregistrationstructure+*@link:EntryingloballistofPMdomainproviders+*@node:PointertodevicetreenodeofPMdomainprovider+*@xlate:Provider-specificxlatecallbackmappingasetofspecifiercells+*intoaPMdomain.+*@data:contextpointertobepassedinto@xlatecallback+*/+structof_genpd_provider{+structlist_headlink;+structdevice_node*node;+genpd_xlate_txlate;+void*data;+};++/* List of registered PM domain providers. */+staticLIST_HEAD(of_genpd_providers);+/* Mutex to protect the list above. */+staticDEFINE_MUTEX(of_genpd_mutex);++/**+*__of_genpd_xlate_simple()-Xlatefunctionfordirectnode-domainmapping+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgeneric_pm_domain+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelPMdomainsthat+*havetheirowndevicetreenodes.Theprivatedataofxlatefunctionneeds+*tobeavalidpointertostructgeneric_pm_domain.+*/+structgeneric_pm_domain*__of_genpd_xlate_simple(+structof_phandle_args*genpdspec,+void*data)+{+if(genpdspec->args_count!=0)+returnERR_PTR(-EINVAL);+returndata;+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_simple);++/**+*__of_genpd_xlate_onecell()-Xlatefunctionusingasingleindex.+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgenpd_onecell_data+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelsimplePMdomain+*controllersthathaveonedevicetreenodeandprovidemultiplePMdomains.+*AsinglecellisusedasanindexintoanarrayofPMdomainsspecifiedin+*thegenpd_onecell_datastructwhenregisteringtheprovider.+*/+structgeneric_pm_domain*__of_genpd_xlate_onecell(+structof_phandle_args*genpdspec,+void*data)+{+structgenpd_onecell_data*genpd_data=data;+unsignedintidx=genpdspec->args[0];++if(genpdspec->args_count!=1)+returnERR_PTR(-EINVAL);++if(idx>=genpd_data->num_domains){+pr_err("%s: invalid domain index %u\n",__func__,idx);+returnERR_PTR(-EINVAL);+}++if(!genpd_data->domains[idx])+returnERR_PTR(-ENOENT);++returngenpd_data->domains[idx];+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_onecell);++/**+*__of_genpd_add_provider()-RegisteraPMdomainproviderforanode+*@np:DevicenodepointerassociatedwiththePMdomainprovider.+*@xlate:CallbackfordecodingPMdomainfromphandlearguments.+*@data:Contextpointerfor@xlatecallback.+*/+int__of_genpd_add_provider(structdevice_node*np,genpd_xlate_txlate,+void*data)+{+structof_genpd_provider*cp;++cp=kzalloc(sizeof(*cp),GFP_KERNEL);+if(!cp)+return-ENOMEM;++cp->node=of_node_get(np);+cp->data=data;+cp->xlate=xlate;++mutex_lock(&of_genpd_mutex);+list_add(&cp->link,&of_genpd_providers);+mutex_unlock(&of_genpd_mutex);+pr_debug("Added domain provider from %s\n",np->full_name);++return0;+}+EXPORT_SYMBOL_GPL(__of_genpd_add_provider);++/**+*of_genpd_del_provider()-RemoveapreviouslyregisteredPMdomainprovider+*@np:DevicenodepointerassociatedwiththePMdomainprovider+*/+voidof_genpd_del_provider(structdevice_node*np)+{+structof_genpd_provider*cp;++mutex_lock(&of_genpd_mutex);+list_for_each_entry(cp,&of_genpd_providers,link){+if(cp->node==np){+list_del(&cp->link);+of_node_put(cp->node);+kfree(cp);+break;+}+}+mutex_unlock(&of_genpd_mutex);+}+EXPORT_SYMBOL_GPL(of_genpd_del_provider);++/**+*of_genpd_get_from_provider()-Look-upPMdomain+*@genpdspec:OFphandleargstouseforlook-up+*+*LooksforaPMdomainproviderunderthenodespecifiedby@genpdspecandif+*found,usesxlatefunctionoftheprovidertomapphandleargstoaPM+*domain.+*+*Returnsavalidpointertostructgeneric_pm_domainonsuccessorERR_PTR()+*onfailure.+*/+staticstructgeneric_pm_domain*of_genpd_get_from_provider(+structof_phandle_args*genpdspec)+{+structgeneric_pm_domain*genpd=ERR_PTR(-ENOENT);+structof_genpd_provider*provider;++mutex_lock(&of_genpd_mutex);++/* Check if we have such a provider in our array */+list_for_each_entry(provider,&of_genpd_providers,link){+if(provider->node==genpdspec->np)+genpd=provider->xlate(genpdspec,provider->data);+if(!IS_ERR(genpd))+break;+}++mutex_unlock(&of_genpd_mutex);++returngenpd;+}++/**+*genpd_dev_pm_attach-AttachadevicetoitsPMdomainusingDT.+*@dev:Devicetoattach.+*+*Parsedevice'sOFnodetofindaPMdomainspecifier.Ifsuchisfound,+*attachesthedevicetoretrievedpm_domainops.+*+*BothgenericandlegacySamsung-specificDTbindingsaresupportedtokeep+*backwardscompatibilitywithexistingDTBs.+*+*Returns0onsuccessfullyattachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_attach(structdevice*dev)+{+structof_phandle_argspd_args;+structgeneric_pm_domain*pd;+intret;++if(!dev->of_node)+return-ENODEV;++if(dev->pm_domain)+return-EEXIST;++ret=of_parse_phandle_with_args(dev->of_node,"power-domains",+"#power-domain-cells",0,&pd_args);+if(ret<0){+if(ret!=-ENOENT)+returnret;++/*+*TrylegacySamsung-specificbindings+*(forbackwardscompatibilityofDTABI)+*/+pd_args.args_count=0;+pd_args.np=of_parse_phandle(dev->of_node,+"samsung,power-domain",0);+if(!pd_args.np)+return-ENOENT;+}++pd=of_genpd_get_from_provider(&pd_args);+if(IS_ERR(pd)){+dev_dbg(dev,"%s() failed to find PM domain: %ld\n",+__func__,PTR_ERR(pd));+of_node_put(dev->of_node);+returnPTR_ERR(pd);+}++dev_dbg(dev,"adding to PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_add_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to add to PM domain %s: %d",+pd->name,ret);+of_node_put(dev->of_node);+returnret;+}++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);++/**+*genpd_dev_pm_detach-DetachadevicefromitsPMdomain.+*@dev:Devicetoattach.+*+*TrytolocateacorrespondinggenericPMdomain,whichthedevicewas+*attachedtopreviously.Ifsuchisfound,thedeviceisdetachedfromit.+*+*Returns0onsuccessfullydetachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_detach(structdevice*dev)+{+structgeneric_pm_domain*pd=NULL,*gpd;+intret=0;++if(!dev->pm_domain)+return-ENODEV;++mutex_lock(&gpd_list_lock);+list_for_each_entry(gpd,&gpd_list,gpd_list_node){+if(&gpd->domain==dev->pm_domain){+pd=gpd;+break;+}+}+mutex_unlock(&gpd_list_lock);++if(!pd)+return-ENOENT;++dev_dbg(dev,"removing from PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_remove_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to remove from PM domain %s: %d",+pd->name,ret);+returnret;+}++/* Check if PM domain can be powered off after removing this device. */+genpd_queue_power_off_work(pd);++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_detach);+#endif
From: Tomasz Figa <hidden> Date: 2014-09-08 20:53:09
On 08.09.2014 23:08, Rafael J. Wysocki wrote:
On Monday, September 08, 2014 11:04:23 PM Rafael J. Wysocki wrote:
quoted
On Monday, September 08, 2014 09:26:20 AM Ulf Hansson wrote:
quoted
On 8 September 2014 00:13, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Thursday, September 04, 2014 03:52:29 PM Ulf Hansson wrote:
quoted
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
Signed-off-by: Tomasz Figa <redacted>
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Added attach|detach functions, fixed review comments]
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
However, for this one (and consequently the rest) I need an ACK from the
people who maintain the bindings.
These DT bindings have been discussed between Tomasz and devicetree
maintainers previously. So I think there are fine.
Also, when browsing the mail-archives, I found an ack from Rob Herrring:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/237989.html
I realize that I didn't put the DT maintainers on the to-line when
posting this patch, but just the devicetree list. I have now included
them on this reply, but maybe I should repost instead. What do you
think? Are you happy with the above ack from Rob?
That should be sufficient, but I wonder why you didn't add it to the patch
to start with?
BTW, I get bounces from t.figa at samsung.com, so I won't apply the patch with
that as the "From" field. And the s-o-b from a bouncing address is worthless
too.
Yes, that e-mail address is no longer valid, as I'm not at Samsung
anymore. I'm not sure what's the right thing to do with From and SOB in
this series, though.
If it's of any help, my private address (and the one I use for things I
maintain and any open source activity on my own) is this one.
Best regards,
Tomasz
Hi Rafael,
On Mon, Sep 8, 2014 at 11:08 PM, Rafael J. Wysocki [off-list ref] wrote:
BTW, I get bounces from t.figa at samsung.com, so I won't apply the patch with
that as the "From" field. And the s-o-b from a bouncing address is worthless
too.
In the mean time, Tomasz has moved:
http://www.spinics.net/lists/arm-kernel/msg357102.html
Still, the From/SoB indicate attribution to Samsung, so I think it should be
kept.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
From: Rafael J. Wysocki <hidden> Date: 2014-09-08 21:04:23
On Monday, September 08, 2014 09:26:20 AM Ulf Hansson wrote:
On 8 September 2014 00:13, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Thursday, September 04, 2014 03:52:29 PM Ulf Hansson wrote:
quoted
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
Signed-off-by: Tomasz Figa <redacted>
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Added attach|detach functions, fixed review comments]
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
However, for this one (and consequently the rest) I need an ACK from the
people who maintain the bindings.
These DT bindings have been discussed between Tomasz and devicetree
maintainers previously. So I think there are fine.
Also, when browsing the mail-archives, I found an ack from Rob Herrring:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/237989.html
I realize that I didn't put the DT maintainers on the to-line when
posting this patch, but just the devicetree list. I have now included
them on this reply, but maybe I should repost instead. What do you
think? Are you happy with the above ack from Rob?
That should be sufficient, but I wonder why you didn't add it to the patch
to start with?
Rafael
From: Rafael J. Wysocki <hidden> Date: 2014-09-08 21:08:15
On Monday, September 08, 2014 11:04:23 PM Rafael J. Wysocki wrote:
On Monday, September 08, 2014 09:26:20 AM Ulf Hansson wrote:
quoted
On 8 September 2014 00:13, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Thursday, September 04, 2014 03:52:29 PM Ulf Hansson wrote:
quoted
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
Signed-off-by: Tomasz Figa <redacted>
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Added attach|detach functions, fixed review comments]
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
However, for this one (and consequently the rest) I need an ACK from the
people who maintain the bindings.
These DT bindings have been discussed between Tomasz and devicetree
maintainers previously. So I think there are fine.
Also, when browsing the mail-archives, I found an ack from Rob Herrring:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/237989.html
I realize that I didn't put the DT maintainers on the to-line when
posting this patch, but just the devicetree list. I have now included
them on this reply, but maybe I should repost instead. What do you
think? Are you happy with the above ack from Rob?
That should be sufficient, but I wonder why you didn't add it to the patch
to start with?
BTW, I get bounces from t.figa at samsung.com, so I won't apply the patch with
that as the "From" field. And the s-o-b from a bouncing address is worthless
too.
Rafael
From: Rafael J. Wysocki <hidden> Date: 2014-09-08 22:11:53
On Thursday, September 04, 2014 03:52:30 PM Ulf Hansson wrote:
quoted hunk
To maintain scalability let's add common methods to attach and detach
a PM domain for a device, dev_pm_domain_attach|detach().
Typically dev_pm_domain_attach() shall be invoked from subsystem level
code at the probe phase to try to attach a device to its PM domain.
The reversed actions may be done a the remove phase and then by invoking
dev_pm_domain_detach().
The supported PM domains at this point are the ACPI and the generic
PM domains.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
---
drivers/base/power/common.c | 56 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm.h | 14 ++++++++++++
2 files changed, 70 insertions(+)
@@ -82,3 +84,57 @@ int dev_pm_put_subsys_data(struct device *dev)returnret;}EXPORT_SYMBOL_GPL(dev_pm_put_subsys_data);++/**+*dev_pm_domain_attach-AttachadevicetoitsPMdomain.+*@dev:Devicetoattach.+*@power_on:Usedtoindicatewhetherweshouldpoweronthedevice.+*+*The@devmayonlybeattachedtoasinglePMdomain.Byiteratingthrough+*theavailablealternativeswetrytofindavalidPMdomainforthedevice.+*+*Thisfunctionshouldtypicallybeinvokedfromsubsystemlevelcodeduring+*theprobephase.Especiallyforthosethatholdsdeviceswhichrequires+*powermanagementthroughPMdomains.+*+*Callersmustensurepropersynchronizationofthisfunctionwithpower+*managementcallbacks.+*+*Returns0onsuccessfullyattachedPMdomainornegativeerrorcode.+*/+intdev_pm_domain_attach(structdevice*dev,boolpower_on)+{+intret;++ret=acpi_dev_pm_attach(dev,power_on);+if(!ret||ret==-EPROBE_DEFER)
acpi_dev_pm_attach() doesn't return EPROBE_DEFER and there are no plans for it
to do that. IIRC, I pointed that out to you in the previous round (or even
earlier). Please remove this check, it is pointless.
And why don't you write this as
ret = acpi_dev_pm_attach(dev, power_on);
if (ret)
ret = genpd_dev_pm_attach(dev);
return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_domain_attach);
+
+/**
+ * dev_pm_domain_detach - Detach a device from its PM domain.
+ * @dev: Device to attach.
+ * @power_off: Used to indicate whether we should power off the device.
+ *
+ * The @dev may be attached to a PM domain. By iterating through the available
+ * alternatives we detach it from its PM domain.
+ *
+ * This functions will reverse the actions from dev_pm_domain_attach() and thus
+ * detach the @dev from its PM domain. Typically it should be invoked from
+ * subsystem level code during the remove phase.
+ *
+ * Callers must ensure proper synchronization of this function with power
+ * management callbacks.
+ *
+ * Returns 0 on successfully detached PM domain or negative error code.
+ */
+int dev_pm_domain_detach(struct device *dev, bool power_off)
+{
+ if (acpi_dev_pm_detach(dev, power_off))
+ return genpd_dev_pm_detach(dev);
And analogously here? Or the other way around? Just please make them both
look analogously.
On 8 September 2014 23:04, Rafael J. Wysocki [off-list ref] wrote:
On Monday, September 08, 2014 09:26:20 AM Ulf Hansson wrote:
quoted
On 8 September 2014 00:13, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Thursday, September 04, 2014 03:52:29 PM Ulf Hansson wrote:
quoted
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
Signed-off-by: Tomasz Figa <redacted>
Signed-off-by: Ulf Hansson <redacted>
[Ulf:Added attach|detach functions, fixed review comments]
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
However, for this one (and consequently the rest) I need an ACK from the
people who maintain the bindings.
These DT bindings have been discussed between Tomasz and devicetree
maintainers previously. So I think there are fine.
Also, when browsing the mail-archives, I found an ack from Rob Herrring:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/237989.html
I realize that I didn't put the DT maintainers on the to-line when
posting this patch, but just the devicetree list. I have now included
them on this reply, but maybe I should repost instead. What do you
think? Are you happy with the above ack from Rob?
That should be sufficient, but I wonder why you didn't add it to the patch
to start with?
I didn't remember it being formally acked, until I decided to browsed
the mail archives in detail. Sorry about that.
Kind regards
Uffe
Changes in v4:
- Rebased patch "PM / Domains: Add generic OF-based PM domain look-up" -
and updated the author and the commit message.
- Adopted review comments for "PM / Domains: Add APIs to attach/detach
a PM domain for a device".
- Updated author and commit message for "ARM: exynos: Move to generic
PM domain DT bindings".
- Added some acks and reviewed by tags.
- Started to use the "--in-reply-to" option to git-send-email. It should
provide the option to show a better diffstat per patch.
Changes in v3:
- Aligned on terminology, now using "PM domain" in comments and commit
- messages/headers.
- Improved English and grammar in comments and commit messages/headers.
- Adopted proposal from Geert, to have compile-time-check wrapper
functions for the API that adds xlate_simple and xlate_onecell
providers.
- Renamed "domain_num" to "num_domains", in genpd_onecell_data struct.
- Handle non-contiguous arrays for onecell PM domain providers.
- Rebased the Exynos patch to follow the new genpd API changes.
Changes in v2:
- Fix the ACPI patch, it didn't even compile for CONFIG_ACPI.
- Updated some comments in code and in commit messages.
- Fixed the dev_pm_domain_attach API to handle EPROBE_DEFER properly.
- Rebased the ARM Exynos patch.
- Added some Tested-by tags.
This patchset has a bit of a history and some parts of it has been posted
earlier.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262725.html
In the first revision I intentially didn't increase version number of the
patches, since I think it would have cause more confusion than clarity.
A summary of changes in V1 and since the last patchset, from the link above:
- Instead of letting driver core handling the device to power domain
binding/unbinding, follow the behavior of how the ACPI power domain
is handled.
This is a summary of what these patches are intended to do:
1)
Add generic power domain OF-based support which also includes APIs to handle
attach/detach of generic power domains to devices.
2)
Adding a common API to attach/detach power domains and include support for the
ACPI and the generic power domain in there.
3)
From subsystem level code, at probe/remove, convert from invoking the ACPI
specific power domain attach/detach functions to the new common attach/detach
APIs.
4)
Add support for the AMBA bus to attach/detach power domains, using the new
common APIs.
5)
Convert Exynos to use the new generic power domain OF support.
Obviously, there are dependencies througout this patchset, which means if they
get accepted the all need to go together. It might also be convenient to share
them through an immutable branch.
Tomasz Figa (2):
PM / Domains: Add generic OF-based PM domain look-up
ARM: exynos: Move to generic PM domain DT bindings
Ulf Hansson (7):
ACPI / PM: Let acpi_dev_pm_detach() return an error code
PM / Domains: Add APIs to attach/detach a PM domain for a device
drivercore / platform: Convert to dev_pm_domain_attach|detach()
i2c: core: Convert to dev_pm_domain_attach|detach()
mmc: sdio: Convert to dev_pm_domain_attach|detach()
spi: core: Convert to dev_pm_domain_attach|detach()
amba: Add support for attach/detach of PM domains
.../bindings/arm/exynos/power_domain.txt | 13 +-
.../devicetree/bindings/power/power_domain.txt | 49 ++++
arch/arm/mach-exynos/pm_domains.c | 78 +-----
drivers/acpi/device_pm.c | 8 +-
drivers/amba/bus.c | 10 +-
drivers/base/platform.c | 15 +-
drivers/base/power/common.c | 60 +++++
drivers/base/power/domain.c | 291 +++++++++++++++++++++
drivers/i2c/i2c-core.c | 13 +-
drivers/mmc/core/sdio_bus.c | 4 +-
drivers/spi/spi.c | 12 +-
include/linux/acpi.h | 7 +-
include/linux/pm.h | 14 +
include/linux/pm_domain.h | 57 ++++
kernel/power/Kconfig | 4 +
15 files changed, 528 insertions(+), 107 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
--
1.9.1
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Pavel Machek <redacted>
Reviewed-by: Kevin Hilman <redacted>
---
drivers/acpi/device_pm.c | 8 +++++++-
include/linux/acpi.h | 7 +++++--
2 files changed, 12 insertions(+), 3 deletions(-)
From: Tomasz Figa <redacted>
This patch introduces generic code to perform PM domain look-up using
device tree and automatically bind devices to their PM domains.
Generic device tree bindings are introduced to specify PM domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific PM domain bindings
is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code.
This will change as soon as the Exynos PM domain code gets converted to
use the generic framework in further patch.
This patch was originally submitted by Tomasz Figa when he was employed
by Samsung.
http://marc.info/?l=linux-pm&m=139955349702152&w=2
Signed-off-by: Ulf Hansson <redacted>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Kevin Hilman <redacted>
---
.../devicetree/bindings/power/power_domain.txt | 49 ++++
drivers/base/power/domain.c | 291 +++++++++++++++++++++
include/linux/pm_domain.h | 57 ++++
kernel/power/Kconfig | 4 +
4 files changed, 401 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,49 @@+* Generic PM domains++System on chip designs are often divided into multiple PM domains that can be+used for power gating of selected IP blocks for power saving by reduced leakage+current.++This device tree binding can be used to bind PM domain consumer devices with+their PM domains provided by PM domain providers. A PM domain provider can be+represented by any node in the device tree and can provide one or more PM+domains. A consumer node can refer to the provider by a phandle and a set of+phandle arguments (so called PM domain specifiers) of length specified by the+#power-domain-cells property in the PM domain provider node.++==PM domain providers==++Required properties:+ - #power-domain-cells : Number of cells in a PM domain specifier;+ Typically 0 for nodes representing a single PM domain and 1 for nodes+ providing multiple PM domains (e.g. power controllers), but can be any value+ as specified by device tree binding documentation of particular provider.++Example:++ power: power-controller at 12340000 {+ compatible = "foo,power-controller";+ reg = <0x12340000 0x1000>;+ #power-domain-cells = <1>;+ };++The node above defines a power controller that is a PM domain provider and+expects one cell as its phandle argument.++==PM domain consumers==++Required properties:+ - power-domains : A phandle and PM domain specifier as defined by bindings of+ the power controller specified by phandle.++Example:++ leaky-device at 12350000 {+ compatible = "foo,i-leak-current";+ reg = <0x12350000 0x1000>;+ power-domains = <&power 0>;+ };++The node above defines a typical PM domain consumer device, which is located+inside a PM domain with index 0 of a power controller represented by a node+with the label "power".
@@ -1933,3 +1934,293 @@ void pm_genpd_init(struct generic_pm_domain *genpd,list_add(&genpd->gpd_list_node,&gpd_list);mutex_unlock(&gpd_list_lock);}++#ifdef CONFIG_PM_GENERIC_DOMAINS_OF+/*+*DeviceTreebasedPMdomainproviders.+*+*ThecodebelowimplementsgenericdevicetreebasedPMdomainprovidersthat+*binddevicetreenodeswithgenericPMdomainsregisteredinthesystem.+*+*AnydriverthatregistersgenericPMdomainsandneedstosupportbindingof+*devicestothesedomainsissupposedtoregisteraPMdomainprovider,which+*mapsaPMdomainspecifierretrievedfromthedevicetreetoaPMdomain.+*+*Twosimplemappingfunctionshavebeenprovidedforconvenience:+*-__of_genpd_xlate_simple()for1:1devicetreenodetoPMdomainmapping.+*-__of_genpd_xlate_onecell()formappingofmultiplePMdomainspernodeby+*index.+*/++/**+*structof_genpd_provider-PMdomainproviderregistrationstructure+*@link:EntryingloballistofPMdomainproviders+*@node:PointertodevicetreenodeofPMdomainprovider+*@xlate:Provider-specificxlatecallbackmappingasetofspecifiercells+*intoaPMdomain.+*@data:contextpointertobepassedinto@xlatecallback+*/+structof_genpd_provider{+structlist_headlink;+structdevice_node*node;+genpd_xlate_txlate;+void*data;+};++/* List of registered PM domain providers. */+staticLIST_HEAD(of_genpd_providers);+/* Mutex to protect the list above. */+staticDEFINE_MUTEX(of_genpd_mutex);++/**+*__of_genpd_xlate_simple()-Xlatefunctionfordirectnode-domainmapping+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgeneric_pm_domain+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelPMdomainsthat+*havetheirowndevicetreenodes.Theprivatedataofxlatefunctionneeds+*tobeavalidpointertostructgeneric_pm_domain.+*/+structgeneric_pm_domain*__of_genpd_xlate_simple(+structof_phandle_args*genpdspec,+void*data)+{+if(genpdspec->args_count!=0)+returnERR_PTR(-EINVAL);+returndata;+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_simple);++/**+*__of_genpd_xlate_onecell()-Xlatefunctionusingasingleindex.+*@genpdspec:OFphandleargstomapintoaPMdomain+*@data:xlatefunctionprivatedata-pointertostructgenpd_onecell_data+*+*ThisisagenericxlatefunctionthatcanbeusedtomodelsimplePMdomain+*controllersthathaveonedevicetreenodeandprovidemultiplePMdomains.+*AsinglecellisusedasanindexintoanarrayofPMdomainsspecifiedin+*thegenpd_onecell_datastructwhenregisteringtheprovider.+*/+structgeneric_pm_domain*__of_genpd_xlate_onecell(+structof_phandle_args*genpdspec,+void*data)+{+structgenpd_onecell_data*genpd_data=data;+unsignedintidx=genpdspec->args[0];++if(genpdspec->args_count!=1)+returnERR_PTR(-EINVAL);++if(idx>=genpd_data->num_domains){+pr_err("%s: invalid domain index %u\n",__func__,idx);+returnERR_PTR(-EINVAL);+}++if(!genpd_data->domains[idx])+returnERR_PTR(-ENOENT);++returngenpd_data->domains[idx];+}+EXPORT_SYMBOL_GPL(__of_genpd_xlate_onecell);++/**+*__of_genpd_add_provider()-RegisteraPMdomainproviderforanode+*@np:DevicenodepointerassociatedwiththePMdomainprovider.+*@xlate:CallbackfordecodingPMdomainfromphandlearguments.+*@data:Contextpointerfor@xlatecallback.+*/+int__of_genpd_add_provider(structdevice_node*np,genpd_xlate_txlate,+void*data)+{+structof_genpd_provider*cp;++cp=kzalloc(sizeof(*cp),GFP_KERNEL);+if(!cp)+return-ENOMEM;++cp->node=of_node_get(np);+cp->data=data;+cp->xlate=xlate;++mutex_lock(&of_genpd_mutex);+list_add(&cp->link,&of_genpd_providers);+mutex_unlock(&of_genpd_mutex);+pr_debug("Added domain provider from %s\n",np->full_name);++return0;+}+EXPORT_SYMBOL_GPL(__of_genpd_add_provider);++/**+*of_genpd_del_provider()-RemoveapreviouslyregisteredPMdomainprovider+*@np:DevicenodepointerassociatedwiththePMdomainprovider+*/+voidof_genpd_del_provider(structdevice_node*np)+{+structof_genpd_provider*cp;++mutex_lock(&of_genpd_mutex);+list_for_each_entry(cp,&of_genpd_providers,link){+if(cp->node==np){+list_del(&cp->link);+of_node_put(cp->node);+kfree(cp);+break;+}+}+mutex_unlock(&of_genpd_mutex);+}+EXPORT_SYMBOL_GPL(of_genpd_del_provider);++/**+*of_genpd_get_from_provider()-Look-upPMdomain+*@genpdspec:OFphandleargstouseforlook-up+*+*LooksforaPMdomainproviderunderthenodespecifiedby@genpdspecandif+*found,usesxlatefunctionoftheprovidertomapphandleargstoaPM+*domain.+*+*Returnsavalidpointertostructgeneric_pm_domainonsuccessorERR_PTR()+*onfailure.+*/+staticstructgeneric_pm_domain*of_genpd_get_from_provider(+structof_phandle_args*genpdspec)+{+structgeneric_pm_domain*genpd=ERR_PTR(-ENOENT);+structof_genpd_provider*provider;++mutex_lock(&of_genpd_mutex);++/* Check if we have such a provider in our array */+list_for_each_entry(provider,&of_genpd_providers,link){+if(provider->node==genpdspec->np)+genpd=provider->xlate(genpdspec,provider->data);+if(!IS_ERR(genpd))+break;+}++mutex_unlock(&of_genpd_mutex);++returngenpd;+}++/**+*genpd_dev_pm_attach-AttachadevicetoitsPMdomainusingDT.+*@dev:Devicetoattach.+*+*Parsedevice'sOFnodetofindaPMdomainspecifier.Ifsuchisfound,+*attachesthedevicetoretrievedpm_domainops.+*+*BothgenericandlegacySamsung-specificDTbindingsaresupportedtokeep+*backwardscompatibilitywithexistingDTBs.+*+*Returns0onsuccessfullyattachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_attach(structdevice*dev)+{+structof_phandle_argspd_args;+structgeneric_pm_domain*pd;+intret;++if(!dev->of_node)+return-ENODEV;++if(dev->pm_domain)+return-EEXIST;++ret=of_parse_phandle_with_args(dev->of_node,"power-domains",+"#power-domain-cells",0,&pd_args);+if(ret<0){+if(ret!=-ENOENT)+returnret;++/*+*TrylegacySamsung-specificbindings+*(forbackwardscompatibilityofDTABI)+*/+pd_args.args_count=0;+pd_args.np=of_parse_phandle(dev->of_node,+"samsung,power-domain",0);+if(!pd_args.np)+return-ENOENT;+}++pd=of_genpd_get_from_provider(&pd_args);+if(IS_ERR(pd)){+dev_dbg(dev,"%s() failed to find PM domain: %ld\n",+__func__,PTR_ERR(pd));+of_node_put(dev->of_node);+returnPTR_ERR(pd);+}++dev_dbg(dev,"adding to PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_add_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to add to PM domain %s: %d",+pd->name,ret);+of_node_put(dev->of_node);+returnret;+}++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);++/**+*genpd_dev_pm_detach-DetachadevicefromitsPMdomain.+*@dev:Devicetoattach.+*+*TrytolocateacorrespondinggenericPMdomain,whichthedevicewas+*attachedtopreviously.Ifsuchisfound,thedeviceisdetachedfromit.+*+*Returns0onsuccessfullydetachedPMdomainornegativeerrorcode.+*/+intgenpd_dev_pm_detach(structdevice*dev)+{+structgeneric_pm_domain*pd=NULL,*gpd;+intret=0;++if(!dev->pm_domain)+return-ENODEV;++mutex_lock(&gpd_list_lock);+list_for_each_entry(gpd,&gpd_list,gpd_list_node){+if(&gpd->domain==dev->pm_domain){+pd=gpd;+break;+}+}+mutex_unlock(&gpd_list_lock);++if(!pd)+return-ENOENT;++dev_dbg(dev,"removing from PM domain %s\n",pd->name);++while(1){+ret=pm_genpd_remove_device(pd,dev);+if(ret!=-EAGAIN)+break;+cond_resched();+}++if(ret<0){+dev_err(dev,"failed to remove from PM domain %s: %d",+pd->name,ret);+returnret;+}++/* Check if PM domain can be powered off after removing this device. */+genpd_queue_power_off_work(pd);++return0;+}+EXPORT_SYMBOL_GPL(genpd_dev_pm_detach);+#endif
To maintain scalability let's add common methods to attach and detach
a PM domain for a device, dev_pm_domain_attach|detach().
Typically dev_pm_domain_attach() shall be invoked from subsystem level
code at the probe phase to try to attach a device to its PM domain.
The reversed actions may be done a the remove phase and then by invoking
dev_pm_domain_detach().
The supported PM domains at this point are the ACPI and the generic
PM domains.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Kevin Hilman <redacted>
---
drivers/base/power/common.c | 60 +++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm.h | 14 +++++++++++
2 files changed, 74 insertions(+)
Previously only the ACPI PM domain was supported by the platform bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Kevin Hilman <redacted>
---
drivers/base/platform.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Previously only the ACPI PM domain was supported by the i2c bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Cc: linux-i2c at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
Reviewed-by: Kevin Hilman <redacted>
---
drivers/i2c/i2c-core.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
Previously only the ACPI PM domain was supported by the sdio bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Cc: linux-mmc at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
Reviewed-by: Kevin Hilman <redacted>
---
drivers/mmc/core/sdio_bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Previously only the ACPI PM domain was supported by the spi bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Cc: linux-spi at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
Reviewed-by: Kevin Hilman <redacted>
---
drivers/spi/spi.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
AMBA devices may on some SoCs resides in PM domains. To be able to
manage these devices from there, let's try to attach devices to their
corresponding PM domain during the probe phase.
To reverse these actions at the remove phase, we try to detach the
device from its PM domain.
Signed-off-by: Ulf Hansson <redacted>
Reviewed-by: Kevin Hilman <redacted>
---
drivers/amba/bus.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
From: Tomasz Figa <redacted>
This patch moves Exynos PM domain code to use the new generic PM domain
look-up framework introduced in previous patches, thus also allowing
the new code to be compiled with CONFIG_ARCH_EXYNOS.
This patch was originally submitted by Tomasz Figa when he was employed
by Samsung.
http://marc.info/?l=linux-pm&m=139955336002083&w=2
Cc: linux-samsung-soc at vger.kernel.org
Signed-off-by: Ulf Hansson <redacted>
Reviewed-by: Kevin Hilman <redacted>
---
.../bindings/arm/exynos/power_domain.txt | 13 ++--
arch/arm/mach-exynos/pm_domains.c | 78 +---------------------
kernel/power/Kconfig | 2 +-
3 files changed, 8 insertions(+), 85 deletions(-)
@@ -8,6 +8,8 @@ Required Properties: * samsung,exynos4210-pd - for exynos4210 type power domain. - reg: physical base address of the controller and length of memory mapped region.+- #power-domain-cells: number of cells in power domain specifier;+ must be 0. Optional Properties: - clocks: List of clock handles. The parent clocks of the input clocks to the
@@ -105,78 +105,6 @@ static int exynos_pd_power_off(struct generic_pm_domain *domain)returnexynos_pd_power(domain,false);}-staticvoidexynos_add_device_to_domain(structexynos_pm_domain*pd,-structdevice*dev)-{-intret;--dev_dbg(dev,"adding to power domain %s\n",pd->pd.name);--while(1){-ret=pm_genpd_add_device(&pd->pd,dev);-if(ret!=-EAGAIN)-break;-cond_resched();-}--pm_genpd_dev_need_restore(dev,true);-}--staticvoidexynos_remove_device_from_domain(structdevice*dev)-{-structgeneric_pm_domain*genpd=dev_to_genpd(dev);-intret;--dev_dbg(dev,"removing from power domain %s\n",genpd->name);--while(1){-ret=pm_genpd_remove_device(genpd,dev);-if(ret!=-EAGAIN)-break;-cond_resched();-}-}--staticvoidexynos_read_domain_from_dt(structdevice*dev)-{-structplatform_device*pd_pdev;-structexynos_pm_domain*pd;-structdevice_node*node;--node=of_parse_phandle(dev->of_node,"samsung,power-domain",0);-if(!node)-return;-pd_pdev=of_find_device_by_node(node);-if(!pd_pdev)-return;-pd=platform_get_drvdata(pd_pdev);-exynos_add_device_to_domain(pd,dev);-}--staticintexynos_pm_notifier_call(structnotifier_block*nb,-unsignedlongevent,void*data)-{-structdevice*dev=data;--switch(event){-caseBUS_NOTIFY_BIND_DRIVER:-if(dev->of_node)-exynos_read_domain_from_dt(dev);--break;--caseBUS_NOTIFY_UNBOUND_DRIVER:-exynos_remove_device_from_domain(dev);--break;-}-returnNOTIFY_DONE;-}--staticstructnotifier_blockplatform_nb={-.notifier_call=exynos_pm_notifier_call,-};-static__initintexynos4_pm_init_power_domain(void){structplatform_device*pdev;
@@ -202,7 +130,6 @@ static __init int exynos4_pm_init_power_domain(void)pd->base=of_iomap(np,0);pd->pd.power_off=exynos_pd_power_off;pd->pd.power_on=exynos_pd_power_on;-pd->pd.of_node=np;pd->oscclk=clk_get(dev,"oscclk");if(IS_ERR(pd->oscclk))
@@ -228,15 +155,12 @@ static __init int exynos4_pm_init_power_domain(void)clk_put(pd->oscclk);no_clk:-platform_set_drvdata(pdev,pd);-on=__raw_readl(pd->base+0x4)&INT_LOCAL_PWR_EN;pm_genpd_init(&pd->pd,NULL,!on);+of_genpd_add_provider_simple(np,&pd->pd);}-bus_register_notifier(&platform_bus_type,&platform_nb);-return0;}arch_initcall(exynos4_pm_init_power_domain);
From: Tomasz Figa <hidden> Date: 2014-09-09 11:43:10
Hi Ulf,
On 09.09.2014 13:36, Ulf Hansson wrote:
Changes in v4:
- Rebased patch "PM / Domains: Add generic OF-based PM domain look-up" -
and updated the author and the commit message.
- Adopted review comments for "PM / Domains: Add APIs to attach/detach
a PM domain for a device".
- Updated author and commit message for "ARM: exynos: Move to generic
PM domain DT bindings".
- Added some acks and reviewed by tags.
- Started to use the "--in-reply-to" option to git-send-email. It should
provide the option to show a better diffstat per patch.
I guess this series doesn't need more tags, but, anyway, it looks good
to me. Thanks a lot for taking care of it.
Best regards,
Tomasz
From: Mark Brown <broonie@kernel.org> Date: 2014-09-09 11:54:46
On Tue, Sep 09, 2014 at 01:36:01PM +0200, Ulf Hansson wrote:
Changes in v4:
- Rebased patch "PM / Domains: Add generic OF-based PM domain look-up" -
and updated the author and the commit message.
- Adopted review comments for "PM / Domains: Add APIs to attach/detach
a PM domain for a device".
- Updated author and commit message for "ARM: exynos: Move to generic
PM domain DT bindings".
- Added some acks and reviewed by tags.
- Started to use the "--in-reply-to" option to git-send-email. It should
provide the option to show a better diffstat per patch.
Please don't send serieses in reply to earlier versions, it buries
things in the middle of old discussions which can mean they don't get
noticed, especially when you're sending multiple large patch serieses at
the same time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140909/9406e4fc/attachment.sig>
On 9 September 2014 13:54, Mark Brown [off-list ref] wrote:
On Tue, Sep 09, 2014 at 01:36:01PM +0200, Ulf Hansson wrote:
quoted
Changes in v4:
- Rebased patch "PM / Domains: Add generic OF-based PM domain look-up" -
and updated the author and the commit message.
- Adopted review comments for "PM / Domains: Add APIs to attach/detach
a PM domain for a device".
- Updated author and commit message for "ARM: exynos: Move to generic
PM domain DT bindings".
- Added some acks and reviewed by tags.
- Started to use the "--in-reply-to" option to git-send-email. It should
provide the option to show a better diffstat per patch.
Please don't send serieses in reply to earlier versions, it buries
things in the middle of old discussions which can mean they don't get
noticed, especially when you're sending multiple large patch serieses at
the same time.
Sorry, I just thought that it simplified life in this particular case. :-)
If additional versions needs to be posted I will follow your advise. Thanks!
Kind regards
Uffe
From: Rafael J. Wysocki <hidden> Date: 2014-09-09 13:46:28
On Tuesday, September 09, 2014 01:36:05 PM Ulf Hansson wrote:
Previously only the ACPI PM domain was supported by the platform bus.
Let's convert to the common attach/detach functions for PM domains,
which currently means we are extending the support to include the
generic PM domain as well.
Signed-off-by: Ulf Hansson <redacted>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Kevin Hilman <redacted>
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
Thanks.
--
Dmitry
From: Rafael J. Wysocki <hidden> Date: 2014-09-14 16:38:58
On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
quoted
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
This is specifically for what patch [3/9] is doing AFAICS.
The existing callers don't need to worry about this.
Rafael
On Sun, Sep 14, 2014 at 06:38:58PM +0200, Rafael J. Wysocki wrote:
On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
quoted
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
quoted
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
This is specifically for what patch [3/9] is doing AFAICS.
The existing callers don't need to worry about this.
OK, so I have the very same comment about patch 3 then: we have
dev_pm_domain_detach() returning error. How would the callers handle errors?
WRT this patch: I'd rater we did not just return generic "error code" just
because we do not know who manages PD for the device. Can we add API to check
if we are using ACPI to manage power domains? Then patch #3 could check if it
needs to use ACPI or generic power domain API.
Thanks.
--
Dmitry
From: Rafael J. Wysocki <hidden> Date: 2014-09-15 23:36:15
On Monday, September 15, 2014 09:53:59 AM Dmitry Torokhov wrote:
On Sun, Sep 14, 2014 at 06:38:58PM +0200, Rafael J. Wysocki wrote:
quoted
On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
quoted
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
quoted
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
This is specifically for what patch [3/9] is doing AFAICS.
The existing callers don't need to worry about this.
OK, so I have the very same comment about patch 3 then: we have
dev_pm_domain_detach() returning error. How would the callers handle errors?
Ulf?
WRT this patch: I'd rater we did not just return generic "error code" just
because we do not know who manages PD for the device. Can we add API to check
if we are using ACPI to manage power domains? Then patch #3 could check if it
needs to use ACPI or generic power domain API.
The rule is that if there is an ACPI companion object for the given device, then
ACPI is used. So the API is ACPI_COMPANION(dev) and we have that check around
until someone realized that acpi_dev_pm_attach/detach() made it too. We can
restore it, I suppose, but I'm not sure how much better it is going to be.
Either way, I have no strong preferences here.
Rafael
On 16 September 2014 01:36, Rafael J. Wysocki [off-list ref] wrote:
On Monday, September 15, 2014 09:53:59 AM Dmitry Torokhov wrote:
quoted
On Sun, Sep 14, 2014 at 06:38:58PM +0200, Rafael J. Wysocki wrote:
quoted
On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
quoted
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
quoted
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
The benefit is only relevant when ACPI and genpd PM domains would
co-exist. In that case we might be able to skip genpd_dev_pm_detach()
if acpi_dev_pm_detach() succeeds. So, currently there are no benefit,
but still it doesn't hurt.
quoted
quoted
This is specifically for what patch [3/9] is doing AFAICS.
The existing callers don't need to worry about this.
OK, so I have the very same comment about patch 3 then: we have
dev_pm_domain_detach() returning error. How would the callers handle errors?
Ulf?
I see your point. How about making dev_pm_domain_detach() to be a void
function instead?
quoted
WRT this patch: I'd rater we did not just return generic "error code" just
because we do not know who manages PD for the device. Can we add API to check
if we are using ACPI to manage power domains? Then patch #3 could check if it
needs to use ACPI or generic power domain API.
The problem is scalability. If we have other PM domains implementation
in future, each of them need to be checked prior invoking the attach
functions.
Also, how would we distinguish between genpd and a new PM domain XYZ?
Kind regards
Uffe
The rule is that if there is an ACPI companion object for the given device, then
ACPI is used. So the API is ACPI_COMPANION(dev) and we have that check around
until someone realized that acpi_dev_pm_attach/detach() made it too. We can
restore it, I suppose, but I'm not sure how much better it is going to be.
Either way, I have no strong preferences here.
Rafael
On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
On 16 September 2014 01:36, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Monday, September 15, 2014 09:53:59 AM Dmitry Torokhov wrote:
quoted
On Sun, Sep 14, 2014 at 06:38:58PM +0200, Rafael J. Wysocki wrote:
quoted
On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
quoted
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
quoted
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
The benefit is only relevant when ACPI and genpd PM domains would
co-exist. In that case we might be able to skip genpd_dev_pm_detach()
if acpi_dev_pm_detach() succeeds. So, currently there are no benefit,
but still it doesn't hurt.
It doe snot have any negative material effect, the drawback is purely
from API perspective.
quoted
quoted
quoted
This is specifically for what patch [3/9] is doing AFAICS.
The existing callers don't need to worry about this.
OK, so I have the very same comment about patch 3 then: we have
dev_pm_domain_detach() returning error. How would the callers handle errors?
Ulf?
I see your point. How about making dev_pm_domain_detach() to be a void
function instead?
Yes, please.
quoted
quoted
WRT this patch: I'd rater we did not just return generic "error code" just
because we do not know who manages PD for the device. Can we add API to check
if we are using ACPI to manage power domains? Then patch #3 could check if it
needs to use ACPI or generic power domain API.
The problem is scalability. If we have other PM domains implementation
in future, each of them need to be checked prior invoking the attach
functions.
Also, how would we distinguish between genpd and a new PM domain XYZ?
I do not think that trying all available methods to detach a pm domain,
i.e.
err = acpi_dev_pm_detach();
if (err)
err = blah_dev_pm_detach();
if (err)
err = flab_dev_pm_detach();
if (err)
err = gen_dev_pm_detach();
is any better from scalability point of view. If you need to do that you
will probably have to store something like "struct pd_ops *pd_ops" in
your device and call appropriate implementation via it.
Thanks.
--
Dmitry
On 17 September 2014 22:10, Dmitry Torokhov [off-list ref] wrote:
On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
quoted
On 16 September 2014 01:36, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Monday, September 15, 2014 09:53:59 AM Dmitry Torokhov wrote:
quoted
On Sun, Sep 14, 2014 at 06:38:58PM +0200, Rafael J. Wysocki wrote:
quoted
On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
quoted
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
quoted
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
The benefit is only relevant when ACPI and genpd PM domains would
co-exist. In that case we might be able to skip genpd_dev_pm_detach()
if acpi_dev_pm_detach() succeeds. So, currently there are no benefit,
but still it doesn't hurt.
It doe snot have any negative material effect, the drawback is purely
from API perspective.
quoted
quoted
quoted
quoted
This is specifically for what patch [3/9] is doing AFAICS.
The existing callers don't need to worry about this.
OK, so I have the very same comment about patch 3 then: we have
dev_pm_domain_detach() returning error. How would the callers handle errors?
Ulf?
I see your point. How about making dev_pm_domain_detach() to be a void
function instead?
Yes, please.
OK!
quoted
quoted
quoted
WRT this patch: I'd rater we did not just return generic "error code" just
because we do not know who manages PD for the device. Can we add API to check
if we are using ACPI to manage power domains? Then patch #3 could check if it
needs to use ACPI or generic power domain API.
The problem is scalability. If we have other PM domains implementation
in future, each of them need to be checked prior invoking the attach
functions.
Also, how would we distinguish between genpd and a new PM domain XYZ?
I do not think that trying all available methods to detach a pm domain,
i.e.
err = acpi_dev_pm_detach();
if (err)
err = blah_dev_pm_detach();
if (err)
err = flab_dev_pm_detach();
if (err)
err = gen_dev_pm_detach();
is any better from scalability point of view. If you need to do that you
will probably have to store something like "struct pd_ops *pd_ops" in
your device and call appropriate implementation via it.
No, that's not needed. Go ahead and have look at both ACPI and genpd,
the interesting part is the validation of struct dev_pm_domain pointer
in the struct device. That's all there is to it, no additional data
are required.
Kind regards
Uffe
On Thu, Sep 18, 2014 at 01:20:49AM +0200, Ulf Hansson wrote:
On 17 September 2014 22:10, Dmitry Torokhov [off-list ref] wrote:
quoted
On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
quoted
On 16 September 2014 01:36, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Monday, September 15, 2014 09:53:59 AM Dmitry Torokhov wrote:
quoted
On Sun, Sep 14, 2014 at 06:38:58PM +0200, Rafael J. Wysocki wrote:
quoted
On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
quoted
Hi Ulf,
On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
quoted
To give callers the option of acting on a errors while removing the
pm_domain ops for the device in the ACPI PM domain, let
acpi_dev_pm_detach() return an int to provide the error code.
So how would callers handle the errors? As far as I can see
acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
there is no meaningful strategy to handle errors as you are past the point of
no return and you keep on tearing down the device.
The benefit is only relevant when ACPI and genpd PM domains would
co-exist. In that case we might be able to skip genpd_dev_pm_detach()
if acpi_dev_pm_detach() succeeds. So, currently there are no benefit,
but still it doesn't hurt.
It doe snot have any negative material effect, the drawback is purely
from API perspective.
quoted
quoted
quoted
quoted
This is specifically for what patch [3/9] is doing AFAICS.
The existing callers don't need to worry about this.
OK, so I have the very same comment about patch 3 then: we have
dev_pm_domain_detach() returning error. How would the callers handle errors?
Ulf?
I see your point. How about making dev_pm_domain_detach() to be a void
function instead?
Yes, please.
OK!
quoted
quoted
quoted
quoted
WRT this patch: I'd rater we did not just return generic "error code" just
because we do not know who manages PD for the device. Can we add API to check
if we are using ACPI to manage power domains? Then patch #3 could check if it
needs to use ACPI or generic power domain API.
The problem is scalability. If we have other PM domains implementation
in future, each of them need to be checked prior invoking the attach
functions.
Also, how would we distinguish between genpd and a new PM domain XYZ?
I do not think that trying all available methods to detach a pm domain,
i.e.
err = acpi_dev_pm_detach();
if (err)
err = blah_dev_pm_detach();
if (err)
err = flab_dev_pm_detach();
if (err)
err = gen_dev_pm_detach();
is any better from scalability point of view. If you need to do that you
will probably have to store something like "struct pd_ops *pd_ops" in
your device and call appropriate implementation via it.
No, that's not needed. Go ahead and have look at both ACPI and genpd,
the interesting part is the validation of struct dev_pm_domain pointer
in the struct device. That's all there is to it, no additional data
are required.
OK, so can you simply put the needed method into struct dev_pm_domain and then
dev_pm_domain_detach() would become:
void dev_pm_domain_detach(struct device *dev, bool power_off)
{
if (dev->pm_domain)
dev->pm_domain->detach(dev, power_off);
}
Thanks.
--
Dmitry