Received: by 10.192.165.148 with SMTP id m20csp486216imm; Fri, 4 May 2018 13:39:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqj+V4N6OelI5Az4nPclqypMhfIKpCnl988sgobtmaTnwi0OnhxZi9TsI9zeeW7tL2C6RuI X-Received: by 2002:a63:740c:: with SMTP id p12-v6mr15662744pgc.259.1525466392836; Fri, 04 May 2018 13:39:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525466392; cv=none; d=google.com; s=arc-20160816; b=bmBLsVvqAQH9+ux2bcuSKLQNxRRQV8NBifI5C1Qd4Ypr4VvIp6ScSBnW+J3bRDzQ87 9ElYYbB8C7VtdbkoD5XM9tgImlOeOwHKr+lVN+bmhFJ6NC5r9HOtVKMabluPnZ0DSiWG KnkiM0kxmqykXGi5EXHAxy931Xrl7spbWl3g/imrx2zRJwUxYAWQJa2Jch1v34zUb3cn NLuHJcJSM0+fShH9vF2iP0yBfL+aG3jFFAo3xVkbrWQkBWlVclsQPVpNQcALiU+k+MK0 rFRBTJsLz6unoeGugqSuq5ZpQrSSWpnajxUPhDMnHn+cij39p+Swz37VcYto0BgE2XD2 M6XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=95IY+cdUHJQU23BmvsXWgCIDBNK5YJhD/KRifGv5Vfw=; b=EslV+Vy/3HZJJ8CiRWrKfRFw18BR9SMs2nb6ze7sCOqifXr962wkEO6XZnjst9S941 fkxdv82ZWkJqWnePm+FXV4DQ58cY+uoDZ6JqzMmAXgaG3xAfLGVv8GrDLr2Q4F3PUhiu 0UsmI3u8do+MsZhbDDyVDQqmq66NTGgIvku3s54W5RMBzZpve7HDCfKgQOIlw72DMjP6 ZbOt/6yzvD2R29WK+2Rqb3x+iNxS3C7HsbwG1IktfDcglPT0G0T9S69r47hVt9MIZe8V Ra51WrBw1XQHVfGo1Fo+HCwpYO2ISs3EysFhL5G2I7rilH0G6cyzLB+E1tJtQ0O/1CW7 fm2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kFeW5lg7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a11-v6si2796165pgt.680.2018.05.04.13.39.37; Fri, 04 May 2018 13:39:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kFeW5lg7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751814AbeEDUig (ORCPT + 99 others); Fri, 4 May 2018 16:38:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:40124 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751760AbeEDUif (ORCPT ); Fri, 4 May 2018 16:38:35 -0400 Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com [209.85.216.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9ED8821783; Fri, 4 May 2018 20:38:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1525466314; bh=8+Xqam3lIlv6bapwAth0hWs2FR88W1Af1wz3i/Tru0U=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=kFeW5lg7cgc1I7YIXCcX/oZ/mgD0xbKc/zqO+ReZzakxKiddQIx4b6COumy2ZgeI1 5WJPUoLjLtULYz9SrYe5wVY9UMzXnGxQraXZ9qboDMTVGFqsuvJo7tO0SttZrUTBd4 zI8g59n2S/9SabqVWdXjfa1R9vi8agXnhuuu8VUc= Received: by mail-qt0-f169.google.com with SMTP id m16-v6so29050662qtg.13; Fri, 04 May 2018 13:38:34 -0700 (PDT) X-Gm-Message-State: ALQs6tBPo4nos+HpodXcftU2RXtp3gg3s+xSmlWRYBJip2MACZ5e1+cT UvhvXcgmwxhAImx6YOgtNiDB/pgVXDQexgcIGQ== X-Received: by 2002:aed:26c3:: with SMTP id q61-v6mr26677682qtd.60.1525466313761; Fri, 04 May 2018 13:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.155.2 with HTTP; Fri, 4 May 2018 13:38:13 -0700 (PDT) In-Reply-To: <26de0a75-e4e1-7c43-e31d-599d3c7de0ff@st.com> References: <1524759514-12392-1-git-send-email-ludovic.Barre@st.com> <1524759514-12392-8-git-send-email-ludovic.Barre@st.com> <20180501145611.GA6842@rob-hp-laptop> <6fdb652b-e7f9-7035-3eda-39f763ed7ea3@st.com> <26de0a75-e4e1-7c43-e31d-599d3c7de0ff@st.com> From: Rob Herring Date: Fri, 4 May 2018 15:38:13 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/11] irqchip: stm32: add stm32mp1 support with hierarchy domain To: Ludovic BARRE Cc: Thomas Gleixner , Jason Cooper , Marc Zyngier , Maxime Coquelin , Alexandre Torgue , Gerald BAEZA , Loic PALLARDY , "linux-kernel@vger.kernel.org" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 3, 2018 at 4:55 AM, Ludovic BARRE wrote: > > > On 05/02/2018 07:45 PM, Rob Herring wrote: >> >> On Wed, May 2, 2018 at 11:03 AM, Ludovic BARRE >> wrote: >>> >>> Hi Rob >>> >>> >>> >>> On 05/01/2018 04:56 PM, Rob Herring wrote: >>>> >>>> >>>> On Thu, Apr 26, 2018 at 06:18:30PM +0200, Ludovic Barre wrote: >>>>> >>>>> >>>>> From: Ludovic Barre >>>>> >>>>> Exti controller has been differently integrated on stm32mp1 SoC. >>>>> A parent irq has only one external interrupt. A hierachy domain could >>>>> be used. Handlers are call by parent, each parent interrupt could be >>>>> masked and unmasked according to the needs. >>>>> >>>>> Signed-off-by: Ludovic Barre >>>>> --- >>>>> .../interrupt-controller/st,stm32-exti.txt | 3 + >>>>> drivers/irqchip/irq-stm32-exti.c | 322 >>>>> +++++++++++++++++++++ >>>>> 2 files changed, 325 insertions(+) >>>>> >>>>> diff --git >>>>> >>>>> a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt >>>>> >>>>> b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt >>>>> index edf03f0..136bd61 100644 >>>>> --- >>>>> >>>>> a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt >>>>> +++ >>>>> >>>>> b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.txt >>>>> @@ -5,11 +5,14 @@ Required properties: >>>>> - compatible: Should be: >>>>> "st,stm32-exti" >>>>> "st,stm32h7-exti" >>>>> + "st,stm32mp1-exti" >>>>> - reg: Specifies base physical address and size of the registers >>>>> - interrupt-controller: Indentifies the node as an interrupt >>>>> controller >>>>> - #interrupt-cells: Specifies the number of cells to encode an >>>>> interrupt >>>>> specifier, shall be 2 >>>>> - interrupts: interrupts references to primary interrupt controller >>>>> + (only needed for exti controller with multiple exti under >>>>> + same parent interrupt: st,stm32-exti and st,stm32h7-exti") >>>>> Example: >>>>> diff --git a/drivers/irqchip/irq-stm32-exti.c >>>>> b/drivers/irqchip/irq-stm32-exti.c >>>>> index b38c655..ebf7146 100644 >>>>> --- a/drivers/irqchip/irq-stm32-exti.c >>>>> +++ b/drivers/irqchip/irq-stm32-exti.c >>>> >>>> >>>> >>>> [...] >>>> >>>>> +static const struct stm32_desc_irq stm32mp1_desc_irq[] = { >>>>> + { .exti = 1, .irq_parent = 7 }, >>>>> + { .exti = 2, .irq_parent = 8 }, >>>>> + { .exti = 3, .irq_parent = 9 }, >>>>> + { .exti = 4, .irq_parent = 10 }, >>>>> + { .exti = 5, .irq_parent = 23 }, >>>>> + { .exti = 6, .irq_parent = 64 }, >>>>> + { .exti = 7, .irq_parent = 65 }, >>>>> + { .exti = 8, .irq_parent = 66 }, >>>>> + { .exti = 9, .irq_parent = 67 }, >>>>> + { .exti = 10, .irq_parent = 40 }, >>>>> + { .exti = 11, .irq_parent = 42 }, >>>>> + { .exti = 12, .irq_parent = 76 }, >>>>> + { .exti = 13, .irq_parent = 77 }, >>>>> + { .exti = 14, .irq_parent = 121 }, >>>>> + { .exti = 15, .irq_parent = 127 }, >>>>> + { .exti = 16, .irq_parent = 1 }, >>>>> + { .exti = 65, .irq_parent = 144 }, >>>>> + { .exti = 68, .irq_parent = 143 }, >>>>> + { .exti = 73, .irq_parent = 129 }, >>>>> +}; >>>> >>>> >>>> >>>> You can use an interrupt-map property rather than put this into the >>>> driver. >>> >>> >>> >>> interrupt-map seemed interesting and promising like used in pci host. >>> At first sight this property can't be used into node with >>> "interrupt-controller" property (see in drivers/of/irq.c function: >>> of_irq_parse_raw) because "of_irq_parse_raw" checks if node got >>> it first, and after lookup the interrupt-map. >>> >>> Rob, Thomas, Jason, Marc what do you prefers or the right ways...? >> >> >> I believe the correct thing to do is simply drop "interrupt-controller". > Actually, that's not right. > if I drop "interrupt-controller" of my node, my driver will not be > initialized by "of_irq_init" > (start_kernel->init_IRQ->irqchip_init->of_irq_init). > Probably, we could replace "IRQCHIP_DECLARE" by a > "module_platform_driver" or "postcore_initcall" but I'm not a big fan of > this solution. what do you think ? You'd have to parse 'interrupt-map' yourself to extract the data for this to work because interrupt-map currently only works when the translation is transparent (i.e. doesn't need s/w handling). So I guess leave this in the driver. Sorry for the noise. Rob