Hi Eric, On Wed, Oct 17, 2012 at 5:41 PM, Eric Nelson <eric.nel...@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.nel...@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. Regards, Simon > > Regards, > > > Eric _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
