Messages in this thread | | | From | Brian Norris <> | Date | Fri, 8 Apr 2022 20:34:59 -0700 | Subject | Re: [RFC PATCH 1/2] soc: rockchip: power-domain: Manage resource conflicts with firmware |
| |
Hi Chanwoo,
On Wed, Apr 6, 2022 at 9:38 PM Chanwoo Choi <cw00.choi@samsung.com> wrote: > Instead of adding the specific function for only rockchip, > how about adding new function pointer (like block/unblock or start/stop and others) > into 'struct generic_pm_domain'? And add new pm_genpd_* function > to control the power domain.
I suppose that is technically possible, but I'm not sure it makes a ton of sense.
First, genpd doesn't seem to typically expose operations directly to client device drivers. It's mostly about abstract handling of the dependencies of "how do I power on this device?" behind the scenes of things like pm_runtime_*(). I guess maybe something like dev_pm_genpd_set_performance_state() is an approximately similar API though (i.e., a genpd operation exposed to client drivers)? I could try to go that route, if the genpd maintainers think this makes sense.
But secondly, this isn't exactly an operation on one power domain. It's an operation on the entire power controller. I suppose I could make a new domain here for the memory controller, and teach that domain to implicitly manipulate all the other domains provided by the PMU, but that feels like a fake abstraction to me.
Lastly, and perhaps least importantly: this likely would require a device tree binding change. So far, the memory controller hasn't had its own power domain. I guess one could argue that it has some similarities to a power domain, albeit one that is managed in firmware -- so maybe this is a reasonable "bug" to fix, if it really comes down to it.
> Because it is better to use subsystem interface.
I don't agree this is universally true. It makes sense when there are truly abstract concepts represented, which are likely to appear across multiple implementations. Or maybe if the object model is complex. But this operation seems very SoC-specific to me, and it's pretty simple to implement this way. Or, do you think this is really something that others will need -- pausing (and powering) a power controller so another entity can manage it?
I guess I'd also like some thoughts from the genpd maintainers (CC'd), of whether this seems like a good fit for a new genpd callback and API.
Brian
| |