MMC compatibility fix - OCR mask
PATCH 3/3 MMC compatibility fix - OCR mask
This patch avoids using a emtpy OCR mask for the initial power up. Since some cards do not like a one bit-mask a routine has been added which grows the mask to three bits (one extra bit on each side) if necessary.
drivers/mmc/mmc.c +28 -1
@@ -300,6 +300,31 @@return ocr; } +/* +* Calculate a OCR mask to use for initial scanning. +* All zeroes and all ones cannot be used with some cards. +* Just on bit cannot be used either so extend the OCR +* if needed. +*/ + +static u32 mmc_select_scan_ocr (struct mmc_host *host) +{ +u32 ocr; + + ocr = host->ocr_avail; + +/* Check if we have more than one bit */ +if (ocr & (ocr <<1 )) +return ocr; +if (ocr & (ocr >>1 )) +return ocr; + +/* Extend the mask to surrounding bits */ + ocr |= (ocr <<1 ) | (ocr >>1 ); + +return ocr; +} +static void mmc_decode_cid (struct mmc_cid *cid,u32 *resp) {memset (cid,0 ,sizeof (struct mmc_cid ));
@@ -589,7 +614,9 @@mmc_power_up (host); - err =mmc_send_op_cond (host,0 , &ocr); + ocr =mmc_select_scan_ocr (host); + + err =mmc_send_op_cond (host, ocr, &ocr);if (err !=MMC_ERR_NONE )return ;
Quoted 3 lines · Pierre Ossman
This patch avoids using a emtpy OCR mask for the initial power up. Since some cards do not like a one bit-mask a routine has been added which grows the mask to three bits (one extra bit on each side) if necessary.
As I already replied on this topic, this will not work on hosts which support a wide range of supplies. If you send an OP_COND command with bits set outside the MMC cards allowable range, they go gaga.
Signature · 4 lines
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial coreQuoted 14 lines · Russell King
Quoted 3 lines · Pierre Ossman
This patch avoids using a emtpy OCR mask for the initial power up. Since some cards do not like a one bit-mask a routine has been added which grows the mask to three bits (one extra bit on each side) if necessary.
As I already replied on this topic, this will not work on hosts which support a wide range of supplies. If you send an
OP_CONDcommand with bits set outside the MMC cards allowable range, they go gaga.
Sorry, my bad. I was reviewing the previous discussion about this in an attempt to find a solution. Completely missed that case. Please disregard this patch then.
The problem still remains though. Do you know what the wide range controller you have send when used with the manufacturer's driver?
Rgds
Pierre
Quoted 2 lines · Pierre Ossman
The problem still remains though. Do you know what the wide range controller you have send when used with the manufacturer's driver?
There isn't a manufacturers driver for it.
Signature · 4 lines
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial coreQuoted 11 lines · Russell King
Quoted 3 lines · Pierre Ossman
The problem still remains though. Do you know what the wide range controller you have send when used with the manufacturer's driver?
There isn't a manufacturers driver for it.
Since I'm a bit keen on actually being able to read the cards I already own I have another suggestion. Start out using a zero OCR. If no card responds using this we try again using the bit mask created in this patch. That would get compliant cards using the first go and the rest using the second. If someone tries to combine faulty cards with good ones on the same bus the faulty ones will of course not work but at least people have the chance of getting them to work when inserted by themselves.
Does this sound like a solution that would work? I'd be happy to write the code and test it with the cards I have at my disposal.
Rgds
Pierre