Re: [U-Boot] [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)
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 ?
Regards,
Hans
Signed-off-by: Michal Suchanek hramrach@gmail.com
arch/arm/cpu/armv7/sunxi/dram_sun4i.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c index ec8aaa7..e20cd2b 100644 --- a/arch/arm/cpu/armv7/sunxi/dram_sun4i.c +++ b/arch/arm/cpu/armv7/sunxi/dram_sun4i.c @@ -207,7 +207,7 @@ static u32 hpcr_value[32] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
- 0x1031, 0x1031, 0x0735, 0x1035,
- 0x1031, 0x1031, 0x0735, 0x1037, 0x1035, 0x0731, 0x1031, 0, 0x0301, 0x0301, 0x0301, 0x0301, 0x0301, 0x0301, 0x0301, 0
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
On 19 January 2015 at 05:29, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
The result is that with full HD HDMI output lima-memtester cube jumps without the patch and does not jump with the patch. I have only 1 A10s board.
Thanks
Michal
Hi,
On 19-01-15 10:06, Michal Suchanek wrote:
On 19 January 2015 at 05:29, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
The result is that with full HD HDMI output lima-memtester cube jumps without the patch and does not jump with the patch. I have only 1 A10s board.
Since you're running lima-memtester, I assume you're using a sunxi-3.4 kernel, correct?
Looking at the patch you're not modifying DEBE DRAM priority, but rather DEFE priority.
Can you check the fex file and see what fb0_scaler_mode_enable is set too ?
If it is not enabled, it is weird that this fix helps, if it is enabled, then this fix shouldn't be necessary, but maybe things are different on sun5i vs sun4i.
Regardless can you try with fb0_scaler_mode_enable inverted from what it is now, it would be good to know if it has any impact on sun5i.
Regards,
Hans
Hi,
On 19-01-15 10:16, Hans de Goede wrote:
Hi,
On 19-01-15 10:06, Michal Suchanek wrote:
On 19 January 2015 at 05:29, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
The result is that with full HD HDMI output lima-memtester cube jumps without the patch and does not jump with the patch. I have only 1 A10s board.
Since you're running lima-memtester, I assume you're using a sunxi-3.4 kernel, correct?
Looking at the patch you're not modifying DEBE DRAM priority, but rather DEFE priority.
Can you check the fex file and see what fb0_scaler_mode_enable is set too ?
If it is not enabled, it is weird that this fix helps, if it is enabled, then this fix shouldn't be necessary, but maybe things are different on sun5i vs sun4i.
Regardless can you try with fb0_scaler_mode_enable inverted from what it is now, it would be good to know if it has any impact on sun5i.
Also instead of changing the priority to 0x1037, can you try changing it to 0x5031, this is what sun4i uses after Siarhei's fixes, and perhaps it is the right value to use for DEFE everywhere in general.
Thanks & Regards,
Hans
On 19 January 2015 at 10:29, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 19-01-15 10:16, Hans de Goede wrote:
Hi,
On 19-01-15 10:06, Michal Suchanek wrote:
On 19 January 2015 at 05:29, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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 nota13).
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.
The result is that with full HD HDMI output lima-memtester cube jumps without the patch and does not jump with the patch. I have only 1 A10s board.
Since you're running lima-memtester, I assume you're using a sunxi-3.4 kernel, correct?
Looking at the patch you're not modifying DEBE DRAM priority, but rather DEFE priority.
Can you check the fex file and see what fb0_scaler_mode_enable is set too ?
If it is not enabled, it is weird that this fix helps, if it is enabled, then this fix shouldn't be necessary, but maybe things are different on sun5i vs sun4i.
Regardless can you try with fb0_scaler_mode_enable inverted from what it is now, it would be good to know if it has any impact on sun5i.
Also instead of changing the priority to 0x1037, can you try changing it to 0x5031, this is what sun4i uses after Siarhei's fixes, and perhaps it is the right value to use for DEFE everywhere in general.
That did not work for me.
Thanks
Michal
On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
But enough about A20.
As Hans already mentioned, the submitted A10s patch is tweaking the DEFE host port settings (not DEBE, contrary to what the summary says). Michal, could you please run a few more tests and check whether there is any observable difference between DEBE and DEFE on A10s (fb0_scaler_mode_enable=0 vs. fb0_scaler_mode_enable=1 in fex)? If they behave in the same way and the magic 'reserved' bit fixes both of them, then IMHO the patch should just tweak both. Thanks for working on this!
Hi,
On 20-01-15 09:16, Siarhei Siamashka wrote:
On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
Regards,
Hans
On Tue, 20 Jan 2015 14:16:35 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 20-01-15 09:16, Siarhei Siamashka wrote:
On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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?
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.
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. 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).
Hi,
On 22-01-15 08:30, Siarhei Siamashka wrote:
On Tue, 20 Jan 2015 14:16:35 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 20-01-15 09:16, Siarhei Siamashka wrote:
On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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
Hello,
On 22 January 2015 at 14:26, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 22-01-15 08:30, Siarhei Siamashka wrote:
On Tue, 20 Jan 2015 14:16:35 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 20-01-15 09:16, Siarhei Siamashka wrote:
On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
I need to re-test this but it seemed that on my a10s board enabling and disabling scaler had pretty much no impact on display performance. Increasing the priority of the display ports did not seem to increase display performance either. However, setting the 'magic' bit degraded memory throughput as reported by the lima-memspeed somewhat but enabled jump-free lima-memtester rotating cube. Since a13 has no hdmi this is moot for most sun5i hardware.
Affected would be the obsolete olinuxinos and a few HDMI sticks that actually had a10s in them.
Thanks
Michal
Hi,
On 22-01-15 15:43, Michal Suchanek wrote:
Hello,
On 22 January 2015 at 14:26, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 22-01-15 08:30, Siarhei Siamashka wrote:
On Tue, 20 Jan 2015 14:16:35 +0100 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 20-01-15 09:16, Siarhei Siamashka wrote:
On Mon, 19 Jan 2015 06:29:47 +0200 Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 04 Jan 2015 20:49:38 +0100 Hans de Goede hdegoede@redhat.com 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.
I need to re-test this but it seemed that on my a10s board enabling and disabling scaler had pretty much no impact on display performance. Increasing the priority of the display ports did not seem to increase display performance either. However, setting the 'magic' bit degraded memory throughput as reported by the lima-memspeed somewhat but enabled jump-free lima-memtester rotating cube. Since a13 has no hdmi this is moot for most sun5i hardware.
Affected would be the obsolete olinuxinos and a few HDMI sticks that actually had a10s in them.
There are actually a lot of a10s using HDMI sticks out there (all later mk802 models use the a10s + many others) as well as various a10s based top setboxes and an a10s variant of the mini-x. So I would really like to get this fixed, I'm ok with applying your fix, but before that I would like to see the following confirmed:
1) That currently you are using the scaler, since your patch modifies the scaler dram prio anything else would make no sense
2) Please retest without the scalar, and if you've the same problem try applying the same fix / DRAM settings to the DEBE dram prio bits. See http://ssvb.github.io/2014/11/11/revisiting-fullhd-x11-desktop-performance-o... for a list of which dram prio config word is what.
Thanks,
Hans
participants (3)
-
Hans de Goede -
Michal Suchanek -
Siarhei Siamashka