public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Andre Puschmann <andre.puschmann@imms.de>
To: linux-mtd@lists.infradead.org
Cc: linux-mtd@lists.infradead.org
Subject: Re: flash read performance
Date: Mon, 03 Nov 2008 15:23:41 +0100	[thread overview]
Message-ID: <490F096D.5060208@imms.de> (raw)
In-Reply-To: <49098716.1010404@thomson.net>

Hi,

I spent some more time on this issue and investigated some mtd-maps
drivers.
The kernel I am using is a 2.6.21 that comes out of the gumstix 
svn-repo. Unfortunately, it uses a legacy driver which only does a
ioremap() but no ioremap_nocache(). Patching the driver with this
additional call boosts up transfers up to around 5.5MB/s, which
is a fairly improvement.
I will send a patch to the gumstix list. Users of newer kernel might
not need this, as they use a newer driver (pxa2xx-flash.c) anyway.

But I am wondering if things still can go faster?!
Jamie, do you some information about the speed I can expect 
theoretically? Or do I have to switch over to another operation
mode (i.e. async) for higher speeds?

Thanks in advance.

Best regards,
Andre



Arnaud Mouiche schrieb:
> I was using redboot, configured to use the optimized memcpy (yes, it 
> gives the choice at configuration time)
> on kernel side, I just hack memcpy_fromio to add a "weak" attribute, and 
> rewrite it to directly use the linux optimized memcpy (shame on me for 
> this "not suggested" methode, but speed was my goal)
> 
> after that, performances are equal between bootloader and linux, and 
> really near the one reached by a DMA access, which is also the 
> performances we can calculate from FLASH time access configuration.
> 
> arnaud
> 
> Andre Puschmann a écrit :
>> Hi,
>>
>>   
>>> I was faced with the same wondering in the past : bootloader NOR access 
>>> was really much faster that Linux one.
>>>     
>> About how much faster? It really depends on the access method. I am
>> using u-boot and if I use the basic cp.b routine its about the same
>> _slow_ speed. I tried to use the asm-optimised memcpy routine that the 
>> kernel has. This is much faster, around 5MB/s.
>>
>>   
>>> Yes, no DMA was used (but the same on bootloader, and anyway that 
>>> doesn't impact the data rate, only the CPU load), but even worse, Linux 
>>> code was using memcpy_fromio which a basic byte by byte loop copy in the 
>>> default ARM implementation.
>>>     
>> Yes, memcpy_fromio is quite slow. But using normal memcpy is not 
>> suggested, only use writel()/readl() and memcpy_[from|to]io().
>>
>> I am not sure about the right _fast_ way to to such copies.
>>
>>
>> Regards,
>> Andre
>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>>   
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

  reply	other threads:[~2008-11-03 14:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 10:14 flash read performance Andre Puschmann
2008-10-29 11:42 ` Josh Boyer
2008-10-29 12:03   ` Jamie Lokier
2008-10-29 15:52   ` Andre Puschmann
2008-10-30  8:33     ` Arnaud Mouiche
2008-10-30  9:52       ` Andre Puschmann
2008-10-30 10:06         ` Arnaud Mouiche
2008-11-03 14:23           ` Andre Puschmann [this message]
2008-11-04  8:30             ` Andre Puschmann
2008-11-04 11:42             ` Jamie Lokier
2008-11-04 14:31               ` Andre Puschman
2008-11-07  2:41                 ` Trent Piepho
2008-11-07  4:02                   ` Jamie Lokier
2008-11-07  5:36                     ` Trent Piepho
2008-11-07  5:57                       ` Jamie Lokier
2008-11-07  9:47                   ` Andre Puschmann
2008-11-08  5:28                     ` Trent Piepho
2008-11-11 13:28                       ` Andre Puschmann
2008-11-15  2:02                         ` Trent Piepho

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=490F096D.5060208@imms.de \
    --to=andre.puschmann@imms.de \
    --cc=linux-mtd@lists.infradead.org \
    /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