[Intel-gfx] [PATCH 00/19] ILK+ interrupt improvements

Daniel Vetter daniel at ffwll.ch
Wed Jan 22 22:08:20 CET 2014


On Wed, Jan 22, 2014 at 05:52:18PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni at intel.com>
> 
> Hi
> 
> Back in July 2013 I sent an email asking about interrupts and suggesting ways to
> improve our code [0]. Based on those discussions, I submitted a patch series
> proposing some changes [1]. I received some reviews and the general idea was
> accepted, but due to priority changes I couldn't update the series and resend
> it.
> 
> After this, BDW code got merged and, with it, some BDW-specific IRQ macros
> that do basically what I had proposed earlier. So this series tries to reuse
> those BDW macros on ILK+ code.
> 
> I think this series is an improvement because now, if we want to change how we
> treat interrupts, we just need to change the macro and everything gets
> automatically updated. Also, our code is now smaller :)
> 
> In some of the patches I had to decide between adding POSTING_READ calls to the
> macros or leave them on the callers. Adding the calls to the macros means we'll
> call them more times than what is strictly necessary. Not doing that means we
> may forget some POSTING_READ calls at some point. I chose to follow the BDW
> example and leave the task of doing POSTING_READ outside the macros. If we don't
> think this is the best way, I can change it, no problem.

I think for init/fini code which isn't really perf critical it's better to
do the posting reads in the common macros, now that we have them. Imo that
makes them a notch clearer to understand, and the occasionaly superflous
mmio read shouldn't really be noticeable. We have mucher bigger fish to
fry first.

But no need to redo this series, maybe just a todo item for a boring day
once this has all settled a bit.

> I also considered doing the exact same changes to the previous Gens, but I don't
> have hardware to test them, and there's a potential to use some different macros
> due to PIPESTAT handling. So adding Gen2+ support is left as an exercise to
> developers from the future :)

Yeah, pipestat is special and I think it's good if we keep that separate.
But the other registers mostly work the same, so I guess we could reuse
that. Although if we really aim for gen2+ and not gen3+ then we need 16bit
versions ;-)

Again something for a really rainy day, in case someone gets truly upset
with our vlv irq code.

Just figured I'll comment on these two issues, patches themselves look
really nice \o/

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



More information about the Intel-gfx mailing list