linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yu-Chien Peter Lin <peterlin@andestech.com>
To: Anup Patel <apatel@ventanamicro.com>
Cc: <acme@kernel.org>, <adrian.hunter@intel.com>,
	<ajones@ventanamicro.com>, <alexander.shishkin@linux.intel.com>,
	<andre.przywara@arm.com>, <anup@brainfault.org>,
	<aou@eecs.berkeley.edu>, <atishp@atishpatra.org>,
	<conor+dt@kernel.org>, <conor.dooley@microchip.com>,
	<conor@kernel.org>, <devicetree@vger.kernel.org>,
	<dminus@andestech.com>, <evan@rivosinc.com>,
	<geert+renesas@glider.be>, <guoren@kernel.org>, <heiko@sntech.de>,
	<irogers@google.com>, <jernej.skrabec@gmail.com>,
	<jolsa@kernel.org>, <jszhang@kernel.org>,
	<krzysztof.kozlowski+dt@linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-perf-users@vger.kernel.org>,
	<linux-renesas-soc@vger.kernel.org>,
	<linux-riscv@lists.infradead.org>, <linux-sunxi@lists.linux.dev>,
	<locus84@andestech.com>, <magnus.damm@gmail.com>,
	<mark.rutland@arm.com>, <mingo@redhat.com>, <n.shubin@yadro.com>,
	<namhyung@kernel.org>, <palmer@dabbelt.com>,
	<paul.walmsley@sifive.com>, <peterz@infradead.org>,
	<prabhakar.mahadev-lad.rj@bp.renesas.com>,
	<rdunlap@infradead.org>, <robh+dt@kernel.org>,
	<samuel@sholland.org>, <sunilvl@ventanamicro.com>,
	<tglx@linutronix.de>, <tim609@andestech.com>, <uwu@icenowy.me>,
	<wens@csie.org>, <will@kernel.org>, <ycliang@andestech.com>,
	<inochiama@outlook.com>
Subject: Re: [PATCH v5 02/16] irqchip/riscv-intc: Allow large non-standard interrupt number
Date: Tue, 19 Dec 2023 15:43:29 +0800	[thread overview]
Message-ID: <ZYFJjR1rD5Hn-HEH@APC323> (raw)
In-Reply-To: <CAK9=C2U+rSP8YMahPmTHLYZ+ZBfwwY5y52JeU_=R+VL1frR1Uw@mail.gmail.com>

Hi Anup,

On Wed, Dec 13, 2023 at 08:49:23PM +0530, Anup Patel wrote:
> On Wed, Dec 13, 2023 at 7:58 PM Anup Patel <apatel@ventanamicro.com> wrote:
> >
> > On Wed, Dec 13, 2023 at 12:34 PM Yu Chien Peter Lin
> > <peterlin@andestech.com> wrote:
> > >
> > > Currently, the implementation of the RISC-V INTC driver uses the
> > > interrupt cause as hardware interrupt number and has a limitation of
> > > supporting a maximum of 64 interrupts. However, according to the
> > > privileged spec, interrupt causes >= 16 are defined for platform use.
> >
> > I disagree with this patch.
> >
> > Even though RISC-V priv sepc allows interrupt causes >= 16, we
> > still need CSRs to manage arbitrary local interrupts
> >
> > Currently, we have following standard CSRs:
> > 1) [m|s]ie and [m|s]ip which are XLEN wide
> > 2) With AIA, we have [m|s]ieh and [m|s]iph for RV32
> >
> > Clearly, we can only have a XLEN number of standard local
> > interrupts without AIA and 64 local interrupts with AIA.
> >
> > Now for implementations with custom CSRs (such as Andes),
> > we still can't assume infinite local interrupts because HW will
> > have a finite number of custom CSRs.
> >
> > >
> > > This limitation prevents to fully utilize the available local interrupt
> > > sources. Additionally, the interrupt number used on RISC-V are sparse,
> > > with only interrupt numbers 1, 5 and 9 (plus Sscofpmf or T-Head's PMU
> > > interrupt) being currently used for supervisor mode.
> > >
> > > Switch to using irq_domain_create_tree() to create the radix tree
> > > map, so a larger number of hardware interrupts can be handled.
> > >
> > > Signed-off-by: Yu Chien Peter Lin <peterlin@andestech.com>
> > > Reviewed-by: Charles Ci-Jyun Wu <dminus@andestech.com>
> > > Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
> > > ---
> > > Changes v1 -> v2:
> > >   - Fixed irq mapping failure checking (suggested by Clément and Anup)
> > > Changes v2 -> v3:
> > >   - No change
> > > Changes v3 -> v4: (Suggested by Thomas [1])
> > >   - Use pr_warn_ratelimited instead
> > >   - Fix coding style and commit message
> > > Changes v4 -> v5: (Suggested by Thomas)
> > >   - Fix commit message
> > >
> > > [1] https://patchwork.kernel.org/project/linux-riscv/patch/20231023004100.2663486-3-peterlin@andestech.com/#25573085
> > > ---
> > >  drivers/irqchip/irq-riscv-intc.c | 12 ++++--------
> > >  1 file changed, 4 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
> > > index e8d01b14ccdd..2fdd40f2a791 100644
> > > --- a/drivers/irqchip/irq-riscv-intc.c
> > > +++ b/drivers/irqchip/irq-riscv-intc.c
> > > @@ -24,10 +24,9 @@ static asmlinkage void riscv_intc_irq(struct pt_regs *regs)
> > >  {
> > >         unsigned long cause = regs->cause & ~CAUSE_IRQ_FLAG;
> > >
> > > -       if (unlikely(cause >= BITS_PER_LONG))
> > > -               panic("unexpected interrupt cause");
> > > -
> > > -       generic_handle_domain_irq(intc_domain, cause);
> > > +       if (generic_handle_domain_irq(intc_domain, cause))
> > > +               pr_warn_ratelimited("Failed to handle interrupt (cause: %ld)\n",
> > > +                                   cause);
> > >  }
> > >
> > >  /*
> > > @@ -117,8 +116,7 @@ static int __init riscv_intc_init_common(struct fwnode_handle *fn)
> > >  {
> > >         int rc;
> > >
> > > -       intc_domain = irq_domain_create_linear(fn, BITS_PER_LONG,
> > > -                                              &riscv_intc_domain_ops, NULL);
> > > +       intc_domain = irq_domain_create_tree(fn, &riscv_intc_domain_ops, NULL);
> >
> > I disagree with this change based on the reasoning above.
> >
> > Instead of this, we should determine the number of local interrupts
> > based on the type of RISC-V intc:
> > 1) For standard INTC without AIA, we have XLEN (or BITS_PER_LONG)
> >     local interrupts
> > 2) For standart INTC with AIA, we have 64 local interrupts
> > 3) For custom INTC (such as Andes), the number of local interrupt
> >     should be custom (Andes specific) which can be determined based
> >     on compatible string.
> >
> > Also, creating a linear domain with a fixed number of local interrupts
> > ensures that drivers can't map a local interrupt beyond the availability
> > of CSRs to manage it.
> 
> Thinking about this more. We do have a problem because Andes local
> interrupts are really sparse which is not the case for standard local
> interrupts
> 
> I have an alternate suggestion which goes as follows ...
> 
> We use irq_domain_create_tree() in-place of irq_domain_create_linear()
> and enforce checks on hwirq in riscv_intc_domain_alloc() to ensure that
> we only allow hwirq for which we have corresponding standard or custom
> CSR.
> 
> To achieve this, riscv_intc_init_common() will have to save the following
> as static global variables:
> 1) riscv_intc_nr_irqs: Number of standard local interrupts
> 2) riscv_intc_custom_base and riscv_intc_custom_nr_irqs: Base and
>     number of custom local interrupts.
> 
> Using the above static global variables, the riscv_intc_domain_alloc()
> can return error if one of the following conditions are met:
> 1) riscv_intc_nr_irqs<= hwirq && hwirq < riscv_intc_custom_base
> 2) (riscv_intc_custom_base + riscv_intc_custom_nr_irqs) <= hwirq
> 
> For standard INTC, we can set the static global variable as follows:
> riscv_intc_nr_irqs = XLEN or BITS_PER_LONG
> riscv_intc_custom_base = riscv_intc_nr_irqs
> riscv_intc_custom_nr_irqs = 0
> 
> For Andes INTC, we can set the static global variables as follows:
> riscv_intc_nr_irqs = XLEN or BITS_PER_LONG
> riscv_intc_custom_base = 256
> riscv_intc_custom_nr_irqs = XLEN or BITS_PER_LONG
> 
> Regards,
> Anup

Thank you for offering your help on this.
I will rework the patch accordingly.

Best regards,
Peter Lin

> >
> > >         if (!intc_domain) {
> > >                 pr_err("unable to add IRQ domain\n");
> > >                 return -ENXIO;
> > > @@ -132,8 +130,6 @@ static int __init riscv_intc_init_common(struct fwnode_handle *fn)
> > >
> > >         riscv_set_intc_hwnode_fn(riscv_intc_hwnode);
> > >
> > > -       pr_info("%d local interrupts mapped\n", BITS_PER_LONG);
> > > -
> >
> > Same as above, we should definitely advertise the type of INTC and
> > number of local interrupts mapped.
> >
> > Regards,
> > Anup
> >
> > >         return 0;
> > >  }
> > >
> > > --
> > > 2.34.1
> > >
> > >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2023-12-19  7:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13  7:02 [PATCH v5 00/16] Support Andes PMU extension Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 01/16] riscv: errata: Rename defines for Andes Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 02/16] irqchip/riscv-intc: Allow large non-standard interrupt number Yu Chien Peter Lin
2023-12-13 14:28   ` Anup Patel
2023-12-13 15:19     ` Anup Patel
2023-12-19  7:43       ` Yu-Chien Peter Lin [this message]
2023-12-13  7:02 ` [PATCH v5 03/16] irqchip/riscv-intc: Introduce Andes hart-level interrupt controller Yu Chien Peter Lin
2023-12-13 14:45   ` Anup Patel
2023-12-13 15:44     ` Yu-Chien Peter Lin
2023-12-13 15:48       ` Anup Patel
2023-12-13  7:02 ` [PATCH v5 04/16] dt-bindings: riscv: Add Andes interrupt controller compatible string Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 05/16] riscv: dts: renesas: r9a07g043f: Update compatible string to use Andes INTC Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 06/16] perf: RISC-V: Eliminate redundant interrupt enable/disable operations Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 07/16] RISC-V: Move T-Head PMU to CPU feature alternative framework Yu Chien Peter Lin
2023-12-13 15:27   ` Conor Dooley
2023-12-13 15:32     ` Conor Dooley
2023-12-13  7:02 ` [PATCH v5 08/16] perf: RISC-V: Introduce Andes PMU for perf event sampling Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 09/16] dt-bindings: riscv: Add T-Head PMU extension description Yu Chien Peter Lin
2023-12-13 15:26   ` Conor Dooley
2023-12-13  7:02 ` [PATCH v5 10/16] dt-bindings: riscv: Add Andes " Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 11/16] riscv: dts: allwinner: Add T-Head PMU extension for sun20i-d1s Yu Chien Peter Lin
2023-12-13  7:02 ` [PATCH v5 12/16] riscv: dts: sophgo: Add T-Head PMU extension for cv1800b Yu Chien Peter Lin
2023-12-13 15:23   ` Conor Dooley
2023-12-13  7:02 ` [PATCH v5 13/16] riscv: dts: sophgo: Add T-Head PMU extension for sg2042 Yu Chien Peter Lin
2023-12-13 15:24   ` Conor Dooley
2023-12-13  7:02 ` [PATCH v5 14/16] riscv: dts: thead: Add T-Head PMU extension for th1520 Yu Chien Peter Lin
2023-12-13 15:23   ` Conor Dooley
2023-12-13  7:03 ` [PATCH v5 15/16] riscv: dts: renesas: Add Andes PMU extension for r9a07g043f Yu Chien Peter Lin
2023-12-13 15:24   ` Conor Dooley
2023-12-13  7:03 ` [PATCH v5 16/16] riscv: andes: Support specifying symbolic firmware and hardware raw events Yu Chien Peter Lin

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=ZYFJjR1rD5Hn-HEH@APC323 \
    --to=peterlin@andestech.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ajones@ventanamicro.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andre.przywara@arm.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=atishp@atishpatra.org \
    --cc=conor+dt@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dminus@andestech.com \
    --cc=evan@rivosinc.com \
    --cc=geert+renesas@glider.be \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=inochiama@outlook.com \
    --cc=irogers@google.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=jszhang@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=locus84@andestech.com \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=n.shubin@yadro.com \
    --cc=namhyung@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=samuel@sholland.org \
    --cc=sunilvl@ventanamicro.com \
    --cc=tglx@linutronix.de \
    --cc=tim609@andestech.com \
    --cc=uwu@icenowy.me \
    --cc=wens@csie.org \
    --cc=will@kernel.org \
    --cc=ycliang@andestech.com \
    /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).