[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 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.

Regards,


Eric