On 27-01-21, 22:01, Akhil P Oommen wrote:
> On 1/22/2021 10:15 AM, Viresh Kumar wrote:
> > On 22-01-21, 00:41, Dmitry Osipenko wrote:
> > > 21.01.2021 14:17, Viresh Kumar пишет:
> > > > @@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev,
> > > > unsigned long target_freq)
> > > >
On 1/22/2021 10:15 AM, Viresh Kumar wrote:
On 22-01-21, 00:41, Dmitry Osipenko wrote:
21.01.2021 14:17, Viresh Kumar пишет:
@@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned
long target_freq)
if (!ret) {
ret = _set_opp_bw(opp_table, opp, dev, f
On 22-01-21, 17:31, Dmitry Osipenko wrote:
> This may not be true for all kinds of hardware, a display controller is
> one example. If display's pixclock is raised before the memory bandwidth
> of the display's memory client, then display controller may get a memory
> underflow since it won't be ab
22.01.2021 07:45, Viresh Kumar пишет:
> On 22-01-21, 00:41, Dmitry Osipenko wrote:
>> 21.01.2021 14:17, Viresh Kumar пишет:
>>> @@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev,
>>> unsigned long target_freq)
>>>
>>> if (!ret) {
>>> ret = _set_opp_bw(opp_table,
On 22-01-21, 00:41, Dmitry Osipenko wrote:
> 21.01.2021 14:17, Viresh Kumar пишет:
> > @@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev,
> > unsigned long target_freq)
> >
> > if (!ret) {
> > ret = _set_opp_bw(opp_table, opp, dev, false);
> > - if (!re
21.01.2021 14:17, Viresh Kumar пишет:
> @@ -1074,15 +1091,18 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned
> long target_freq)
>
> if (!ret) {
> ret = _set_opp_bw(opp_table, opp, dev, false);
> - if (!ret)
> + if (!ret) {
>
The dev_pm_opp_set_rate() helper needs to know the currently programmed
OPP to make few decisions and currently we try to find it on every
invocation of this routine.
Lets start keeping track of the current_opp programmed for the devices
of the opp table, that will be quite useful going forward.
7 matches
Mail list logo