Acceleration for map_copy_from on powerpc 512x

Hi,
I'm working on a powerpc (PPC512x) embedded Linux product, and while I 
was trying to improve boot time, I found I could exploit the hw in order 
to speed up reading from NOR flashes.
The Linux/mtd version we're using is 2.6.24.6+Freescale patches.
Basically, I needed to hack the map_copy_from, which for my arch and 
uncached areas translates to a memcpy, in order to use the SCLPC FIFO, 
with a performance benefit of >2x on aligned multiple of 32Bytes transfers.

I didn't find a cleaner way than just #ifdef'ing the map_copy_from call 
and substitute with my call on relevant cases. I wonder if there is a 
cleaner way.

And yes, as soon as I've cleaned up the code a little bit, I will 
definitely post a patch about it.

Moreover: a huge benefit would come from exploiting DMA on these 
transfers, but I found I'm in_atomic while doing map_copy_from... is 
there an alternative way of locking than just disabling preemption?
I know maybe a newer kernel has already fixed it, but we're kind of 
stuck with the old one since we don't have time to port all of our 
device drivers to 2.6.3x

Thanks,
Matteo

On Mon, 2009-10-19 at 09:52 +0200, Fortini Matteo wrote:

I didn't find a cleaner way than just #ifdef'ing the map_copy_from call 
and substitute with my call on relevant cases. I wonder if there is a 
cleaner way.

Remove the call to simple_map_init() and do it manually in your driver
with your own functions.

And yes, as soon as I've cleaned up the code a little bit, I will 
definitely post a patch about it.

Moreover: a huge benefit would come from exploiting DMA on these 
transfers, 

probably depends on the block size if it's a gain or not. What is the
size you normally see. 

The simple_map_init() works at a higher level, what I'm redefining is a 
function called by mtd->read()

The block size for e.g. a dd if=/dev/mtd0 of=/dev/null
with the default block size (I believe it's 512Bytes), fetches from 
/dev/mtd0 4096 Bytes at a time.
I'd prefer the kernel to be scheduling other tasks meanwhile, instead of 
busy-waiting on completion.

Regards

Kenneth Johansson ha scritto:

On Mon, 2009-10-19 at 09:52 +0200, Fortini Matteo wrote:

  

quoted

I didn't find a cleaner way than just #ifdef'ing the map_copy_from call 
and substitute with my call on relevant cases. I wonder if there is a 
cleaner way.
    

Remove the call to simple_map_init() and do it manually in your driver
with your own functions.

  

quoted

And yes, as soon as I've cleaned up the code a little bit, I will 
definitely post a patch about it.

Moreover: a huge benefit would come from exploiting DMA on these 
transfers, 
    

probably depends on the block size if it's a gain or not. What is the
size you normally see. 


  

On Tue, 2009-10-27 at 11:02 +0100, Fortini Matteo wrote:

The simple_map_init() works at a higher level, what I'm redefining is a 
function called by mtd->read()

not sure I follow. What you want to do is change the access to the
flash. You do this by turning on MTD_COMPLEX_MAPPINGS and then setting
up the function pointers like is done in simple_map_init() but point to
your own functions. Now every access to the NOR flash will be done using
your functions and you can do whatever optimization you like.

The block size for e.g. a dd if=/dev/mtd0 of=/dev/null
with the default block size (I believe it's 512Bytes), fetches from 
/dev/mtd0 4096 Bytes at a time.
I'd prefer the kernel to be scheduling other tasks meanwhile, instead of 
busy-waiting on completion.

Regards

Kenneth Johansson ha scritto:

quoted

On Mon, 2009-10-19 at 09:52 +0200, Fortini Matteo wrote:

  

quoted

I didn't find a cleaner way than just #ifdef'ing the map_copy_from call 
and substitute with my call on relevant cases. I wonder if there is a 
cleaner way.
    

Remove the call to simple_map_init() and do it manually in your driver
with your own functions.

  

quoted

And yes, as soon as I've cleaned up the code a little bit, I will 
definitely post a patch about it.

Moreover: a huge benefit would come from exploiting DMA on these 
transfers, 
    

probably depends on the block size if it's a gain or not. What is the
size you normally see.