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
next prev parent 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®