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

[Michal Suchanek]

Hello,

On 22 January 2015 at 14:26, Hans de Goede <hdegoede at 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 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.

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