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