linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Daire.McNamara@microchip.com>
To: <heinrich.schuchardt@canonical.com>, <Conor.Dooley@microchip.com>,
	<robh+dt@kernel.org>
Cc: <linux-riscv@lists.infradead.org>,
	<emil.renner.berthing@canonical.com>,
	<devicetree@vger.kernel.org>, <paul.walmsley@sifive.com>,
	<aou@eecs.berkeley.edu>, <palmer@dabbelt.com>,
	<geert@linux-m68k.org>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>, <atishp@rivosinc.com>,
	<krzysztof.kozlowski+dt@linaro.org>
Subject: Re: [PATCH 1/1] riscv: dts: microchip: correct L2 cache interrupts
Date: Thu, 18 Aug 2022 07:03:45 +0000	[thread overview]
Message-ID: <ccb5792bfe467dcc5046b7cb4de3a6af14cd3d5a.camel@microchip.com> (raw)
In-Reply-To: <32a72954-c692-6c5d-b07b-266d426c3cb4@microchip.com>

On Wed, 2022-08-17 at 18:04 +0000, Conor Dooley - M52691 wrote:
> Hey Heinrich,
> Interesting CC list you got there! Surprised the mailmap didn't sort
> out Atish & Krzysztof's addresses, but I think I've fixed them up.
>  I see Daire isn't there either so +CC him too.
> 
> On 17/08/2022 14:25, Heinrich Schuchardt wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> > 
> > The "PolarFire SoC MSS Technical Reference Manual" documents the
> > following PLIC interrupts:
> > 
> > 1 - L2 Cache Controller Signals when a metadata correction event
> > occurs
> > 2 - L2 Cache Controller Signals when an uncorrectable metadata
> > event occurs
> > 3 - L2 Cache Controller Signals when a data correction event occurs
> > 4 - L2 Cache Controller Signals when an uncorrectable data event
> > occurs
> > 
> > This differs from the SiFive FU540 which only has three L2 cache
> > related
> > interrupts.
> > 
> > The sequence in the device tree is defined by an enum:
in drivers/soc/sifive/sifive_l2_cache.c
> > 
> >     enum {
> >             DIR_CORR = 0,
> >             DATA_CORR,
> >             DATA_UNCORR,
> >             DIR_UNCORR,
> >     };
> 
> Nit: more accurately by the dt-binding:
>   interrupts:
>     minItems: 3
>     items:
>       - description: DirError interrupt
>       - description: DataError interrupt
>       - description: DataFail interrupt
>       - description: DirFail interrupt
> 
> I do find the names in the enum to be a bit more understandable
> however,
> and ditto for the descriptions in our TRM... Maybe I should put that
> on
> my todo list of cleanups :)
> 
> 
> > So the correct sequence of the L2 cache interrupts is
> > 
> >     interrupts = <1>, <3>, <4>, <2>;
> 
> This looks correct to me. You mentioned on IRC that what you were
> seeing
> was a wall of
> L2CACHE: DataFail @ 0x00000000.0807FFD8
> From a quick look at the driver, what seems to be happening here is
> that
> at some point (possibly before Linux even comes into the picture)
> there
> is an uncorrectable data error. Because the ordering in the dt is
> wrong,
> we read the wrong register and so the interrupt is never actually
> cleared. With this patch applied, I see a single DataFail right as
> the
> interrupt gets registed & nothing after that.
> 
> I am not really sure what value there is in enabling that driver
> though,
> mostly just seems like a debugging tool & from our pov we would see
> the
> HSS running in the monitor core as being responsible for handling the
> l2-cache errors.
> 
> @Daire, maybe you have an opinion here?
Likewise. The new ordering of the interrupts to what the driver expects
looks correct - as far as it goes. However, I'm not convinced enabling
the SiFive l2 cache driver out of the box makes sense. Using l2 cache
driver doesn't align terribly well with the current MPFS roadmap for
mgt of ECC errors.
> 
> Patch LGTM, so I'll likely apply it in the next day or two, would
> just
> like to see what Daire has to say first.
If l2-cache controller is enabled, then interrupts should be connected
as per TRM.  I think this specific patch lgtm, ideally with a
'disabled' stanza and it's up to individual MPFS customers/boards to
enable l2 cache controller if they want it.
> 
> > Fixes: e35b07a7df9b ("riscv: dts: microchip: mpfs: Group tuples in
> > interrupt properties")
> 
> BTW, it isn't really fixing this patch right? This is a dependency
> for
> backports to 5.15.
> 
> Thanks for your patch,
> Conor.
> 
> > Fixes: 0fa6107eca41 ("RISC-V: Initial DTS for Microchip ICICLE
> > board")
> > Cc: Conor Dooley <conor.dooley@microchip.com>
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Heinrich Schuchardt <
> > heinrich.schuchardt@canonical.com>
> > ---
> >  arch/riscv/boot/dts/microchip/mpfs.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/riscv/boot/dts/microchip/mpfs.dtsi
> > b/arch/riscv/boot/dts/microchip/mpfs.dtsi
> > index 496d3b7642bd..ec1de6344be9 100644
> > --- a/arch/riscv/boot/dts/microchip/mpfs.dtsi
> > +++ b/arch/riscv/boot/dts/microchip/mpfs.dtsi
> > @@ -169,7 +169,7 @@ cctrllr: cache-controller@2010000 {
> >                         cache-size = <2097152>;
> >                         cache-unified;
> >                         interrupt-parent = <&plic>;
> > -                       interrupts = <1>, <2>, <3>;
> > +                       interrupts = <1>, <3>, <4>, <2>;
> >                 };
> > 
> >                 clint: clint@2000000 {
> > --
> > 2.36.1
> > 

  reply	other threads:[~2022-08-18  7:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 13:25 [PATCH 1/1] riscv: dts: microchip: correct L2 cache interrupts Heinrich Schuchardt
2022-08-17 18:04 ` Conor.Dooley
2022-08-18  7:03   ` Daire.McNamara [this message]
2022-08-18  8:17     ` Heinrich Schuchardt
2022-08-18  8:33       ` Conor.Dooley
2022-08-18 20:19 ` Conor Dooley
2022-08-29  9:10 Heinrich Schuchardt
2022-08-29 10:32 ` Conor.Dooley

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=ccb5792bfe467dcc5046b7cb4de3a6af14cd3d5a.camel@microchip.com \
    --to=daire.mcnamara@microchip.com \
    --cc=Conor.Dooley@microchip.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=atishp@rivosinc.com \
    --cc=devicetree@vger.kernel.org \
    --cc=emil.renner.berthing@canonical.com \
    --cc=geert@linux-m68k.org \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=stable@vger.kernel.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).