Re: [linuxsh-dev] Strange behavior when accessing mmap'd framebuffer

[David M. <Dav...@st...>]

On Jul 4, 10:10pm, m-...@aa... wrote:
> Subject: [linuxsh-dev] Strange behavior when accessing mmap'd framebuffer
>
> Hello all,
>
> Today I would like to get comments/suggestions on my problem, if you
> have. I'll really appreciate any info you would provide.
>
> I'm running custom SH4 machine with LCD controller (Epson s1d13706) with
> monochrome LCD, using it as framebuffer device. It can be accessed as
> /dev/fb0 now.
> When I access mmap'd framebuffer memory area from user program (by
> memcpy, for example), sometimes it takes very long time to complete.
> Writing (unsigned char)0x00 to the area sometimes took more than 700
> microseconds. Usually it takes just about 10 microseconds.
>

We have seen exactly this behaviour. It is caused by the TLB handler code
(Pre the latest patches). What happens is the dcache aliasing code kicks in,
causing all TLB entries to be scanned.

As a quick hack, what I did was change the code in update_mmu_cache() to
instead of

if(pte_shared(pte))

to if(pte_shared(pte) && pte_cacheable(pte))

Dcache aliasing can't happen if the memory is uncached.

Anyway, this provided a big performance increase for me.

We actually were going to rewrite the whole of the way the dcache aliasing was
done, but as usual Niibe beat us to it:-) That's another bug chunk of work gone
from our project plan!

The latest kernel should fix this problem I think, but I haven't tested it yet,
for framebuffer access, although it appears stable to me for other purposes.

Hope this helps!

-- 
Dave McKay 
Software Engineer STMicroelectronics
Email: dav...@st...