Sharp SL Series NAND Driver

Sharp SL Series NAND Driver

[Richard Purdie]

As mentioned on IRC, I've ported the nand driver for the Sharp SL series to
the current kernel. This first patch adds the driver which supports all the
Zaurus models that use nand flash. (thanks for the pointers in trimming it
down! :)

http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl.patch

I also have some other patches I'd appreciate your views on. Two of these
should be straightforward. The third is more for comments.

http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-map.patch - maps a ROM on
the device (I think its used to access configuration information?).

http://www.rpsys.net/openzaurus/mtd/rp-jffs2-longfilename.patch - if you try
and create filenames longer than 255 characters, the fs gets corrupted. This
adds a couple of checks to prevent it.

http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-extra.patch - This is for
comments. The sharp driver uses a smaller eraseblock than the current mtd
code supports so I have to disable a check to get the code to work properly.
I think this is due to a limitation on kmalloc? The code gets around this by
using dma_alloc_coherent. Is there a way I can do this in an acceptable
manner? (I'm assuming the above patch isn't acceptable?)

(NB: The filesystem is written out by an older driver we can't change so we
have to remain compatible with it - changing eraseblock size therefore isn't
an option).

Thanks,

Richard

Re: Sharp SL Series NAND Driver

[John Lenz]

On 11/12/04 11:38:54, Richard Purdie wrote:
> As mentioned on IRC, I've ported the nand driver for the Sharp SL series  
> to
> the current kernel. This first patch adds the driver which supports all  
> the
> Zaurus models that use nand flash. (thanks for the pointers in trimming  
> it
> down! :)
> 
> http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl.patch

In the suspend and resume functions, you still have some prinks... those  
should be removed.  And does there need to be any code in resume?

This patch is very similar to the patch in my tree, except you also provide
the scan_bbt function.

I just got poodle to boot up correctly with my patch.  The problem all
along was that I was passing the wrong root= option to the kernel!  Passing
the correct root device, and poodle boots up fine.  I can log in and run a
few commands.  Note, this is with my patch but it should work with yours as
well since they are so similar.  Secondly, I have it working without any of
the other patches you posted...

> 
> I also have some other patches I'd appreciate your views on. Two of these
> should be straightforward. The third is more for comments.
> 
> http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-map.patch - maps a ROM  
> on
> the device (I think its used to access configuration information?).

Do we actually need this patch?  Perhaps we should hold off including it  
until we have a program that needs to access this stuff.


> http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-map.patch - maps a ROM
> on
> the device (I think its used to access configuration information?).
> 
>  http://www.rpsys.net/openzaurus/mtd/rp-jffs2-longfilename.patch - if you
> try  and create filenames longer than 255 characters, the fs gets
> corrupted.  This  adds a couple of checks to prevent it.
> 
>  http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-extra.patch - This is
> for  comments. The sharp driver uses a smaller eraseblock than the
> current mtd  code supports so I have to disable a check to get the code
> to work  properly.  I think this is due to a limitation on kmalloc? The
> code gets around this  by  using dma_alloc_coherent. Is there a way I can
> do this in an acceptable  manner? (I'm assuming the above patch isn't
> acceptable?)
> 
>  (NB: The filesystem is written out by an older driver we can't change so
> we  have to remain compatible with it - changing eraseblock size
> therefore  isn't  an option).

I notice in this patch you have CONFIG_MACH_HUSKY used... do we need to add  
CONFIG_MACH_POODLE?  Is this something that poodle would have as well?  It  
seems to be working here without this change... although I haven't tested  
it a lot yet.

John

Re: Sharp SL Series NAND Driver

[Richard Purdie]

John Lenz:
> In the suspend and resume functions, you still have some prinks... those 
> should be removed.  And does there need to be any code in resume?

They're leftovers from the sharp driver. Knowing Sharp, they probably wake 
up the screen or something but I'll remove them.

> This patch is very similar to the patch in my tree, except you also 
> provide the scan_bbt function.

This sorts out the POSTBADBLOCK problem by adding an extra badblock marker
in oob position 4 as the sharp driver does.

> I just got poodle to boot up correctly with my patch.  The problem all
> along was that I was passing the wrong root= option to the kernel! Passing 
> the correct root device, and poodle boots up fine.  I can log in and run a 
> few commands.  Note, this is with my patch but it should work
> with yours as well since they are so similar.  Secondly, I have it working 
> without any of the other patches you posted...

We've both got their via different routes. Mine's caught some things, yours 
others but I guess the main thing is we've got there! :). I just continued 
on with mine as I hadn't heard anything from you...

>> http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-map.patch - maps a ROM 
>> on
>> the device (I think its used to access configuration information?).
>
> Do we actually need this patch?  Perhaps we should hold off including it 
> until we have a program that needs to access this stuff.

I'm not sure if we need it or not. My view was it kept the device numbers
consistent and as its rather simple, I didn't see a problem with including
it. I can be persuaded otherwise...

>>  http://www.rpsys.net/openzaurus/mtd/rp-mtd-sharpsl-extra.patch - This is
>
> I notice in this patch you have CONFIG_MACH_HUSKY used... do we need to 
> add  CONFIG_MACH_POODLE?  Is this something that poodle would have as 
> well?  It  seems to be working here without this change... although I 
> haven't tested  it a lot yet.

There is a problem and I suspect its HUSKY and maybe tosa specific (as they
have the large 128MB flash chips). The rootfs is large so it causes the
eraseblock size to become too large and malloc can't cope. The kernel's
solution - increase the eraseblock size by combing blocks. Sharp decided to
use a different memory allocator which could cope with the increased size 
instead. The two methods are incompatible. The machines that will need this 
are ones which have filesystems that force a change in eraseblock size and 
are too big for malloc. In the sharp driver this ifdef was for all the SL 
series so we could probably change it to an ifdef MTD_NAND_SHARPSL safely. 
Using dma may give a slight performance increase? I'm open to discussing 
ways forward but if necessary we'll just have to keep that patch separate.

I've just realised I left in the line that kills the RTIME compressor. I 
think Sharp's performance calculations must have suggested it was beneficial 
to do so but I'm not expecting that to go into the mtd-cvs!

-- 
RP