Hi,
On 22-01-15 08:30, Siarhei Siamashka wrote:
On Tue, 20 Jan 2015 14:16:35 +0100
Hans de Goede <[email protected]> wrote:
Hi,
On 20-01-15 09:16, Siarhei Siamashka wrote:
On Mon, 19 Jan 2015 06:29:47 +0200
Siarhei Siamashka <[email protected]> wrote:
On Sun, 04 Jan 2015 20:49:38 +0100
Hans de Goede <[email protected]> wrote:
Hi,
On 04-01-15 20:19, Michal Suchanek wrote:
Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for
smooth HDMI scanout of large frambuffer (eg. 1080p).
This fix comes at the cost of some overall memory bandwidth so it
might be appropriate to detect a10s and only apply there (and not a13).
Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what
do you think of the proposed change ?
I don't have A10s hardware, so have no idea and can't test anything
myself.
It would be great to have a better description of what exactly is
happening before the patch. And precisely how the patch is helping.
A description of the test setup and benchmark numbers would be
appreciated. And it would be perfect if somebody else could reproduce
the test and confirm the results.
I may try to check A20 with the bus width artificially reduced
to 16 bits (not a totally unrealistic configuration, since
A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar
enough, then the magic reserved bit may have some effect there too.
But that's a different hardware either way.
Done these tests with A20. Ironically, now the tables have turned and
A10 seems to be doing a better job than A20 at low DRAM clock speeds
(~408MHz) and 16-bit bus width when dealing with full-hd monitors.
Just like Michal observed on A10s, setting 0x5031 as DEFE host port
config makes things much worse on A20. Overall, the test results look
in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes,
none of the real boards uses such a slow DRAM setup) while running
lima-memtester and driving 1920x1080-32@60Hz monitor:
0x1035 - The screen regularly blanks, but comes back again instantly.
0x1037 - The screen regularly blanks, but comes back again instantly.
0x5031 - Severe screen shaking.
Unlike A10, there does not seem to be any difference between using DEBE
or DEFE for framebuffer scanout on A20, so using DEBE has the same
effect as listed above. Setting the magic 'reserved' hpcr bit 1
(0x1037 value) does not seem to have any effect on sun7i. It is
great that it is apparently helping on sun5i/A10s though.
Thanks for running these tests, this makes me more confident that I
only need to enable DEFE in u-boot on A10, and can directly use
DEBE on the others.
But what about A10s? Do we want to do something about it?
Once we have some feedback from hramrach from running tests with /
without the frontend enabled, then yes, unless the fix is to simple
disable the frontend, and then u-boot probably is fine as is.
Regarding the 0x5031 settings. It just looks like sun7i (and sun5i?)
might have an upper cap for the 'CmdNum' bits (bits 15-8) and bumping
it to 0x50 or even 0xFF is not effective. If we instead reduce 'CmdNum'
for the CPU and GPU host ports to 1, then the screen glitches disappear
too.
What glitches exactly, you mean the scanout fifo engine underruns we've
been seeing on sun4i, or ? I thought that only hramrach was seeing
glitches on his A10s, and that you could not reproduce them on A20 ?
Also won't reducing the number of outstanding commands the CPU / GPU
can have significantly impact overall performance ?
Eventually I would like to also identify the source of occasional
monitor blinks on sun7i with full-hd monitors and slow DRAM settings
in order to apply some sort of a workaround.
Yes fixing that would be great.
Maybe it has something to
do with DRAM refresh settings, maybe it is something else. But for now
it can be left alone because the problem is not easily reproducible
on 'normal' workloads (it needs a special setup in which CPU & GPU
are torturing slow DRAM simultaneously, trying to disrupt the
1920x1080-32@60Hz framebuffer scanout).
I agree that fixing this does not have a high priority.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
