On 6/11/2019 4:24 PM, Viresh Kumar wrote:
On 20-03-19, 15:19, Rajendra Nayak wrote:
From: Stephen Boyd <swb...@chromium.org>
Doing this allows us to call this API with any rate requested and have
it not need to match in the OPP table. Instead, we'll round the rate up
to the nearest OPP that we see so that we can get the voltage or level
that's required for that OPP. This supports users of OPP that want to
specify the 'fmax' tables of a device instead of every single frequency
that they need. And for devices that required the exact frequency, we
can rely on the clk framework to round the rate to the nearest supported
frequency instead of the OPP framework to do so.
Note that this may affect drivers that don't want the clk framework to
do rounding, but instead want the OPP table to do the rounding for them.
Do we have that case? Should we add some flag to the OPP table to
indicate this and then not have that flag set when there isn't an OPP
table for the device and also introduce a property like 'opp-use-clk' to
tell the table that it should use the clk APIs to round rates instead of
OPP?
Signed-off-by: Stephen Boyd <swb...@chromium.org>
Signed-off-by: Rajendra Nayak <rna...@codeaurora.org>
---
[]...
I see a logical problem with this patch.
Suppose the clock driver supports following frequencies: 500M, 800M,
1G, 1.2G and the OPP table contains following list: 500M, 1G, 1.2G
(i.e. missing 800M).
Now 800M should never get programmed as it isn't part of the OPP
table. But if you pass 600M to opp-set-rate, then it will end up
selecting 800M as clock driver will round up to the closest value.
correct
Even if no one is doing this right now, it is a sensible usecase,
specially during testing of patches and I don't think we should avoid
it.
What exactly is the use case for which we need this patch ?
Like the changelog says 'This supports users of OPP that want to
specify the 'fmax' tables of a device instead of every single frequency
that they need'
so the 'fmax' tables basically say what the max frequency the device can
operate at for a given performance state/voltage level.
so in your example it would be for instance
500M, Perf state = 2
1G, Perf state = 3
1.2G, Perf state = 4
Now when the device wants to operate at say 800Mhz, you need to set the
Perf state to 3, so this patch basically avoids you having to put those
additional
OPPs in the table which would otherwise look something like this
500M, Perf state = 2
800M, Perf state = 3 <-- redundant OPP
1G, Perf state = 3
1.2G, Perf state = 4
Your example had just 1 missing entry in the 'fmax' tables in reality its a lot
more,
atleast on all qualcomm platforms.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
