linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nguyen, Tom L" <tom.l.nguyen@intel.com>
To: "Zwane Mwaikambo" <zwane@arm.linux.org.uk>
Cc: "Linux Kernel" <linux-kernel@vger.kernel.org>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	"long" <tlnguyen@snoqualmie.dp.intel.com>
Subject: RE: Updated MSI Patches
Date: Tue, 12 Aug 2003 10:04:34 -0700	[thread overview]
Message-ID: <C7AB9DA4D0B1F344BF2489FA165E5024015416F5@orsmsx404.jf.intel.com> (raw)

> diff -X excludes -urN linux-2.6.0-test2/arch/i386/kernel/io_apic.c linux-2.6.0-test2-create-vectorbase/arch/i386/kernel/io_apic.c
> --- linux-2.6.0-test2/arch/i386/kernel/io_apic.c	2003-07-27 13:00:21.000000000 -0400
> +++ linux-2.6.0-test2-create-vectorbase/arch/i386/kernel/io_apic.c	2003-08-05 09:25:54.000000000 -0400
> @@ -76,6 +76,20 @@
>  	int apic, pin, next;
>  } irq_2_pin[PIN_MAP_SIZE];
>  
> +#ifdef CONFIG_PCI_USE_VECTOR
> +int vector_irq[NR_IRQS] = { [0 ... NR_IRQS -1] = -1};
> + 
> +static int platform_irq(int irq) 	
> +{ 	
> +	if (platform_legacy_irq(irq))
> +		return irq;
> +	else
> +		return vector_irq[irq];
> +}
> +#else
> +#define platform_irq(irq)	(irq)
> +#endif 

> I wish you wouldn't mix up vector and irq like this :( This is really 
> beginning to look like IPF. When is an irq an irq and when is a vector a 
> vector? This can get very confusing very quickly. I spent a fair 
> amount of time debugging this last time due to the confusion in the 
> common_interrupt -> do_IRQ path, i'd hate for this to be a permanent 
> fixture. If you're going to change things just change everything 
> (including variable names) instead of making it conditional.
I understand that mixing up vector and irq is very confusing. However, to support non-PCI legacy devices with IRQ less than 16, such as keyboard and mouse for example, may be impossilbe to achieve without mixing up. Some existing driver of legacy keyboard/mouse devices, for example, may use fixed IO ranges and fixed IRQs (as assigned to 1 for keyboard and 12 for mouse). If these device drivers use these fixed legacy IRQs and the interrupt routings for these non-PCI legacy devices use vectors, then the system may break. As you know, MSI support requires vector allocation instead of IRQ allocation since MSI does not require a support of BIOS IRQ table. Mixing vector with IRQ to be compatible with non-PCI legacy devices must be achieved. Last time, your suggestion of changing variable name from irq to vector is the good approach. I am looking at restructuring the code of the vector-base patch. I will send you an update when I am done for your feedback.

> diff -X excludes -urN linux-2.6.0-test2-create-vectorbase/arch/i386/kernel/io_apic.c linux-2.6.0-test2-create-msi/arch/i386/kernel/io_apic.c
> --- linux-2.6.0-test2-create-vectorbase/arch/i386/kernel/io_apic.c	2003-08-05 09:25:54.000000000 -0400
> +++ linux-2.6.0-test2-create-msi/arch/i386/kernel/io_apic.c	2003-08-05 09:45:25.000000000 -0400
> @@ -427,6 +427,11 @@
>  			/* Is this an active IRQ? */
>  			if (!irq_desc[j].action)
>  				continue;
> +#ifdef CONFIG_PCI_MSI
> +			/* Is this an active MSI? */
> +			if (msi_desc[j])
> +				continue;
> +#endif

> Is there any locking for msi_desc? Or are you relying on something else?
Since the code determinces whether this entry is NULL or not, I think any locking for msi_desc may not be required.


> +	if (current_vector == FIRST_SYSTEM_VECTOR) 
> +		panic("ran out of interrupt sources!");

> Please just fail and return -ENOSPC or something like that.
Good. Thanks!

Thanks,
Long


             reply	other threads:[~2003-08-12 17:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-12 17:04 Nguyen, Tom L [this message]
2003-08-12 18:11 ` Updated MSI Patches Zwane Mwaikambo
  -- strict thread matches above, loose matches on Subject: below --
2003-10-03 22:15 long
2003-10-01 18:26 Nguyen, Tom L
2003-10-01 15:37 long
2003-10-01 17:09 ` Jeff Garzik
2003-08-22 18:25 long
2003-08-19 15:42 Nguyen, Tom L
2003-08-14 23:46 Nguyen, Tom L
2003-08-13 15:19 Nguyen, Tom L
2003-08-13  4:14 Nakajima, Jun
2003-08-13  1:34 Nakajima, Jun
2003-08-13  1:37 ` Zwane Mwaikambo
2003-08-12 23:59 Nakajima, Jun
2003-08-13  0:48 ` Zwane Mwaikambo
2003-08-12 18:36 Nakajima, Jun
2003-08-12 18:48 ` Jeff Garzik
2003-08-12 19:14   ` Zwane Mwaikambo
2003-08-12 19:44     ` Jeff Garzik
2003-08-12 17:32 Nguyen, Tom L
2003-08-12 18:14 ` Zwane Mwaikambo
2003-08-12 15:22 long
2003-08-11 20:51 long
2003-08-11 21:16 ` Greg KH
2003-08-12  1:41   ` Zwane Mwaikambo
2003-08-12  5:53     ` Greg KH
2003-08-08 19:33 long
2003-08-08 20:15 ` Greg KH
2003-08-08 14:41 Nguyen, Tom L
2003-08-07 23:07 Nakajima, Jun
2003-08-07 21:25 long
2003-08-07 22:14 ` Greg KH
2003-08-07 22:44 ` Jeff Garzik
2003-08-07 23:03   ` Matt Porter
2003-08-08  2:36 ` Zwane Mwaikambo

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=C7AB9DA4D0B1F344BF2489FA165E5024015416F5@orsmsx404.jf.intel.com \
    --to=tom.l.nguyen@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tlnguyen@snoqualmie.dp.intel.com \
    --cc=zwane@arm.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).