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
Quoted 3 lines · Fortini Matteo
I didn't find a cleaner way than just #ifdef'ing the
map_copy_fromcall 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 5 lines
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:
Quoted 20 lines · Fortini Matteo
Quoted 4 lines
I didn't find a cleaner way than just #ifdef'ing the
map_copy_fromcall 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 4 lines
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.
Quoted 2 lines · Fortini Matteo
The
simple_map_init()works at a higher level, what I'm redefining is a function called bymtd->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.
Quoted 35 lines
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/mtd04096 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 24 lines · Fortini Matteo
Quoted 6 lines
I didn't find a cleaner way than just #ifdef'ing the
map_copy_fromcall 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 6 lines
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.