Re: [PATCH] mmc: dw_mmc: setpower on MMC_POWER_{UP,OFF}
From: James Hogan
Date: Wed Mar 13 2013 - 10:37:40 EST
On 13/03/13 14:20, Seungwon Jeon wrote:
> Hi James,
>
> On Tuesday, March 12, 2013, James Hogan wrote:
>> Call the setpower platform callback in response to set_ios with
>> ios->power_mode == MMC_POWER_UP or MMC_POWER_OFF, instead of from the
>> card detect work function.
>>
>> This appears to fix a problem I have where a card stuck in a funny state
>> doesn't get properly cleared by the power being turned off, presumably
>> due to lack of power sequencing. This resulted in the following log
>> messages after boot:
>>
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 200000Hz, actual 199680HZ div = 250)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 195765Hz, actual 195764HZ div = 255)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 400000Hz, actual 399360HZ div = 125)
>> mmc0: error -110 whilst initialising SD card
>> mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167)
>>
>> Signed-off-by: James Hogan <james.hogan@xxxxxxxxxx>
>> Cc: Seungwon Jeon <tgih.jun@xxxxxxxxxxx>
>
> This patch is reasonable.
> I just want to know though.
> I guess this problem is happened when card is inserted as soon as card is removed.
> If not, could you explain your situation more?
Hi,
It initially started happening after the patch by Yuvaraj CD ("mmc:
dw_mmc: enable controller interrupt before calling mmc_start_host").
Basically after hard resetting the board the card would be in a dodgy
state, and I'd get these elusive errors after boot (see the above patch
thread for details). It was specifically the position of the prink that
it was sensitive to (I have a JTAG console turned on which adds big
latencies to prinks, so it's clearly some kind of race). Unplugging the
card cleared the problem, as did cutting the power to the card for a
sufficient amount of time. While trying to debug the messages I saw
these power callbacks and thought I'd try them as they seem like a much
better place to control the card power, and seem to match other host
drivers too, and it fixed the problem, I presume due to the intentional
delays around those calls. It is of course possible that the race is
just hiding again, but I think the patch is an improvement regardless.
Cheers
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/