devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, vincent.guittot@linaro.org,
	souvik.chakravarty@arm.com, nicola.mazzucato@arm.com,
	Tushar.Khandelwal@arm.com, viresh.kumar@linaro.org,
	jassisinghbrar@gmail.com,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: mailbox : arm,mhuv2: Allow for more RX interrupts
Date: Wed, 12 Apr 2023 08:15:21 -0500	[thread overview]
Message-ID: <20230412131521.GA1830888-robh@kernel.org> (raw)
In-Reply-To: <ZCVIVhtSLKTHs+to@e120937-lin>

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

  reply	other threads:[~2023-04-12 13:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230329153936.394911-1-cristian.marussi@arm.com>
2023-03-29 15:39 ` [PATCH 1/2] dt-bindings: mailbox : arm,mhuv2: Allow for more RX interrupts Cristian Marussi
2023-03-29 17:44   ` Sudeep Holla
2023-03-30  8:29     ` Cristian Marussi
2023-04-12 13:15       ` Rob Herring [this message]
2023-04-12 13:20         ` Cristian Marussi
2023-03-30  7:36   ` Krzysztof Kozlowski
2023-03-30  8:45     ` Cristian Marussi
2023-03-30  7:57   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230412131521.GA1830888-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=Tushar.Khandelwal@arm.com \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicola.mazzucato@arm.com \
    --cc=souvik.chakravarty@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).