On 10/17/2024 9:12 PM, Brian Masney wrote:
> On Thu, Oct 17, 2024 at 02:58:31PM +0530, Jagadeesh Kona wrote:
>> + cpu0_opp_table: opp-table-cpu0 {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + cpu0_opp_1267mhz: opp-1267200000 {
>> + opp-hz = /bits/ 64 <1267200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>> +
>> + cpu0_opp_1363mhz: opp-1363200000 {
>> + opp-hz = /bits/ 64 <1363200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>
> [snip]
>
>> + cpu4_opp_table: opp-table-cpu4 {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + cpu4_opp_1267mhz: opp-1267200000 {
>> + opp-hz = /bits/ 64 <1267200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>> +
>> + cpu4_opp_1363mhz: opp-1363200000 {
>> + opp-hz = /bits/ 64 <1363200000>;
>> + opp-peak-kBps = <6220800 29491200>;
>> + };
>
> There's no functional differences in the cpu0 and cpu4 opp tables. Can
> a single table be used?
>
> This aligns with my recollection that this particular SoC only has the
> gold cores.
>
> Brian
>
Thanks Brian for your review. Sorry for the delayed response.
We require separate OPP tables for CPU0 and CPU4 to allow independent
scaling of DDR and L3 frequencies for each CPU domain, with the final
DDR and L3 frequencies being an aggregate of both.
If we use a single OPP table for both CPU domains, then _allocate_opp_table() [1]
won't be invoked for CPU4. As a result both CPU devices will end up in sharing
the same ICC path handle, which could lead to one CPU device overwriting the bandwidth
votes of other.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/opp/core.c#n1588
Thanks,
Jagadeesh
