public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Grant Grundler <grundler@parisc-linux.org>
Cc: tom.l.nguyen@intel.com, linux-pci@atrey.karlin.mff.cuni.cz,
	linux-kernel@vger.kernel.org, roland@topspin.com,
	davem@davemloft.net
Subject: Re: pci_enable_msi() for everyone?
Date: Sat, 4 Jun 2005 00:18:03 -0700	[thread overview]
Message-ID: <20050604071803.GA13684@suse.de> (raw)
In-Reply-To: <20050604070537.GB8230@colo.lackof.org>

On Sat, Jun 04, 2005 at 01:05:37AM -0600, Grant Grundler wrote:
> On Fri, Jun 03, 2005 at 11:48:21PM -0700, Greg KH wrote:
> > > One complication is some drivers will want to register a different
> > > IRQ handler depending on if MSI is enabled or not.
> > 
> > That's fine, they can always check the device capabilities and do that.
> 
> Can you be more specific?
> Maybe a short chunk of psuedo code?

Hm, here's a possible function to do it (typed into my email client, not
compiled, no warranties, etc...):

/* returns 1 if device is in MSI mode, 0 otherwise */
int pci_in_msi_mode(struct pci_dev *dev)
{
	int pos;
	u16 control;

	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
	if (!pos)
		return 0;
	pci_read_config_word(dev, msi_control_reg(pos), &control);
	if (control & PCI_MSI_FLAGS_ENABLE);
		return 1;
	return 0;
}

> > > If MSI is enabled (and usable), then some MMIO reads can be omitted.
> > > I've posted a patch for tg3 driver:
> > > 	ftp://ftp.parisc-linux.org/patches/diff-2.6.10-tg3_MSI-03
> > > 
> > > (Just an example! It was not accepted because of buggy HW
> > >  though it worked great on the HW I have access to.)
> > > 
> > > drivers/infiniband/hw/mthca driver is another example.
> > 
> > But it doesn't do that yet either ;)
> 
> Sorry - only uses different IRQ handlers for MSI-X support.
> But it could do something different for MSI IRQ handlers as well.

Sure.

> > > How can the driver know which IRQ handlers to register?
> > 
> > Same as always, use the dev->irq field like they do today.
> 
> I think you misunderstood my question.
> The driver uses dev->irq as a "token" to register *some* IRQ handler.
> If the driver wants to register "tg3_irq_nommioread()" for the
> MSI case and "tg3_irq()" for Line Based IRQ case, how would the
> driver know which IRQ handler it should register?
> 
> The arch IRQ support knows the difference and currently returns
> that status in the pci_msi_enable() call.

If you use the above function, then you can tell the difference and
register different irq handlers if you wish.

The main point being is that the pci_enable_msi() function would not
have to be explicitly called by your driver, it would have already been
taken care of earlier by the PCI core.  That's what I want to do and am
wondering if there would be any bad side affects to it.

thanks,

greg k-h

  reply	other threads:[~2005-06-04  7:18 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-03 22:45 pci_enable_msi() for everyone? Greg KH
2005-06-03 23:16 ` Jeff Garzik
2005-06-04  0:01   ` Benjamin Herrenschmidt
2005-06-04  0:08     ` Jeff Garzik
2005-06-04  0:16       ` Benjamin Herrenschmidt
2005-06-04  0:34         ` Jeff Garzik
2005-06-04  6:51   ` Greg KH
2005-06-03 23:36 ` Roland Dreier
2005-06-06 22:58   ` Greg KH
2005-06-07  0:23     ` Roland Dreier
2005-06-07  5:19       ` Greg KH
2005-06-04  1:31 ` Grant Grundler
2005-06-04  6:48   ` Greg KH
2005-06-04  7:05     ` Grant Grundler
2005-06-04  7:18       ` Greg KH [this message]
2005-06-04  7:23         ` Dave Jones
2005-06-04 14:58           ` Roland Dreier
2005-06-06 23:01           ` Greg KH
2005-06-07  0:26             ` Roland Dreier
2005-06-07  5:22               ` Greg KH
2005-06-07  5:46                 ` Adam Belay
2005-06-07 17:43                   ` Luben Tuikov
2005-06-05 22:00         ` Benjamin Herrenschmidt
2005-06-06 23:00           ` Greg KH
2005-06-06 23:56             ` Benjamin Herrenschmidt
2005-06-05 19:46 ` David S. Miller
2005-06-06 22:55   ` Greg KH
2005-06-06 22:59     ` David S. Miller
2005-06-06 23:09       ` Greg KH
2005-06-06 23:08     ` Jeff Garzik
2005-06-06 23:10       ` David S. Miller
2005-06-06 23:13       ` Greg KH
2005-06-06 23:53         ` Jeff Garzik
2005-06-06 23:56           ` Greg KH
2005-06-06 23:58           ` David S. Miller
2005-06-07  4:24       ` Grant Grundler
2005-06-07  0:18     ` Roland Dreier
2005-06-07  5:21       ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2005-06-07 22:33 Nguyen, Tom L

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=20050604071803.GA13684@suse.de \
    --to=gregkh@suse.de \
    --cc=davem@davemloft.net \
    --cc=grundler@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=roland@topspin.com \
    --cc=tom.l.nguyen@intel.com \
    /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