From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754416AbbIBMMS (ORCPT ); Wed, 2 Sep 2015 08:12:18 -0400 Received: from pmta2.delivery5.ore.mailhop.org ([54.186.218.12]:57139 "EHLO pmta2.delivery5.ore.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752970AbbIBMMQ (ORCPT ); Wed, 2 Sep 2015 08:12:16 -0400 X-DKIM: OpenDKIM Filter v2.6.8 io AA16D8011D Date: Wed, 2 Sep 2015 12:12:09 +0000 From: Jason Cooper To: Marc Zyngier Cc: Qais Yousef , Mark Rutland , Thomas Gleixner , "alsa-devel@alsa-project.org" , "linux-kernel@vger.kernel.org" , "linux-mips@linux-mips.org" , Jiang Liu , Mark Brown , Lisa Parratt Subject: Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Message-ID: <20150902121209.GA10628@io.lakedaemon.net> References: <55DDA1C4.4070301@imgtec.com> <55DDD3E3.7070009@imgtec.com> <55DDDE3C.8030609@imgtec.com> <55E03A2B.3070805@imgtec.com> <55E6C250.50100@imgtec.com> <55E6C788.2000405@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E6C788.2000405@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 02, 2015 at 10:55:20AM +0100, Marc Zyngier wrote: > On 02/09/15 10:33, Qais Yousef wrote: > > On 08/28/2015 03:22 PM, Thomas Gleixner wrote: > >> 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. > >> > > > > Hi Marc Zyngier, Mark Rutland, > > > > Any comments about the DT binding for the IPIs? > > > > To recap, the proposal which is based on Marc Zyngier's is to use > > interrupt-source to represent an IPI from Linux CPU to a coprocessor and > > interrupt-sink to receive an IPI from coprocessor to Linux CPU. > > Hopefully the description above is self explanatory. Please let me know > > if you need more info. Thomas covered the routing, synthesising, and > > requesting parts in the core code. The remaining (high level) issue is > > how to describe the IPIs in DT. > > I'm definitely *not* a DT expert! ;-) My initial binding proposal was > only for wired interrupts, not for IPIs. There is definitely some common > aspects, except for one part: > > Who decides on the IPI number? So far, we've avoided encoding IPI > numbers in the DT just like we don't encode MSIs, because they are > programmable things. My feeling is that we shouldn't put the IPI number > in the DT because the rest of the kernel uses them as well and could > decide to use this particular IPI number for its own use: *clash*. Agree. The best way I've found to design DT bindings is to imagine providing the DT to something other than Linux. The DT should *only* be describing the hardware. As such, I think we should be describing the connection here, and leaving the assignment up to the OS. thx, Jason.