RE: [PATCH] mmc: dw_mmc: setpower on MMC_POWER_{UP,OFF}

[Seungwon Jeon]

On Wednesday, March 13, 2013, James Hogan wrote:
> 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.
Thank you for your description.
I think the reason is insufficiency of power-on time.
Voltage level shall be below 0.5V at least 1ms when card power-on (from SD spec).
I'm adding...

Acked-by: Seungwon Jeon <tgih.jun@xxxxxxxxxxx>

Thanks,
Seungwon Jeon

--
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/