On Thu, 2015-08-27 at 16:44 +0200, Ulf Hansson wrote: > [...] > > > > > > > Currently drivers return error codes according to when they can't set > > > the requested voltage level, so that's all fine - right? > > > > Yes, they should. Hovever it seems like my fsl controller cannot. > > There is VS18,VS30 and VS33 bits in hostcap register but theses are > > always set :( > > If there are set in the *hostcap* register, doesn't that indicates > that they are supported? Not what's currently used!? hmm, this only shows that I am a newbie in this area :) What register/bits normally holds this info? > > What controller/driver are you using here? esdhc,v3.0/sdhci-of-esdhc > > > Moreover, the above code snippet is modified by you (or someone else) > > > locally, since in the upstream version of the code, the prints are > > > > ahh, yes a did that while debugging. > > > > > done a debug level. That's also okay, I think. > > > Perhaps changing the last print to warn level instead, since reaching > > > that point would mean all attempts have failed. > > > > Since not all controllers can tell what VS is you have to specify that, in my case I > > do it in my device tree as there is a way to do that already. > > > > So I think mmc_power_up() should mask away VS not supported and then try the remaining. > > The exact way to do this escapes me as I am not familiar with this area yet. > > Okay, I think we could potentially look at the host caps and figure > out what IO voltage level the host supports before trying to set them. > > Although it does complicates things, so before going there I just want > to be sure that we really have an issue here. > > I haven't yet really understood why your driver is unable to return > error codes when failing to set an unsupported voltage level, you need > to convince me on that. None the less, the info is there in the host caps so why not use it? If caps say 1.8V only why insist on trying 3/3.3 Volt? Jocke -- 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