Hi!
2012/11/18 Daniel Drake <d...@laptop.org>:
> On Fri, Nov 2, 2012 at 8:35 AM, Johan Rudholm <jrudh...@gmail.com> wrote:
>> Good question. I’d guess that mmc_power_off/up does not work as
>> expected here, that the card is not at all power cycled.
>
> Before going further on the "find a way to quirk it" route, there is
> something else we could look into.
>
> According to our hardware engineers, the external SD card power has
> been "always-on" until now. It is actually controlled by our embedded
> controller, separate from the CPU.
>
> In a test firmware, I can now control the SD card power via our "OLPC
> EC" interface, I call into that from mmc_power_up and mmc_power_down.
> And, with your hacky patch to make the voltage switch failure
> detection work, this fixes it: it tries 10 times at 1.8v then falls
> back to 3.3 successfully. No more problems with the power cycle.
Ah, great! Then we know what the issue was at least. Then I guess that
this code did not work with your driver:
host->ios.clock = 0;
mmc_set_ios(host);
so with my original patch ([RFC/PATCH,v2] mmc: core: Fixup signal
voltage switch), the clock was actually never stopped during the
signal voltage switch? I guess this will need some further
investigation also.
> So we have the option of fixing it that way: if we can fix the voltage
> switch failure detection, we could implement a custom vmmc regulator
> driver that uses our EC interface to enable and disable the SD power
> appropriately, solving our ability to power cycle.
Being able to power cycle the SD-card might also come in handy in
other situations, perhaps if a poor SD-card misbehaves in some way?
SD-cards have no "reset cord" like eMMCs, so being able to power cycle
the card feels like a good thing.
> On the other hand, we may have a good basis to add a quirk, triggered
> by the device tree, for when the hardware physically does not have
> 1.8v capabilities.
This also seems proper, if we know we can't get 1.8V, then we
shouldn't even try for it. In this way the detection will also be
faster (no 10 retries).
> I'm also curious if there is a 3rd option. It seems like in the case
> of our SoC, the SoC design mandates that the SD card power is separate
> from the SDHCI interface - requiring either a GPIO or some other
> mechanism (e.g. OLPC EC) to be able to control it.
>
> I'm wondering if this is the same for all sdhci-pxa devices. And the
> same for all sdhci devices? Maybe the SDHCI specs would help here, but
> I guess they aren't public.
>
> If this is the case, the driver could have another heuristic: if there
> is no vmmc regulator, there is no way of cutting the card power,
> therefore we could avoid even trying 1.8v on the basis that we know we
> can't recover if things go wrong.
So the driver could for instance drop the MMC_CAP_UHS_DDR50 cap if
there is no way to power cycle the card? I think that sounds
reasonable and according to spec, although also a little bit hard
since there probably are cards out there that never require a power
cycle to perform a proper voltage switch?
Kind regards, Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
