From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Wed, 17 Oct 2012 17:41:54 -0700 Subject: [U-Boot] [PATCH v3 13/18] lcd: Add support for flushing LCD fb from dcache after update In-Reply-To: References: <1342106718-3058-1-git-send-email-sjg@chromium.org> <1342106718-3058-14-git-send-email-sjg@chromium.org> <20120809094315.79012bd2@amdc308.digital.local> <20121017123829.278b8758@amdc308.digital.local> <507ED014.1030204@boundarydevices.com> Message-ID: <507F5052.7000106@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > wrote: >> On 10/17/2012 03:38 AM, Lukasz Majewski wrote: >>> >>> >>> >>>> 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