Subject: [GIT PULL] ARM: OMAP: DSS hwmod/reset fixes for 3.2

From: [email-masked] (Tony Lindgren)
Date: Fri, 18 Nov 2011 16:06:00 -0800

* Tomi Valkeinen <[email-masked]> [111114 22:31]:
> On Mon, 2011-11-14 at 14:04 -0800, Tony Lindgren wrote:
> > * Paul Walmsley <[email-masked]> [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