linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Alex Dubov <oakad@yahoo.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: Legacy memstick support + FTL questions
Date: Mon, 22 Feb 2010 00:42:39 +0200	[thread overview]
Message-ID: <1266792159.3445.9.camel@maxim-laptop> (raw)
In-Reply-To: <1266449977.4185.0.camel@maxim-laptop>

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

  reply	other threads:[~2010-02-21 22:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1266091737.30330.16.camel@maxim-laptop>
2010-02-14 15:06 ` Legacy memstick support + FTL questions Alex Dubov
2010-02-14 19:03   ` Maxim Levitsky
2010-02-16 14:15     ` Alex Dubov
2010-02-16 23:49       ` Maxim Levitsky
2010-02-17  2:26         ` Alex Dubov
2010-02-17 23:39           ` Maxim Levitsky
2010-02-21 22:42             ` Maxim Levitsky [this message]
2010-02-22 14:04               ` Alex Dubov
2010-02-22 23:11                 ` Maxim Levitsky
2010-02-23  9:01                   ` Alex Dubov
2010-02-24  1:10                     ` Maxim Levitsky
2010-02-24  2:20                       ` Alex Dubov
2010-01-26 21:43 Maxim Levitsky
2010-01-27  2:16 ` Alex Dubov

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=1266792159.3445.9.camel@maxim-laptop \
    --to=maximlevitsky@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=oakad@yahoo.com \
    /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;
as well as URLs for NNTP newsgroup(s).