Re: [PATCH V6 1/9] PM / OPP: Introduce "power-domain-opp" property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 12 May 2017 at 20:29, Kevin Hilman <khilman@xxxxxxxxxxxx> wrote:
> Viresh Kumar <viresh.kumar@xxxxxxxxxx> writes:

>> Why should we do that?
>
> For starters, because the lack of it looks very strange upon first read
> (notice that both Rob and I pointed that out), and because you didn't
> explain why in the first place, it draws attention.

:)

>> I don't see why would we like to put some index value in the microvolts
>> property. We are setting the index value in the opp-hz property to avoid adding
>> extra fields and making sure opp-hz is still the unique property for the nodes.
>
> What about the case where firmware wants exact frequencies, and
> microvolts property is just an index?
>
> The point is, you have a very specific SoC and use-case in mind, but the
> goal of a binding change like this is to make something that could be
> generically useful.

I agree, but I am not sure of having such a case in very near future at least.
Wouldn't it be wise to not touch opp-microvolt for now and update it only
when needed? Its not a big change anyway..

>> Hmm, I am not sure how things are going to work in that case. The opp-hz value
>> read from the phandle is passed to the QoS framework in this series, which makes
>> sure that we select the highest requested performance point for a particular
>> power-domain. The index value is required to be present with the OPP framework
>> to make it all work, at least based on the way I have designed it for now.
>
> IMO, this kind of dependency isn't the job of the OPP framework, it's
> the job of the power-domain governor.

Okay. So the way it will work with the current suggestions is:

- OPP framework gets DVFS update request for device X
- OPP framework finds that the device has a power-domain and so it asks
  the power-domain framework to set the device in a particular state
  corresponding to the OPP (if we are going to a higher OPP).
- If the power-domain supports state selection, it does that or returns error.
  (Actually we can optimize this by asking the genpd initially if
state selection
   is possible, only then OPP core calls the genpd API).
- The genpd API will manage a list of all devices in the domain (which it
  already does) and also the states selected for them. It finds the max of
  the requested states and selects that.
- Note that the QoS framework isn't there in the picture anymore.

Will that be fine ?

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux