Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags

From: Sibi Sankar
Date: Thu Sep 10 2020 - 03:23:32 EST

On 2020-08-25 23:23, Bjorn Andersson wrote:
On Tue 25 Aug 02:20 CDT 2020, Stephen Boyd wrote:
Quoting Bjorn Andersson (2020-08-24 09:42:12)
> On Fri 21 Aug 14:41 PDT 2020, Stephen Boyd wrote:
> > I find it odd that this is modeled as a power domain instead of some
> > Qualcomm specific message that the remoteproc driver sends to AOSS. Is
> > there some sort of benefit the driver gets from using the power domain
> > APIs for this vs. using a custom API?
> We need to send "up" and "down" notifications and this needs to happen
> at the same time as other standard resources are enabled/disabled.
> Further more, at the time the all resources handled by the downstream
> driver was either power-domains (per above understanding) or clocks, so
> it made sense to me not to spin up a custom API.

So the benefit is not spinning up a custom API? I'm not Ulf, but it
looks like this is hard to rationalize about as a power domain. It
doesn't have any benefit to model it this way besides to make it
possible to turn on with other power domains.

This modem remoteproc drivers isn't SoC agnostic anyway, it relies on
SMEM APIs, so standing up another small qmp_remoteproc_booted() and
qmp_remoteproc_shutdown() API would avoid adding a genpd flag here that
probably will never be used outside of this corner-case. There is also
some get/put EPROBE_DEFER sort of logic to implement, but otherwise it
would be possible to do this outside of power domains, and that seems
better given that this isn't really a power domain to start with.

In later platforms a few new users of the AOSS communication interface
is introduced that certainly doesn't fit any existing API/framework in
the kernel. So the plan was to pretty much expose qmp_send() to these

My worry with using this interface is that we'll probably have to come
up with some DT binding pieces and probably we'll end up adding yet
another piece of hard coded information in the remoteproc drivers.

But I'm not against us doing this work in favor of not having to
introduce a one-off for this corner case.


So the consensus is to stop modelling
aoss load_state as pds and expose qmp_send
to drivers?


Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.