[SOLVED] Invalid Vdd is coming during mmc driver access.

Hi,
I am getting invalid vdd while mmc driver access in linux boot up.
basically during mmc_power_up function, after executing __mmc_set_signal_voltage and before setting power mode to MMC_POWER_ON, sdhci_runtime_suspend_host is been called followed by mmc_rescan. Though there is power off sequence is mmc_rescan, when it comes back to mmc_power_up function, it makes directly power mode to MMC_POWER_UP and goes in mmc_set_ios and later it calls sdhci_set_power where the BUG is coming as invalid vdd. In sdhci_set_power, vdd is 0 and power mode is 2(power on). Hence the problem.

I am using yocto kernel version 3.14.55 and I can't upgrade it due to some limitations.

Anybody can help me what is the reason and how to fix it?

VDD is drain voltage. On n-channel fets(nearly universal) what they're saying is that the '+' line is invalid - not on, or wrong value. That's the translation from gobbledygook to English.

As you're powering something up, this is not unexpected. The only hidden nastiness is this: If it's being powered with 5V, for example, 3.3V circuitry is not specified to take that. It will switch slower, run hotter, and may well blow. Most 3.3V inputs & outputs are 5V tolerant, but the supply line into the chip internals(Vdd) is not 5V tolerant. Neither is any capacitors on Vdd.

If you think it's a software bug, the software probably isn't giving enough settling time for Vdd to get within spec. When you switch on a power line, it isn't there immediately; it arrives. When you switch it off, it doesn't disappear, it decays. Contact the maintainer.

If you think it's a hardware bug, don't risk it. Contact your hardware supplier. I wouldn't try poking around feeling for voltages unless you have very good information on the kit (e.g. you're in the R & D making this stuff).

Thanks for the reply. Actually it is software who is causing issue, don't know actual reason. Software is giving proper settling time for vdd and I am getting correct vdd. In my case reading correct vdd is not issue. The issue is the vdd variable used is becoming 0 after reading correct vdd as 21 from hardware/software.
In software, mmc_power_up function had 2 power mode setting. 1st it set power mode to power up after reading correct vdd and then it makes power mode to power on. In some of the scenario, between power mode transition from power up to power on, mmc_rescan is called where at the end power off been called.
So when power mode become power up(value 1) vdd was 21 and when power mode become power on(value 2) then vdd become 0 though mmc_recan just called before that. Hence I am getting BUG in sdhci_set_power function. Bellow is the snippet.
host->ios.vdd = fls(ocr) - 1;
if (mmc_host_is_spi(host))
host->ios.chip_select = MMC_CS_HIGH;
else
host->ios.chip_select = MMC_CS_DONTCARE;
host->ios.bus_mode = MMC_BUSMODE_PUSHPULL;
host->ios.power_mode = MMC_POWER_UP;
host->ios.bus_width = MMC_BUS_WIDTH_1;
host->ios.timing = MMC_TIMING_LEGACY;
mmc_set_ios(host);

/* Set signal voltage to 3.3V */
ret = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330);

/* ------------------------>>>> here mmc_rescan been called where vdd is 0 due to
power off been called.
* This delay should be sufficient to allow the power supply
* to reach the minimum voltage.
*/
mmc_delay(10);

host->ios.clock = host->f_init;
host->ios.power_mode = MMC_POWER_ON;

This issue is not always reproducible. It happens sometimes.

Thanks,
Diptendu

That's ok. You know it's a bogus issue, so you can ignore it.

A settling time of 10 seconds is ridiculous. That's nearly long enough for thermionic valves to warm up, and certainly 1000 times long enough to blow any silicon in sight if too high a voltage is applied.

I would file a bug, and if a fix isn't forthcoming, I would attempt a "go and play in the traffic" type pat to disable the entire test. That code offers zero protection. Why bother with it? Alternatively, see if you can pipe it's error to /dev/null - everyone's favourite write only memory.

Thanks for the reply. I know this, but as I am working in an organisation, I can't ignore the issue or suppress the issue. I am looking for a fix to avoid mmc_rescan call in between.

Can you hack/patch the code, or is this in the kernel which is going to be updated every week by apt or dnf?

Another possibility is some option to the module in /etc/modprobe.d, but that's up to you. Some modules have some options which set some things; that's all I know.

Yeah I can hack and make it work, but that is not accepted here , don't know why. The version I am using and current version have many many changes which will make my life painful. I need to know the cause of mmc_rescan. I am not getting specific patch to solve the issue though.

Originally Posted by diptendulinux Yeah I can hack and make it work, but that is not accepted here , don't know why. The version I am using and current version have many many changes which will make my life painful. I need to know the cause of mmc_rescan. I am not getting specific patch to solve the issue though.

If you could hack it, but they don't want you to, why not leave the issue there? Yes, you know what to do but your hands are tied. It's not WON'T_FIX, but buggy software and NOT_ALLOWED_FIX. Keep the focus on the issue.

EDIT: Is there a patch you can revert? That might circumvent the issue in the short term, and file a bug long term.