Acceleration for map_copy_from on powerpc 512x

[Matteo Fortini-3]

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

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@...
https://lists.ozlabs.org/listinfo/linuxppc-dev

[kenneth johansson-4]

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.


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@...
https://lists.ozlabs.org/listinfo/linuxppc-dev

[Matteo Fortini-3]

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:
>
>  
>> 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.
>
>
>  

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@...
https://lists.ozlabs.org/listinfo/linuxppc-dev

[kenneth johansson-4]

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:
> > 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.
> >
> >
> >  
>
>

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@...
https://lists.ozlabs.org/listinfo/linuxppc-dev