On 28/01/2022 23:30, Bryan O'Donoghue wrote:
On 28/01/2022 23:23, Bryan O'Donoghue wrote:
On 28/01/2022 22:24, Dmitry Baryshkov wrote:
This would lead to higher frequencies being set on both 'normal' and
mm snoc clocks, thus (possibly) increasing power consumption.
How so ?
There are four clocks
bus
bus_a
bus_mm
bus_a_mm
The last two clocks
SNOC performance points are
0 | 19.2 | XO
1 | 50 | GPLL0
2 | 100 | GPLL0
3 | 133.3 | GPLL0
4 | 160 | GPLL0
5 | 200 | GPLL0
6 | 266.6 | GPLL0
SNOC_MM performance points are
0 | 19.2 | XO
1 | 50 | GPLL0
2 | 100 | GPLL0
3 | 133.3 | GPLL0
4 | 160 | GPLL0
5 | 200 | GPLL0
6 | 266.6 | GPLL0
7 | 320 | GPLL0
8 | 400 | GPLL0
Its GPLL0 being set, the snoc_mm clocks really just map back to GPLL0
So taking an example
If venus
interconnects = <&snoc_mm MASTER_VIDEO_P0 &bimc SLAVE_EBI_CH0>;
or mdp
interconnects = <&snoc_mm MASTER_MDP_PORT0 &bimc SLAVE_EBI_CH0>,
<&snoc_mm MASTER_MDP_PORT1 &bimc SLAVE_EBI_CH0>;
wants performance point #6 GPLL0 runs at 266.6 but for performance point
#7 it runs at 320 MHz
Since the points all map back to a GPLL0 frequency, how does aggregating
snoc and snoc_mm - result in higher power consumption ?
Anyway - thanks for the pointer to the virt clock.
I don't mind re-implementing the fix this way given there's an
established upstream canon.
---
bod
