On 10/01/18 22:06, Ulf Hansson wrote: > On 10 January 2018 at 19:04, Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: >> On Wed, 2018-01-10 at 18:01 +0100, Ulf Hansson wrote: >>> On 10 January 2018 at 16:32, Andy Shevchenko >>> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: >>>> On Intel Edison the Broadcom WiFi card, which is connected to SDIO, >>>> requires 2.0v, while the host, according to Intel Merrifield TRM, >>>> supports 1.8v supply only. >> >>>> + /* >>>> + * Without a regulator, SDHCI does not support 2.0v but we >>>> get >>>> + * here because we advertised 2.0v support for compatibility >>>> + * with the SDIO card's OCR. Map it to 1.8v for the purpose >>>> of >>>> + * turning on the power. >>>> + */ >>>> + if (IS_ERR(host->mmc->supply.vmmc) && vdd == >>>> ilog2(MMC_VDD_20_21)) >>>> + vdd = ilog2(MMC_VDD_165_195); >>> >>> Why not instead extend the range in sdhci_set_power_noreg() to also >>> check for MMC_VDD_20_21? >>> >>> Or is there a problem with that? >> >> Do we have any grounds to do this in generic code? >> >> Moreover, if we check for 2.0v what should we do in generic code? >> For my understanding >> >> case _20_21: >> pwr = _180; > > Yeah, why is that a problem? Shouldn't be a problem. Just add a comment: /* * Without a regulator, SDHCI does not support 2.0v so we only * get here if the driver deliberately added the 2.0v range to * ocr_avail. Map it to 1.8V for the purpose of turning on the * power. */ case MMC_VDD_20_21: pwr = SDHCI_POWER_180; break; > > You should never reach this point, unless the host announce support > via the ocr mask, for the _20_21 VDD. > > What does other variants do in this regards? Use regulators or 3V I expect. -- 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
