Plan for adding XD support in mtd layer

[Maxim Levitsky <maximlevitsky@gmail.com>]

Here is my plan for adding the XD format into MTD subsystem.
Please review.

New additions are marked with '->'


Chip driver:

no problems with that, in fact ricoh controller I reverse engineered is
very similar conceptually
to jmicron.
I can take original jmicron driver almost verbatim.
This will live in new sub folder of mtd and call into base XD driver


Base XD mtd driver:

* No way to tell that readsize = 512, but write & erase size isn't.
Not such a big deal, since higher level FTL driver can hardcode that
assumption, and access via mtdblk isn't necessary, since FTL will
replace it for XD, and the raw access will be done through mtdchar.

* it is possible to export 'extra' via oob. FTL will use that, and will
be available to user via char device

* No need to export CIF block, it will be available for user via char
device by scanning the device (using a new utility)


-> I need new mtd_info member for at least for card identification, and
will be nice to have zone/block/page size
This will be used by FTL and mtdchar to be exported to user space


FTL driver:

I will write new XD/smartmedia FTL driver.

* Will read ID/type from device and do all the work based on that,
(figure page size/zone count/block size, etc...) or will get that info
from mtd driver 

* Will cache read/writes (this will overlap with mtdblk)

* Will provide normal block level access to filesystems, and user.
(using common block device of course)

* No debugging information or/and device specific ioctls.


Char driver:

* Already exists, and I will need to modify it, so I could read ID/media
type
Also would be nice to pass info about sizes (zones/pages/blocks) to
userspace 
If not, I will put translation table to userspace utility based on media
ID


Userspace utility:
* Will allow user to read FTL maps (based on oob), Media ID, CIF, all
using char device
* Will also allow low level format.



Best regards,
Maxim Levitsky