On Thu 10 Sep 03:18 CDT 2020, Ulf Hansson wrote: > On Thu, 10 Sep 2020 at 09:23, Sibi Sankar <sibis@xxxxxxxxxxxxxx> wrote: > > > > 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 > > > 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. > > > > Bjorn/Stephen, > > > > So the consensus is to stop modelling > > aoss load_state as pds and expose qmp_send > > to drivers? > > Would that mean qmp_send would have to be called from generic drivers? > Then, please no. We want to keep drivers portable. > No, this is only called from Qualcomm specific drivers. So I'm okay with that approach. Regards, Bjorn
