* Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> [140904 01:46]: > On 09/03/2014 08:39 PM, Tony Lindgren wrote: > >> good.txt and bad.txt are from the late_initcall. > >> > >> $ diff -u good.txt bad.txt > >> --- good.txt 2014-09-03 10:29:58.920317368 +0200 > >> +++ bad.txt 2014-09-03 10:28:57.064313222 +0200 > > > > Hmm can you check that you have good.txt and bad.txt the > > right way? I'd assume you need VAUX2 or VAUX3 enabled > > not disabled for the MMC to work? > > No, it was correct. If you look at the complete file you will notice > the - which removes the mmc detect/mount in the bad case and + which > adds the -110 error ... > With that patch it seems it is a little harder to trigger. It is > usually every other boot that fails. Here a diff between two that > worked (say good-v1 vs good-v2): ... > It took mmc a little longer to detect but it worked. And the content of > the three registers seem not to matter _or_ it was dumped before MMC > got active. ... > I didn't change a thing, I just pressed reset. As you see the content > of the TWL registers don't seem to be that important since it was the > same at the time of the dump. And the mmc didn't came back. OK. I guess that means that it's most likely some timing related issue, or an issue with some regulator not being ready by the time the MMC probes. Or it's a bug somewhere that I'm not figuring out. Looking at the twl-regulator.c, twl4030reg_enable just sets the group bit and we're not checking any status and don't have startup-delay-us for them. At least phy-twl4030-usb.c has twl4030_i2c_write_u8_verify(), I wonder if adding a read back of the register to twl-regulator.c would help? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
