Re: XD/smartmedia - how to implement it right?

[Maxim Levitsky]

On Tue, 2009-12-01 at 09:22 +0100, JÃrn Engel wrote: 
> On Tue, 1 December 2009 01:04:26 +0200, Maxim Levitsky wrote:
> > 
> > Alex, could you do me a favor, and explain why partial block writes
> > don't work?
> > What happens if its done?
> 
> With the Alauda and the limited set of cards I tried they work.
> 
> JÃrn
> 
I have few severe problems in writing the driver, but otherwise its is
almost written. I also suspect that I will have to modify mtd core in
several places to achieve what I need to. I guess Alex was right after
all...

First of all, the device I deal with supports 32 bit dma only, as well
as many other pci devices. (I know that for sure because dma register is
32 bit wide....)

Now, mtd_blkdevs doesn't ask block subsystem for 32 bit bounce, and in
addition to that there is no guarantee that my mtd driver won't be
called on unrelated kernel buffer (for example if ftl layer does
caching....)
So I guess, ether I need to try to map the buffer, and then fail back to
copying into preallocated buffer in 32 bit zone, or always use that
buffer.
MMC core seem to handle the dma bouncing inside.


But that minor problem, other problem, I revealed when I began to think
about how properly to guard against races.
Problem is that mtd core doesn't handle hot-plug well.

Suppose, user has mounted filesystem on xd card and pulls it out.
SD/MMC cards handle that case. There might be fs corruption though, but
that is the user responsibility.

Now if anything has open the mtd_blkdevs, it increments the mtd user
count, thus removal of the mtd device will just fail.
Now I really don't know how to handle that property, but I know that
yanking out usb keys, mmc cards, etc works, and all devices that were
created disappear.

I will eventually figure out how to do that right, but it would be great
if you help me a bit.

Best regards,
Maxim Levitsly 




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