Thread (18 messages) 18 messages, 8 authors, 2015-05-12

Re: simple framebuffer slower by factor of 20, on socfpga (arm) platform

From: Tomi Valkeinen <hidden>
Date: 2015-04-09 11:35:09
Also in: linux-devicetree, lkml

On 09/04/15 14:21, Tomi Valkeinen wrote:
On 09/04/15 14:06, Pavel Machek wrote:
quoted
On Tue 2015-04-07 14:19:33, Geert Uytterhoeven wrote:
quoted
Hi Pavel,

On Tue, Apr 7, 2015 at 2:12 PM, Pavel Machek [off-list ref] wrote:
quoted
I have an socfpga board, which uses has simple framebuffer implemented
in the FPGA. On 3.15, framebuffer is fast:

root@wagabuibui:~# time cat /dev/fb0 > /dev/null
real               0m 0.00s
user               0m 0.00s
sys                0m 0.00s

on 3.18, this takes 220msec. Similar slowdown exists for
writes. Simple framebuffer did not change at all between 3.15 and
3.18; resource flags of the framebuffer are still same (0x200).

If I enable caching on 3.18, it speeds up a bit, to 70msec or
so... Which means problem is not only in caching.

Any ideas?
My first guess was  commit 67dc0d4758e5 ("vt_buffer: drop console buffer
copying optimisations"), but this was introduced only in v4.0-rc1.

Just in case you encounter another performance regression after upgrading
to a more modern kernel ;-)
:-). I did a git bisect, and it pointed to this. And reverting it
indeed fixes the problem in 3.18. Problem is still there in 4.0.
The difference is probably caused by memcpy() vs memcpy_fromio(). The
comment above memcpy_fromio() says "This needs to be optimized". I think
generally speaking memcpy_fromio() is correct for a framebuffer.

That said, if the fb is in RAM, and is only written by the CPU, I think
a normal memcpy() for fb_memcpy_fromfb() should be fine...

 Tomi

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help