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

[Eric Nelson]

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.

Regards,


Eric