On Fri, Jun 22, 2012 at 9:09 PM, Chris Ball <cjb@xxxxxxxxxx> wrote: > Hi, > > On Fri, Jun 22 2012, T Krishnamoorthy, Balaji wrote: >>>>> After bisecting, this commit dba3c29 is found to ruin micro-SD card data >>>>> (writing incorrect file, or fs is corrupt after several times mount) >>>>> on the beagle-xm revB, and reverting the commit will fix the problem. >>>> >>>> Hi Ming, >>>> Rather than reverting the entire commit, >>>> Can you try with the below change alone, so that AutoCMD12 can be easily >>>> enabled back when needed. >>>> >>>> @@ -1859,7 +1859,6 @@ static int __devinit omap_hsmmc_probe(st >>>> host->mapbase = res->start + pdata->reg_offset; >>>> host->base = ioremap(host->mapbase, SZ_4K); >>>> host->power_mode = MMC_POWER_OFF; >>>> - host->flags = AUTO_CMD12; >>>> host->next_data.cookie = 1; >>>> >>>> platform_set_drvdata(pdev, host); >>> >>> I'm not totally comfortable with that; seems like it should be harder >>> to cause data corruption than turning on a single flag in the host. >>> >>> The full revert is probably best until we know what the underlying >>> bug is, and how to disable AUTO_CMD12 on all affected systems. >> >> I tested autocmd12 to be working on OMAP2,3,4 SDP. With beagle board >> data corruption is observed with some cards, so it is going to be >> selectively enabling/disabling for some SoCs via board data or DT >> until data corruption due to Autocmd12 is root caused. > > So far I agree with Ming that AUTO_CMD12 support should just be reverted > until you understand the root cause circumstances of the corruption and > know how to turn it back on safely. > > I'm not willing to build up a blacklist of which boards don't support it > by waiting for more reports of data corruption, and I'm even reluctant > to use a whitelist until we understand more about the nature of the > whitelist. The effort here should be concentrated on root causing, > not on trying to make per-board decisions without understanding what's > actually going on. OK, revert is the best option until I can reproduce and root cause the issue. -- Thanks and Regards, Balaji T K -- 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
