Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752601AbbH1OWm (ORCPT ); Fri, 28 Aug 2015 10:22:42 -0400 Received: from www.linutronix.de ([62.245.132.108]:35284 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752470AbbH1OWl (ORCPT ); Fri, 28 Aug 2015 10:22:41 -0400 Date: Fri, 28 Aug 2015 16:22:08 +0200 (CEST) From: Thomas Gleixner To: Qais Yousef cc: Marc Zyngier , "alsa-devel@alsa-project.org" , Jason Cooper , "linux-kernel@vger.kernel.org" , "linux-mips@linux-mips.org" , Mark Rutland , Jiang Liu , Mark Brown , Lisa Parratt Subject: Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi In-Reply-To: <55E03A2B.3070805@imgtec.com> Message-ID: References: <1440419959-14315-1-git-send-email-qais.yousef@imgtec.com> <1440419959-14315-2-git-send-email-qais.yousef@imgtec.com> <55DB15EB.3090109@imgtec.com> <55DB1CD2.5030300@arm.com> <55DB29B5.3010202@imgtec.com> <55DB48C9.7010508@imgtec.com> <55DB519D.2090203@arm.com> <55DDA1C4.4070301@imgtec.com> <55DDD3E3.7070009@imgtec.com> <55DDDE3C.8030609@imgtec.com> <55E03A2B.3070805@imgtec.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Content-Length: 2306 Lines: 65 On Fri, 28 Aug 2015, Qais Yousef wrote: > Thanks a lot for the detailed explanation. I wasn't looking for a quick and > dirty solution but my view of the problem is much simpler than yours so my > idea of a solution would look quick and dirty. I have a better appreciation of > the problem now and a way to approach it :-) > > From DT point of view are we OK with this form then > > coprocessor { > interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>; > interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>; > } > > and if the root controller sends normal IPI as it sends normal device > interrupts then interrupt-sink can be a standard interrupts property (like in > my case) > > coprocessor { > interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>; > interrupts = ; > } > > Does this look right to you? Is there something else that needs to be covered > still? I'm not an DT wizard. I leave that to the DT experts. > One more thing I can think of now is that the coprocessor will need the raw > irq numbers that are picked by linux so that it can use them to trigger the > IPI. Are we ok to add a function that returns this raw irq number (as opposed > to linux irq number) directly from DT? The way this is communicated to the > coprocessor will be platform specific. Why do you want that to be hacked into DT? > > To configure your coprocessor proper, we need a translation > > mechanism from the linux interrupt number to the magic value which > > needs to be written into the trigger register when the coprocessor > > wants to send an interrupt or an IPI. > > > > int irq_get_irq_hwcfg(unsigned int irq, struct irq_hwcfg *cfg); > > > > struct irq_hwcfg needs to be defined, but it might look like this: > > > > { > > /* Generic fields */ > > x; > > ... > > union { > > mips_gic; > > ... > > }; > > }; That function provides you the information which you have to hand over to your coprocessor firmware. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/