Alex Dubov wrote:
> 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.
>
>
Ah, ok, I see. The socket structure would then be similar to a device
structure in the kernel. Perhaps you should use the name "host" instead
of "card" then as that is widely used in the other mmc host drivers. It
makes it easier when reviewing your future patches.
> 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?)
>
Some controllers are brain dead like this, which makes forward
compatibility a bit difficult. I just wanted to make sure as some
previous drivers have added this artificial restriction in just the
software.
I would still like it to bail out on an unknown type though as anything
else can generate really unpredictable and annoying bugs.
> 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).
>
These are more functional in nature, and therefore exactly how things
should work.
> 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.
>
>
The SD spec is focused on cards, not controllers. If you check their
controller spec (sdhci), you'll see that they've split it up.
> 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.
>
>
That's all one can expect. :)
You could put some comments about the registers somewhere so that other
people working on the driver will now what you've already tested.
Reverse engineered drivers are usually difficult for others to get into,
so everything you document will increase the changes of more people
helping you out.
Rgds
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
