[U-Boot] [PATCH v3 13/18] lcd: Add support for flushing LCD fb from dcache after update

[Simon Glass]

Hi Eric,

On Wed, Oct 17, 2012 at 6:07 PM, Eric Nelson
<eric.nelson at boundarydevices.com> wrote:
> Hi Simon,
>
>
> On 10/17/2012 05:50 PM, Simon Glass wrote:
>>
>> Hi Eric,
>>
>> On Wed, Oct 17, 2012 at 5:41 PM, Eric Nelson
>> <eric.nelson at boundarydevices.com>  wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>> On 10/17/2012 03:07 PM, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Eric,
>>>>
>>>> On Wed, Oct 17, 2012 at 8:34 AM, Eric Nelson
>>>> <eric.nelson at boundarydevices.com>   wrote:
>>>>>
>>>>>
>>>>> On 10/17/2012 03:38 AM, Lukasz Majewski wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>
>>>>>>> Certainly we could make the flushing more fine grained. My reasons
>>>>>>> for
>>>>>>> not (so far) are:
>>>>>>>
>>>>>>> 1. It is simpler to flush everything (no need to figure out what part
>>>>>>> of display has changed)
>>>>>>> 2. The performance difference is likely to be small since flushing an
>>>>>>> already-flushed range should be fast.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>      From the sake of "SW engineering" I would opt for fine grained
>>>>>> flushing. But if it turns out, that it costs too much, we can flush
>>>>>> everything.
>>>>>>
>>>>>
>>>>> Is anybody else in a position to get some numbers about how/if
>>>>> performance is better when flushing at the more granular level?
>>>>>
>>>>> Before deciding it wasn't worth the code, I implemented granular
>>>>> flushing and didn't see any noticeable degradation when just
>>>>> flushing at the end of all public functions as in this patch.
>>>>>
>>>>>
>>>>> http://lists.denx.de/pipermail/u-boot/2012-September/134979.html
>>>>>
>>>>> It seems that performance is the only reason for fine-grained
>>>>> cache flush operations
>>>>
>>>>
>>>>
>>>> Also we might be talking about different things. I have taken the
>>>> approach of flushing the whole display, but only after some display
>>>> functions. We could flush only what has changed, which is what I was
>>>> referring to as 'fine-grained'. You may have meant the idea of
>>>> flushing after every function that touches the display, or a
>>>> 'fine-grained' approach of only flushing after some functions.
>>>>
>>>
>>> You're right. That's what I get for chiming in quickly before
>>> attending a customer meeting: I jump to conclusions.
>>>
>>> I thought 'finer-grained' referred to the way Anatolij originally
>>> did things:
>>>
>>>
>>> http://git.denx.de/?p=u-boot.git;a=commit;h=bfd4be803bbb7d122c2e3aaf6eaf987efa8d69da
>>>
>>> I tried to follow that lead, but it degenerated into a horrible
>>> mess of alignment checking.
>>>
>>>
>>>> My testing shows that flushing is pretty fast, but I was reluctant to
>>>> flush after every putc() as it seemed egregiously inefficient.
>>>>
>>>
>>> I need to spend some time with the patch to figure out how you
>>> get around cache issues for keystroke echo.
>>
>>
>> Well my less-than-lovely approach was to use puts() for all character
>> echo. That has a flush.
>>
>
> I just read through that and it makes perfect sense.
>
> I'm anxious to test this and your CONFIG_CONSOLE_SCROLL_LINES patch
> to see how it operates at 1080P.
>
> Without the CONFIG_CONSOLE_SCROLL_LINES patch, scrolling was incredibly
> slow.

Yes, it makes a big difference. Another option would be to enable the L2 cache.

Regards,
Simon

>
> Regards,
>
>
> Eric