On 2 February 2015 at 23:10, NeilBrown <neilb@xxxxxxx> wrote:
> On Mon, 2 Feb 2015 16:10:29 +0100 Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>
>> On 2 February 2015 at 16:05, Russell King - ARM Linux
>> <linux@xxxxxxxxxxxxxxxx> wrote:
>> > On Mon, Feb 02, 2015 at 03:57:37PM +0100, Ulf Hansson wrote:
>> >> On 30 January 2015 at 23:27, NeilBrown <neilb@xxxxxxx> wrote:
>> >> > Shortly before this call is
>> >> >
>> >> > host->ios.power_mode = MMC_POWER_ON;
>> >> > mmc_set_ios(host);
>> >> >
>> >> > and omap_hsmmc_set_ios() contains:
>> >> >
>> >> > switch (ios->power_mode) {
>> >> > ....
>> >> > case MMC_POWER_ON:
>> >> > do_send_init_stream = 1;
>> >> > break;
>> >> >
>> >> >
>> >> > if (do_send_init_stream)
>> >> > send_init_stream(host);
>> >> >
>> >> > Which sends the "init stream" to the card.
>> >> > If the card is still being reset at this time, the stream may not
>> >> > be effective.
>> >> >
>> >> > I find that about 10%-20% of the time when I release the reset line
>> >> > *after* the sequence is sent, my card fails to initialised. When I
>> >> > release *before* the sequence is sent, it never fails.
>> >>
>> >> Okay, thanks for providing these details.
>> >
>> > The right thing to do then is to pulse the reset line at the pre-power-up
>> > stage.
>>
>> I don't think that will work, since the card hasn't yet been powered
>> and will thus not respond properly to the reset.
>
> My understanding, at least in the case of my hardware, is that the power-on
> is sufficient to reset the device.
> In my case, the one supply is shared between two devices (wifi and bluetooth)
> so if the bluetooth is on, then the wifi cannot be power-cycled. That is
> when the reset is particularly needed.
>
> I'll try to arrange some testing to confirm this is the case. Of course,
> this would not be general result, it would only be relevant for my hardware.
I refreshed my memory for how the cw1200 WLAN device works on the
ux500 SOC. I decided to post the complete information here, also for
my own reference.
These resources need to be controlled during the power sequence of CW1200:
There are two GPIOs (one reset and one for SPI/SDIO selection), one LP
(low power) clock and a few power supplies.
The sequence for power up that needs to be followed are:
1. Keep reset GPIO asserted.
2. Enable power supplies.
3. Enable LP clock.
4. Wait a few LP clock cycles to let power/clock stabilize.
5. Make sure SPI/SDIO select pin is in SDIO mode. The value will be
sampled by the WLAN device when reset GPIO is de-asserted.
6. De-assert reset GPIO.
7. Wait 30 ms for the WLAN device to power up.
The power supplies may also be shared with a bluetooth device. That
also means the reset GPIO must be kept asserted in power off state, to
prevent power up of the WLAN device.
>From the above, it's clear that toggling the reset GPIOs in the
->pre_power_on() phase won't work for CW1200/UX500 case. That in
conjunction with the "init stream" issue tells me that we need to
progress with the below patch:
"mmc: core: Invoke mmc_pwrseq_post_power_on() prior MMC_POWER_ON state"
http://www.spinics.net/lists/arm-kernel/msg396592.html
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
