Re: [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Doug,

[snip]

>>>> I think you shall be able use MMC_CAP_NEEDS_POLL, to handle this
>>>> broken card detect mechanism. We even have a DT binding for that,
>>>> "broken-cd".
>>>
>>> I don't think this is possible, but let me explain why I think so and
>>> you can correct me.
>>>
>>> The voltage domain of the "card detect" pin on the SoC is vqmmc,
>>> right?  That means that you won't be able to read the pin without
>>> turning on vqmmc.  Even if you could read the pin without turning on
>>> vqmmc, the pullup on this line is connected to vqmmc too.  ...so if
>>> vqmmc is off then there's no pulup and you can't use card detect.
>>>
>>> Are you suggesting that we should flip the voltage of vqmmc (and thus
>>> vmmc to prevent damaging the card) during polling?  That seems ugly.
>>
>> I am not sure I follow to understand the problem. All I am saying is:
>> From your ->set_ios() when you get MMC_POWER_UP, enable vcc and vccq.
>> From your ->set_ios() when you get MMC_POWER_OFF, disable vccq and vcc.
>>
>> The rest is taken care of from mmc core, when trying to initialize the card.
>
> We must not be on the same page, so I'll put all my assumptions in
> super detail and we can see what's different...
>
>
> So if I have "MMC_CAP_NEEDS_POLL" set, the MMC core will poll things,
> right?  ...and you are suggesting that I could solve my vqmmc vs. card
> detect problem by using MMC_CAP_NEEDS_POLL, right?

Yes.

>
>
> Let's think about the case when no card is inserted.  When no card is
> inserted the core will call set_ios() with MMC_POWER_OFF, right?
>
> ...and we want that to turn off vmmc.
> ...and if we turn off vmmc, we should turn off vqmmc.

Correct. At MMC_POWER_OFF, all host drivers shall turn off all the
possible powers that goes to the card. I am just telling this to make
sure, we don't think this is a dw_mmc specific thing.

>
> Now we've got vmmc off and vqmmc off and on this board we can't read
> the card detect line, right?

Got it. :-)

>
> Now, we've got MMC_CAP_NEEDS_POLL, so dw_mmc will periodically be
> called to check the card detect line, but with vmmc and vqmmc off.  It
> will be unable to return a sensible value without actually turning on
> vmmc and vqmmc.

Currently MMC_CAP_NEEDS_POLL mean the mmc rescan work will reschedule
itself with HZ interval. This to check for card insert/removal.

Now, mmc_rescan() will, if present, invoke host's ->get_cd() callback
to check whether it's worth to continue initialization sequence or if
it should re-schedule itself again.

If your host driver can distinguish whether a card is inserted, which
in this the are when vccq is turned off, your ->get_cd() callback need
to return 0. That will allow mmc_rescan() to continue it's
initialization sequence and do mmc_power_up().

>
>
> ...so with that context, I'll ask my questoin again:
>
> Are you suggesting that we should flip the voltage of vqmmc (and thus
> vmmc to prevent damaging the card) during polling?  That seems ugly.

Nope.

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




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux