login
Search
v2: fix hpet compiling Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/hpet.c | 3 +++ arch/x86/kernel/io_apic.c | 7 +++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 422c577..686505a 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -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; } diff --git a/arch/x86/kernel/io_apic.c b/arch/x86/kernel/io_apic.c index 4cc9cb6..dc82397 100644 --- a/arch/x86/kernel/io_apic.c +++ b/arch/x86/kernel/io_apic.c @@ -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; } -- 1.5.6 --
applied to tip/irq/sparseirq, thanks Yinghai. Ingo --
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 --
looks there is some merge problem.
Index: linux-2.6/arch/x86/kernel/hpet.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/hpet.c
+++ 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
--
ok, figure it out, the problem was that your change depended on tip/timers/hpet-percpu. sorted it out. Ingo --
Are you sure you sent the right patch? It only adds some printk()'s and=20 unrelated newlines. Eike
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 --
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 --
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 --
[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 - --
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 --
[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 - --
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"). +1 --
On Mon, Sep 29, 2008 at 11:57 PM, Grant Grundler 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! --
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, 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, --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object d |