devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Maulik Shah <quic_mkshah@quicinc.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 2/2] irqchip: Add Qualcomm MPM controller driver
Date: Wed, 02 Mar 2022 10:25:45 +0000	[thread overview]
Message-ID: <877d9c3b2u.wl-maz@kernel.org> (raw)
In-Reply-To: <20220302084028.GL269879@dragon>

On Wed, 02 Mar 2022 08:40:28 +0000,
Shawn Guo <shawn.guo@linaro.org> wrote:
> 
> Hi Marc,
> 
> On Tue, Mar 01, 2022 at 11:13:30AM +0000, Marc Zyngier wrote:
> > Hi Shawn,

[...]

> > 
> > > +static int qcom_mpm_set_type(struct irq_data *d, unsigned int type)
> > > +{
> > > +	struct qcom_mpm_priv *priv = d->chip_data;
> > > +	int pin = d->hwirq;
> > > +	unsigned int index = pin / 32;
> > > +	unsigned int shift = pin % 32;
> > > +
> > > +	switch (type & IRQ_TYPE_SENSE_MASK) {
> > > +	case IRQ_TYPE_EDGE_RISING:
> > > +		mpm_set_type(priv, !!(type & IRQ_TYPE_EDGE_RISING),
> > > +			     MPM_REG_RISING_EDGE, index, shift);
> > > +		break;
> > > +	case IRQ_TYPE_EDGE_FALLING:
> > > +		mpm_set_type(priv, !!(type & IRQ_TYPE_EDGE_FALLING),
> > > +			     MPM_REG_FALLING_EDGE, index, shift);
> > > +		break;
> > > +	case IRQ_TYPE_LEVEL_HIGH:
> > > +		mpm_set_type(priv, !!(type & IRQ_TYPE_LEVEL_HIGH),
> > > +			     MPM_REG_POLARITY, index, shift);
> > > +		break;
> > > +	}
> > 
> > All these '!!(type & BLAH)' are totally superfluous, as they all expand
> > to 'true' by construction.
> 
> Yes, you are right!
> 
> > And this leads to a few questions:
> > 
> > - Shouldn't a rising interrupt clear the falling detection?
> > - Shouldn't a level-low clear the polarity?
> > - How do you handle IRQ_TYPE_EDGE_BOTH?
> > - How is MPM_REG_POLARITY evaluated for edge interrupts (resp the EDGE
> >   registers for level interrupts), as you never seem to be configuring
> >   a type here?
> 
> Honestly, qcom_mpm_set_type() was mostly taken from downstream without
> too much thinking.  I trusted it as a "good" reference as I have no
> document to verify the code.  These questions are great and resulted the
> code changes are pretty sensible to me.

I don't think these changes are enough. For example, an interrupt
being switched from level to edge is likely to misbehave (how do you
distinguish the two?). If that's what the downstream driver does, then
it is terminally broken.

As I asked before, we need some actual specs, or at least someone to
paraphrase it for us. There are a number of QC folks on Cc, and I
expect them to chime in and explain how MPM works here.

> 
> > - What initialises the MPM trigger types at boot time?
> 
> I dumped the vMPM region and it's all zeros.  My understanding is if
> vMPM needs any sort of initialization, it should be done by RPM firmware
> before APSS gets booting.

What about kexec? We can't rely on this memory region to always be
0-initialised, nor do we know what that means.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-03-02 10:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01  6:24 [PATCH v7 0/2] Add Qualcomm MPM irqchip driver support Shawn Guo
2022-03-01  6:24 ` [PATCH v7 1/2] dt-bindings: interrupt-controller: Add Qualcomm MPM support Shawn Guo
2022-03-01  6:24 ` [PATCH v7 2/2] irqchip: Add Qualcomm MPM controller driver Shawn Guo
2022-03-01 11:13   ` Marc Zyngier
2022-03-02  8:40     ` Shawn Guo
2022-03-02 10:25       ` Marc Zyngier [this message]
2022-03-02 13:34         ` Shawn Guo
2022-03-02 13:57           ` Marc Zyngier
2022-03-03  4:02             ` Shawn Guo
2022-03-04  7:59               ` Marc Zyngier
2022-03-04  8:23                 ` Shawn Guo
2022-03-04 15:24                   ` Marc Zyngier
2022-03-05  9:24                     ` Shawn Guo
2022-03-05 11:05                       ` Marc Zyngier
2022-03-06 12:57                         ` Shawn Guo
2022-03-07 11:45                           ` Marc Zyngier

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=877d9c3b2u.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_mkshah@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=shawn.guo@linaro.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    /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).