Skip to contentSkip to conversation

x86: print out irq nr for msi/ht -v2

PATCH Applied Yinghai Lu 9 participants 17 messages Sep 25, 2008 – Sep 30, 2008

Subsystems (3)
lore
Share & tools
lore

Yinghai Lu

author
#0 lore raw

PATCH 7/7 x86: print out irq nr for msi/ht -v2

v2: fix hpet compiling

---
 arch/x86/kernel/hpet.c    |    3 +++
 arch/x86/kernel/io_apic.c |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)
arch/x86/kernel/hpet.c +3 -0
index 422c577..686505a 100644
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_dev *dev)
 	irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
 	enable_irq(dev->irq);
 
+	printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+			 dev->name, dev->irq, dev->irq);
+
 	return 0;
 }
 
arch/x86/kernel/io_apic.c +7 -0
index 4cc9cb6..dc82397 100644
@@ -3355,6 +3355,9 @@ static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc, int irq)
 #endif
 		set_irq_chip_and_handler_name(irq, &msi_chip, handle_edge_irq, "edge");
 
+	printk(KERN_DEBUG "PCI: %s is using irq %#x aka %d for MSI/MSI-X\n",
+			 pci_name(dev), irq, irq);
+
 	return 0;
 }
 
@@ -3587,6 +3590,7 @@ int arch_setup_hpet_msi(unsigned int irq)
 	hpet_msi_write(irq, &msg);
 	set_irq_chip_and_handler_name(irq, &hpet_msi_type, handle_edge_irq,
 		"edge");
+
 	return 0;
 }
 #endif
@@ -3683,6 +3687,9 @@ int arch_setup_ht_irq(unsigned int irq, struct pci_dev *dev)
 
 		set_irq_chip_and_handler_name(irq, &ht_irq_chip,
 					      handle_edge_irq, "edge");
+
+		printk(KERN_DEBUG "PCI: %s is using irq %#x aka %d for HT\n",
+				 pci_name(dev), irq, irq);
 	}
 	return err;
 }
Signature · 1 line
1.5.6
Applied
#1 lore raw
Quoted 7 lines · Yinghai Lu

v2: fix hpet compiling

---
 arch/x86/kernel/hpet.c    |    3 +++
 arch/x86/kernel/io_apic.c |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

applied to tip/irq/sparseirq, thanks Yinghai.

Ingo

#2 lore raw
Quoted 2 lines
Quoted 2 lines

v2: fix hpet compiling

still bad:

arch/x86/kernel/hpet.c: In function ‘hpet_late_init’:
arch/x86/kernel/hpet.c:828: error: ‘dev’ undeclared (first use in this function) arch/x86/kernel/hpet.c:828: error: (Each undeclared identifier is reported only once arch/x86/kernel/hpet.c:828: error: for each function it appears in.)

we've got some changes in this area (per cpu hpet).

Ingo

#3 lore raw
Quoted 11 lines · Ingo Molnar
Quoted 2 lines
Quoted 2 lines

v2: fix hpet compiling

still bad:

arch/x86/kernel/hpet.c: In function 'hpet_late_init':
arch/x86/kernel/hpet.c:828: error: 'dev' undeclared (first use in this function) arch/x86/kernel/hpet.c:828: error: (Each undeclared identifier is reported only once arch/x86/kernel/hpet.c:828: error: for each function it appears in.)

we've got some changes in this area (per cpu hpet).

will check it.

YH

#4 lore raw
In reply to Ingo Molnar
Quoted 12 lines · Ingo Molnar
Quoted 2 lines
Quoted 2 lines

v2: fix hpet compiling

still bad:

arch/x86/kernel/hpet.c: In function 'hpet_late_init':
arch/x86/kernel/hpet.c:828: error: 'dev' undeclared (first use in this function) arch/x86/kernel/hpet.c:828: error: (Each undeclared identifier is reported only once arch/x86/kernel/hpet.c:828: error: for each function it appears in.)

we've got some changes in this area (per cpu hpet).

looks there is some merge problem.

arch/x86/kernel/hpet.c +3 -0
Index: linux-2.6/arch/x86/kernel/hpet.c
===================================================================
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_de
        irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
        enable_irq(dev->irq);
 
+       printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+                        dev->name, dev->irq, dev->irq);
+
        return 0;
 }
 

the change should be in hpet_setup_irq instead of hpet_late_init

the patch can be applied to tip/master cleanly.

YH

#5 lore raw
Quoted 32 lines · Yinghai Lu
Quoted 12 lines · Ingo Molnar
Quoted 2 lines
Quoted 2 lines

v2: fix hpet compiling

still bad:

arch/x86/kernel/hpet.c: In function 'hpet_late_init':
arch/x86/kernel/hpet.c:828: error: 'dev' undeclared (first use in this function) arch/x86/kernel/hpet.c:828: error: (Each undeclared identifier is reported only once arch/x86/kernel/hpet.c:828: error: for each function it appears in.)

we've got some changes in this area (per cpu hpet).

looks there is some merge problem.

Index: linux-2.6/arch/x86/kernel/hpet.c
===================================================================

arch/x86/kernel/hpet.c +3 -0
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_de
        irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
        enable_irq(dev->irq);
 
+       printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+                        dev->name, dev->irq, dev->irq);
+
        return 0;
 }
 

the change should be in hpet_setup_irq instead of hpet_late_init

Quoted 1 line

the patch can be applied to tip/master cleanly.

ok, figure it out, the problem was that your change depended on tip/timers/hpet-percpu.

sorted it out.

Ingo

#7 lore raw
In reply to Yinghai Lu
Quoted 13 lines · Yinghai Lu

v2: fix hpet compiling

---
 arch/x86/kernel/hpet.c    |    3 +++
 arch/x86/kernel/io_apic.c |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)
arch/x86/kernel/hpet.c +0 -0
index 422c577..686505a 100644

arch/x86/kernel/hpet.c static int hpet_setup_irq(struct hpet_dev *dev) · line 472

Quoted 6 lines
arch/x86/kernel/hpet.c +3 -0
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_dev *dev)
 	irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
 	enable_irq(dev->irq);
 
+	printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+			 dev->name, dev->irq, dev->irq);
+

Why do we want to print the irq as hex? Do we do that anywhere else? I think we should pick one format and stick with it, and I think decimal is the logical choice because it's the most common.

#8 lore raw
Quoted 17 lines · Bjorn Helgaas
Quoted 16 lines · Yinghai Lu

v2: fix hpet compiling

---
 arch/x86/kernel/hpet.c    |    3 +++
 arch/x86/kernel/io_apic.c |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)
arch/x86/kernel/hpet.c +0 -0
index 422c577..686505a 100644
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_dev *dev)
      irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
      enable_irq(dev->irq);
 
Quoted 7 lines

arch/x86/kernel/hpet.c static int hpet_setup_irq(struct hpet_dev *dev) · line 472

Quoted 3 lines
arch/x86/kernel/hpet.c +3 -0
+     printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+                      dev->name, dev->irq, dev->irq);
+

Why do we want to print the irq as hex? Do we do that anywhere else? I think we should pick one format and stick with it, and I think decimal is the logical choice because it's the most common.

when sparseirq is enabled, irq for msi will be bus_nr/dev/func + 12bits. so show it as hex is more straight. but we can not use hex in /proc/interrupts --ABI want decimal.

just try to print out...in log, so user could get some idea that who is using it...

YH

#9 lore raw
Quoted 26 lines · Yinghai Lu
Quoted 17 lines · Bjorn Helgaas
Quoted 16 lines · Yinghai Lu

v2: fix hpet compiling

---
 arch/x86/kernel/hpet.c    |    3 +++
 arch/x86/kernel/io_apic.c |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)
arch/x86/kernel/hpet.c +0 -0
index 422c577..686505a 100644
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_dev *dev)
      irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
      enable_irq(dev->irq);
 
Quoted 7 lines

arch/x86/kernel/hpet.c static int hpet_setup_irq(struct hpet_dev *dev) · line 472

Quoted 3 lines
arch/x86/kernel/hpet.c +3 -0
+     printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+                      dev->name, dev->irq, dev->irq);
+

Why do we want to print the irq as hex? Do we do that anywhere else? I think we should pick one format and stick with it, and I think decimal is the logical choice because it's the most common.

Quoted 6 lines

when sparseirq is enabled, irq for msi will be bus_nr/dev/func + 12bits. so show it as hex is more straight. but we can not use hex in /proc/interrupts --ABI want decimal.

just try to print out...in log, so user could get some idea that who is using it...

I think it'd be better to just print the MSI IRQ number in decimal using a dev_printk(). Then the connection is obvious and we don't need to make everything ugly by having IRQs in both decimal and hex.

I know it's a nuisance to make hpet use dev_printk because it's pretty muddled as far as getting a struct device. But I'd rather fix that than add confusion like this.

Bjorn

#10 lore raw
Quoted 34 lines · Bjorn Helgaas
Quoted 26 lines · Yinghai Lu
Quoted 17 lines · Bjorn Helgaas
Quoted 16 lines · Yinghai Lu

v2: fix hpet compiling

---
 arch/x86/kernel/hpet.c    |    3 +++
 arch/x86/kernel/io_apic.c |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)
arch/x86/kernel/hpet.c +0 -0
index 422c577..686505a 100644
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_dev *dev)
      irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
      enable_irq(dev->irq);
 
Quoted 7 lines

arch/x86/kernel/hpet.c static int hpet_setup_irq(struct hpet_dev *dev) · line 472

Quoted 3 lines
arch/x86/kernel/hpet.c +3 -0
+     printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+                      dev->name, dev->irq, dev->irq);
+

Why do we want to print the irq as hex? Do we do that anywhere else? I think we should pick one format and stick with it, and I think decimal is the logical choice because it's the most common.

Quoted 6 lines

when sparseirq is enabled, irq for msi will be bus_nr/dev/func + 12bits. so show it as hex is more straight. but we can not use hex in /proc/interrupts --ABI want decimal.

just try to print out...in log, so user could get some idea that who is using it...

Quoted 7 lines

I think it'd be better to just print the MSI IRQ number in decimal using a dev_printk(). Then the connection is obvious and we don't need to make everything ugly by having IRQs in both decimal and hex.

I know it's a nuisance to make hpet use dev_printk because it's pretty muddled as far as getting a struct device. But I'd rather fix that than add confusion like this.

incidentally, in tip/timers/hpet-percpu [ new feature tree: MSI HPETs with per-CPU clockevents ] we have grown a struct device in that place, so it was easy :)

Ingo

#11 lore raw

[Ingo Molnar - Sat, Sep 27, 2008 at 08:53:06PM +0200] |
...

A bit offtopic...well...completely offtopic I would say :)

Ingo maybe you have any PCI specs? I've asked several people for this. Peter adviced to ask HW vendors but I don't have friends who has access to a such docs. Evgeniy Polyakov promised to ask someone but I think there will not be success too :(. I'll ask Maciej too later since now he seems to be quite busy.

- Cyrill -

#12 lore raw
Quoted 4 lines · Cyrill Gorcunov

[Ingo Molnar - Sat, Sep 27, 2008 at 08:53:06PM +0200]

...

Quoted 8 lines

A bit offtopic...well...completely offtopic I would say :)

Ingo maybe you have any PCI specs? I've asked several people for this. Peter adviced to ask HW vendors but I don't have friends who has access to a such docs. Evgeniy Polyakov promised to ask someone but I think there will not be success too :(. I'll ask Maciej too later since now he seems to be quite busy.

I think if you use google you can find the PCI spec in pdf form (search for pci pdf probably). The MindShare books are also quite good, and cover PCI, PCI-X, and PCI Express in great detail (far more readable than the spec too).

Signature · 1 line
Jesse Barnes, Intel Open Source Technology Center
#13 lore raw

[Jesse Barnes - Mon, Sep 29, 2008 at 10:05:02AM -0700]

| On Saturday, September 27, 2008 12:02 pm Cyrill Gorcunov wrote:
| > [Ingo Molnar - Sat, Sep 27, 2008 at 08:53:06PM +0200]
| >
| > ...
| >
| > A bit offtopic...well...completely offtopic I would say :)
| >
| > Ingo maybe you have any PCI specs? I've asked several people
| > for this. Peter adviced to ask HW vendors but I don't have
| > friends who has access to a such docs. Evgeniy Polyakov
| > promised to ask someone but I think there will not be success
| > too :(. I'll ask Maciej too later since now he seems to be
| > quite busy.
| 
| I think if you use google you can find the PCI spec in pdf form (search for 
| pci pdf probably).  The MindShare books are also quite good, and cover PCI, 
| PCI-X, and PCI Express in great detail (far more readable than the spec too).
| 
| -- 
| Jesse Barnes, Intel Open Source Technology Center
| 

Thanks for reply, Jesse! Of course I could use google. But actually the only think I found is version 2.2 (which is a bit old). Will take a look if I could buy this book (not sure if it may be done here). PCI membership is quite expencive for me that is why I was asking for this documents in private mails I sent before. I don't like to behave like that but just had to.

- Cyrill -

#14 lore raw
Quoted 17 lines · Cyrill Gorcunov

[Jesse Barnes - Mon, Sep 29, 2008 at 10:05:02AM -0700]

| On Saturday, September 27, 2008 12:02 pm Cyrill Gorcunov wrote:
| > [Ingo Molnar - Sat, Sep 27, 2008 at 08:53:06PM +0200]
| >
| > ...
| >
| > A bit offtopic...well...completely offtopic I would say :)
| >
| > Ingo maybe you have any PCI specs? I've asked several people
| > for this. Peter adviced to ask HW vendors but I don't have
| > friends who has access to a such docs. Evgeniy Polyakov
| > promised to ask someone but I think there will not be success
| > too :(. I'll ask Maciej too later since now he seems to be
| > quite busy.
| 
| I think if you use google you can find the PCI spec in pdf form (search for 
| pci pdf probably).

Not probably. You will find them that way.

It is illegal for anyone to redistribute PCISIG copyrighted documents. That hasn't stopped it from happening. I've pointed this out in the past (and got a polite "please don't point that out again publicly"). I'm glad Jesse did instead. :)

Quoted 2 lines

The MindShare books are also quite good, and cover PCI,
| PCI-X, and PCI Express in great detail (far more readable than the spec too).

+1

grant

Quoted 17 lines
| 
| -- 
| Jesse Barnes, Intel Open Source Technology Center
| 

Thanks for reply, Jesse! Of course I could use google. But actually the only think I found is version 2.2 (which is a bit old). Will take a look if I could buy this book (not sure if it may be done here). PCI membership is quite expencive for me that is why I was asking for this documents in private mails I sent before. I don't like to behave like that but just had to.

- Cyrill -
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#15 lore raw
Quoted 26 lines · Grant Grundler
Quoted 17 lines · Cyrill Gorcunov

[Jesse Barnes - Mon, Sep 29, 2008 at 10:05:02AM -0700]

| On Saturday, September 27, 2008 12:02 pm Cyrill Gorcunov wrote:
| > [Ingo Molnar - Sat, Sep 27, 2008 at 08:53:06PM +0200]
| >
| > ...
| >
| > A bit offtopic...well...completely offtopic I would say :)
| >
| > Ingo maybe you have any PCI specs? I've asked several people
| > for this. Peter adviced to ask HW vendors but I don't have
| > friends who has access to a such docs. Evgeniy Polyakov
| > promised to ask someone but I think there will not be success
| > too :(. I'll ask Maciej too later since now he seems to be
| > quite busy.
|
| I think if you use google you can find the PCI spec in pdf form (search for
| pci pdf probably).

Not probably. You will find them that way.

It is illegal for anyone to redistribute PCISIG copyrighted documents. That hasn't stopped it from happening. I've pointed this out in the past (and got a polite "please don't point that out again publicly"). I'm glad Jesse did instead. :)

Quoted 20 lines
Quoted 2 lines

The MindShare books are also quite good, and cover PCI,
| PCI-X, and PCI Express in great detail (far more readable than the spec too).

+1

grant

Quoted 13 lines
|
| --
| Jesse Barnes, Intel Open Source Technology Center
|

Thanks for reply, Jesse! Of course I could use google. But actually the only think I found is version 2.2 (which is a bit old). Will take a look if I could buy this book (not sure if it may be done here). PCI membership is quite expencive for me that is why I was asking for this documents in private mails I sent before. I don't like to behave like that but just had to.

- Cyrill -

Yes, the only acceptable solution is to buy one of these books - I've found one in a local online shop. So I have no rights to ask such a question neither I should. Actually it's a good example of _bad_ behaviour absolutely non- acceptable in LKML!!! My apologizes!

#16 lore raw
In reply to Yinghai Lu

Doesn't look like this patch is doing anything with respect to "hpet compiling". It is just adding some debug prints. I guess we need a better patch description.

Thanks,
Venki

Quoted 10 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Yinghai Lu
Sent: Wednesday, September 24, 2008 11:14 PM
To: Jesse Barnes; Len Brown; Ingo Molnar; Thomas Gleixner; H. Peter Anvin; Andrew Morton
Cc: [email protected]; [email protected]; [email protected]; Yinghai Lu
Subject: [PATCH 7/7] x86: print out irq nr for msi/ht -v2

Quoted 3 lines

v2: fix hpet compiling

Doesn't look like the patch below is doing anything with respect to "hpet compiling". It is just adding some debug prints. I guess we need a different patch description.

Thanks,
Venki

Quoted 67 lines

---

arch/x86/kernel/hpet.c    |    3 +++
arch/x86/kernel/io_apic.c |    7 +++++++
2 files changed, 10 insertions(+), 0 deletions(-)
arch/x86/kernel/hpet.c +3 -0
index 422c577..686505a 100644
@@ -467,6 +467,9 @@ static int hpet_setup_irq(struct hpet_dev *dev)
       irq_set_affinity(dev->irq, cpumask_of_cpu(dev->cpu));
       enable_irq(dev->irq);
 
+       printk(KERN_DEBUG "hpet: %s is using irq %#x aka %d for MSI\n",
+                        dev->name, dev->irq, dev->irq);
+
       return 0;
 }
 
arch/x86/kernel/io_apic.c +3 -0
index 4cc9cb6..dc82397 100644
@@ -3355,6 +3355,9 @@ static int setup_msi_irq(struct pci_dev
 *dev, struct msi_desc *desc, int irq)
 #endif
               set_irq_chip_and_handler_name(irq, &msi_chip,
 handle_edge_irq, "edge");
 
+       printk(KERN_DEBUG "PCI: %s is using irq %#x aka %d for
 MSI/MSI-X\n",
+                        pci_name(dev), irq, irq);
+
       return 0;
}
arch/x86/kernel/io_apic.c +1 -0
@@ -3587,6 +3590,7 @@ int arch_setup_hpet_msi(unsigned int irq)
       hpet_msi_write(irq, &msg);
       set_irq_chip_and_handler_name(irq, &hpet_msi_type,
 handle_edge_irq,
               "edge");
+
       return 0;
 }

#endif

arch/x86/kernel/io_apic.c +3 -0
@@ -3683,6 +3687,9 @@ int arch_setup_ht_irq(unsigned int irq,
 struct pci_dev *dev)
 
               set_irq_chip_and_handler_name(irq, &ht_irq_chip,
                                             handle_edge_irq, "edge");
+
+               printk(KERN_DEBUG "PCI: %s is using irq %#x
 aka %d for HT\n",
+                                pci_name(dev), irq, irq);
       }
       return err;
}

--
1.5.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/