On Sun, Sep 04, 2011 at 07:50:08PM +, Ben Widawsky wrote:
> So I would rework some of your comments a bit, and I also think it's
> about time we create a central place to cancel workqueue items. Mostly
> because I think this patch is subject to a deadlock with struct_mutex
> (you're holding it
On Sun, Sep 04, 2011 at 09:17:24PM +0200, Daniel Vetter wrote:
> > > spin_lock_irq(&dev_priv->rps_lock);
> > > dev_priv->pm_iir = 0;
> > > + I915_WRITE(GEN6_PMIER, 0);
> > > spin_unlock_irq(&dev_priv->rps_lock);
> > >
> > > I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
> > I'm not sure t
On Sun, Sep 04, 2011 at 05:23:30PM +, Ben Widawsky wrote:
> On Sun, Sep 04, 2011 at 05:35:02PM +0200, Daniel Vetter wrote:
> > The rps disabling code wasn't properly cancelling outstanding work
> > items. Also add a comment that explains why we're not racing with
> > the work item, that could a
On Sun, Sep 04, 2011 at 05:35:02PM +0200, Daniel Vetter wrote:
> The rps disabling code wasn't properly cancelling outstanding work
> items. Also add a comment that explains why we're not racing with
> the work item, that could again unmask interrupts.
>
> This also fixes a bug on module unload be
The rps disabling code wasn't properly cancelling outstanding work
items. Also add a comment that explains why we're not racing with
the work item, that could again unmask interrupts.
This also fixes a bug on module unload because nothing was properly
syncing up with that work item, possibly leadi
