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. - Chris. -- Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/> One Laptop Per Child -- 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
