From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Wed, 17 Oct 2012 18:07:43 -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> <507F5052.7000106@boundarydevices.com> Message-ID: <507F565F.8050101@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 05:50 PM, Simon Glass wrote: > Hi Eric, > > On Wed, Oct 17, 2012 at 5:41 PM, Eric Nelson > 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 >>> 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. > > 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