From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7590FC7618F for ; Wed, 17 Jul 2019 17:57:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 54C1621743 for ; Wed, 17 Jul 2019 17:57:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="u2sqBbq9"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lechnology.com header.i=@lechnology.com header.b="JUQJVM1v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 54C1621743 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lechnology.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=WAJSAmO7+Tsjmauv1KEcXBGy+HRwhLHVoJqy8+kE62c=; b=u2sqBbq9BGoU8rs+X1Yq0iRqa VNKvtfEe5Bkhj7qn39788fxNtPUVjYmjKsQlqbL7wpt7cDyw0EDwOdWd0Y6m26Gvo6WHIcMu6ByG+ vE67+An6wfU9ce3ijgrH12F09iEDJMz1Or6djGfabks1OgBUzCh34QauitEqv4W35g26aUcpB1EL/ H6fSNpFBXHO5ZlApMOF9kg0htRg7wycItlATpMKd53Uj6Ff7ei66nFUhYJc7n/hQjsGkggVr8OKkH qYEkTivSFQ5kyZafTLKe2gqXUKuRi/ILp84yZLHoMzoseqUcTYTetjPSEvPb1T86vX1OfRuJ0U60Q G2/z0Fc5Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hnoBM-0004W7-Ji; Wed, 17 Jul 2019 17:57:36 +0000 Received: from vern.gendns.com ([98.142.107.122]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hnoBJ-0004Vf-EZ for linux-arm-kernel@lists.infradead.org; Wed, 17 Jul 2019 17:57:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lechnology.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kBCqv/tlrCEB7BtFXFOJV8+OGPJGlXhO5dquLsunvpA=; b=JUQJVM1vwnZ1tOfW05WU4K8sS2 nnbTCmMPTP6+9fc5yWMZ2iP7WFyv+sU+yUiKL1DeKN/yCiRIE+Oto8digXX58a8eUQcBIUjgvV5ua UUEToaMClhulA2UtFibfORrN/XoiIcY5QyuGKr4nURytgYQdCx1zHnUwobNvlsf4rYZtKS8eLKntU 0ae9SntXkf+cQxpG/F5LwfkqQUhKWFbuOjJ1CaXASbnjl7ETaDflMcn00WrHPcJDN6Mkqgvl98ftq vrDMN8nLWRDAkIxmQSEwZcQKwNYHitsoXyA5TWcLf+IJp3Qye49SsOvgyhEeOzOC8pjnmAiBXx067 t3rfX8Dg==; Received: from 108-198-5-147.lightspeed.okcbok.sbcglobal.net ([108.198.5.147]:48454 helo=[192.168.0.134]) by vern.gendns.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hnoBG-007dWK-Hb; Wed, 17 Jul 2019 13:57:30 -0400 Subject: Re: [PATCH 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping To: Suman Anna , Marc Zyngier , Rob Herring , Thomas Gleixner , Jason Cooper References: <20190708035243.12170-1-s-anna@ti.com> <20190708035243.12170-5-s-anna@ti.com> <9aa5acd8-81bf-10dc-5a86-cea2acd1132b@lechnology.com> <23ae1767-3531-ea57-2c82-f2657baa123f@ti.com> From: David Lechner Message-ID: <22825f06-d968-03a7-585b-8cbf4123915c@lechnology.com> Date: Wed, 17 Jul 2019 12:57:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <23ae1767-3531-ea57-2c82-f2657baa123f@ti.com> Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - lists.infradead.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190717_105733_651329_457E1453 X-CRM114-Status: GOOD ( 18.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Grygorii Strashko , Tony Lindgren , Sekhar Nori , linux-kernel@vger.kernel.org, "Andrew F. Davis" , Lokesh Vutla , Murali Karicheri , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Roger Quadros Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 7/16/19 6:29 PM, Suman Anna wrote: > Hi David, > > On 7/10/19 10:10 PM, David Lechner wrote: >> On 7/7/19 10:52 PM, Suman Anna wrote: >>> The PRUSS INTC receives a number of system input interrupt source events >>> and supports individual control configuration and hardware >>> prioritization. >>> These input events can be mapped to some output host interrupts through 2 >>> levels of many-to-one mapping i.e. events to channel mapping and channels >>> to host interrupts. >>> >>> This mapping information is provided through the PRU firmware that is >>> loaded onto a PRU core/s or through the device tree node of the PRU >> > > Thanks for the thorough review and alternate solutions/suggestions. > >> What will the device tree bindings for this look like? > > They would be as in the below patch you already figured. Ah, makes sense now: the mapping is defined in the remoteproc node rather than in the interrupt controller node. > >> >> Looking back at Rob's comment on the initial series [1], I still think >> that increasing the #interrupt-cells sounds like a reasonable solution. >> >> [1]: https://patchwork.kernel.org/patch/10697705/#22375155 > > So, there are couple of reasons why I did not use an extended > #interrupt-cells: > > 1. There is only one irq descriptor associated with each event, and the > usage of events is typically per application. And the descriptor mapping > is done once. We can have two different applications use the same event > with different mappings. So we want this programming done at > application's usage of PRU (so done when a consumer driver acquires a > PRU processor(s) which are treated as an exclusive resource). All the > different application properties that you saw in [1] are configured at > the time of acquiring a PRU and reset when they release a PRU. > > 2. The configuration is performed by Linux for all host interrupts and > channels, and this was primarily done to save the very limited IRAM > space for those needed by the PRUs. From firmware's point of view, this > was offloaded to the ARM OS driver/infrastructure, but in general it is > a design by contract between a PRU client driver and its firmware. Also, > the DT binding semantics using interrupts property and request_irq() > typically limits these to interrupts only being requested by MPU, and so > will leave out those needed by PRUs. > Hmm... case 1. is a tricky one indeed. If there are going to be times where an event requires multiple mappings, I agree that this doesn't seem to fit into any existing device tree bindings. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel