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

[Bjorn Andersson]

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
drivers.

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.

Regards,
Bjorn