Legacy memstick support + FTL questions

Maxim Levitsky maximlevitsky at gmail.com
Sun Feb 21 17:42:39 EST 2010


On Thu, 2010-02-18 at 01:39 +0200, Maxim Levitsky wrote: 
> On Tue, 2010-02-16 at 18:26 -0800, Alex Dubov wrote: 
> > > I  mean when controller reads the 'int status' it does
> > > send a TPC?
> > > (I am sure that it does)
> > > 
> > > However mine can't do that and int status is read normally
> > > (yay...)
> > > 
> > 
> > There are two things to know:
> > 1. In serial mode, some controllers issue GET_INT TPC automatically
> > after each command, but only if certain configuration bit is set.
> > 
> > 2. In parallel mode, the meaningful bits of the interrupt register
> > are exposed on the DIO pins of the media at the end of command execution
> > and can be latched by the controller (this is a suggested behavior).
> > 
> > If you want to write a generic legacy MS support, you must take into
> > account that this behavior is not there for granted.
> > 
> 
> Thank you very very much.
> This clears this issue for good.
In fact I found out that these 'meaningful bits of the interrupt
register' are indeed exposed as a part of reg #16, but at different
place.

Alex, could you explain how a single TPC is performed?

I currently first send MS_TPC_SET_RW_REG_ADRS, and then MS_TPC_READ_REG

When I send the TPC I specify both the tpc number and its len. Is the
len transmitted?

I see that if I set addr.r_length != MS_TPC_READ_REG len, I get errors
in reg #16, but different errors depending if i set it lower or higher.

Currently I think that a level change on the #SDIO is the signal for
host to start reading, but who sets the #BS to high? Host or card.

Does card signal end of transmission?

Also it seems that if I write to 'param' register, I can't read it back
(maybe I do something wrong). Is this register write only?

Best regards,
Maxim Levitsky





More information about the linux-mtd mailing list