On 14 February 2013 09:05, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote:
>
> On 2/13/2013 12:35 PM, Mark Brown wrote:
>>
>> On Wed, Feb 13, 2013 at 08:45:56AM +0100, Guennadi Liakhovetski wrote:
>> > On Wed, 13 Feb 2013, Marek Szyprowski wrote:
>>
>> > > BTW, mmc_regulator_get_ocrmask() won't work with continuous range
>> > > regulators.
>>
>> > This seems like a problem, that has to be fixed...
>>
>> Indeed, what's the issue?
>
>
> There are probably 2 issues:
>
> 1. mmc_regulator_get_ocrmask() works only with regulators which support
> regulator_count_voltages() and regulator_list_voltage(). Recently support
> for
> continuous regulators have been merged. Such regulators doesn't provide
> regulator_list_voltage() method, but are able to change/set voltage to the
> given value. I agree that they are not very common, so right now we can
> probably ignore them until the first board, which uses them arrives.
>
> 2. The second issue might be related to the testing of precise voltage
> values
> in the ocr mask, not the whole allowed ranges. Such issues in sdhci.c driver
> has been recently fixed by commit cec2e216f72c6b5ccdadb60aadbe99821d744503
> ("mmc: sdhci: Use regulator min/max voltage range according to spec"), but I
> don't know MMC core code to judge if ocr mask is used for exact voltage
> checking or only for checking the voltage ranges. However someone with good
> mmc subsystem knowledge should check it.
>
Not 100% sure what your problem relates too here, but I am aware of an
issue for how the mmc protocol layer are handling ocr_masks. Let me
try to describe it here:
1. During "card init" mmc_power_up will be called for telling the host
driver to provide power to the card. The level of voltage will be set
to "ocr_avail" which means the highest supported voltage by the host.
2. At the protocol layer the card init sequence tries to negotiate to
lowest possible ocr value from what the card and the host together
supports. Once done, the ocr mask value will be cached into the host
struct.
3. The host will informed about the new ocr mask from the protocol
layer with mmc_select_voltage and it somewhere here the problems
starts. No host are actually changing the voltage level at this state
(MMC_POWER_ON) which is correct since it would likely mean violation
of the spec. At the same time the protocol layer still believes the
host has switched to operate at the new voltage level.
4. So the host and the protocol layer are out of sync with regards to
the ocr mask, which is why the cached ocr_mask in the host struct is
reset when doing mmc_power_off. Otherwise the suspend/resume sequence
would have been broken.
I have been looking into a solution for the above problem, but has not
yet been able to finalize the task.
Hope this did not become more fussy now. :-)
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
> --
> 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
Kind regards
Ulf Hansson
--
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
