On 22 December 2015 at 10:39, Fabio Estevam <festevam@xxxxxxxxx> wrote: > Hi Ulf and Holger, > > On Thu, Dec 17, 2015 at 2:10 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > >> The no-1-8-v is a somewhat broken DT binding. I advise people to not >> use any more. >> Depending on the sdhci variant it have different meanings. >> >> I guess you are using the sdhci-esdhc-imx variant, which means >> no-1-8-v will disable UHS modes for SD-cards (those requiring 1.8V >> signal voltage). It has no impact on (e)MMC. >> >> As the host driver announces support for MMC_CAP_1_8V_DDR, that's what >> the mmc core will try to use. Actually the mmc core will first try >> 1.8V and if it fails, go for 3.3V. >> >> Likely, sdhci_do_start_signal_voltage_switch() will success to write >> the corresponding registers to change the signal voltage to 1.8V, >> which makes the mmc core believe it was a success. >> >> *If* your statement around that your HW don't support 1.8V signal >> voltage, we should perhaps add new mmc cap as currently we don't have >> a "MMC_CAP_3_3V_DDR". Although, you need to convince on that, because >> my experience tells that quite many has misunderstood the HW design in >> this regard. > > Yes, I have added a 'MMC_CAP_3_3V_ONLY_DDR' in this proposal to fix > the same issue as Holger describes: > http://www.spinics.net/lists/linux-mmc/msg32285.html > > ,but it seems you were not happy with such approach at that time. > Unfortunately, I was not able to rework it. Yes, I had vague memory of this discussion. Thanks for pointing it out. So, I think I am reaching the same consensus again. We need to move away from using the no-1.8-v, and thus not add any new interpretation of that binding. I think what I suggested as the solution here should work, right!? I understand the problem with keeping DTB backwards compatible, don't you think sdhci-esdhc-imx can handle that internally via using a MMC_CAP_3_3V_DDR? 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
