linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
	Russell King <rmk@arm.linux.org.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Archit Taneja <architt@codeaurora.org>,
	Marek Vasut <marek.vasut@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Dinh Nguyen <dinh.linux@gmail.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Jingoo Han <jg1.han@samsung.com>, Rob Clark <robdclark@gmail.com>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Alexander Shiyan <shc_work@mail.ru>,
	Russell King <linux@arm.linux.org.uk>,
	H Hartley Sweeten <hsweeten@visionengravers.com>
Subject: Re: simple framebuffer slower by factor of 20, on socfpga (arm) platform
Date: Sun, 26 Apr 2015 19:31:46 +0000	[thread overview]
Message-ID: <20150426193146.GA4539@amd> (raw)
In-Reply-To: <CAMuHMdV+-VcZD5TMswUjwW0fk=-76oYimeKJ_P9QC5Md4De-JA@mail.gmail.com>

On Fri 2015-04-24 15:46:56, Geert Uytterhoeven wrote:
> On Fri, Apr 24, 2015 at 3:40 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 24/04/15 16:29, Pavel Machek wrote:
> >> 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?
> >
> > The old way worked fine, afaik, so maybe we can revert. But still, isn't
> > it more correct to use memcpy_fromio? It's (possibly) io memory we have
> > here.
> 
> Yes it is.
> 
> So please optimize ARM's _memcpy_fromio(), _memcpy_toio(), and _memset_io().
> That will benefit other drivers on ARM, too.

No, sorry. Yes, I could "optimize" memcpy_toio... just by sticking
memcpy there, as for example asm-generic/io.h suggests.

Maybe it would break something. Maybe not, but potential for that
clearly is there... since this is very seldom used function. Or do you
know drivers that would benefit from this?

void _memcpy_toio(volatile void __iomem *to, const void *from, size_t count)
{
        const unsigned char *f = from;
	while (count) {
	      count--;
	      writeb(*f, to);
	      f++;
	      to++;
 	}
}

We have a regression, we have a patch that causes the
regression. Right fix at this point is to revert a "cleanup" that
causes this, not try to "optimize" otherwise unused piece of code.

commit 981409b25e2a99409b26daa67293ca1cfd5ea0a0
Author: Archit Taneja <archit@ti.com>
Date:   Fri Nov 16 14:46:04 2012 +0530

    fbdev: arm has __raw I/O accessors, use them in fb.h

    This removes the sparse warnings on arm platforms:

    warning: cast removes address space of expression

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: H Hartley Sweeten <hsweeten at visionengravers.com>
Cc: Alexander Shiyan <shc_work@mail.ru>
Cc: Russell King <linux@arm.linux.org.uk>

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2015-04-26 19:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-07 12:12 simple framebuffer slower by factor of 20, on socfpga (arm) platform Pavel Machek
2015-04-07 12:19 ` Geert Uytterhoeven
2015-04-07 14:24   ` Marek Vasut
2015-04-09 11:06   ` Pavel Machek
2015-04-09 11:21     ` Tomi Valkeinen
2015-04-09 11:34       ` Tomi Valkeinen
     [not found]         ` <552663C2.70308-l0cyMroinI0@public.gmane.org>
2015-04-09 19:51           ` Arnd Bergmann
2015-04-24 13:31             ` Pavel Machek
2015-04-10  7:17         ` Archit Taneja
2015-04-24 13:29           ` Pavel Machek
2015-04-24 13:40             ` Tomi Valkeinen
2015-04-24 13:46               ` Geert Uytterhoeven
2015-04-26 19:31                 ` Pavel Machek [this message]
2015-04-28 13:48                 ` Russell King - ARM Linux
     [not found]                   ` <20150428134848.GC12732-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-04-28 15:28                     ` Nicolas Pitre
2015-05-06 10:45                       ` Russell King - ARM Linux
2015-05-06 20:32                         ` Nicolas Pitre
2015-05-12  8:52                         ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150426193146.GA4539@amd \
    --to=pavel@ucw.cz \
    --cc=architt@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dinh.linux@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=grant.likely@linaro.org \
    --cc=hsweeten@visionengravers.com \
    --cc=jg1.han@samsung.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marek.vasut@gmail.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=rmk@arm.linux.org.uk \
    --cc=robdclark@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=shc_work@mail.ru \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).