From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Thu, 22 Jan 2015 14:26:34 +0100 Subject: [U-Boot] [linux-sunxi] [u-boot 2/2] sun5i: bump DEBE priority (useful on a10s only) In-Reply-To: <20150122093029.30b96ba7@i7> References: <4250c53f8df139084acfaad14a88819a600b9965.1420399561.git.hramrach@gmail.com> <54A99952.6080905@redhat.com> <20150119062947.3dac60c3@i7> <20150120101630.0ac3616e@i7> <54BE5533.4070402@redhat.com> <20150122093029.30b96ba7@i7> Message-ID: <54C0FA8A.8010405@redhat.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, On 22-01-15 08:30, Siarhei Siamashka wrote: > On Tue, 20 Jan 2015 14:16:35 +0100 > Hans de Goede wrote: > >> Hi, >> >> On 20-01-15 09:16, Siarhei Siamashka wrote: >>> On Mon, 19 Jan 2015 06:29:47 +0200 >>> Siarhei Siamashka wrote: >>> >>>> On Sun, 04 Jan 2015 20:49:38 +0100 >>>> Hans de Goede wrote: >>>> >>>>> Hi, >>>>> >>>>> On 04-01-15 20:19, Michal Suchanek wrote: >>>>>> Setting magic 'reserved' hpcr bit on sun5i DEBE seems required for >>>>>> smooth HDMI scanout of large frambuffer (eg. 1080p). >>>>>> >>>>>> This fix comes at the cost of some overall memory bandwidth so it >>>>>> might be appropriate to detect a10s and only apply there (and not a13). >>>>> >>>>> Hmm, Sairhei is the expert on this, adding him to the Cc. Sairhei, what >>>>> do you think of the proposed change ? >>>> >>>> I don't have A10s hardware, so have no idea and can't test anything >>>> myself. >>>> >>>> It would be great to have a better description of what exactly is >>>> happening before the patch. And precisely how the patch is helping. >>>> A description of the test setup and benchmark numbers would be >>>> appreciated. And it would be perfect if somebody else could reproduce >>>> the test and confirm the results. >>>> >>>> I may try to check A20 with the bus width artificially reduced >>>> to 16 bits (not a totally unrealistic configuration, since >>>> A20-OLinuXino-LIME board exists). If sun5i and sun7i are similar >>>> enough, then the magic reserved bit may have some effect there too. >>>> But that's a different hardware either way. >>> >>> Done these tests with A20. Ironically, now the tables have turned and >>> A10 seems to be doing a better job than A20 at low DRAM clock speeds >>> (~408MHz) and 16-bit bus width when dealing with full-hd monitors. >>> >>> Just like Michal observed on A10s, setting 0x5031 as DEFE host port >>> config makes things much worse on A20. Overall, the test results look >>> in the following way on A20 with 16-bit DRAM clocked at 408MHz (yes, >>> none of the real boards uses such a slow DRAM setup) while running >>> lima-memtester and driving 1920x1080-32 at 60Hz monitor: >>> >>> 0x1035 - The screen regularly blanks, but comes back again instantly. >>> 0x1037 - The screen regularly blanks, but comes back again instantly. >>> 0x5031 - Severe screen shaking. >>> >>> Unlike A10, there does not seem to be any difference between using DEBE >>> or DEFE for framebuffer scanout on A20, so using DEBE has the same >>> effect as listed above. Setting the magic 'reserved' hpcr bit 1 >>> (0x1037 value) does not seem to have any effect on sun7i. It is >>> great that it is apparently helping on sun5i/A10s though. >> >> Thanks for running these tests, this makes me more confident that I >> only need to enable DEFE in u-boot on A10, and can directly use >> DEBE on the others. > > But what about A10s? Do we want to do something about it? Once we have some feedback from hramrach from running tests with / without the frontend enabled, then yes, unless the fix is to simple disable the frontend, and then u-boot probably is fine as is. > Regarding the 0x5031 settings. It just looks like sun7i (and sun5i?) > might have an upper cap for the 'CmdNum' bits (bits 15-8) and bumping > it to 0x50 or even 0xFF is not effective. If we instead reduce 'CmdNum' > for the CPU and GPU host ports to 1, then the screen glitches disappear > too. What glitches exactly, you mean the scanout fifo engine underruns we've been seeing on sun4i, or ? I thought that only hramrach was seeing glitches on his A10s, and that you could not reproduce them on A20 ? Also won't reducing the number of outstanding commands the CPU / GPU can have significantly impact overall performance ? > Eventually I would like to also identify the source of occasional > monitor blinks on sun7i with full-hd monitors and slow DRAM settings > in order to apply some sort of a workaround. Yes fixing that would be great. > Maybe it has something to > do with DRAM refresh settings, maybe it is something else. But for now > it can be left alone because the problem is not easily reproducible > on 'normal' workloads (it needs a special setup in which CPU & GPU > are torturing slow DRAM simultaneously, trying to disrupt the > 1920x1080-32 at 60Hz framebuffer scanout). I agree that fixing this does not have a high priority. Regards, Hans