Message-ID: <1259589517.13049.31.camel@maxim-laptop>
Date:	Mon, 30 Nov 2009 15:58:37 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Alex Dubov <oakad@...oo.com>
Cc:	Jörn Engel <joern@...fs.org>,
	linux-kernel <linux-kernel@...r.kernel.org>, arnd@...db.de,
	tglx@...utonix.de
Subject: Re: XD/smartmedia - how to implement it right?

On Mon, 2009-11-30 at 04:35 -0800, Alex Dubov wrote: 
> 
> --- On Sat, 11/28/09, Maxim Levitsky <maximlevitsky@...il.com> wrote:
> 
> > From: Maxim Levitsky <maximlevitsky@...il.com>
> > Subject: Re: XD/smartmedia - how to implement it right?
> > To: "Alex Dubov" <oakad@...oo.com>
> > Cc: "Jörn Engel" <joern@...fs.org>, "linux-kernel" <linux-kernel@...r.kernel.org>, arnd@...db.de, tglx@...utonix.de
> > Date: Saturday, November 28, 2009, 2:36 AM
> > On Fri, 2009-11-27 at 23:22 -0800,
> > Alex Dubov wrote: 
> > > > 
> > > > The "mtd uses blocking calls" argument I can
> > help
> > > > with.  For some other
> > > > project I've added non-blocking calls to mtd[1].
> > > > 
> > > > Biggest problems I see are a) the userspace
> > interface and
> > > > b) allowing
> > > > both raw flash access through MTD and block
> > device access
> > > > with an FTL.
> > > > 
> > > > [1] http://lists.infradead.org/pipermail/linux-mtd/2009-November/028065.html
> > > > 
> > > > Jörn
> > > 
> > > I actually tried several approaches to this problem
> > and I think, I have a good idea about how to create a fully
> > asynchronous mtd driver, which can handle different device
> > models. Unfortunately, I had other commitments so I couldn't
> > advance my mtd stuff.
> > > 
> > > Recently I was going to go back to it, but then I was
> > asked to implement some additional functionality in rapidio
> > subsystem, which I'll have to take care of first.
> > 
> > Hi, 
> > 
> > First of all, thank you very much for your contributions.
> > Could you explain, why we need an asynchronous mtd driver?
> 
> Because it's the future. ;-)
Although I like the xD format, it has no future,
Everyone migrated to SD now.

Reasons are very simple:

1 - xD hardcodes device sizes, thus if somebody makes say 8GB card, many
readers couldn't use it.
I know that windows driver I was dealing with supports sizes up to 2GB


2 - xD is a nand card, but with 8-bit bus.
Newer nand chips seem to favor 16 bit bus or more.
Obviously, if they were to implement that it would be physically
incompatible.

3 - embedded cpus are cheap dirt now, and allow to use their, always
'better' FTL strategy, and also hide inner working of the chip.

Memstick pro is also today sort of SD card, but for Sony its their first
priority to keep proprietary standards even if inferior.
I won't be surprised though if this format dies too.

Could you explain why we need an asynchronous interface?
I understand that filesystem/page cache/block cache/and block layer,
already provide caches and asynchronous behavior.

Only maybe reading several pages at time, and writing could benefit, but
many devices don't support that feature.
And again, bulk of the time will be spend writing, and only saving will
be from queuing more work to the device.



> 
> > 
> > Also, as I understand the command interface more and more,
> > it seems that
> > 'magically' xD card had same interface as standard NAND
> > flash chip.
> > 
> > I think I can implement the driver for each controller just
> > like an nand
> > chip driver.
> > 
> 
> xD spec, first of all, is about flash-based ordinary block devices.
> All the hard problems are in good r/w FTL implementation, which is
> currently mostly absent from the MTD.

Its true, and I will write an r/w FTL for xD devices, in same manner as
existing FTL implementations.
It works above the mtd layer btw.



Best regards,
Maxim Levitsky


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists