Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752611AbbLIQvB (ORCPT ); Wed, 9 Dec 2015 11:51:01 -0500 Received: from mail.kernel.org ([198.145.29.136]:32771 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751997AbbLIQu6 (ORCPT ); Wed, 9 Dec 2015 11:50:58 -0500 MIME-Version: 1.0 In-Reply-To: <56684877.3020708@imgtec.com> References: <561E2BE6.2090807@imgtec.com> <5628BE00.4020106@imgtec.com> <20151022115551.GI3953@io.lakedaemon.net> <56684877.3020708@imgtec.com> From: Rob Herring Date: Wed, 9 Dec 2015 10:50:35 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Generic DT binding for IPIs To: Qais Yousef Cc: "devicetree-spec@vger.kernel.org" , Jason Cooper , "devicetree@vger.kernel.org" , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Thomas Gleixner , Marc Zyngier , Jiang Liu , "linux-kernel@vger.kernel.org" , Lisa Parratt Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3238 Lines: 92 On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote: > Hi, > > On 10/22/2015 12:55 PM, Jason Cooper wrote: >> >> On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote: >>> >>> Is there anything more I can do to get more attention about this? I >>> think Marc's suggestion is more generic and future proof, if I send >>> RFC patches for that would this be better? >> >> Please do. > > > Unfortunately I haven't had a chance to get around writing the patches yet. > I came up with a different description though that I thought maybe worth > sharing > to see if there's any opinion about it before the actual work being done. I've not given this too much thought, but here's my initial thoughts. > > To summarise, the problem I am trying to solve is that we have a type of > coprocessors which share the interrupt controller with Linux, hence the IPI > mechanism this controller uses. I've been working with Thomas on > implementing > a generic API to allocate IPIs for coprocesors and a way for drivers to send > these IPIs [1]. > > To complement this new API, we need a mechanism to describe this in > device tree so a driver that wants to allocate an IPI can have this done > automatically for it like we handle interrupts. > > What I have in mind is: > > coproc { > ipi-parent = <&gic>; > > ipis = ; > ipi-names = "in"; > }; > > This will allocate an IPI to go to cpu @CPU_VALUE passing @IPI_SPEC as > parameters to the controller. Which means we need a new ipi-cells to > define how many cells are in ipis property. Note the new ipi-parent too. These are still interrupts, so I'd prefer to use or extend the interrupt binding if possible. > I think this is better than interrupt-sink and interrupt-source [2] as we > give the driver the flexibility to give a meaning to what this IPI is. > One thing I found confusing about interrupt-source and interrupt-sink is > from what perspective are we viewing that, host system or firmware.. DT is usually from host perspective. But I agree, the naming was still confusing to me. > ipis property also is similar to interrupts, so using it would be easier > (I think). > > If we have 2 coprocessors that want to communicate using IPIs that are > managed by the host we use ipi-refs property to refer to IPIs defined in > another node. > > coproc1 { > ipis = , , ; Don't you need to specify a certain IPI number in addition to which cpu is the target? I'm thinking the cpu target could be part of the interrupts property flags field or something. > ipi-names = "in", "coproc2data", "coproc2ctrl"; -names should be optional in general. So define something that works without them. > }; > > coproc2 { > ipi-refs = <&coproc1 "in">, <&coproc1 "coproc2data">, <&coproc1 > "corpoc2ctrl">; This isn't actually parseable. You need a known length of cells after a phandle. Rob -- 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/