All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Dubov <oakad@yahoo.com>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: Legacy memstick support + FTL questions
Date: Tue, 16 Feb 2010 06:15:58 -0800 (PST)	[thread overview]
Message-ID: <154304.22668.qm@web37606.mail.mud.yahoo.com> (raw)
In-Reply-To: <1266174235.3451.107.camel@maxim-laptop>


> > 
> > It is quite possible. Some controllers will
> automatically retrieve an
> > "interrupt" field from the status register on each
> media access (in fact,
> > this behavior is mandated in parallel mode). Check if
> the bits fit "inter-
> > rupt" register bits.
> Doesn't seem to map to anything.
> 
> 
> 
> 
> 0x10 is polled on register writes
> 0x20 is polled on command writes, and then 0x10 is polled
> 0x50 (0x40 | 0x10) if polled after MS_TPC_GET_INT and only
> it
> 
> 0x03 is mask for error detection, if found in any of above
> polls, error
> out.
> 
> The above was for register #19 (0xXX000000) 

So, it's probably an implementation specific register.
There's no common standard for MS interfaces.

> 
> after the MS_TPC_READ_LONG_DATA, 0x40 is polled, and
> register #18 is
> polled for 0x20 clear. These are all bits that are
> accessed.
> 
> You try to tell me that controller itself issues TPCs,
> reads their
> responses, and puts that in registers, right? This is very
> interesting.
> 
> Bus is half duplex, and there is a line that indicates who
> sends data.
> 
> I currently understand that host sends an TPC, then card
> sends a
> response. Is it another TPC?


Not at all.
I answered this already.
See below.

> > > As I understand it, TPCs are send in both
> directions, and
> > > nothing more.
> > > There are no dedicated lines, or something like
> that.
> > 
> > TPC means "transport protocol command" and it is only
> send from host to
> > media. Generally speaking, the whole thing works like
> this (each point
> > is a TPC):
> > 
> > 1. Host selects media register access window.
> > 2. Host modifies media register values.
> > 3. Host invokes media command.
> > 4. Host reads media registers.
> > 5. Host moves data around.
> > 6. Lather, rinse, repeat.
> 
> > 
> > > 
> > > So status should be a content of the answer TPC
> or
> > > something like that.
> > 
> > It is not.
> > 

Legacy MS protocol uses 3 meaningful lines: SCLK (clock), SDIO (data/
command IO) and BS (bus state lane). There may be additional 3 or 7
DIO lines but they are only used for bulk data transfer.

There are 4 hw states:

1) BS at low - media is idle
2) BS goes to high - TPC is clocked in on SDIO
3) BS goes to low - host waits for level change on SDIO
4) BS goes to high - data can be clocked in/out on all data lines
5) BS goes to low again -> same as 1 (idle)

Media can not initiate anything and can not send anything to host.
Host is responsible to query the media state as necessary.

> > > I wish I had the memstick spec (original not
> pro)
> > > 
> > 
> > There's an email address on Sony's website.
> And the chances they give me the specs without NDA and a
> lump of money
> are higher that winning a lottery?
> 

They will give you the spec for nothing if you're a certified sony
developer. How do you become one is different question, but it is not
money dependent.



      __________________________________________________________________________________
Yahoo!7: Catch-up on your favourite Channel 7 TV shows easily, legally, and for free at PLUS7. www.tv.yahoo.com.au/plus7

  reply	other threads:[~2010-02-16 14:16 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 [this message]
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
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=154304.22668.qm@web37606.mail.mud.yahoo.com \
    --to=oakad@yahoo.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=maximlevitsky@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.