All of lore.kernel.org
 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>,
	Loic Poulain <loic.poulain@linaro.org>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] irqchip: Add Qualcomm MPM controller driver
Date: Tue, 07 Dec 2021 10:16:32 +0000	[thread overview]
Message-ID: <87mtlc1zzz.wl-maz@kernel.org> (raw)
In-Reply-To: <20211207094835.GO10105@dragon>

On Tue, 07 Dec 2021 09:48:36 +0000,
Shawn Guo <shawn.guo@linaro.org> wrote:
> 
> On Mon, Dec 06, 2021 at 01:48:12PM +0000, Marc Zyngier wrote:
> > > > > +static int qcom_mpm_enter_sleep(struct qcom_mpm_priv *priv)
> > > > > +{
> > > > > +	int i, ret;
> > > > > +
> > > > > +	for (i = 0; i < priv->reg_stride; i++)
> > > > > +		qcom_mpm_write(priv, MPM_REG_STATUS, i, 0);
> > > > > +
> > > > > +	/* Notify RPM to write vMPM into HW */
> > > > 
> > > > What do you mean by 'into HW'? We just did that, right? or are these
> > > > registers just fake and most of the stuff is in the RPM?
> > > 
> > > I have a note about this in commit log.
> > > 
> > > - All the register settings are done by APSS on an internal memory
> > >   region called vMPM, and RPM will flush them into hardware after it
> > >   receives a mailbox/IPC notification from APSS.
> > > 
> > > So yes, these registers are fake/virtual in memory, and RPM will
> > > actually flush the values into the MPM hardware block.
> > 
> > Then why are you using MMIO accessors all over the place if this is
> > just RAM? Who *owns* this memory? Is it normal DRAM? Or some flops
> > exposed by a device? Why isn't the state simply communicated over the
> > mailbox instead?
> 
> It's a piece of internal memory (SRAM) which can be access by AP and
> RPM.  The communication mechanism is defined by SoC/RPM design, and we
> can do nothing but following the procedure.

Then the procedure needs to be documented:

- Who owns the memory at any given time?

- What are the events that trigger a change of ownership?

- What are the messages exchanged between these entities?

- What is the synchronisation mechanism between the various processing
  entities (MPM. RPM, APSS...)?

- Is the per-interrupt tracking a HW requirement or a SW
  implementation choice? Could this instead be a one-shot operation
  iterating over the whole state?

All this needs to be explained so that it is maintainable, because I'm
getting tired of drivers that mimic the QC downstream code without
justification nor documentation to support the implementation.

	M.

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

  reply	other threads:[~2021-12-07 10:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-02 12:21 [PATCH v3 0/3] Add Qualcomm MPM irqchip driver support Shawn Guo
2021-12-02 12:21 ` [PATCH v3 1/3] irqchip: Pass platform_device pointer to init_cb Shawn Guo
2021-12-02 17:52   ` Florian Fainelli
2021-12-02 19:10     ` Marc Zyngier
2021-12-02 21:44       ` Florian Fainelli
2021-12-06  6:40       ` Shawn Guo
2021-12-06  8:29         ` Marc Zyngier
2021-12-06  6:35     ` Shawn Guo
2021-12-02 12:21 ` [PATCH v3 2/3] dt-bindings: interrupt-controller: Add Qualcomm MPM support Shawn Guo
2021-12-02 12:21 ` [PATCH v3 3/3] irqchip: Add Qualcomm MPM controller driver Shawn Guo
2021-12-03  0:00   ` kernel test robot
2021-12-03  0:00     ` kernel test robot
2021-12-06  9:46   ` Marc Zyngier
2021-12-06 13:15     ` Shawn Guo
2021-12-06 13:48       ` Marc Zyngier
2021-12-07  9:48         ` Shawn Guo
2021-12-07 10:16           ` Marc Zyngier [this message]
2021-12-08 10:04             ` Shawn Guo

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=87mtlc1zzz.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@linaro.org \
    --cc=quic_mkshah@quicinc.com \
    --cc=shawn.guo@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.