[U-Boot] [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only)

[Hans de Goede]

Hi,

On 22-01-15 08:30, Siarhei Siamashka wrote:
> On Tue, 20 Jan 2015 14:16:35 +0100
> Hans de Goede <hdegoede at 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 at gmail.com> wrote:
>>>
>>>> On Sun, 04 Jan 2015 20:49:38 +0100
>>>> Hans de Goede <hdegoede at 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 at 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 at 60Hz framebuffer scanout).

I agree that fixing this does not have a high priority.

Regards,

Hans