[PATCH 0/2] riscv,aplic: support for hart indexes

[PATCH 0/2] riscv,aplic: support for hart indexes

[Vladimir Kondratiev]

Risc-v APLIC uses "hart index" to access data per destination hart.
Current implementation assumes hart indexes are consecutive integers
starting from 0, while Risc-V documentation says it may be
arbitrary numbers, with a clue that it may be related to the hart IDs.

In all boards I see in today's kernel, hart IDs are consecutive
integers, thus using dart IDs is the same as indexes.

However, for the MIPS P8700, hart IDs are different from indexes,
on this SoC they encode thread number, core and cluster in bits
[0..3], [4..15], [16..19] resulting Soc consisting of 3 clusters *
4 cores * 2 threads with hart IDs:
0x0, 0x1, 0x10, 0x11, 0x20, 0x21, 0x30, 0x31, 0x10000 etc.

Change default hart index to be hart ID related to the start of domain,
and add optional property to configure arbitrary indexes.

Use of "device_property" API allows to cover both ACPI and OF in single
code

1-st commit adds dt-bindings, 2-nd - code

Vladimir Kondratiev (2):
  dt-bindings: interrupt-controller: add risc-v,aplic hart indexes
  irqchip/riscv-aplic: add support for hart indexes

 .../interrupt-controller/riscv,aplic.yaml     |  8 ++++++
 drivers/irqchip/irq-riscv-aplic-direct.c      | 25 +++++++++++++++++--
 2 files changed, 31 insertions(+), 2 deletions(-)


base-commit: 5bea460cb3a4118c3914e5ce2787736a32365859
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Vladimir Kondratiev]

Document optional property "riscv,hart-index"

Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
---
 .../bindings/interrupt-controller/riscv,aplic.yaml        | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
index 190a6499c932..e163c8de3524 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
@@ -91,6 +91,14 @@ properties:
       Firmware must configure interrupt delegation registers based on
       interrupt delegation list.
 
+  riscv,hart-index:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 16384
+    description:
+      A list of hart indexes that APLIC should use to address each hart
+      that is mentioned in the "interrupts-extended"
+
 dependencies:
   riscv,delegation: [ "riscv,children" ]
 
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 2/2] irqchip/riscv-aplic: add support for hart indexes

[Vladimir Kondratiev]

Risc-V APLIC specification defines "hart index" in [1]:

Within a given interrupt domain, each of the domain’s harts has a
unique index number in the range 0 to 214 − 1 (= 16,383). The index
number a domain associates with a hart may or may not have any
relationship to the unique hart identifier (“hart ID”) that the
RISC-V Privileged Architecture assigns to the hart. Two different
interrupt domains may employ entirely different index numbers for
the same set of harts.

Support arbitrary hart indexes specified in optional APLIC property
"riscv,hart-index" that should be array of u32 elements, one per
interrupt target. If this property not specified, fallback is to use
hart ids, with hart index for each APLIC to be (hartid - hartid0)
where hartid0 is hart id for the 1-st target.

[1]: https://github.com/riscv/riscv-aia

Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
---
 drivers/irqchip/irq-riscv-aplic-direct.c | 25 ++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c b/drivers/irqchip/irq-riscv-aplic-direct.c
index 7cd6b646774b..80c82e34e894 100644
--- a/drivers/irqchip/irq-riscv-aplic-direct.c
+++ b/drivers/irqchip/irq-riscv-aplic-direct.c
@@ -221,12 +221,15 @@ static int aplic_direct_parse_parent_hwirq(struct device *dev, u32 index,
 
 int aplic_direct_setup(struct device *dev, void __iomem *regs)
 {
+	static const char *prop_hart_index = "riscv,hart-index";
 	int i, j, rc, cpu, current_cpu, setup_count = 0;
 	struct aplic_direct *direct;
 	struct irq_domain *domain;
 	struct aplic_priv *priv;
 	struct aplic_idc *idc;
 	unsigned long hartid;
+	unsigned long hartid0;
+	u32 *hart_index = NULL;
 	u32 v, hwirq;
 
 	direct = devm_kzalloc(dev, sizeof(*direct), GFP_KERNEL);
@@ -240,6 +243,22 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
 		return rc;
 	}
 
+	rc = device_property_count_u32(dev, prop_hart_index);
+	if (rc == -ENODATA)
+		rc = 0;
+	if (rc > 0 && rc != priv->nr_idcs)
+		rc = -EOVERFLOW;
+	if (rc > 0) {
+		hart_index = devm_kcalloc(dev, priv->nr_idcs, sizeof(*hart_index), GFP_KERNEL);
+		if (!hart_index)
+			return -ENOMEM;
+		rc = device_property_read_u32_array(dev, prop_hart_index,
+						    hart_index, priv->nr_idcs);
+	}
+	if (rc < 0) {
+		dev_err(dev, "APLIC property \"%s\" error %pe\n", prop_hart_index, ERR_PTR(rc));
+		return rc;
+	}
 	/* Setup per-CPU IDC and target CPU mask */
 	current_cpu = get_cpu();
 	for (i = 0; i < priv->nr_idcs; i++) {
@@ -249,6 +268,8 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
 			continue;
 		}
 
+		if (i == 0)
+			hartid0 = hartid;
 		/*
 		 * Skip interrupts other than external interrupts for
 		 * current privilege level.
@@ -265,8 +286,8 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
 		cpumask_set_cpu(cpu, &direct->lmask);
 
 		idc = per_cpu_ptr(&aplic_idcs, cpu);
-		idc->hart_index = i;
-		idc->regs = priv->regs + APLIC_IDC_BASE + i * APLIC_IDC_SIZE;
+		idc->hart_index = hart_index ? hart_index[i] : hartid - hartid0;
+		idc->regs = priv->regs + APLIC_IDC_BASE + idc->hart_index * APLIC_IDC_SIZE;
 		idc->direct = direct;
 
 		aplic_idc_set_delivery(idc, true);
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/2] riscv,aplic: support for hart indexes

[Anup Patel]

On Thu, Jan 2, 2025 at 3:11 PM Vladimir Kondratiev
<vladimir.kondratiev@mobileye.com> wrote:
>
> Risc-v APLIC uses "hart index" to access data per destination hart.
> Current implementation assumes hart indexes are consecutive integers
> starting from 0, while Risc-V documentation says it may be
> arbitrary numbers, with a clue that it may be related to the hart IDs.
>
> In all boards I see in today's kernel, hart IDs are consecutive
> integers, thus using dart IDs is the same as indexes.
>
> However, for the MIPS P8700, hart IDs are different from indexes,
> on this SoC they encode thread number, core and cluster in bits
> [0..3], [4..15], [16..19] resulting Soc consisting of 3 clusters *
> 4 cores * 2 threads with hart IDs:
> 0x0, 0x1, 0x10, 0x11, 0x20, 0x21, 0x30, 0x31, 0x10000 etc.
>
> Change default hart index to be hart ID related to the start of domain,
> and add optional property to configure arbitrary indexes.

We don't need any APLIC DT binding change for supporting random
HART ID assignments. Please see below for a detailed explanation.

>
> Use of "device_property" API allows to cover both ACPI and OF in single
> code
>
> 1-st commit adds dt-bindings, 2-nd - code
>
> Vladimir Kondratiev (2):
>   dt-bindings: interrupt-controller: add risc-v,aplic hart indexes
>   irqchip/riscv-aplic: add support for hart indexes

The RISC-V APLIC driver does not assume any correlation between
APLIC "HART Index" and the actual HART ID of various HARTs.

Each APLIC domain has its own 14bit "HART Index" space and the
APLIC driver determines "HART Index" based on the APLIC mode
(Direct/MSI mode).

The APLIC domain in direct mode requires "HART Index" to be
between 0 to N - 1 where N is the number of HARTs targeted by
the APLIC domain because the APLIC IDC structures are placed
consecutively in the MMIO space and located based on "HART index".
(Refer, first paragraph of the section "4.8 Interrupt delivery directly
by the APLIC" of the ratified RISC-V AIA v1.0 specification)

On the other hand, there is no constraint on the "HART Index" space
for the APLIC domain in MSI mode because the "HART Index" bits
are part of the MSI target address generated by APLIC.
(Refer, section "4.9.1 Addresses and data for outgoing MSIs" of
the ratified RISC-V AIA v1.0 specification).

The RISC-V APLIC direct mode driver uses the "interrupts-extended"
DT property to determine how an APLIC domain connects to a
set of HARTs. Here's how this DT property is used:
1) The number of entries in the "interrupts-extended" DT property
tells the number of APLIC IDC structures where the first entry is for
"HART Index = 0", the second entry is for "HART Index = 1" and so on.
2) The first value (aka phandle) of each entry in the "interrupts-extended"
DT property points to the target HART INTC.
3) The second value of each entry in the "interrupts-extended" DT
property determines the target privilege level on the HART. For
example, 11 means "M-mode external interrupt" and 9 means
"S-mode external interrupt"

The RISC-V APLIC MSI mode driver extracts the "HART Index"
the target MSI address and the RISC-V IMSIC driver selects
the target HART for handling a particular APLIC MSI-mode
interrupt.

Clearly, the APLIC DT binding is flexible and does not depend
upon the HART IDs assigned to the HARTs.

The "Example1" of the riscv,aplic.yaml already shows three
different APLIC domains targeting different sets of HARTs and
privilege levels. In fact, the upstream QEMU virt machine already
supports creating up to 8 APLIC domains in direct mode where
each targets a different set of HARTs and privilege levels.

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/2] riscv,aplic: support for hart indexes

[Vladimir Kondratiev]

>The APLIC domain in direct mode requires "HART Index" to be
>between 0 to N - 1 where N is the number of HARTs targeted by
>the APLIC domain because the APLIC IDC structures are placed
>consecutively in the MMIO space and located based on "HART index".
>(Refer, first paragraph of the section "4.8 Interrupt delivery directly
>by the APLIC" of the ratified RISC-V AIA v1.0 specification)

Hi Anup,

Sorry, perhaps I am reading spec the wrong way. I don't see where
spec required this:

>"HART Index" to be
>between 0 to N - 1 where N is the number of HARTs targeted by
>the APLIC domain

I have a real hardware (MIPS P8700) where APLIC is in direct mode
and hart indexes are same as hart IDs, masking out cluster number.
These hart indexes as I mentioned, "0x00, 0x01, 0x10, 0x11" etc.
For delivering IRQ, for example,  to CPU2 I need to access its IDC
by hart index 0x10. Current code uses IDC at index 2 and hardware
don't work this way because there's no registers at this address.

If spec indeed requires hart indexes to be in range as you mentioned,
such hardware is not spec compliant. Is it the case?

In addition, as spec says, hart index may be different than its hart ID
and I don't see any provisioning in current code to supply this
hart index.

What am I missing?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/2] riscv,aplic: support for hart indexes

[Anup Patel]

On Thu, Jan 2, 2025 at 7:31 PM Vladimir Kondratiev
<Vladimir.Kondratiev@mobileye.com> wrote:
>
> >The APLIC domain in direct mode requires "HART Index" to be
> >between 0 to N - 1 where N is the number of HARTs targeted by
> >the APLIC domain because the APLIC IDC structures are placed
> >consecutively in the MMIO space and located based on "HART index".
> >(Refer, first paragraph of the section "4.8 Interrupt delivery directly
> >by the APLIC" of the ratified RISC-V AIA v1.0 specification)
>
> Hi Anup,
>
> Sorry, perhaps I am reading spec the wrong way. I don't see where
> spec required this:
>
> >"HART Index" to be
> >between 0 to N - 1 where N is the number of HARTs targeted by
> >the APLIC domain
>
> I have a real hardware (MIPS P8700) where APLIC is in direct mode
> and hart indexes are same as hart IDs, masking out cluster number.
> These hart indexes as I mentioned, "0x00, 0x01, 0x10, 0x11" etc.
> For delivering IRQ, for example,  to CPU2 I need to access its IDC
> by hart index 0x10. Current code uses IDC at index 2 and hardware
> don't work this way because there's no registers at this address.
>
> If spec indeed requires hart indexes to be in range as you mentioned,
> such hardware is not spec compliant. Is it the case?

Here's the text from "4.8 Interrupt delivery directly by the APLIC" of
the AIA specification:

"When an interrupt domain is in direct delivery mode (domaincfg.DM = 0),
interrupts are delivered from the APLIC to harts by a unique signal to each
hart, usually a dedicated wire. In this case, the domain’s memory-mapped
control region contains at the end an array of interrupt delivery control (IDC)
structures, one IDC structure per potential hart index. The first IDC structure
is for the domain’s hart with index 0; the second is for the hart with
index 1; etc."

The AIA spec clearly says that for APLIC in direct mode requires
sequential "HART index" starting from 0 so that IDC structures can
be located using the APLIC "HART index".

The non-contiguous APLIC "HART index" assignment in MIPS P8700
is clearly a violation of the AIA specification.

>
> In addition, as spec says, hart index may be different than its hart ID
> and I don't see any provisioning in current code to supply this
> hart index.

Yes, this is true for both APLIC direct-mode as well because each
APLIC domain in direct-mode will have its own "HART index" space
starting from 0.

>
> What am I missing?

To me it seems MIPS P8700 is only IP and not actual silicon ??
(https://mips.com/products/hardware/p8700/)

If so then it is better to fix the IP itself. If it is real silicon then I can
think of some work-around for the non-compliance.

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/2] riscv,aplic: support for hart indexes

[Vladimir Kondratiev]

>Here's the text from "4.8 Interrupt delivery directly by the APLIC" of
>the AIA specification:

>"When an interrupt domain is in direct delivery mode (domaincfg.DM = 0),
>interrupts are delivered from the APLIC to harts by a unique signal to each
>hart, usually a dedicated wire. In this case, the domain’s memory-mapped
>control region contains at the end an array of interrupt delivery control (IDC)
>structures, one IDC structure per potential hart index. The first IDC structure
>is for the domain’s hart with index 0; the second is for the hart with
>index 1; etc."

>The AIA spec clearly says that for APLIC in direct mode requires
>sequential "HART index" starting from 0 so that IDC structures can
>be located using the APLIC "HART index".

Hi Anup,
I am reading same text but interpreting it differently. I understand it this way:
for every hart, there's "hart index" that may be arbitrary (unique in domain)
14-bit  integer. Then IDC should be accessed using this index. I don't see
anything that prohibits sparse array of IDCs.

To support this, #4.5 "Memory-mapped control region for an interrupt domain" says:

The array of IDC structures may include some for potential hart index numbers that are not actual
hart index numbers in the domain. For example, the first IDC structure is always for hart index 0,
but 0 is not necessarily a valid index number for any hart in the domain. For each IDC structure in
the array that does not correspond to a valid hart index number in the domain, the IDC structure’s
registers may (or may not) be all read-only zeros.

This suggests 0 may be not a valid hart index, so clearly some gaps are allowed.

Thanks, Vladimir.



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 0/2] riscv,aplic: support for hart indexes

[Anup Patel]

On Thu, Jan 2, 2025 at 8:37 PM Vladimir Kondratiev
<Vladimir.Kondratiev@mobileye.com> wrote:
>
> >Here's the text from "4.8 Interrupt delivery directly by the APLIC" of
> >the AIA specification:
>
> >"When an interrupt domain is in direct delivery mode (domaincfg.DM = 0),
> >interrupts are delivered from the APLIC to harts by a unique signal to each
> >hart, usually a dedicated wire. In this case, the domain’s memory-mapped
> >control region contains at the end an array of interrupt delivery control (IDC)
> >structures, one IDC structure per potential hart index. The first IDC structure
> >is for the domain’s hart with index 0; the second is for the hart with
> >index 1; etc."
>
> >The AIA spec clearly says that for APLIC in direct mode requires
> >sequential "HART index" starting from 0 so that IDC structures can
> >be located using the APLIC "HART index".
>
> Hi Anup,
> I am reading same text but interpreting it differently. I understand it this way:
> for every hart, there's "hart index" that may be arbitrary (unique in domain)
> 14-bit  integer. Then IDC should be accessed using this index. I don't see
> anything that prohibits sparse array of IDCs.
>
> To support this, #4.5 "Memory-mapped control region for an interrupt domain" says:
>
> The array of IDC structures may include some for potential hart index numbers that are not actual
> hart index numbers in the domain. For example, the first IDC structure is always for hart index 0,
> but 0 is not necessarily a valid index number for any hart in the domain. For each IDC structure in
> the array that does not correspond to a valid hart index number in the domain, the IDC structure’s
> registers may (or may not) be all read-only zeros.
>
> This suggests 0 may be not a valid hart index, so clearly some gaps are allowed.

I see your point and this is a fair interpretation.
I will review other patches.

Thanks,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Anup Patel]

On Thu, Jan 2, 2025 at 3:11 PM Vladimir Kondratiev
<vladimir.kondratiev@mobileye.com> wrote:
>
> Document optional property "riscv,hart-index"
>
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
> ---
>  .../bindings/interrupt-controller/riscv,aplic.yaml        | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
> index 190a6499c932..e163c8de3524 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
> @@ -91,6 +91,14 @@ properties:
>        Firmware must configure interrupt delegation registers based on
>        interrupt delegation list.
>
> +  riscv,hart-index:

I suggest naming this property "riscv,hart-indexes" (pural)

> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1
> +    maxItems: 16384
> +    description:
> +      A list of hart indexes that APLIC should use to address each hart
> +      that is mentioned in the "interrupts-extended"
> +
>  dependencies:
>    riscv,delegation: [ "riscv,children" ]
>
> --
> 2.43.0
>

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/2] irqchip/riscv-aplic: add support for hart indexes

[Anup Patel]

On Thu, Jan 2, 2025 at 3:11 PM Vladimir Kondratiev
<vladimir.kondratiev@mobileye.com> wrote:
>
> Risc-V APLIC specification defines "hart index" in [1]:
>
> Within a given interrupt domain, each of the domain’s harts has a
> unique index number in the range 0 to 214 − 1 (= 16,383). The index
> number a domain associates with a hart may or may not have any
> relationship to the unique hart identifier (“hart ID”) that the
> RISC-V Privileged Architecture assigns to the hart. Two different
> interrupt domains may employ entirely different index numbers for
> the same set of harts.

Rather than this, better cite the text in "4.5 Memory-mapped control
region for an interrupt domain".

>
> Support arbitrary hart indexes specified in optional APLIC property
> "riscv,hart-index" that should be array of u32 elements, one per
> interrupt target. If this property not specified, fallback is to use
> hart ids, with hart index for each APLIC to be (hartid - hartid0)
> where hartid0 is hart id for the 1-st target.

This is an incorrect assumption in the default cause. The HART IDs
of the HARTs targeted by an APLIC domain can be non-contiguous.

>
> [1]: https://github.com/riscv/riscv-aia
>
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
> ---
>  drivers/irqchip/irq-riscv-aplic-direct.c | 25 ++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c b/drivers/irqchip/irq-riscv-aplic-direct.c
> index 7cd6b646774b..80c82e34e894 100644
> --- a/drivers/irqchip/irq-riscv-aplic-direct.c
> +++ b/drivers/irqchip/irq-riscv-aplic-direct.c
> @@ -221,12 +221,15 @@ static int aplic_direct_parse_parent_hwirq(struct device *dev, u32 index,
>
>  int aplic_direct_setup(struct device *dev, void __iomem *regs)
>  {
> +       static const char *prop_hart_index = "riscv,hart-index";
>         int i, j, rc, cpu, current_cpu, setup_count = 0;
>         struct aplic_direct *direct;
>         struct irq_domain *domain;
>         struct aplic_priv *priv;
>         struct aplic_idc *idc;
>         unsigned long hartid;
> +       unsigned long hartid0;
> +       u32 *hart_index = NULL;
>         u32 v, hwirq;
>
>         direct = devm_kzalloc(dev, sizeof(*direct), GFP_KERNEL);
> @@ -240,6 +243,22 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
>                 return rc;
>         }
>
> +       rc = device_property_count_u32(dev, prop_hart_index);
> +       if (rc == -ENODATA)
> +               rc = 0;
> +       if (rc > 0 && rc != priv->nr_idcs)
> +               rc = -EOVERFLOW;
> +       if (rc > 0) {
> +               hart_index = devm_kcalloc(dev, priv->nr_idcs, sizeof(*hart_index), GFP_KERNEL);
> +               if (!hart_index)
> +                       return -ENOMEM;
> +               rc = device_property_read_u32_array(dev, prop_hart_index,
> +                                                   hart_index, priv->nr_idcs);
> +       }
> +       if (rc < 0) {
> +               dev_err(dev, "APLIC property \"%s\" error %pe\n", prop_hart_index, ERR_PTR(rc));
> +               return rc;
> +       }

No need for this additional array allocation and reading.

>         /* Setup per-CPU IDC and target CPU mask */
>         current_cpu = get_cpu();
>         for (i = 0; i < priv->nr_idcs; i++) {
> @@ -249,6 +268,8 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
>                         continue;
>                 }
>
> +               if (i == 0)
> +                       hartid0 = hartid;
>                 /*
>                  * Skip interrupts other than external interrupts for
>                  * current privilege level.
> @@ -265,8 +286,8 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
>                 cpumask_set_cpu(cpu, &direct->lmask);
>
>                 idc = per_cpu_ptr(&aplic_idcs, cpu);
> -               idc->hart_index = i;
> -               idc->regs = priv->regs + APLIC_IDC_BASE + i * APLIC_IDC_SIZE;
> +               idc->hart_index = hart_index ? hart_index[i] : hartid - hartid0;
> +               idc->regs = priv->regs + APLIC_IDC_BASE + idc->hart_index * APLIC_IDC_SIZE;
>                 idc->direct = direct;
>
>                 aplic_idc_set_delivery(idc, true);
> --
> 2.43.0
>

How about this ?

diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c
b/drivers/irqchip/irq-riscv-aplic-direct.c
index 7cd6b646774b..bac88b7790ec 100644
--- a/drivers/irqchip/irq-riscv-aplic-direct.c
+++ b/drivers/irqchip/irq-riscv-aplic-direct.c
@@ -31,7 +31,7 @@ struct aplic_direct {
 };

 struct aplic_idc {
-    unsigned int        hart_index;
+    u32            hart_index;
     void __iomem        *regs;
     struct aplic_direct    *direct;
 };
@@ -219,6 +219,19 @@ static int aplic_direct_parse_parent_hwirq(struct
device *dev, u32 index,
     return 0;
 }

+static int aplic_direct_get_hart_index(struct device *dev, u32 logical_index,
+                    u32 *hart_index)
+{
+    if (!is_of_node(dev->fwnode) ||
+        !of_property_present(to_of_node(dev->fwnode), "riscv,hart-indexes")) {
+        *hart_index = logical_index;
+        return 0;
+    }
+
+    return of_property_read_u32_index(to_of_node(dev->fwnode),
"riscv,hart-indexes",
+                      logical_index, hart_index);
+}
+
 int aplic_direct_setup(struct device *dev, void __iomem *regs)
 {
     int i, j, rc, cpu, current_cpu, setup_count = 0;
@@ -265,8 +278,13 @@ int aplic_direct_setup(struct device *dev, void
__iomem *regs)
         cpumask_set_cpu(cpu, &direct->lmask);

         idc = per_cpu_ptr(&aplic_idcs, cpu);
-        idc->hart_index = i;
-        idc->regs = priv->regs + APLIC_IDC_BASE + i * APLIC_IDC_SIZE;
+        rc = aplic_direct_get_hart_index(dev, i, &idc->hart_index);
+        if (rc) {
+            dev_warn(dev, "hart index not found for IDC%d\n", i);
+            continue;
+        }
+
+        idc->regs = priv->regs + APLIC_IDC_BASE + idc->hart_index *
APLIC_IDC_SIZE;
         idc->direct = direct;

         aplic_idc_set_delivery(idc, true);

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Krzysztof Kozlowski]

On 02/01/2025 10:41, Vladimir Kondratiev wrote:
> Document optional property "riscv,hart-index"
> 
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.

Please kindly resend and include all necessary To/Cc entries.
</form letter>

Best regards,
Krzysztof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/2] irqchip/riscv-aplic: add support for hart indexes

[Vladimir Kondratiev]

>> Risc-V APLIC specification defines "hart index" in [1]:
>>
>> Within a given interrupt domain, each of the domain’s harts has a
>> unique index number in the range 0 to 214 − 1 (= 16,383). The index
>> number a domain associates with a hart may or may not have any
>> relationship to the unique hart identifier (“hart ID”) that the
>> RISC-V Privileged Architecture assigns to the hart. Two different
>> interrupt domains may employ entirely different index numbers for
>> the same set of harts.

>Rather than this, better cite the text in "4.5 Memory-mapped control
>region for an interrupt domain".

Adding quote from 4.5 to the commit message

>> Support arbitrary hart indexes specified in optional APLIC property
>> "riscv,hart-index" that should be array of u32 elements, one per
>> interrupt target. If this property not specified, fallback is to use
>> hart ids, with hart index for each APLIC to be (hartid - hartid0)
>> where hartid0 is hart id for the 1-st target.

>This is an incorrect assumption in the default cause. The HART IDs
>of the HARTs targeted by an APLIC domain can be non-contiguous.

Fixing this to say "fallback to logical indexes"

>How about this ?

Taking your approach. Applying idea from
ef7080bd30ba ("irqchip/riscv-aplic: Simplify the initialization code")

Will shortly re-submit as "V2"
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v2] irqchip/riscv-aplic: add support for hart indexes

[Vladimir Kondratiev]

Risc-V APLIC specification defines "hart index" in [1]:

Within a given interrupt domain, each of the domain’s harts has a
unique index number in the range 0 to 2^14 − 1 (= 16,383). The index
number a domain associates with a hart may or may not have any
relationship to the unique hart identifier (“hart ID”) that the
RISC-V Privileged Architecture assigns to the hart. Two different
interrupt domains may employ entirely different index numbers for
the same set of harts.

Further, this document says in "4.5 Memory-mapped control
region for an interrupt domain":

The array of IDC structures may include some for potential hart index
numbers that are not actual hart index numbers in the domain. For
example, the first IDC structure is always for hart index 0, but 0 is
not necessarily a valid index number for any hart in the domain.

Support arbitrary hart indexes specified in optional APLIC property
"riscv,hart-index" that should be array of u32 elements, one per
interrupt target. If this property not specified, fallback is to use
logical hart indexes within the domain.

[1]: https://github.com/riscv/riscv-aia

Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
---
 drivers/irqchip/irq-riscv-aplic-direct.c | 25 +++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c b/drivers/irqchip/irq-riscv-aplic-direct.c
index 7cd6b646774b..c80a65c1732a 100644
--- a/drivers/irqchip/irq-riscv-aplic-direct.c
+++ b/drivers/irqchip/irq-riscv-aplic-direct.c
@@ -31,7 +31,7 @@ struct aplic_direct {
 };
 
 struct aplic_idc {
-	unsigned int		hart_index;
+	u32			hart_index;
 	void __iomem		*regs;
 	struct aplic_direct	*direct;
 };
@@ -219,6 +219,21 @@ static int aplic_direct_parse_parent_hwirq(struct device *dev, u32 index,
 	return 0;
 }
 
+static int aplic_direct_get_hart_index(struct device *dev, u32 logical_index,
+				       u32 *hart_index)
+{
+	static const char *prop_hart_index = "riscv,hart-index";
+	struct device_node *np = to_of_node(dev->fwnode);
+
+	if (!np || !of_property_present(np, prop_hart_index)) {
+		*hart_index = logical_index;
+		return 0;
+	}
+
+	return of_property_read_u32_index(np, prop_hart_index,
+					  logical_index, hart_index);
+}
+
 int aplic_direct_setup(struct device *dev, void __iomem *regs)
 {
 	int i, j, rc, cpu, current_cpu, setup_count = 0;
@@ -265,8 +280,12 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
 		cpumask_set_cpu(cpu, &direct->lmask);
 
 		idc = per_cpu_ptr(&aplic_idcs, cpu);
-		idc->hart_index = i;
-		idc->regs = priv->regs + APLIC_IDC_BASE + i * APLIC_IDC_SIZE;
+		rc = aplic_direct_get_hart_index(dev, i, &idc->hart_index);
+		if (rc) {
+			dev_warn(dev, "hart index not found for IDC%d\n", i);
+			continue;
+		}
+		idc->regs = priv->regs + APLIC_IDC_BASE + idc->hart_index * APLIC_IDC_SIZE;
 		idc->direct = direct;
 
 		aplic_idc_set_delivery(idc, true);
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v2] irqchip/riscv-aplic: add support for hart indexes

[Anup Patel]

On Sun, Jan 5, 2025 at 2:09 PM Vladimir Kondratiev
<vladimir.kondratiev@mobileye.com> wrote:
>
> Risc-V APLIC specification defines "hart index" in [1]:
>
> Within a given interrupt domain, each of the domain’s harts has a
> unique index number in the range 0 to 2^14 − 1 (= 16,383). The index
> number a domain associates with a hart may or may not have any
> relationship to the unique hart identifier (“hart ID”) that the
> RISC-V Privileged Architecture assigns to the hart. Two different
> interrupt domains may employ entirely different index numbers for
> the same set of harts.
>
> Further, this document says in "4.5 Memory-mapped control
> region for an interrupt domain":
>
> The array of IDC structures may include some for potential hart index
> numbers that are not actual hart index numbers in the domain. For
> example, the first IDC structure is always for hart index 0, but 0 is
> not necessarily a valid index number for any hart in the domain.
>
> Support arbitrary hart indexes specified in optional APLIC property
> "riscv,hart-index" that should be array of u32 elements, one per

I had commented on v1 that it's better to rename this property to
"riscv,hart-indexes" (plural).

> interrupt target. If this property not specified, fallback is to use
> logical hart indexes within the domain.
>
> [1]: https://github.com/riscv/riscv-aia
>
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

Otherwise, this looks good to me.

Reviewed-by: Anup Patel <anup@brainfault.org>

> ---
>  drivers/irqchip/irq-riscv-aplic-direct.c | 25 +++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c b/drivers/irqchip/irq-riscv-aplic-direct.c
> index 7cd6b646774b..c80a65c1732a 100644
> --- a/drivers/irqchip/irq-riscv-aplic-direct.c
> +++ b/drivers/irqchip/irq-riscv-aplic-direct.c
> @@ -31,7 +31,7 @@ struct aplic_direct {
>  };
>
>  struct aplic_idc {
> -       unsigned int            hart_index;
> +       u32                     hart_index;
>         void __iomem            *regs;
>         struct aplic_direct     *direct;
>  };
> @@ -219,6 +219,21 @@ static int aplic_direct_parse_parent_hwirq(struct device *dev, u32 index,
>         return 0;
>  }
>
> +static int aplic_direct_get_hart_index(struct device *dev, u32 logical_index,
> +                                      u32 *hart_index)
> +{
> +       static const char *prop_hart_index = "riscv,hart-index";
> +       struct device_node *np = to_of_node(dev->fwnode);
> +
> +       if (!np || !of_property_present(np, prop_hart_index)) {
> +               *hart_index = logical_index;
> +               return 0;
> +       }
> +
> +       return of_property_read_u32_index(np, prop_hart_index,
> +                                         logical_index, hart_index);
> +}
> +
>  int aplic_direct_setup(struct device *dev, void __iomem *regs)
>  {
>         int i, j, rc, cpu, current_cpu, setup_count = 0;
> @@ -265,8 +280,12 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
>                 cpumask_set_cpu(cpu, &direct->lmask);
>
>                 idc = per_cpu_ptr(&aplic_idcs, cpu);
> -               idc->hart_index = i;
> -               idc->regs = priv->regs + APLIC_IDC_BASE + i * APLIC_IDC_SIZE;
> +               rc = aplic_direct_get_hart_index(dev, i, &idc->hart_index);
> +               if (rc) {
> +                       dev_warn(dev, "hart index not found for IDC%d\n", i);
> +                       continue;
> +               }
> +               idc->regs = priv->regs + APLIC_IDC_BASE + idc->hart_index * APLIC_IDC_SIZE;
>                 idc->direct = direct;
>
>                 aplic_idc_set_delivery(idc, true);
> --
> 2.43.0
>

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 0/2] riscv,aplic: support for hart indexes

[Vladimir Kondratiev]

Risc-v APLIC uses "hart index" to access data per destination hart.
Current implementation assumes hart indexes are consecutive integers
starting from 0, while Risc-V documentation says it may be
arbitrary numbers, with a clue that it may be related to the hart IDs.

In all boards I see in today's kernel, hart IDs are consecutive
integers, thus using dart IDs is the same as indexes.

However, for the MIPS P8700, hart IDs are different from indexes,
on this SoC they encode thread number, core and cluster in bits
[0..3], [4..15], [16..19] resulting Soc consisting of 3 clusters *
4 cores * 2 threads with hart IDs:
0x0, 0x1, 0x10, 0x11, 0x20, 0x21, 0x30, 0x31, 0x10000 etc.

Change default hart index to be hart ID related to the start of domain,
and add optional property to configure arbitrary indexes.

Use of "device_property" API allows to cover both ACPI and OF in single
code

1-st commit adds dt-bindings, 2-nd - code

Changed from v1:
1. use as fallback logical indexes instead of hart ids
2. refactor code to avoid unnecessary memory allocation

Changed from v2:
1. change property name to plural "riscv,hart-indexes"

Vladimir Kondratiev (2):
  dt-bindings: interrupt-controller: add risc-v,aplic hart indexes
  irqchip/riscv-aplic: add support for hart indexes

 .../interrupt-controller/riscv,aplic.yaml     |  8 ++++++
 drivers/irqchip/irq-riscv-aplic-direct.c      | 25 ++++++++++++++++---
 2 files changed, 30 insertions(+), 3 deletions(-)


base-commit: 9d89551994a430b50c4fffcb1e617a057fa76e20
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Vladimir Kondratiev]

Document optional property "riscv,hart-indexes"

Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
---
 .../bindings/interrupt-controller/riscv,aplic.yaml        | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
index 190a6499c932..bef00521d5da 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
@@ -91,6 +91,14 @@ properties:
       Firmware must configure interrupt delegation registers based on
       interrupt delegation list.
 
+  riscv,hart-indexes:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 16384
+    description:
+      A list of hart indexes that APLIC should use to address each hart
+      that is mentioned in the "interrupts-extended"
+
 dependencies:
   riscv,delegation: [ "riscv,children" ]
 
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v3 2/2] irqchip/riscv-aplic: add support for hart indexes

[Vladimir Kondratiev]

Risc-V APLIC specification defines "hart index" in [1]:

Within a given interrupt domain, each of the domain’s harts has a
unique index number in the range 0 to 2^14 − 1 (= 16,383). The index
number a domain associates with a hart may or may not have any
relationship to the unique hart identifier (“hart ID”) that the
RISC-V Privileged Architecture assigns to the hart. Two different
interrupt domains may employ entirely different index numbers for
the same set of harts.

Further, this document says in "4.5 Memory-mapped control
region for an interrupt domain":

The array of IDC structures may include some for potential hart index
numbers that are not actual hart index numbers in the domain. For
example, the first IDC structure is always for hart index 0, but 0 is
not necessarily a valid index number for any hart in the domain.

Support arbitrary hart indexes specified in optional APLIC property
"riscv,hart-indexes" that should be array of u32 elements, one per
interrupt target. If this property not specified, fallback is to use
logical hart indexes within the domain.

[1]: https://github.com/riscv/riscv-aia

Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
---
 drivers/irqchip/irq-riscv-aplic-direct.c | 25 +++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c b/drivers/irqchip/irq-riscv-aplic-direct.c
index 7cd6b646774b..ea61329decb2 100644
--- a/drivers/irqchip/irq-riscv-aplic-direct.c
+++ b/drivers/irqchip/irq-riscv-aplic-direct.c
@@ -31,7 +31,7 @@ struct aplic_direct {
 };
 
 struct aplic_idc {
-	unsigned int		hart_index;
+	u32			hart_index;
 	void __iomem		*regs;
 	struct aplic_direct	*direct;
 };
@@ -219,6 +219,21 @@ static int aplic_direct_parse_parent_hwirq(struct device *dev, u32 index,
 	return 0;
 }
 
+static int aplic_direct_get_hart_index(struct device *dev, u32 logical_index,
+				       u32 *hart_index)
+{
+	static const char *prop_hart_index = "riscv,hart-indexes";
+	struct device_node *np = to_of_node(dev->fwnode);
+
+	if (!np || !of_property_present(np, prop_hart_index)) {
+		*hart_index = logical_index;
+		return 0;
+	}
+
+	return of_property_read_u32_index(np, prop_hart_index,
+					  logical_index, hart_index);
+}
+
 int aplic_direct_setup(struct device *dev, void __iomem *regs)
 {
 	int i, j, rc, cpu, current_cpu, setup_count = 0;
@@ -265,8 +280,12 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
 		cpumask_set_cpu(cpu, &direct->lmask);
 
 		idc = per_cpu_ptr(&aplic_idcs, cpu);
-		idc->hart_index = i;
-		idc->regs = priv->regs + APLIC_IDC_BASE + i * APLIC_IDC_SIZE;
+		rc = aplic_direct_get_hart_index(dev, i, &idc->hart_index);
+		if (rc) {
+			dev_warn(dev, "hart index not found for IDC%d\n", i);
+			continue;
+		}
+		idc->regs = priv->regs + APLIC_IDC_BASE + idc->hart_index * APLIC_IDC_SIZE;
 		idc->direct = direct;
 
 		aplic_idc_set_delivery(idc, true);
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Vladimir Kondratiev]

>Please use scripts/get_maintainers.pl to get a list of necessary people
>and lists to CC. It might happen, that command when run on an older
>kernel, gives you outdated entries. Therefore please be sure you base
>your patches on recent Linux kernel.

>Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>people, so fix your workflow. Tools might also fail if you work on some
>ancient tree (don't, instead use mainline) or work on fork of kernel
>(don't, instead use mainline). Just use b4 and everything should be
>fine, although remember about `b4 prep --auto-to-cc` if you added new
>patches to the patchset.

>You missed at least devicetree list (maybe more), so this won't be
>tested by automated tooling. Performing review on untested code might be
>a waste of time.

>Please kindly resend and include all necessary To/Cc entries.
></form letter>

>Best regards,
>Krzysztof

Hi Krzysztof.
you're right, I missed devicetree@vger.kernel.org.
I do run scripts/get_maintainer.pl but indeed I missed this line.
I'll re-send adding it.
Question: can I re-send same "patch v3" or shall I increment
the version to "patch v4"?

Thanks, Vladimir


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Anup Patel]

On Tue, Jan 7, 2025 at 1:29 PM Vladimir Kondratiev
<vladimir.kondratiev@mobileye.com> wrote:
>
> Document optional property "riscv,hart-indexes"
>
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

LGTM.

Reviewed-by: Anup Patel <anup@brainfault.org>

Regards,
Anup

> ---
>  .../bindings/interrupt-controller/riscv,aplic.yaml        | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
> index 190a6499c932..bef00521d5da 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
> @@ -91,6 +91,14 @@ properties:
>        Firmware must configure interrupt delegation registers based on
>        interrupt delegation list.
>
> +  riscv,hart-indexes:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1
> +    maxItems: 16384
> +    description:
> +      A list of hart indexes that APLIC should use to address each hart
> +      that is mentioned in the "interrupts-extended"
> +
>  dependencies:
>    riscv,delegation: [ "riscv,children" ]
>
> --
> 2.43.0
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 2/2] irqchip/riscv-aplic: add support for hart indexes

[Anup Patel]

On Tue, Jan 7, 2025 at 1:29 PM Vladimir Kondratiev
<vladimir.kondratiev@mobileye.com> wrote:
>
> Risc-V APLIC specification defines "hart index" in [1]:
>
> Within a given interrupt domain, each of the domain’s harts has a
> unique index number in the range 0 to 2^14 − 1 (= 16,383). The index
> number a domain associates with a hart may or may not have any
> relationship to the unique hart identifier (“hart ID”) that the
> RISC-V Privileged Architecture assigns to the hart. Two different
> interrupt domains may employ entirely different index numbers for
> the same set of harts.
>
> Further, this document says in "4.5 Memory-mapped control
> region for an interrupt domain":
>
> The array of IDC structures may include some for potential hart index
> numbers that are not actual hart index numbers in the domain. For
> example, the first IDC structure is always for hart index 0, but 0 is
> not necessarily a valid index number for any hart in the domain.
>
> Support arbitrary hart indexes specified in optional APLIC property
> "riscv,hart-indexes" that should be array of u32 elements, one per
> interrupt target. If this property not specified, fallback is to use
> logical hart indexes within the domain.
>
> [1]: https://github.com/riscv/riscv-aia
>
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>

Please include the Reviewed-by tags obtained on previous patch revisions.

In any case, this still looks to me.

Reviewed-by: Anup Patel <anup@brainfault.org>

Regards,
Anup

> ---
>  drivers/irqchip/irq-riscv-aplic-direct.c | 25 +++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-riscv-aplic-direct.c b/drivers/irqchip/irq-riscv-aplic-direct.c
> index 7cd6b646774b..ea61329decb2 100644
> --- a/drivers/irqchip/irq-riscv-aplic-direct.c
> +++ b/drivers/irqchip/irq-riscv-aplic-direct.c
> @@ -31,7 +31,7 @@ struct aplic_direct {
>  };
>
>  struct aplic_idc {
> -       unsigned int            hart_index;
> +       u32                     hart_index;
>         void __iomem            *regs;
>         struct aplic_direct     *direct;
>  };
> @@ -219,6 +219,21 @@ static int aplic_direct_parse_parent_hwirq(struct device *dev, u32 index,
>         return 0;
>  }
>
> +static int aplic_direct_get_hart_index(struct device *dev, u32 logical_index,
> +                                      u32 *hart_index)
> +{
> +       static const char *prop_hart_index = "riscv,hart-indexes";
> +       struct device_node *np = to_of_node(dev->fwnode);
> +
> +       if (!np || !of_property_present(np, prop_hart_index)) {
> +               *hart_index = logical_index;
> +               return 0;
> +       }
> +
> +       return of_property_read_u32_index(np, prop_hart_index,
> +                                         logical_index, hart_index);
> +}
> +
>  int aplic_direct_setup(struct device *dev, void __iomem *regs)
>  {
>         int i, j, rc, cpu, current_cpu, setup_count = 0;
> @@ -265,8 +280,12 @@ int aplic_direct_setup(struct device *dev, void __iomem *regs)
>                 cpumask_set_cpu(cpu, &direct->lmask);
>
>                 idc = per_cpu_ptr(&aplic_idcs, cpu);
> -               idc->hart_index = i;
> -               idc->regs = priv->regs + APLIC_IDC_BASE + i * APLIC_IDC_SIZE;
> +               rc = aplic_direct_get_hart_index(dev, i, &idc->hart_index);
> +               if (rc) {
> +                       dev_warn(dev, "hart index not found for IDC%d\n", i);
> +                       continue;
> +               }
> +               idc->regs = priv->regs + APLIC_IDC_BASE + idc->hart_index * APLIC_IDC_SIZE;
>                 idc->direct = direct;
>
>                 aplic_idc_set_delivery(idc, true);
> --
> 2.43.0
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Krzysztof Kozlowski]

On 07/01/2025 08:58, Vladimir Kondratiev wrote:
> Document optional property "riscv,hart-indexes"
> 
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
> ---
So you are going to keep ignoring comments?

NAK, not tested.

Also:
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets.

Best regards,
Krzysztof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Vladimir Kondratiev]

On 07/01/2025 08:58, Vladimir Kondratiev wrote:
>> Document optional property "riscv,hart-indexes"
>>
>> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
>> ---
>So you are going to keep ignoring comments?

Not intentionally, sorry for this. I saw your mail too late, after I already posted
"v3". So I asked you how to better handle this. Perhaps this lost somewhere in
the mail thread. I'll repeat - what is the best way, re-submit patch set
as "v4" adding missed address, or re-send "v3"?

Thanks, Vladimir

>NAK, not tested.

>Also:
>Do not attach (thread) your patchsets to some other threads (unrelated
>or older versions). This buries them deep in the mailbox and might
>interfere with applying entire sets.

>Best regards,
>Krzysztof
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: add risc-v,aplic hart indexes

[Krzysztof Kozlowski]

On 09/01/2025 10:13, Vladimir Kondratiev wrote:
> 
> On 07/01/2025 08:58, Vladimir Kondratiev wrote:
>>> Document optional property "riscv,hart-indexes"
>>>
>>> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>
>>> ---
>> So you are going to keep ignoring comments?
> 
> Not intentionally, sorry for this. I saw your mail too late, after I already posted

How?

You sent first version on 2nd of Jan. You got my reply after 6 hours, so
still 2nd of Jan. You even replied to it on 7th of Jan.

This was sent on 9th Jan.

How could you reply to my message before "seeing my mail"?

> "v3". So I asked you how to better handle this. Perhaps this lost somewhere in
> the mail thread. I'll repeat - what is the best way, re-submit patch set
> as "v4" adding missed address, or re-send "v3"?

Whatever submitting patches is proposing for your specific case. Resend
is for patches without any changes.

Best regards,
Krzysztof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv