gpu: pvr: add support for dynamic timing of SGX HW power down
This is needed by the next patch, which actually enables the support.
Currently the driver implements an aggressive power management policy
and powers down the HW very shortly (1 ms) after each completed command.
The resulting power-down and -up sequence between commands are relatively
long (~250usec), causing a delayed command execution and unnecessary CPU
load.
There is a deadline at the end of each display Vsync period, by which
all commands for the next frame must be completed. If the deadline is
missed FPS goes down. To increase the chance that we meet the deadline
we want to cut down on the above overhead.
One way to reduce the overhead is to get rid of the power-down/up
sequences between commands. The downside is the possibly higher power
consumption, so a solution has to minimize this side effect. Simply
increasing the power-down delay would result in a constant power
consumption increase. To see this let's consider the following two
cases given a 16 ms Vsync period.
Case a:
1. SGX command#1 for frame#N - 3 ms
2. SGX idle - 3 ms
3. SGX command#2 for frame#N - 3 ms
4. SGX idle - 3 ms
5. SGX command#3 for frame#N - 3 ms
6. SGX idle - 1 ms
7. Vsync
8. SGX command#1 for frame#N+1 - 3 ms
9. SGX idle - 3 ms
10. SGX command#2 for frame#N+1 - 3 ms
11. SGX idle - 3 ms
12. SGX command#3 for frame#N+1 - 3 ms
13. SGX idle - 1 ms
14. Vsync
... same pattern repeating for several frames
Here we need to increase the power-down delay to 4 ms, to avoid the
overhead at 2.,4.,9.,11. and to increase the chance to meet the deadlines
at 7. and 14.
Case b:
1. SGX command#1 for frame#N - 1 ms
2. SGX idle - 1 ms
3. SGX command#2 for frame#N - 1 ms
4. SGX idle - 1 ms
5. SGX command#3 for frame#N - 1 ms
6. SGX idle - 11 ms
7. Vsync
8. SGX command#1 for frame#N+1 - 1 ms
9. SGX idle - 1 ms
10. SGX command#2 for frame#N+1 - 1 ms
11. SGX idle - 1 ms
12. SGX command#3 for frame#N+1 - 1 ms
13. SGX idle - 11 ms
14. Vsync
... same pattern repeating for several frames
Here we don't have a risk of missing the deadlines, so we could
power-down immediately after 5. and 12. but we will delay the power-down
by 4 ms due to the constraint in case a. This energy waste will be
incured in each of the following frames having a similar command
scheduling pattern.
The solution in the following patch minimizes the energy waste while
achieving the original goal, by tracking "command bursts". In a burst
command execution periods are separated by idle periods of less than a
fixed amount of time (3 ms). Power-down is avoided between commands
within one burst, but it's performed immediately after the last command
of the burst. For example all commands in case a constitute one burst,
so we won't have any power-down there. In case b we have two bursts:
first burst consisting of 1.,3.,5. second burst consisting of 8.,10.,12.,
so we will power down immediately after 5. and 12.
In cases where commands are interleaved (well behaving applications)
we'll see power consumption decreasing due to the immediate power down
vs. the current 1ms delay. For other cases we might see a slight
increase in power consumption due to not powering down between commands,
but these are the very cases where we have a risk of not meeting the frame
deadlines, so the compromise looks like justified.
Signed-off-by: Imre Deak <imre.deak@nokia.com>
Reviewed-by: Luc Verhaegen <Luc.Verhaegen@basyskom.de>