Message ID | 20230329153936.394911-2-cristian.marussi@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp518529vqo; Wed, 29 Mar 2023 09:02:03 -0700 (PDT) X-Google-Smtp-Source: AKy350aWS82xBG4W6UiPO61hpS/f6SDn12d7yPU0zUo1j+64Ht0wbVNZNxIZPqoDfgFjWgC1WQVO X-Received: by 2002:aa7:cb98:0:b0:4fc:6475:d249 with SMTP id r24-20020aa7cb98000000b004fc6475d249mr17808438edt.3.1680105723327; Wed, 29 Mar 2023 09:02:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680105723; cv=none; d=google.com; s=arc-20160816; b=PNpig1QM8ljA5tRrVvBBQipb+Xi2QYmMX8HYfOemTEPFMdcGIePr2YujQPG6A15cZI Scn92Iifo2U5nOFWuKEH45Lv2qqg/iy+IBpSIDcDq9TT0k7hicrmnoLug+xStm4Ln+br xOpRaMAl3awifhntrmhIIDG4nd5b3ggJvfHUv70beuGFh/gaPKk4LBQMWUDChVyBFWlE A+BrfNqU1CPGuNo9gM0uZeboc6LjOsNczVHNfxj6tbbpgPXod6LfzrYTyt+4a8sMqLxG YzD0rZsi2J40ZFDHTzJ9mfOUasER6e4GyZ5v43lMYX4QkZSJgEEo4YPhyk7vsB3GoVji U1Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=wxkG1khkTVKc5s7LEFdPJTlzNoOYLC5pJ07Egk47egg=; b=AS1BGeAkIRGbpL4yssvxJr0blB1z4b71naCoMipZt1wVqhs89biQibAMtqeIaAPOTa ap6ecWiTug3lCE76jrKLQ5TmCVpOi7czMZetF8kVoSg73uNDLnLXwp1iFqpLrOH3829F pj8w2fiQYkBDXC8kgBYHlEDd83ZZgWzMTkDeY0CX4M4Ott2dQj8TchM3NQpB1KNkXDVB i9FUqqNmNVTiHHwuuBufRJ9RES7xohXY4mxaKWfc6gXkXwXahp3FwODESKFEashPELhf ldw+e8hBOnkiKwKM8T9Dag80NYnpCW0LuFn39RDmlEed83qYYzt68aErCqMEE2R6SjAb Xo4A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j5-20020aa7c405000000b00502259be703si13527695edq.434.2023.03.29.09.01.09; Wed, 29 Mar 2023 09:02:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230443AbjC2PkR (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Wed, 29 Mar 2023 11:40:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231159AbjC2Pj5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 29 Mar 2023 11:39:57 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B99C344A2; Wed, 29 Mar 2023 08:39:52 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C699C2F4; Wed, 29 Mar 2023 08:40:36 -0700 (PDT) Received: from e120937-lin.. (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BDE033F663; Wed, 29 Mar 2023 08:39:50 -0700 (PDT) From: Cristian Marussi <cristian.marussi@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: sudeep.holla@arm.com, cristian.marussi@arm.com, vincent.guittot@linaro.org, souvik.chakravarty@arm.com, nicola.mazzucato@arm.com, Tushar.Khandelwal@arm.com, viresh.kumar@linaro.org, jassisinghbrar@gmail.com, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, devicetree@vger.kernel.org Subject: [PATCH 1/2] dt-bindings: mailbox : arm,mhuv2: Allow for more RX interrupts Date: Wed, 29 Mar 2023 16:39:35 +0100 Message-Id: <20230329153936.394911-2-cristian.marussi@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230329153936.394911-1-cristian.marussi@arm.com> References: <20230329153936.394911-1-cristian.marussi@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761718538964992614?= X-GMAIL-MSGID: =?utf-8?q?1761718538964992614?= |
Series |
Add MHUv2 support for multiple rx interrupt
|
|
Commit Message
Cristian Marussi
March 29, 2023, 3:39 p.m. UTC
The ARM MHUv2 Receiver block can indeed support more interrupts, up to the
maximum number of available channels, but anyway no more than the maximum
number of supported interrupt for an AMBA device.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: devicetree@vger.kernel.org
.../devicetree/bindings/mailbox/arm,mhuv2.yaml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Comments
On Wed, Mar 29, 2023 at 04:39:35PM +0100, Cristian Marussi wrote: > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the > maximum number of available channels, but anyway no more than the maximum > number of supported interrupt for an AMBA device. > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: devicetree@vger.kernel.org > > .../devicetree/bindings/mailbox/arm,mhuv2.yaml | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > index a4f1fe63659a..5a57f4e2a623 100644 > --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > @@ -69,10 +69,15 @@ properties: > > interrupts: > description: | > - The MHUv2 controller always implements an interrupt in the "receiver" > - mode, while the interrupt in the "sender" mode was not available in the > - version MHUv2.0, but the later versions do have it. > - maxItems: 1 > + The MHUv2 controller always implements at least an interrupt in the > + "receiver" mode, while the interrupt in the "sender" mode was not > + available in the version MHUv2.0, but the later versions do have it. > + In "receiver" mode, beside a single combined interrupt, there could be > + multiple interrupts, up to the number of implemented channels but anyway > + no more than the maximum number of interrupts potentially supported by > + AMBA. > + minItems: 1 > + maxItems: 9 I am not sure 9 is the correct value here. IIUC it is just what Linux defines as AMBA_NR_IRQS. Looking at the history it was bumped from 2 to 9 for use by PL330 DMA driver. I couldn't find anything to relate this 9 in any AMBA or other related specification. Ideally I would say we don't know what the max here. We just have a platform implementing 2 interrupts now. Do we for with 2 for now and change it if some new users require more in the future ? I will leave that to the DT maintainers but 9 is simply random based on Linux code so I would rather choose some other random number with a better reasoning than 9 as AMBA code in the kernel is limiting it to 9.
On 29/03/2023 17:39, Cristian Marussi wrote: > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the > maximum number of available channels, but anyway no more than the maximum > number of supported interrupt for an AMBA device. > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: devicetree@vger.kernel.org > > .../devicetree/bindings/mailbox/arm,mhuv2.yaml | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > index a4f1fe63659a..5a57f4e2a623 100644 > --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > @@ -69,10 +69,15 @@ properties: > > interrupts: > description: | > - The MHUv2 controller always implements an interrupt in the "receiver" > - mode, while the interrupt in the "sender" mode was not available in the > - version MHUv2.0, but the later versions do have it. > - maxItems: 1 > + The MHUv2 controller always implements at least an interrupt in the > + "receiver" mode, while the interrupt in the "sender" mode was not > + available in the version MHUv2.0, but the later versions do have it. > + In "receiver" mode, beside a single combined interrupt, there could be > + multiple interrupts, up to the number of implemented channels but anyway > + no more than the maximum number of interrupts potentially supported by > + AMBA. Last sentence indicates that TX mode has something else, e.g. max 1 interrupt. Either correct the sentence or add if:then: narrowing it for TX. Best regards, Krzysztof
On 29/03/2023 17:39, Cristian Marussi wrote: > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the > maximum number of available channels, but anyway no more than the maximum > number of supported interrupt for an AMBA device. Subject: no spaces before colon. > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > --- > Cc: Rob Herring <robh+dt@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: devicetree@vger.kernel.org Best regards, Krzysztof
On Wed, Mar 29, 2023 at 06:44:31PM +0100, Sudeep Holla wrote: > On Wed, Mar 29, 2023 at 04:39:35PM +0100, Cristian Marussi wrote: > > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the > > maximum number of available channels, but anyway no more than the maximum > > number of supported interrupt for an AMBA device. > > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > > --- > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > Cc: devicetree@vger.kernel.org > > > > .../devicetree/bindings/mailbox/arm,mhuv2.yaml | 13 +++++++++---- > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > index a4f1fe63659a..5a57f4e2a623 100644 > > --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > @@ -69,10 +69,15 @@ properties: > > > > interrupts: > > description: | > > - The MHUv2 controller always implements an interrupt in the "receiver" > > - mode, while the interrupt in the "sender" mode was not available in the > > - version MHUv2.0, but the later versions do have it. > > - maxItems: 1 > > + The MHUv2 controller always implements at least an interrupt in the > > + "receiver" mode, while the interrupt in the "sender" mode was not > > + available in the version MHUv2.0, but the later versions do have it. > > + In "receiver" mode, beside a single combined interrupt, there could be > > + multiple interrupts, up to the number of implemented channels but anyway > > + no more than the maximum number of interrupts potentially supported by > > + AMBA. > > + minItems: 1 > > + maxItems: 9 > Hi, > I am not sure 9 is the correct value here. IIUC it is just what Linux defines > as AMBA_NR_IRQS. Looking at the history it was bumped from 2 to 9 for use > by PL330 DMA driver. I couldn't find anything to relate this 9 in any > AMBA or other related specification. > Yes, I could not find either where the 9 comes from, but it is what currently each amba device is limited to, at the software level, in terms of interrupts that can be detected. > Ideally I would say we don't know what the max here. We just have a platform > implementing 2 interrupts now. Do we for with 2 for now and change it if some > new users require more in the future ? > By the spec seems to me that the maximum number of interrupts are equal to the maximum possible channels (124), or one combined interrupt. But these in turn, as said, are capped by the AMBA_NR_IRQS and I have only seen one system using 2. (for which I need this series to work) > I will leave that to the DT maintainers but 9 is simply random based on Linux > code so I would rather choose some other random number with a better reasoning > than 9 as AMBA code in the kernel is limiting it to 9. > Agreed. Aiming to describe any possible hw in the DT, I would say 124 at this point. (even though implausible not to use the combined interrupt at that point...) Thanks, Cristian
On Thu, Mar 30, 2023 at 09:36:06AM +0200, Krzysztof Kozlowski wrote: > On 29/03/2023 17:39, Cristian Marussi wrote: > > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the > > maximum number of available channels, but anyway no more than the maximum > > number of supported interrupt for an AMBA device. > > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > > --- > > Cc: Rob Herring <robh+dt@kernel.org> > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > Cc: devicetree@vger.kernel.org > > > > .../devicetree/bindings/mailbox/arm,mhuv2.yaml | 13 +++++++++---- > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > index a4f1fe63659a..5a57f4e2a623 100644 > > --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > @@ -69,10 +69,15 @@ properties: > > > > interrupts: > > description: | > > - The MHUv2 controller always implements an interrupt in the "receiver" > > - mode, while the interrupt in the "sender" mode was not available in the > > - version MHUv2.0, but the later versions do have it. > > - maxItems: 1 > > + The MHUv2 controller always implements at least an interrupt in the > > + "receiver" mode, while the interrupt in the "sender" mode was not > > + available in the version MHUv2.0, but the later versions do have it. > > + In "receiver" mode, beside a single combined interrupt, there could be > > + multiple interrupts, up to the number of implemented channels but anyway > > + no more than the maximum number of interrupts potentially supported by > > + AMBA. > Hi, > Last sentence indicates that TX mode has something else, e.g. max 1 > interrupt. Either correct the sentence or add if:then: narrowing it for TX. > By the spec really you can have up to 124 rx interrupt (one per channel) and optionally 124 tx interrupt too. At least one RX is mandatory, while the TX clear channel iterrupt is optional (and not supported at all for spec < 2.1) In both cases you could just have one single combined interrupt, though, and this is what the driver did, and still do (I have noot changed this), on the TX side: it just supports one single combined tx interrupt. So on the TX side, at the HW level, there could be really 124 interrupts BUT the driver still only support a single combined one. So I think my statement above is anyway ambiguos and I'll fix it, but how to fix it, really depends if we want to describe fully what the HW potentially supports OR what the driver really can cope with as of now. Thanks, Cristian
On Thu, Mar 30, 2023 at 09:29:23AM +0100, Cristian Marussi wrote: > On Wed, Mar 29, 2023 at 06:44:31PM +0100, Sudeep Holla wrote: > > On Wed, Mar 29, 2023 at 04:39:35PM +0100, Cristian Marussi wrote: > > > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the > > > maximum number of available channels, but anyway no more than the maximum > > > number of supported interrupt for an AMBA device. > > > > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > > > --- > > > Cc: Rob Herring <robh+dt@kernel.org> > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > > Cc: devicetree@vger.kernel.org > > > > > > .../devicetree/bindings/mailbox/arm,mhuv2.yaml | 13 +++++++++---- > > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > > index a4f1fe63659a..5a57f4e2a623 100644 > > > --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > > @@ -69,10 +69,15 @@ properties: > > > > > > interrupts: > > > description: | > > > - The MHUv2 controller always implements an interrupt in the "receiver" > > > - mode, while the interrupt in the "sender" mode was not available in the > > > - version MHUv2.0, but the later versions do have it. > > > - maxItems: 1 > > > + The MHUv2 controller always implements at least an interrupt in the > > > + "receiver" mode, while the interrupt in the "sender" mode was not > > > + available in the version MHUv2.0, but the later versions do have it. > > > + In "receiver" mode, beside a single combined interrupt, there could be > > > + multiple interrupts, up to the number of implemented channels but anyway > > > + no more than the maximum number of interrupts potentially supported by > > > + AMBA. > > > + minItems: 1 > > > + maxItems: 9 > > > > Hi, > > > I am not sure 9 is the correct value here. IIUC it is just what Linux defines > > as AMBA_NR_IRQS. Looking at the history it was bumped from 2 to 9 for use > > by PL330 DMA driver. I couldn't find anything to relate this 9 in any > > AMBA or other related specification. > > > > Yes, I could not find either where the 9 comes from, but it is what > currently each amba device is limited to, at the software level, in terms of > interrupts that can be detected. IIRC, the PL330 can have an interrupt per context with up to 8 contexts and then 1 global interrupt. > > > Ideally I would say we don't know what the max here. We just have a platform > > implementing 2 interrupts now. Do we for with 2 for now and change it if some > > new users require more in the future ? > > > > By the spec seems to me that the maximum number of interrupts are equal to > the maximum possible channels (124), or one combined interrupt. > > But these in turn, as said, are capped by the AMBA_NR_IRQS and I have > only seen one system using 2. (for which I need this series to work) > > > I will leave that to the DT maintainers but 9 is simply random based on Linux > > code so I would rather choose some other random number with a better reasoning > > than 9 as AMBA code in the kernel is limiting it to 9. > > > > Agreed. Aiming to describe any possible hw in the DT, I would say 124 at > this point. (even though implausible not to use the combined interrupt > at that point...) Then use 124, but please describe how you get that in the description. Rob
On Wed, Apr 12, 2023 at 08:15:21AM -0500, Rob Herring wrote: > On Thu, Mar 30, 2023 at 09:29:23AM +0100, Cristian Marussi wrote: > > On Wed, Mar 29, 2023 at 06:44:31PM +0100, Sudeep Holla wrote: > > > On Wed, Mar 29, 2023 at 04:39:35PM +0100, Cristian Marussi wrote: > > > > The ARM MHUv2 Receiver block can indeed support more interrupts, up to the > > > > maximum number of available channels, but anyway no more than the maximum > > > > number of supported interrupt for an AMBA device. > > > > > > > > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> > > > > --- > > > > Cc: Rob Herring <robh+dt@kernel.org> > > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > > > Cc: devicetree@vger.kernel.org > > > > > > > > .../devicetree/bindings/mailbox/arm,mhuv2.yaml | 13 +++++++++---- > > > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > > > index a4f1fe63659a..5a57f4e2a623 100644 > > > > --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > > > +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml > > > > @@ -69,10 +69,15 @@ properties: > > > > > > > > interrupts: > > > > description: | > > > > - The MHUv2 controller always implements an interrupt in the "receiver" > > > > - mode, while the interrupt in the "sender" mode was not available in the > > > > - version MHUv2.0, but the later versions do have it. > > > > - maxItems: 1 > > > > + The MHUv2 controller always implements at least an interrupt in the > > > > + "receiver" mode, while the interrupt in the "sender" mode was not > > > > + available in the version MHUv2.0, but the later versions do have it. > > > > + In "receiver" mode, beside a single combined interrupt, there could be > > > > + multiple interrupts, up to the number of implemented channels but anyway > > > > + no more than the maximum number of interrupts potentially supported by > > > > + AMBA. > > > > + minItems: 1 > > > > + maxItems: 9 > > > > > > > Hi, > > > > > I am not sure 9 is the correct value here. IIUC it is just what Linux defines > > > as AMBA_NR_IRQS. Looking at the history it was bumped from 2 to 9 for use > > > by PL330 DMA driver. I couldn't find anything to relate this 9 in any > > > AMBA or other related specification. > > > > > > > Yes, I could not find either where the 9 comes from, but it is what > > currently each amba device is limited to, at the software level, in terms of > > interrupts that can be detected. > > IIRC, the PL330 can have an interrupt per context with up to 8 contexts > and then 1 global interrupt. > > > > > > Ideally I would say we don't know what the max here. We just have a platform > > > implementing 2 interrupts now. Do we for with 2 for now and change it if some > > > new users require more in the future ? > > > > > > > By the spec seems to me that the maximum number of interrupts are equal to > > the maximum possible channels (124), or one combined interrupt. > > > > But these in turn, as said, are capped by the AMBA_NR_IRQS and I have > > only seen one system using 2. (for which I need this series to work) > > > > > I will leave that to the DT maintainers but 9 is simply random based on Linux > > > code so I would rather choose some other random number with a better reasoning > > > than 9 as AMBA code in the kernel is limiting it to 9. > > > > > > > Agreed. Aiming to describe any possible hw in the DT, I would say 124 at > > this point. (even though implausible not to use the combined interrupt > > at that point...) > > Then use 124, but please describe how you get that in the description. > Ok, thanks, I'll do. Cristian
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml index a4f1fe63659a..5a57f4e2a623 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml @@ -69,10 +69,15 @@ properties: interrupts: description: | - The MHUv2 controller always implements an interrupt in the "receiver" - mode, while the interrupt in the "sender" mode was not available in the - version MHUv2.0, but the later versions do have it. - maxItems: 1 + The MHUv2 controller always implements at least an interrupt in the + "receiver" mode, while the interrupt in the "sender" mode was not + available in the version MHUv2.0, but the later versions do have it. + In "receiver" mode, beside a single combined interrupt, there could be + multiple interrupts, up to the number of implemented channels but anyway + no more than the maximum number of interrupts potentially supported by + AMBA. + minItems: 1 + maxItems: 9 clocks: maxItems: 1