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=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 557E6C433E2 for ; Fri, 3 Jul 2020 17:04:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2FAA0214D8 for ; Fri, 3 Jul 2020 17:04:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="BsQbt2a2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727023AbgGCREd (ORCPT ); Fri, 3 Jul 2020 13:04:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727012AbgGCREb (ORCPT ); Fri, 3 Jul 2020 13:04:31 -0400 Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5A20C061794 for ; Fri, 3 Jul 2020 10:04:30 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id l6so29346365qkc.6 for ; Fri, 03 Jul 2020 10:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kekVEpbIO7y7Zy2ic+9W88OAlfyvYXO9F0MmrWuPMes=; b=BsQbt2a2KxuCsEJCULjMcy0w8Huw7ZYVidvCJLn4GTSqKIYQBX6EFxWqAmV5lJVFcK fChr0d12IgjEhlw4a+1RR1RaVFZt4VLvv/E1QCHnzBwjTAH+BF/u4MvGn/Vv3gGvPRC1 5ooFYrDK/os5YIT5k11pbkxkHT4ZnJpwCMjErn5TT5Q9Tp0qBtyHp/APu8tMzc2s1yMi 3HLpyJoG8ilG0WYMKsS4sKriEHqjFU3yuJ5/KJnP8bBpcZwkQCSeWnX2a7YuALgxVbsT omzWIn4rzPVxspWRXYzOP1X6ffdX13kMVji2FqbVOPmZEYdEzWcqLu5YsQjelTjLG0xy e9uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kekVEpbIO7y7Zy2ic+9W88OAlfyvYXO9F0MmrWuPMes=; b=hzaQKnaTXUwr8a7YrFAoea+11DNuU8M08rZLPUHynO8PnOZNNGwaCrNg1Q8BEQMNb5 NPsXUsB30QqwZrxlXWoJdiKa6iJXyKaUSL79nWRIXYCoSBrqZ6AUnFXznHes3JISPSCe 1qYnj7jPHtSySKxuSQLl6sla5eXgakXNMWF8GdTK+ymexRwpaSPKXNteG92prMrJuH3B r6XNZDiL5K7zY0LUSP3dRQlLH0bgkt2xTTN7cLS/IU54To6hbHjFg5Fk6vBbRcMlr8Wc jKjdKxcUN9wv6M/Ni2Nju/v1w2T0RjYuj7LmgZxPwy73GMKRGOoOm+1HH+G2Fw2xFhlW fQjw== X-Gm-Message-State: AOAM532zngqF7QOzFey+Tn20uQHOPGIGKMQYfZf7kXAuVs11tEuZRcsA Gic/3XhDOiVv2sd5flg/oVQsOsHU65aFuUY53F2bkw== X-Google-Smtp-Source: ABdhPJxh/pON8HZYRKACgaenguZaBxueymNnPYNgshbUR2pBl+67NWCnbO7L0Sk9aTNbXWHiF93mGRGobhPj7u9WQ48= X-Received: by 2002:a37:64cd:: with SMTP id y196mr28956840qkb.303.1593795870000; Fri, 03 Jul 2020 10:04:30 -0700 (PDT) MIME-Version: 1.0 References: <1593699479-1445-1-git-send-email-grzegorz.jaszczyk@linaro.org> <1593699479-1445-5-git-send-email-grzegorz.jaszczyk@linaro.org> <658e3a8d3374eca91387932a9a246add@kernel.org> In-Reply-To: <658e3a8d3374eca91387932a9a246add@kernel.org> From: Grzegorz Jaszczyk Date: Fri, 3 Jul 2020 19:04:18 +0200 Message-ID: Subject: Re: [PATCHv3 4/6] irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops To: Marc Zyngier Cc: tglx@linutronix.de, jason@lakedaemon.net, "Anna, Suman" , robh+dt@kernel.org, Lee Jones , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, david@lechnology.com, "Mills, William" 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, 2 Jul 2020 at 19:54, Marc Zyngier wrote: > > On 2020-07-02 15:17, Grzegorz Jaszczyk wrote: > > From: David Lechner > > > > This implements the irq_get_irqchip_state and irq_set_irqchip_state > > callbacks for the TI PRUSS INTC driver. The set callback can be used > > by drivers to "kick" a PRU by enabling a PRU system event. > > "enabling"? That'd be unmasking an interrupt, which isn't what this > does. "injecting", maybe? Yes "injecting" is much better. > > > > > Example: > > irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, true); > > Nice example. > > What this example does explain is how you are actually going to kick > a PRU via this interface. For that to happen, you'd have to have on > the Linux side an interrupt that is actually routed to a PRU. Correct. > And from what I have understood of the previous patches, this can't > be the case. What didi I miss? The hwirq's handled by this driver are so called system events in PRUSS nomenclature. This driver is responsible for the entire mapping of those system events to PRUSS specific channels which are next mapped to host_irq (patch #6 https://lkml.org/lkml/2020/7/2/612). There are 8 host_irqs that are routed to the main cpu (running Linux) and they are called host_intr0..host_intr7 (were seen in previous patches of this series). But there are other "host_interrupts" that are routed not to the main CPU but to PRU cores and this driver is responsible for creating proper mapping (system event/channel/host_irq) for them, and allowing to kick PRU via the introduced interface. It is worth noting that the PRUSS is quite flexible and allows various things e.g.: - map any of 160/64 internal system events to any of the 20/10 channels - map any of the 20/10 channels to any of the 20/10 host interrupts. So e.g. it is possible to map e.g. system event 17 to the main CPU (through e.g. channel 1 which is the next map to e.g. host_intr0). Or (exclusively) map the same system event 17 to PRU core (through e.g. channel 1 which is the next map to PRU0). > > > > > Signed-off-by: David Lechner > > Signed-off-by: Suman Anna > > Signed-off-by: Grzegorz Jaszczyk > > Reviewed-by: Lee Jones > > --- > > v2->v3: > > - Get rid of unnecessary pruss_intc_check_write() and use > > pruss_intc_write_reg directly. > > v1->v2: > > - https://patchwork.kernel.org/patch/11069769/ > > --- > > drivers/irqchip/irq-pruss-intc.c | 43 > > ++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 41 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/irqchip/irq-pruss-intc.c > > b/drivers/irqchip/irq-pruss-intc.c > > index 49c936f..19b3d38 100644 > > --- a/drivers/irqchip/irq-pruss-intc.c > > +++ b/drivers/irqchip/irq-pruss-intc.c > > @@ -7,6 +7,7 @@ > > * Suman Anna > > */ > > > > +#include > > #include > > #include > > #include > > @@ -39,8 +40,7 @@ > > #define PRU_INTC_HIEISR 0x0034 > > #define PRU_INTC_HIDISR 0x0038 > > #define PRU_INTC_GPIR 0x0080 > > -#define PRU_INTC_SRSR0 0x0200 > > -#define PRU_INTC_SRSR1 0x0204 > > +#define PRU_INTC_SRSR(x) (0x0200 + (x) * 4) > > #define PRU_INTC_SECR0 0x0280 > > #define PRU_INTC_SECR1 0x0284 > > #define PRU_INTC_ESR0 0x0300 > > @@ -145,6 +145,43 @@ static void pruss_intc_irq_relres(struct irq_data > > *data) > > module_put(THIS_MODULE); > > } > > > > +static int pruss_intc_irq_get_irqchip_state(struct irq_data *data, > > + enum irqchip_irq_state which, > > + bool *state) > > +{ > > + struct pruss_intc *intc = irq_data_get_irq_chip_data(data); > > + u32 reg, mask, srsr; > > + > > + if (which != IRQCHIP_STATE_PENDING) > > + return -EINVAL; > > + > > + reg = PRU_INTC_SRSR(data->hwirq / 32); > > I assume the register file scales as more interrupts are added in the > subsequent patch? > Yes, after I will move part of the next patch to patch #2 as you suggested it will stop being confusing. Thank you, Grzegorz 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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 1B8BCC433E0 for ; Fri, 3 Jul 2020 17:06:11 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 DBB5C20760 for ; Fri, 3 Jul 2020 17:06:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="t2bqnIPD"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="BsQbt2a2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBB5C20760 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=w/B/M9o8NCns7MZaylr7doFQbEIDyWnlXEeHgI9cI/M=; b=t2bqnIPDIVXk6GHbCme5LPAa4 aCc8/tnOMItHRv0V78BWFuPVNWJOsIFt1jll/R4M7EtGmstOrpY0148SiP/pc1QBF+98/J5OrjHtB aa6OofPY7Ii3uZLu8qeiJZBv+jlDqQ2scJAH8wfuZoMQtbFYk1LfuMMTTB8/2IY2eQxb4dzXlFMcP 9aENFe1FdtrRSVPua7GHLznL94HxmYwge/7F0u7X/KxINWD8si6Pvw/clpdJj9J6yALvt3bdFLGJQ WqHiaxnO+FzkahLNQUj/CothPJEZL+4rZGj/tohmP8erPAALDgScqnw/EfJzidirNvjWRKsGARrpo ASo3Tkyhw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jrP76-00027K-MD; Fri, 03 Jul 2020 17:04:36 +0000 Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jrP72-00025Y-UK for linux-arm-kernel@lists.infradead.org; Fri, 03 Jul 2020 17:04:34 +0000 Received: by mail-qk1-x741.google.com with SMTP id k18so29334211qke.4 for ; Fri, 03 Jul 2020 10:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kekVEpbIO7y7Zy2ic+9W88OAlfyvYXO9F0MmrWuPMes=; b=BsQbt2a2KxuCsEJCULjMcy0w8Huw7ZYVidvCJLn4GTSqKIYQBX6EFxWqAmV5lJVFcK fChr0d12IgjEhlw4a+1RR1RaVFZt4VLvv/E1QCHnzBwjTAH+BF/u4MvGn/Vv3gGvPRC1 5ooFYrDK/os5YIT5k11pbkxkHT4ZnJpwCMjErn5TT5Q9Tp0qBtyHp/APu8tMzc2s1yMi 3HLpyJoG8ilG0WYMKsS4sKriEHqjFU3yuJ5/KJnP8bBpcZwkQCSeWnX2a7YuALgxVbsT omzWIn4rzPVxspWRXYzOP1X6ffdX13kMVji2FqbVOPmZEYdEzWcqLu5YsQjelTjLG0xy e9uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kekVEpbIO7y7Zy2ic+9W88OAlfyvYXO9F0MmrWuPMes=; b=hIfL4SH9VsLagI7X7zIvarfjkZPf1X2JVOYMbM6mPChMIB262oZpIke4muFGIT+lU/ Lbea4QBF8qobxCFk9uRVFC4Fedu97myyP0XxBi8meUsTBmEqXf4yZowrdahhCBzBtr3z pt60M+WX3DRxSZpqCy/Yw6/4cRhL5onPaP9vGk9Hx+QW3VRIbc3MgixlS7bGTjlnSpxh 1nSY0kqn5r3Pch3mbj5JkdXF00LVaGZH4T6CtOc6BowFpJFcHZ3QQqLS71BEziGARYWw sLgWDi1b2ZhD96rAgl6WXCZxil8U1oL19UkYtUkptTkjiIX+fKZ19UVj09o5AT9/zhtR GiUw== X-Gm-Message-State: AOAM533tVGzmXg7u1p1EN7sm2OnkgIS2qG5+/jW/waPnXHYJ2VXlrh4c FMEPR6PqVZ9ylcbB1oV+xIpJcAEbws4bX7f/G/llwg== X-Google-Smtp-Source: ABdhPJxh/pON8HZYRKACgaenguZaBxueymNnPYNgshbUR2pBl+67NWCnbO7L0Sk9aTNbXWHiF93mGRGobhPj7u9WQ48= X-Received: by 2002:a37:64cd:: with SMTP id y196mr28956840qkb.303.1593795870000; Fri, 03 Jul 2020 10:04:30 -0700 (PDT) MIME-Version: 1.0 References: <1593699479-1445-1-git-send-email-grzegorz.jaszczyk@linaro.org> <1593699479-1445-5-git-send-email-grzegorz.jaszczyk@linaro.org> <658e3a8d3374eca91387932a9a246add@kernel.org> In-Reply-To: <658e3a8d3374eca91387932a9a246add@kernel.org> From: Grzegorz Jaszczyk Date: Fri, 3 Jul 2020 19:04:18 +0200 Message-ID: Subject: Re: [PATCHv3 4/6] irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops To: Marc Zyngier X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200703_130432_997852_246AE61D X-CRM114-Status: GOOD ( 29.02 ) 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, linux-omap@vger.kernel.org, jason@lakedaemon.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, tglx@linutronix.de, Lee Jones , "Mills, William" , linux-arm-kernel@lists.infradead.org, david@lechnology.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2 Jul 2020 at 19:54, Marc Zyngier wrote: > > On 2020-07-02 15:17, Grzegorz Jaszczyk wrote: > > From: David Lechner > > > > This implements the irq_get_irqchip_state and irq_set_irqchip_state > > callbacks for the TI PRUSS INTC driver. The set callback can be used > > by drivers to "kick" a PRU by enabling a PRU system event. > > "enabling"? That'd be unmasking an interrupt, which isn't what this > does. "injecting", maybe? Yes "injecting" is much better. > > > > > Example: > > irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, true); > > Nice example. > > What this example does explain is how you are actually going to kick > a PRU via this interface. For that to happen, you'd have to have on > the Linux side an interrupt that is actually routed to a PRU. Correct. > And from what I have understood of the previous patches, this can't > be the case. What didi I miss? The hwirq's handled by this driver are so called system events in PRUSS nomenclature. This driver is responsible for the entire mapping of those system events to PRUSS specific channels which are next mapped to host_irq (patch #6 https://lkml.org/lkml/2020/7/2/612). There are 8 host_irqs that are routed to the main cpu (running Linux) and they are called host_intr0..host_intr7 (were seen in previous patches of this series). But there are other "host_interrupts" that are routed not to the main CPU but to PRU cores and this driver is responsible for creating proper mapping (system event/channel/host_irq) for them, and allowing to kick PRU via the introduced interface. It is worth noting that the PRUSS is quite flexible and allows various things e.g.: - map any of 160/64 internal system events to any of the 20/10 channels - map any of the 20/10 channels to any of the 20/10 host interrupts. So e.g. it is possible to map e.g. system event 17 to the main CPU (through e.g. channel 1 which is the next map to e.g. host_intr0). Or (exclusively) map the same system event 17 to PRU core (through e.g. channel 1 which is the next map to PRU0). > > > > > Signed-off-by: David Lechner > > Signed-off-by: Suman Anna > > Signed-off-by: Grzegorz Jaszczyk > > Reviewed-by: Lee Jones > > --- > > v2->v3: > > - Get rid of unnecessary pruss_intc_check_write() and use > > pruss_intc_write_reg directly. > > v1->v2: > > - https://patchwork.kernel.org/patch/11069769/ > > --- > > drivers/irqchip/irq-pruss-intc.c | 43 > > ++++++++++++++++++++++++++++++++++++++-- > > 1 file changed, 41 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/irqchip/irq-pruss-intc.c > > b/drivers/irqchip/irq-pruss-intc.c > > index 49c936f..19b3d38 100644 > > --- a/drivers/irqchip/irq-pruss-intc.c > > +++ b/drivers/irqchip/irq-pruss-intc.c > > @@ -7,6 +7,7 @@ > > * Suman Anna > > */ > > > > +#include > > #include > > #include > > #include > > @@ -39,8 +40,7 @@ > > #define PRU_INTC_HIEISR 0x0034 > > #define PRU_INTC_HIDISR 0x0038 > > #define PRU_INTC_GPIR 0x0080 > > -#define PRU_INTC_SRSR0 0x0200 > > -#define PRU_INTC_SRSR1 0x0204 > > +#define PRU_INTC_SRSR(x) (0x0200 + (x) * 4) > > #define PRU_INTC_SECR0 0x0280 > > #define PRU_INTC_SECR1 0x0284 > > #define PRU_INTC_ESR0 0x0300 > > @@ -145,6 +145,43 @@ static void pruss_intc_irq_relres(struct irq_data > > *data) > > module_put(THIS_MODULE); > > } > > > > +static int pruss_intc_irq_get_irqchip_state(struct irq_data *data, > > + enum irqchip_irq_state which, > > + bool *state) > > +{ > > + struct pruss_intc *intc = irq_data_get_irq_chip_data(data); > > + u32 reg, mask, srsr; > > + > > + if (which != IRQCHIP_STATE_PENDING) > > + return -EINVAL; > > + > > + reg = PRU_INTC_SRSR(data->hwirq / 32); > > I assume the register file scales as more interrupts are added in the > subsequent patch? > Yes, after I will move part of the next patch to patch #2 as you suggested it will stop being confusing. Thank you, Grzegorz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel