mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Dubov <oakad@yahoo.com>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Support for TI FlashMedia (pci id 104c:8033, 104c:803b) flash card readers
Date: Mon, 31 Jul 2006 08:11:41 -0700 (PDT)	[thread overview]
Message-ID: <20060731151141.45469.qmail@web36702.mail.mud.yahoo.com> (raw)
In-Reply-To: <44CC85FD.1050000@drzeus.cx>


> Then try to make qualified guesses. Even if the
> constants are
> TIFM_INTFLAG_2, that still makes the code more
> readable as you see which
> values are the same constant.
It is not necessarily good idea for constants that are
used only once on initialization. May be a side
comment will be better. I'll check this out.

> Is it possible for a "socket" to have
> multiple "card":s
> associated with it? Otherwise I see little need for
> the dynamic behaviour.

It appears that any socket can hold any card type. So
the logic goes as following:
1. Get insertion interrupt on socket
2. Detect card type
3. Stick proper handler to the socket
...do work
4. Get removal interrupt on socket
5. Ditch type-specific handler, mark socket as empty
A quick example: on 8033 sd cards are most often wired
to socket 3, while on 803b they are wired to socket 1.

> Sorry, I was a bit unclear. Of course hardware cares
> about what kind of
> response it will get. What I meant was that hardware
> shouldn't care if
> it's R1, R2 or R666. 

I'm afraid you'll have to clarify this issue further.
Consider the following: TI uses look up table to set
command type register. The decoding of this table is
my tifm_sd_op_flags. Its output directly sent to
hardware. Can you notice any bit patterns here:
Response type (4b):
R1 - 1     R1b - 9 (so highest 1 is MMC_RSP_BUSY)
R2 - 2     R3 - 3      R6 - 6
(if bit 1 is MMC_RSP_136 why it is set for R3 and R6;
and if it's MMC_RSP_CRC why it is not set for R1?)

Command type (2b):
BC - 0 (implied)   BCR  - 1
AC - 2             ADTC - 3 
(even if higher bit stands for "addressed vs
broadcast" it still doesn't make sense for lower bit).

By the way, if I recall correctly, SD spec does not
splits command types and responses into components. It
always speaks of R1s and R6s and so on.

> Baby steps. If you test carefully enough (and do
> some qualified
> guessing), you usually can figure out what most bits
> of a register are for.

It's not hard to figure out bits that are used
systematically. The problem is that there are 4 or 5
registers that are set to some constant at
initialization. I made all kinds of trials with them
and got no conclusive idea on their meaning.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

  reply	other threads:[~2006-07-31 15:11 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-28  3:34 Alex Dubov
2006-07-28  4:04 ` Alexey Dobriyan
2006-07-29 15:11   ` Alex Dubov
2006-07-28 11:46 ` Andrey Panin
2006-07-28 13:02   ` Alex Dubov
2006-07-29 20:02 ` Pierre Ossman
2006-07-30  6:29   ` Alex Dubov
2006-07-30 10:12     ` Pierre Ossman
2006-07-31 15:11       ` Alex Dubov [this message]
2006-07-31 17:37         ` Pierre Ossman
2006-08-02  2:12           ` Alex Dubov
2006-08-02  9:31             ` Pierre Ossman
2006-09-02  8:53               ` Alex Dubov
2006-09-02 11:15                 ` Pierre Ossman
2006-09-02 16:48                   ` Andrew Morton
2006-09-02 20:50                     ` Pierre Ossman
2006-09-03  3:48                       ` Greg KH
2006-09-03  9:53                         ` Pierre Ossman
2006-09-05 19:12                           ` Greg KH
2006-09-05 20:08                             ` Pierre Ossman
2006-09-06  3:33                               ` Greg KH
2006-09-06  5:02                                 ` Pierre Ossman
2006-09-07  3:00                                   ` Alex Dubov
2006-09-15  2:17                                   ` Alex Dubov
2006-09-15  6:43                                     ` Pierre Ossman
2006-09-19  3:20                                       ` Alex Dubov
2006-09-19  6:03                                         ` Pierre Ossman
2006-09-03  7:41                   ` Alex Dubov
2006-09-03 10:03                     ` Pierre Ossman
2006-09-04 14:12                       ` Alex Dubov
2006-09-04 14:49                         ` Pierre Ossman
2006-09-03 10:20                     ` Russell King
2006-09-03 10:32                       ` Pierre Ossman
2006-09-04 14:28                         ` Alex Dubov
2006-09-04 14:41                           ` Pierre Ossman
2006-09-05  2:18                             ` Alex Dubov
2006-09-05  5:35                               ` Pierre Ossman
2006-07-28 16:04 Mikael Pettersson
2006-07-29  6:43 ` 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=20060731151141.45469.qmail@web36702.mail.mud.yahoo.com \
    --to=oakad@yahoo.com \
    --cc=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®