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=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, 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 DE59CC433E0 for ; Fri, 31 Jul 2020 14:36:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B88F72177B for ; Fri, 31 Jul 2020 14:36:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="WoRuLYGX" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729554AbgGaOgj (ORCPT ); Fri, 31 Jul 2020 10:36:39 -0400 Received: from lelv0142.ext.ti.com ([198.47.23.249]:51630 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728961AbgGaOgi (ORCPT ); Fri, 31 Jul 2020 10:36:38 -0400 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 06VEZUqm112601; Fri, 31 Jul 2020 09:35:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1596206130; bh=GRu9XzAMRe4+pci8Uhro7LyH72wWLts+VnuOKHzpVv8=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=WoRuLYGXbjzuuoqKVAWXrgHgTQTEY7FKptdrHeOuhCdEEDSnEh5Uvs1P1yMO11DKa 7KJZxf8ZxVKQ/knSJ3RkD9zxrm63AJqFcaeEvvhtn5PQjTW7bjdzywXVFDILttLDwa waJCyQdaKkEevxWywh0ZYVyvUjRGLhxU4oBG2zsE= Received: from DFLE114.ent.ti.com (dfle114.ent.ti.com [10.64.6.35]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 06VEZUdk110843 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 31 Jul 2020 09:35:30 -0500 Received: from DFLE103.ent.ti.com (10.64.6.24) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 31 Jul 2020 09:35:30 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Fri, 31 Jul 2020 09:35:30 -0500 Received: from [10.250.34.248] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 06VEZTnO047666; Fri, 31 Jul 2020 09:35:29 -0500 Subject: Re: [PATCH v4 1/5] dt-bindings: irqchip: Add PRU-ICSS interrupt controller bindings To: Grzegorz Jaszczyk , David Lechner CC: , , Marc Zyngier , , Lee Jones , , , , , "Bajjuri, Praneeth" , "Andrew F . Davis" , Roger Quadros References: <1595927918-19845-1-git-send-email-grzegorz.jaszczyk@linaro.org> <1595927918-19845-2-git-send-email-grzegorz.jaszczyk@linaro.org> <01bac597-c1a0-1851-b630-a79929777a16@lechnology.com> <19fbf4f6-ea75-3eb7-7e95-c7c9ce987996@lechnology.com> From: Suman Anna Message-ID: <36a1157e-4f59-9de5-c9d8-05bcdd67e125@ti.com> Date: Fri, 31 Jul 2020 09:35:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On 7/31/20 9:16 AM, Grzegorz Jaszczyk wrote: > On Fri, 31 Jul 2020 at 16:09, David Lechner wrote: >> >> On 7/31/20 6:48 AM, Grzegorz Jaszczyk wrote: >>> On Wed, 29 Jul 2020 at 19:34, David Lechner wrote: >>>> It is not clear what the meaning of each cell is. Looking at later patches, it >>>> looks like the first cell is the PRU system event number, the second cell is the >>>> channel and the third cell is the host event number. >>> >>> Ok, how about updating above description like this: >>> Client users shall use the PRU System event number (the interrupt source >>> that the client is interested in) [cell 1], PRU channel [cell 2] and PRU >>> host_intr (target) [cell 3] as the value of the interrupts property in their >>> node. The system 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 so through this property entire mapping is provided. >> >> Cell 3 is host_intr0-7? How would we map to other host events? > > Again this is due to misleading TRM nomenclature: host_intr vs host > interrupts (one that we discuss in patch #2). I will use "and PRU host > event (target) [cell 3]...". Sorry for my mistake. Idea is to do the event mapping for other host interrupts using the irq_create_fwspec_mapping() function from the PRU remoteproc driver. We can't use DT to represent them, or atleast can't use "interrupts" property for them since they are not targeted towards the Linux host processor. regards Suman