* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [111114 22:31]: > On Mon, 2011-11-14 at 14:04 -0800, Tony Lindgren wrote: > > * Paul Walmsley <paul@xxxxxxxxx> [111114 13:05]: > > > On Mon, 14 Nov 2011, Tony Lindgren wrote: > > > > > > > I suggest we only merge the ones with "fix" in the subject during the -rc > > > > cycle. The others add new features for the reset, so they should wait until > > > > v3.3 merge window. > > > > > > Most of the other patches in the branch discuss what they fix in the patch > > > descriptions, rather than the subject lines. Do you want the subject > > > lines rewritten to highlight this? > > > > Well we should only merge major bugs and regressions during the -rc cycle. > > It seems that at least "OMAP: HWMOD: Unify DSS resets for OMAPs" has high > > flame potential based on that? Maybe we should wait until the next merge > > window to start removing some of these workarounds? > > I'm not sure what you mean... > > The "Unify DSS resets..." patch itself fixes only a minor bug: "This > causes causes the HWMOD reset to fail for dss_dispc and dss_rfbi". But > it makes the next patch, "Ensure DSS works correctly...", possible. And > that patch fixes a bigger bug, DSS or the whole device hanging if the > bootloader had enabled the display (which I believe is the default on > the shipped beagles/pandas). > > There's one patch in the series that is not a fix, though: "ARM: OMAP4: > HWMOD: remove extra clocks". I'm fine with queuing that for the next > merge window. But most of the patches have now somehow missed two merge > windows, and I'd really like to get them in. OK let's try to get them in then. Hopefully after these DSS will be more independent from the core omap changes. 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
