* Tony Lindgren <tony@xxxxxxxxxxx> [151005 07:44]: > * Tony Lindgren <tony@xxxxxxxxxxx> [151005 04:28]: > > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [151001 03:07]: > > > On Thu, Oct 01, 2015 at 11:50:00AM +0200, Ulf Hansson wrote: > > > > On 1 October 2015 at 11:33, Russell King - ARM Linux > > > > <linux@xxxxxxxxxxxxxxxx> wrote: > > > > > On Thu, Sep 24, 2015 at 04:37:56PM -0700, Tony Lindgren wrote: > > > > >> * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [150924 02:04]: > > > > >> > Nightly testing has revealed that both the OMAP3430 LDP and the OMAP4430 > > > > >> > SDP fail to boot due to lack of working MMC. Both platforms fail to > > > > >> > find their rootfs, which is on a SD card. > > > > >> > > > > > >> > The breakage occurred somewhere between trees of September 9th (commit > > > > >> > 4e4adb2f4628) and September 12th (commit b0a1ea51bda4), so during the > > > > >> > merge window. > > > > >> > > > > >> Yes sorry things got messed up in multiple ways :( I've summarized > > > > >> the mess here earlier: > > > > >> > > > > >> http://article.gmane.org/gmane.linux.kernel.mmc/33911 > > > > >> > > > > >> And today commit b9c93646fd5c ("regulator: pbias: program pbias register > > > > >> offset in pbias driver") hit mainline so I'll send a pull request for > > > > >> the related dts change. > > > > > > > > > > It's still broken and untestable. We're 8 days off it being a full > > > > > month worth of failed testing for OMAP3 and OMAP4 platforms. > > > > > > > > > > I think OMAP and MMC people need to do a post-mortem and work out why > > > > > this happened, and how to stop it happening again in the future. > > > > > > > > You are probably right! > > > > > > > > I think I should have been more persistent when asking on how to deal > > > > with these patches. Typically they should all have gone together via > > > > one tree, or we needed a slower way forward keeping changes more > > > > standalone. > > > > > > > > Anyway, according to kernelci.org, which builds and boot my next > > > > branch omap3/4 seems to boot now... > > > > http://kernelci.org/boot/all/job/ulfh/kernel/v4.3-rc3-27-gf7734d097520/ > > > > > > It continues to fail here. > > > > > > Okay, sod it, I'm at the point of just not giving a damn about whether > > > OMAP3 and OMAP4 boot anymore. > > > > > > I'm taking all OMAP platforms out of my boot farm. I'm totally fed up > > > with this kind of regression happening. It's probably some config option > > > that someone's recently introduced which defaults to being off, thereby > > > breaking the ability for people to move forward without constantly having > > > to re-configure. This is not acceptable. > > > > > > STOP BREAKING THE KERNEL. > > > > I totally agree, this is unacceptable. And I'm fed up chasing driver > > breakage and trying to test everything myself. > > > > If Kihon is not starting to respond to these issues, we better start > > reverting some of the MMC patches. And I'd say in the future non-trivial > > patches really have to sit in linux next for two weeks before merging. > > > > We have still the omap3 legacy booting issue remaining, and warnings > > at least on omap4 overo. > > Sorry i mean Kishon instead of Kihon above. > > Based on some tests it seems that the duovero unpaired regulator usage > is fixed by reverting: > > c55d7a055364 ("mmc: host: omap_hsmmc: use regulator_is_enabled to > find pbias status") With commit c55d7a055364 my guess is that the PBIAS regulator is already on from an earlier MMC probe and getting re-enabled when a deferred probe happens? > And it seems that omap3 legacy MMC is broken earlier in the > series with: > > 7d607f917008 ("mmc: host: omap_hsmmc: use > devm_regulator_get_optional() for vmmc") > > This one does not cleanly revert so have not yet tried reverting > it. And with commit 7d607f917008 I'm guessing we can't return an error if the PBIAS regulator does not exist as that's not there for the legacy booting. 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
