Thread (29 messages) 29 messages, 3 authors, 2016-08-12
STALE3591d

Re: [RFC PATCH 1/8] PM / Domains: Add new helper functions for device-tree

From: Ulf Hansson <hidden>
Date: 2016-06-22 15:36:23
Also in: linux-arm-kernel, linux-tegra

On 22 June 2016 at 17:22, Jon Hunter [off-list ref] wrote:
On 22/06/16 16:08, Ulf Hansson wrote:
quoted
On 22 June 2016 at 16:58, Jon Hunter [off-list ref] wrote:
quoted
Hi Ulf,

On 04/03/16 11:23, Jon Hunter wrote:
quoted
Ideally, if we are returning a reference to a PM domain via a call to
of_genpd_get_from_provider(), then we should keep track of such
references via a reference count. The reference count could then be used
to determine if a PM domain can be safely removed. Alternatively, it is
possible to avoid such external references by providing APIs to access
the PM domain and hence, eliminate any calls to
of_genpd_get_from_provider().

Add new helper functions for adding a device and a subdomain to a PM
domain when using device-tree, so that external calls to
of_genpd_get_from_provider() can be removed.
While we are at it, does it make sense to add helpers for
of_genpd_remove_device/subdomain() as well? Seems that these could be
useful for doing the inverse when cleaning up.
I would prefer if we could avoid adding new APIs until we really see
the need for it.

Moreover, I would like to avoid us adding OF specific APIs, unless
those can be really justified.
Hope that made sense.
Yes makes sense. However, after this series, the
pm_genpd_remove_device/subdomain really become provider only APIs
because clients can no longer get access to the genpd struct. Although
today none of the users of the new of_genpd_add_device/subdomain do any
clean-up on failure, it is possible that someone may. Therefore, I was
thinking that we should have a way for a client to remove a subdomain or
device it has added.

Does that make sense? I guess we could always add those as needed.

I am looking at a use-case for usb where we are populating the
pm-domains at runtime and we may need to clean-up on failure. However, I
can always wait to add more APIs until we really need them.
You may very well be right that these will be needed.

How about posting those patches as separate change and on top of the
series. Then we can decide if we want to pick them now or later.
Let me know what you think about my response to patch 6/8.
I am on it.

Kind regards
Uffe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help