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. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
