The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Lyude Paul <lyude@redhat.com>
Cc: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"keith.busch@intel.com" <keith.busch@intel.com>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>
Subject: Re: "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel
Date: Thu, 25 Jan 2018 21:12:13 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1801252109570.2203@nanos> (raw)
In-Reply-To: <1516908343.5161.4.camel@redhat.com>

On Thu, 25 Jan 2018, Lyude Paul wrote:
> On Thu, 2018-01-25 at 19:46 +0100, Thomas Gleixner wrote:
> > On Thu, 25 Jan 2018, Lyude Paul wrote:
> > 
> > > I think you are right, apologies. Glad to know this isn't a regression in
> > > the
> > > IRQ handling code :). It looks like our nouveau problems are probably coming
> > > from the fact that we don't just leave IRQs setup through suspend/resume
> > > which
> > > as far as I can tell, is probably not the correct thing to do.
> > 
> > If you tear down the interrupt, then you have to make sure that it's
> > completely masked and disabled on the device side (including MSI).
> Does this only need to be done if we handle irq_request()/irq_free() ourselves,
> or can we skip some of these steps if we let the kernel handle
> disabling/enabling IRQs during s/r?

If you do not free the interrupt on suspend, then the core does the right
thing. Though you should not inflict an interrupt storm in that case either :)

Thanks,

	tglx

  reply	other threads:[~2018-01-25 20:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 22:01 "irq/matrix: Spread interrupts on allocation" breaks nouveau in mainline kernel Lyude Paul
2018-01-24  1:26 ` Lyude Paul
2018-01-24 12:52   ` Thomas Gleixner
2018-01-24 17:49     ` Lyude Paul
2018-01-24 19:13       ` Ghannam, Yazen
2018-01-24 19:56         ` Lyude Paul
2018-01-24 20:02           ` Lyude Paul
2018-01-25  3:29             ` Mike Galbraith
2018-01-25 18:29               ` Lyude Paul
2018-01-25  8:54           ` Thomas Gleixner
2018-01-25 18:23             ` Lyude Paul
2018-01-25 18:46               ` Thomas Gleixner
2018-01-25 19:25                 ` Lyude Paul
2018-01-25 20:12                   ` Thomas Gleixner [this message]
2018-01-24 12:50 ` Thomas Gleixner
2018-01-24 13:38   ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1801252109570.2203@nanos \
    --to=tglx@linutronix.de \
    --cc=Yazen.Ghannam@amd.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=mingo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox