My minnow was broken by: drm/i915: Consolidate forcewake code

[Daniel Vetter]

On Fri, Jan 23, 2015 at 02:43:53PM -0800, Darren Hart wrote:
> +Jani
> 
> Jani, I think this may have inadvertently undone the fix you made for
> us on the MinnowMax.

Do you still remember the patch? Some digging around didn't turn up
anything ...
-Daniel

> 
> On Fri, Jan 23, 2015 at 1:44 PM, Olof Johansson <olof at lixom.net> wrote:
> > Hi Daniel, Mika,
> >
> > For the first time in a few days, -next was bootable last night. I
> > noticed that my Minnowboard Max didn't actually boot though, it got
> > stuck shortly after or during DRM probing:
> >
> > http://arm-soc.lixom.net/bootlogs/next/next-20150123/minnowmax-x86-minnowmax_defconfig.html
> >
> > I bisected it down to the below patch that I failed to find posted
> > (with that subject) anywhere on a public list that I am subscribed to.
> >
> > The patch isn't revertable without considerable effort so I can't
> > double check that it's just this one change, but the commit before
> > that in the branch boots, this one does not.
> >
> >
> > commit fc72355f5c04c40f2916a07e9f8d4b357e2e0a93
> > Author:     Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > AuthorDate: Mon Jan 19 16:20:43 2015 +0200
> > Commit:     Daniel Vetter <daniel.vetter at ffwll.ch>
> > CommitDate: Tue Jan 20 12:36:57 2015 +0100
> >
> >     drm/i915: Consolidate forcewake code
> >
> >     As we now have forcewake domains, take advantage of it
> >     by putting the differences in gen fw handling in data rather
> >     than in code.
> >
> >     In past we have opencoded this quite extensively as the fw handling
> >     is in the fast path. There has also been a lot of cargo-culted
> >     copy'n'pasting from older gens to newer ones.
> >
> >     Now when the releasing of the forcewake is done by deferred timer,
> >     it gives chance to consolidate more. Due to the frequency of actual hw
> >     access being significantly less.
> >
> >     Take advantage of this and generalize the fw handling code
> >     as much as possible. But we still aim to keep the forcewake sequence
> >     particularities for each gen intact. So the access pattern
> >     to fw engines should remain the same.
> >
> >     v2: - s/old_ack/clear_ack (Chris)
> >         - s/post_read/posting_read (Chris)
> >         - less polite commit msg (Chris)
> >
> >     v3: - rebase
> >         - check and clear wake_count in init
> >
> >     v4: - fix posting reads for gen8 (PRTS)
> >
> >     Signed-off-by: Mika Kuoppala <mika.kuoppala at intel.com>
> >     Reviewed-by: Deepak S <deepak.s at linux.intel.com> (v2)
> >     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> 
> 
> -- 
> Darren Hart

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch