[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150424132923.GA11729@amd>
Date: Fri, 24 Apr 2015 15:29:23 +0200
From: Pavel Machek <pavel@....cz>
To: Archit Taneja <architt@...eaurora.org>
Cc: Tomi Valkeinen <tomi.valkeinen@...com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Marek Vasut <marek.vasut@...il.com>,
kernel list <linux-kernel@...r.kernel.org>,
Dinh Nguyen <dinh.linux@...il.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
Grant Likely <grant.likely@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Jingoo Han <jg1.han@...sung.com>,
Rob Clark <robdclark@...il.com>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
shc_work@...l.ru, linux@....linux.org.uk,
hsweeten@...ionengravers.com
Subject: Re: simple framebuffer slower by factor of 20, on socfpga (arm)
platform
Hi!
On Fri 2015-04-10 12:35:52, Archit Taneja wrote:
> >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...
>
> I didn't test for performance regressions when I posted this patch.
>
> A look at _memcpy_fromio in arch/arm/kernel/io.c shows that readb() is used
> all the time, even when the source and destination addresses are aligned for
> larger reads to be possible. Other archs seem to use readl() or readq() when
> they can. Maybe that makes memcpy_fromio slower than the implementation of
> memcpy on arm?
Ok, can you prepare a patch for me to try? Or should we just revert
the original commit?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists