From: "Jörn Engel" <joern@logfs.org>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Alex Dubov <oakad@yahoo.com>,
arnd@arndb.de, tglx@linutronix.de
Subject: Re: Plan for adding XD support in mtd layer
Date: Wed, 25 Nov 2009 11:40:27 +0100 [thread overview]
Message-ID: <20091125104027.GB10944@logfs.org> (raw)
In-Reply-To: <1259106610.28219.34.camel@maxim-laptop>
On Wed, 25 November 2009 01:50:10 +0200, Maxim Levitsky wrote:
>
> 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
Ok. Is the code available somewhere or can you send it? And what
devices would one have to buy to test it?
> 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
Block and page size already exist as mtd->erasesize and mtd->writesize
respectively. I'm not sure whether the zone size should become part of
the mtd interface - it looks more like a property of the ftl.
> 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
What userspace programs would need this information? I can imagine some
sort of xd_format or mkxd in case the card has been corrupted or used
raw. Anything else?
> Userspace utility:
> * Will allow user to read FTL maps (based on oob), Media ID, CIF, all
> using char device
What would this be needed for?
> * Will also allow low level format.
Jörn
--
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth
next prev parent reply other threads:[~2009-11-25 10:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-21 0:25 XD/smartmedia - how to implement it right? Maxim Levitsky
2009-11-21 10:25 ` Jörn Engel
2009-11-22 12:58 ` Maxim Levitsky
2009-11-24 23:50 ` Plan for adding XD support in mtd layer Maxim Levitsky
2009-11-25 10:40 ` Jörn Engel [this message]
2009-11-25 13:20 ` Maxim Levitsky
2009-11-25 15:34 ` Jörn Engel
2009-11-25 16:17 ` Maxim Levitsky
2009-11-25 20:59 ` Jörn Engel
2009-11-25 23:22 ` Maxim Levitsky
2009-11-26 8:27 ` Jörn Engel
2009-11-26 13:02 ` Maxim Levitsky
2009-11-26 13:42 ` Jörn Engel
2009-11-26 21:38 ` Maxim Levitsky
2009-11-28 7:22 ` XD/smartmedia - how to implement it right? Alex Dubov
2009-11-28 10:36 ` Maxim Levitsky
2009-11-30 12:35 ` Alex Dubov
2009-11-30 13:58 ` Maxim Levitsky
2009-11-30 23:04 ` Maxim Levitsky
2009-12-01 8:22 ` Jörn Engel
2009-12-01 16:10 ` Alex Dubov
2009-12-01 16:41 ` Maxim Levitsky
2009-12-11 23:48 ` Maxim Levitsky
2009-12-05 19:09 ` Pavel Machek
2009-12-06 21:27 ` Maxim Levitsky
2009-12-07 15:13 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091125104027.GB10944@logfs.org \
--to=joern@logfs.org \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=oakad@yahoo.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox