From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755270Ab2HAOpt (ORCPT ); Wed, 1 Aug 2012 10:45:49 -0400 Received: from www.linutronix.de ([62.245.132.108]:51443 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753970Ab2HAOpr (ORCPT ); Wed, 1 Aug 2012 10:45:47 -0400 Message-ID: <50194115.2030307@linutronix.de> Date: Wed, 01 Aug 2012 16:45:41 +0200 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: Thierry Reding CC: Grant Likely , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: x86 and I/O APIC IRQ domains References: <20120801135839.GA19957@avionic-0098.adnet.avionic-design.de> In-Reply-To: <20120801135839.GA19957@avionic-0098.adnet.avionic-design.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/01/2012 03:58 PM, Thierry Reding wrote: > I've been working on an x86 platform and want to use DT. However I've > hit a snag when trying to instantiate the I/O APIC. I've been trying to > follow what the CE4100 does and most things seem to work fine but when > I add the DT node for the I/O APIC things start to fail. I've been able > to trace the issue to x86_add_irq_domains(), which in turn calls > ioapic_add_ofnode() from which irq_domain_add_legacy() is called. > > The platform that I use hits the WARN_ON(!irq_data || irq_data->domain). > Looking further this seems to be caused by all irq_get_irq_data(irq) > returning NULL for irq>= 16. That in turn I think is due to > init_ISA_irqs() setting up only the first NR_IRQS_LEGACY interrupts. > However the call to irq_domain_add_legacy() wants 32 interrupts. The IOAPIC knows how many sources are available and this number should be used instead of 32. This won't solve the problem with get_irq_data() for the second ioapic which might be available in the system. The reason why there is no irq_data() available is that this is allocated by io_apic_setup_irq_pin_once() which is now called too late. Usually a PCI device does a pci_enable() call and then we do all this. So to keep the function happy you should preallocate all interrupts which are offered. Ah, and you may need a map function which does nothing because the programming is done at io_apic_setup_irq_pin_once() time. Maybe you could live with irq_domain_add_linear() instead. Not sure how important it is to keep rtc at a fixed irq. I think as far as the IOAPIC is concerned, it could be programmed to another number but I kept it in sync. However parts of the ioapic code rely on gsi_number == irq number so maybe we should preallocate the irq_data and use a dummy map() function for the start. > This was introduced by commit b4e5185 "irq_domain/x86: Convert x86 > (embedded) to use common irq_domain)". I wonder what I'm doing wrong. I > don't get how this is made to work on CE4100. Currently it does not > Later the code crashes, but I can't exactly pinpoint the location > because the oops doesn't fit on the screen. I don't have a serial port > that I can use instead, so is there anything else I can do to obtain a > complete backtrace? There is an option which delays each printk by a few msecs. Maybe this could help. > > Thierry Sebastian