On Sun, 15 Jan 2012 16:03:28 +0100, Daniel Vetter wrote:
> Having the one-liner fix as separate patch makes backporting to 3.2
> simpler. But I don't care much, so if you amend your commit to mention
> the small fix hidden in the cleanup and add a note that the fix needs
> to go to 3.2-stable tha
On Sun, Jan 15, 2012 at 07:35, Keith Packard wrote:
> On Sat, 14 Jan 2012 13:12:07 +0100, Daniel Vetter wrote:
>
>> I think that race is air-tight with your patch to rework the reset code
>> already. But better safe than sorry. And as I've said a good cleanup
>> anyway.
>
> Sounds good. I like cl
On Sat, 14 Jan 2012 13:12:07 +0100, Daniel Vetter wrote:
> I think that race is air-tight with your patch to rework the reset code
> already. But better safe than sorry. And as I've said a good cleanup
> anyway.
Sounds good. I like clearer code, especially when it doesn't cost
performance. I thi
On Fri, Jan 13, 2012 at 04:50:39PM -0800, Keith Packard wrote:
> On Sat, 14 Jan 2012 01:31:40 +0100, Daniel Vetter wrote:
> > On Fri, Jan 13, 2012 at 04:11:43PM -0800, Keith Packard wrote:
> > > On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wrote:
> > > > acc101d drm/i915: Hold gt_lock across
On Sat, 14 Jan 2012 01:31:40 +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2012 at 04:11:43PM -0800, Keith Packard wrote:
> > On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wrote:
> > > acc101d drm/i915: Hold gt_lock across forcewake register reads
> > >
> > > Imo this is a simple cleanup (re
On Fri, Jan 13, 2012 at 04:11:43PM -0800, Keith Packard wrote:
> On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wrote:
> > acc101d drm/i915: Hold gt_lock across forcewake register reads
> >
> > Imo this is a simple cleanup (reading forcewake-protected registers isn't
> > really a fast-path for
On Sat, 14 Jan 2012 00:52:31 +0100, Daniel Vetter wrote:
> - I think we need to amend the commit msg of the voodoo patch with the
> piece of doc I've discovered. If you want I can send out a v3 with that.
Sounds good.
> - I think the HWSTAM revert is material for -next
I'd be OK with pushing
On Sat, Jan 14, 2012 at 12:52:31AM +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2012 at 08:42:00AM -0800, Keith Packard wrote:
> > On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
> > wrote:
> >
> > > Two things seem to do the trick on my ivb machine here:
> > > - prevent the gt from powering
On Fri, Jan 13, 2012 at 08:42:00AM -0800, Keith Packard wrote:
> On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
> wrote:
>
> > Two things seem to do the trick on my ivb machine here:
> > - prevent the gt from powering down while waiting for seqno
> > notification interrupts by grabbing the
On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering
On Tue, Jan 10, 2012 at 08:44:20PM -0800, Keith Packard wrote:
> On Tue, 10 Jan 2012 16:51:08 -0800, Eric Anholt wrote:
>
> > So they've gone out of their way to build broken stuff. Awesome.
>
> Well, in theory, the interrupt would be generated *before* the hardware
> goes to RC6; when idle, I'
On 01/10/2012 08:44 PM, Keith Packard wrote:
> On Tue, 10 Jan 2012 16:51:08 -0800, Eric Anholt wrote:
>
>> So they've gone out of their way to build broken stuff. Awesome.
>
> Well, in theory, the interrupt would be generated *before* the hardware
> goes to RC6; when idle, I'm not exactly sure
On 01/10/2012 04:20 AM, Daniel Vetter wrote:
On Wed, Jan 04, 2012 at 07:40:45PM +0100, Daniel Vetter wrote:
Two things seem to do the trick on my ivb machine here:
- prevent the gt from powering down while waiting for seqno
notification interrupts by grabbing the force_wake in get_irq (and
On Tue, 10 Jan 2012 16:51:08 -0800, Eric Anholt wrote:
> So they've gone out of their way to build broken stuff. Awesome.
Well, in theory, the interrupt would be generated *before* the hardware
goes to RC6; when idle, I'm not exactly sure what the hardware would be
doing to generate interrupts.
On Tue, 10 Jan 2012 13:20:06 +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 07:40:45PM +0100, Daniel Vetter wrote:
> > Two things seem to do the trick on my ivb machine here:
> > - prevent the gt from powering down while waiting for seqno
> > notification interrupts by grabbing the force_
On Wed, Jan 04, 2012 at 07:40:45PM +0100, Daniel Vetter wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - orderi
On Thu, 5 Jan 2012 23:29:44 +, Ben Widawsky wrote:
> Please please please make it clear that we still don't understand exactly why
> this works.
If the word 'voodoo' isn't sufficient, I don't know what is...
--
keith.pack...@intel.com
pgpMoLfKZzW2d.pgp
Description: PGP signature
On Fri, Jan 6, 2012 at 00:29, Ben Widawsky wrote:
> Please please please make it clear that we still don't understand exactly why
> this works.
I've hoped that the words "voodoo" and "magic" in the headline of the
commit msg make that clear ;-)
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +
On Wed, 4 Jan 2012 17:52:10 +0100, Daniel Vetter
wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering
On Wed, Jan 04, 2012 at 05:52:10PM +0100, Daniel Vetter wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - orderi
On Thu, Jan 5, 2012 at 09:13, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 06:27:40PM -0800, Keith Packard wrote:
> > On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter <
> daniel.vet...@ffwll.ch> wrote:
> >
> > > Two things seem to do the trick on my ivb machine here:
> > > - prevent the gt fro
On Wed, Jan 04, 2012 at 06:27:40PM -0800, Keith Packard wrote:
> On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
> wrote:
>
> > Two things seem to do the trick on my ivb machine here:
> > - prevent the gt from powering down while waiting for seqno
> > notification interrupts by grabbing the
On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering
Two things seem to do the trick on my ivb machine here:
- prevent the gt from powering down while waiting for seqno
notification interrupts by grabbing the force_wake in get_irq (and
dropping it in put_irq again).
- ordering writes from the ring's CS by reading a CS register, ACTHD
seems to w
On Wed, Jan 4, 2012 at 14:52, Daniel Vetter wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering writes fr
Two things seem to do the trick on my ivb machine here:
- prevent the gt from powering down while waiting for seqno
notification interrupts by grabbing the force_wake in get_irq (and
dropping it in put_irq again).
- ordering writes from the ring's CS by reading a CS register, ACTHD
seems to w
26 matches
Mail list logo
