lkml.org 
[lkml]   [2020]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
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?

>
> Regards,
> Bjorn




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

\
 
 \ /
  Last update: 2020-09-10 09:25    [W:0.154 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site