Linux RISC-V AIA Support
Subsystems (6)
v6 cover Linux RISC-V AIA Support
The RISC-V AIA specification is now frozen as-per the RISC-V international process. The latest frozen specifcation can be found at:
https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf
At a high-level, the AIA specification adds three things:
1) AIA CSRs
- Improved local interrupt support
2) Incoming Message Signaled Interrupt Controller (IMSIC)
- Per-HART MSI controller
- Support MSI virtualization
- Support IPI along with virtualization
3) Advanced Platform-Level Interrupt Controller (APLIC)
- Wired interrupt controller
- In MSI-mode, converts wired interrupt into MSIs (i.e. MSI generator)
- In Direct-mode, injects external interrupts directly into HARTs
For an overview of the AIA specification, refer the AIA virtualization talk at KVM Forum 2022:
https://static.sched.com/hosted_files/kvmforum2022/a1/AIA_Virtualization_in_KVM_RISCV_final.pdf
https://www.youtube.com/watch?v=r071dL8Z0yo
To test this series, use QEMU v7.2 (or higher) and OpenSBI v1.2 (or higher).
These patches can also be found in the riscv_aia_v6 branch at:
https://github.com/avpatel/linux.git
Changes since v5:
- Rebased on Linux-6.5-rc2
- Updated the overall series to ensure that only IPI, timer, and INTC drivers are probed very early whereas rest of the interrupt controllers (such as PLIC, APLIC, and IMISC) are probed as regular platform drivers.
- Renamed riscv_fw_parent_hartid() to riscv_get_intc_hartid()
- New PATCH1 to add fw_devlink support for msi-parent DT property
- New PATCH2 to ensure all INTC suppliers are initialized which in-turn fixes the probing issue for PLIC, APLIC and IMSIC as platform driver
- New PATCH3 to use platform driver probing for PLIC
- Re-structured the IMSIC driver into two separate drivers: early and platform. The IMSIC early driver (PATCH7) only initialized IMSIC state and provides IPIs whereas the IMSIC platform driver (PATCH8) is probed provides MSI domain for platform devices.
- Re-structure the APLIC platform driver into three separe sources: main, direct mode, and MSI mode.
Changes since v4:
- Rebased on Linux-6.5-rc1
- Added "Dependencies" in the APLIC bindings (PATCH6 in v4)
- Dropped the PATCH6 which was changing the IOMMU DMA domain APIs
- Dropped use of IOMMU DMA APIs in the IMSIC driver (PATCH4)
Changes since v3:
- Rebased on Linux-6.4-rc6
- Droped PATCH2 of v3 series instead we now set FWNODE_FLAG_BEST_EFFORT via IRQCHIP_DECLARE()
- Extend riscv_fw_parent_hartid() to support both DT and ACPI in PATCH1
- Extend iommu_dma_compose_msi_msg() instead of adding iommu_dma_select_msi() in PATCH6
- Addressed Conor's comments in PATCH3
- Addressed Conor's and Rob's comments in PATCH7
Changes since v2:
- Rebased on Linux-6.4-rc1
- Addressed Rob's comments on DT bindings patches 4 and 8.
- Addessed Marc's comments on IMSIC driver PATCH5
- Replaced use of OF apis in APLIC and IMSIC drivers with FWNODE apis this makes both drivers easily portable for ACPI support. This also removes unnecessary indirection from the APLIC and IMSIC drivers.
- PATCH1 is a new patch for portability with ACPI support
- PATCH2 is a new patch to fix probing in APLIC drivers for APLIC-only systems.
- PATCH7 is a new patch which addresses the IOMMU DMA domain issues pointed out by SiFive
Changes since v1:
- Rebased on Linux-6.2-rc2
- Addressed comments on IMSIC DT bindings for PATCH4
- Use raw_spin_lock_irqsave() on ids_lock for PATCH5
- Improved MMIO alignment checks in PATCH5 to allow MMIO regions with holes.
- Addressed comments on APLIC DT bindings for PATCH6
- Fixed warning splat in aplic_msi_write_msg() caused by zeroed MSI message in PATCH7
- Dropped DT property riscv,slow-ipi instead will have module parameter in future.
Anup Patel (14):
RISC-V: Add riscv_get_intc_hartid() function
of: property: Add fw_devlink support for msi-parent
drivers: irqchip/riscv-intc: Mark all INTC nodes as initialized irqchip/sifive-plic: Use platform driver probing for PLIC irqchip/riscv-intc: Add support for RISC-V AIA
dt-bindings: interrupt-controller: Add RISC-V incoming MSI controller
irqchip: Add RISC-V incoming MSI controller early driver irqchip/riscv-imsic: Add support for platform MSI irqdomain irqchip/riscv-imsic: Add support for PCI MSI irqdomain
dt-bindings: interrupt-controller: Add RISC-V advanced PLIC
irqchip: Add RISC-V advanced PLIC driver for direct-mode irqchip/riscv-aplic: Add support for MSI-mode
RISC-V: Select APLIC and IMSIC drivers
MAINTAINERS: Add entry for RISC-V AIA drivers
.../interrupt-controller/riscv,aplic.yaml | 172 ++++++ .../interrupt-controller/riscv,imsics.yaml | 172 ++++++ MAINTAINERS | 14 + arch/riscv/Kconfig | 2 + arch/riscv/include/asm/processor.h | 4 +- arch/riscv/kernel/cpu.c | 19 +- drivers/irqchip/Kconfig | 25 +- drivers/irqchip/Makefile | 3 + drivers/irqchip/irq-riscv-aplic-direct.c | 326 +++++++++++ drivers/irqchip/irq-riscv-aplic-main.c | 240 ++++++++ drivers/irqchip/irq-riscv-aplic-main.h | 53 ++ drivers/irqchip/irq-riscv-aplic-msi.c | 285 ++++++++++ drivers/irqchip/irq-riscv-imsic-early.c | 258 +++++++++ drivers/irqchip/irq-riscv-imsic-platform.c | 328 +++++++++++ drivers/irqchip/irq-riscv-imsic-state.c | 523 ++++++++++++++++++ drivers/irqchip/irq-riscv-imsic-state.h | 67 +++ drivers/irqchip/irq-riscv-intc.c | 46 +- drivers/irqchip/irq-sifive-plic.c | 15 +- drivers/of/property.c | 32 ++ include/linux/irqchip/riscv-aplic.h | 119 ++++ include/linux/irqchip/riscv-imsic.h | 86 +++ 21 files changed, 2773 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml create mode 100644 drivers/irqchip/irq-riscv-aplic-direct.c create mode 100644 drivers/irqchip/irq-riscv-aplic-main.c create mode 100644 drivers/irqchip/irq-riscv-aplic-main.h create mode 100644 drivers/irqchip/irq-riscv-aplic-msi.c create mode 100644 drivers/irqchip/irq-riscv-imsic-early.c create mode 100644 drivers/irqchip/irq-riscv-imsic-platform.c create mode 100644 drivers/irqchip/irq-riscv-imsic-state.c create mode 100644 drivers/irqchip/irq-riscv-imsic-state.h create mode 100644 include/linux/irqchip/riscv-aplic.h create mode 100644 include/linux/irqchip/riscv-imsic.h
Signature · 1 line
2.34.1
PATCH v6 1/14 RISC-V: Add riscv_get_intc_hartid() function
We add a common riscv_get_intc_hartid() which help device drivers to get hartid of the HART associated with a INTC (i.e. local interrupt controller) fwnode. This new function is more generic compared to the existing riscv_of_parent_hartid() function hence we also replace use of riscv_of_parent_hartid() with riscv_get_intc_hartid().
--- arch/riscv/include/asm/processor.h | 4 +++- arch/riscv/kernel/cpu.c | 19 ++++++++++++++++++- drivers/irqchip/irq-riscv-intc.c | 2 +- drivers/irqchip/irq-sifive-plic.c | 3 ++- 4 files changed, 24 insertions(+), 4 deletions(-)
arch/riscv/include/asm/processor.h +3 -1
@@ -79,7 +79,9 @@ static inline void wait_for_interrupt(void)struct device_node ;int riscv_of_processor_hartid (struct device_node *node,unsigned long *hartid);int riscv_early_of_processor_hartid (struct device_node *node,unsigned long *hartid); -int riscv_of_parent_hartid (struct device_node *node,unsigned long *hartid); + +struct fwnode_handle ; +int riscv_get_intc_hartid (struct fwnode_handle *node,unsigned long *hartid);extern void riscv_fill_hwcap (void );extern int arch_dup_task_struct (struct task_struct *dst,struct task_struct *src);
arch/riscv/kernel/cpu.c +18 -1
@@ -81,7 +81,8 @@ int riscv_early_of_processor_hartid(struct device_node *node, unsigned long *har* To achieve this, we walk up the DT tree until we find an active * RISC-V core (HART) node and extract the cpuid from it. */ -int riscv_of_parent_hartid (struct device_node *node,unsigned long *hartid) +static int riscv_of_parent_hartid (struct device_node *node, +unsigned long *hartid) {int rc;
@@ -96,6 +97,22 @@ int riscv_of_parent_hartid(struct device_node *node, unsigned long *hartid)return -1 ; } +/* Find hart ID of the INTC fwnode. */ +int riscv_get_intc_hartid (struct fwnode_handle *node,unsigned long *hartid) +{ +int rc; +u64 temp; + +if (!is_of_node (node)) { + rc =fwnode_property_read_u64_array (node,"hartid" , &temp,1 ); +if (!rc) + *hartid = temp; + }else + rc =riscv_of_parent_hartid (to_of_node (node), hartid); + +return rc; +} + DEFINE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);unsigned long riscv_cached_mvendorid (unsigned int cpu_id)
drivers/irqchip/irq-riscv-intc.c +1 -1
@@ -143,7 +143,7 @@ static int __init riscv_intc_init(struct device_node *node,int rc;unsigned long hartid; - rc =riscv_of_parent_hartid (node, &hartid); + rc =riscv_get_intc_hartid (of_fwnode_handle (node), &hartid);if (rc <0 ) {pr_warn ("unable to find hart id for %pOF\n" , node);return 0 ;
drivers/irqchip/irq-sifive-plic.c +2 -1
@@ -477,7 +477,8 @@ static int __init __plic_init(struct device_node *node,continue ; } - error =riscv_of_parent_hartid (parent.np, &hartid); + error =riscv_get_intc_hartid (of_fwnode_handle (parent.np), + &hartid);if (error <0 ) {pr_warn ("failed to parse hart ID for context %d.\n" , i);continue ;
Signature · 1 line
2.34.1
PATCH v6 2/14 of: property: Add fw_devlink support for msi-parent
In reply to Anup PatelThis allows fw_devlink to create device links between consumers of a MSI and the supplier of the MSI.
--- drivers/of/property.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
drivers/of/property.c +32 -0
@@ -1325,6 +1325,37 @@ static struct device_node *parse_interrupts(struct device_node *np,return of_irq_parse_one (np, index, &sup_args) ?NULL : sup_args.np; } +static struct device_node *parse_msi_parent (struct device_node *np, +const char *prop_name,int index) +{ +struct of_phandle_args sup_args; +struct device_node *msi_np; + +if (!IS_ENABLED (CONFIG_OF_IRQ )) +return NULL ; + +if (strcmp (prop_name,"msi-parent" )) +return NULL ; + + msi_np =of_parse_phandle (np, prop_name,0 ); +if (msi_np) { +if (!of_property_read_bool (msi_np,"#msi-cells" )) { +if (index) { +of_node_put (msi_np); +return NULL ; + } +return msi_np; + } +of_node_put (msi_np); + } + +if (of_parse_phandle_with_args (np, prop_name,"#msi-cells" , index, + &sup_args)) +return NULL ; + +return sup_args.np; +} +static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_clocks, }, { .parse_prop = parse_interconnects, },
@@ -1359,6 +1390,7 @@ static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_regulators, }, { .parse_prop = parse_gpio, }, { .parse_prop = parse_gpios, }, + { .parse_prop = parse_msi_parent, }, {} };
Signature · 1 line
2.34.1
Re: [PATCH v6 02/14] of: property: Add fw_devlink support for msi-parent
Quoted 38 lines · Anup Patel
This allows
fw_devlinkto create device links between consumers of a MSI and the supplier of the MSI.Signed-off-by Anup Patel <[email protected]>--- drivers/of/property.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)drivers/of/property.c +21
-0@@ -1325,6 +1325,37 @@ static struct device_node *parse_interrupts(struct device_node *np,return of_irq_parse_one (np, index, &sup_args) ?NULL : sup_args.np; } +static struct device_node *parse_msi_parent (struct device_node *np, +const char *prop_name,int index) +{ +struct of_phandle_args sup_args; +struct device_node *msi_np; + +if (!IS_ENABLED (CONFIG_OF_IRQ )) +return NULL ; + +if (strcmp (prop_name,"msi-parent" )) +return NULL ; + + msi_np =of_parse_phandle (np, prop_name,0 ); +if (msi_np) { +if (!of_property_read_bool (msi_np,"#msi-cells" )) { +if (index) { +of_node_put (msi_np); +return NULL ; + } +return msi_np; + }
drivers/of/property.c static struct device_node *parse_interrupts(struct device_node *np, · line 1358
Quoted 10 lines
drivers/of/property.c +10
-0+of_node_put (msi_np); + } + +if (of_parse_phandle_with_args (np, prop_name,"#msi-cells" , index, + &sup_args)) +return NULL ; + +return sup_args.np; +} +
I'm amazed by the different ways you choose to waste people's time. Did you even scroll up to see how the other properties are handled?
Why can't this be handled using DEFINE_SIMPLE_PROP macro?
-Saravana
Quoted 12 lines
drivers/of/property.c +1
-1static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_clocks, }, { .parse_prop = parse_interconnects, },@@ -1359,6 +1390,7 @@ static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_regulators, }, { .parse_prop = parse_gpio, }, { .parse_prop = parse_gpios, }, + { .parse_prop = parse_msi_parent, }, {} }; --
Quoted 2 lines
2.34.1
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v6 02/14] of: property: Add fw_devlink support for msi-parent
Quoted 54 lines · Saravana Kannan
Quoted 38 lines · Anup Patel
This allows
fw_devlinkto create device links between consumers of a MSI and the supplier of the MSI.Signed-off-by Anup Patel <[email protected]>--- drivers/of/property.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)drivers/of/property.c +21
-0@@ -1325,6 +1325,37 @@ static struct device_node *parse_interrupts(struct device_node *np,return of_irq_parse_one (np, index, &sup_args) ?NULL : sup_args.np; } +static struct device_node *parse_msi_parent (struct device_node *np, +const char *prop_name,int index) +{ +struct of_phandle_args sup_args; +struct device_node *msi_np; + +if (!IS_ENABLED (CONFIG_OF_IRQ )) +return NULL ; + +if (strcmp (prop_name,"msi-parent" )) +return NULL ; + + msi_np =of_parse_phandle (np, prop_name,0 ); +if (msi_np) { +if (!of_property_read_bool (msi_np,"#msi-cells" )) { +if (index) { +of_node_put (msi_np); +return NULL ; + } +return msi_np; + }drivers/of/property.c static struct device_node *parse_interrupts(struct device_node *np, · line 1358
Quoted 10 lines
drivers/of/property.c +10
-0+of_node_put (msi_np); + } + +if (of_parse_phandle_with_args (np, prop_name,"#msi-cells" , index, + &sup_args)) +return NULL ; + +return sup_args.np; +} +I'm amazed by the different ways you choose to waste people's time. Did you even scroll up to see how the other properties are handled?
Quoted 1 line
Why can't this be handled using
DEFINE_SIMPLE_PROPmacro?
DEFINE_SIMPLE_PROP() is not suitable for msi-parent because we have a special case where for a single MSI parent the "#msi-cells" property won't be present in the supplier DT node.
The of_msi_get_domain() function also handles this special case separately.
Regards,
Anup
Quoted 17 lines
-Saravana
Quoted 14 lines
drivers/of/property.c +1
-1static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_clocks, }, { .parse_prop = parse_interconnects, },@@ -1359,6 +1390,7 @@ static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_regulators, }, { .parse_prop = parse_gpio, }, { .parse_prop = parse_gpios, }, + { .parse_prop = parse_msi_parent, }, {} }; --2.34.1
Rob Herring
maintainerRe: [PATCH v6 02/14] of: property: Add fw_devlink support for msi-parent
In reply to Anup PatelQuoted 14 lines · Anup Patel
This allows
fw_devlinkto create device links between consumers of a MSI and the supplier of the MSI.Signed-off-by Anup Patel <[email protected]>--- drivers/of/property.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)drivers/of/property.c +0
-0@@ -1325,6 +1325,37 @@ static struct device_node *parse_interrupts(struct device_node *np,return of_irq_parse_one (np, index, &sup_args) ?NULL : sup_args.np;
drivers/of/property.c static struct device_node *parse_interrupts(struct device_node *np, · line 1335
Quoted 10 lines
drivers/of/property.c +8
-0} +static struct device_node *parse_msi_parent (struct device_node *np, +const char *prop_name,int index) +{ +struct of_phandle_args sup_args; +struct device_node *msi_np; + +if (!IS_ENABLED (CONFIG_OF_IRQ )) +return NULL ;
Why do we need this? Sparc is not going to have MSI properties to begin with. I guess it saves a little bit of code. Though Sparc doesn't need any of this file. Or maybe there's a better kconfig symbol to use here if MSIs are not supported?
Quoted 37 lines
drivers/of/property.c +24
-0+ +if (strcmp (prop_name,"msi-parent" )) +return NULL ; + + msi_np =of_parse_phandle (np, prop_name,0 ); +if (msi_np) { +if (!of_property_read_bool (msi_np,"#msi-cells" )) { +if (index) { +of_node_put (msi_np); +return NULL ; + } +return msi_np; + } +of_node_put (msi_np); + } + +if (of_parse_phandle_with_args (np, prop_name,"#msi-cells" , index, + &sup_args)) +return NULL ; + +return sup_args.np; +} +static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_clocks, }, { .parse_prop = parse_interconnects, },@@ -1359,6 +1390,7 @@ static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_regulators, }, { .parse_prop = parse_gpio, }, { .parse_prop = parse_gpios, }, + { .parse_prop = parse_msi_parent, }, {} };Signature · 1 line
2.34.1
Re: [PATCH v6 02/14] of: property: Add fw_devlink support for msi-parent
Quoted 18 lines · Rob Herring
Quoted 16 lines · Anup Patel
This allows
fw_devlinkto create device links between consumers of a MSI and the supplier of the MSI.Signed-off-by Anup Patel <[email protected]>--- drivers/of/property.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)drivers/of/property.c +0
-0@@ -1325,6 +1325,37 @@ static struct device_node *parse_interrupts(struct device_node *np,return of_irq_parse_one (np, index, &sup_args) ?NULL : sup_args.np; }
Quoted 13 lines
drivers/of/property.c static struct device_node *parse_interrupts(struct device_node *np, · line 1335
Quoted 8 lines
drivers/of/property.c +8
-0+static struct device_node *parse_msi_parent (struct device_node *np, +const char *prop_name,int index) +{ +struct of_phandle_args sup_args; +struct device_node *msi_np; + +if (!IS_ENABLED (CONFIG_OF_IRQ )) +return NULL ;Why do we need this? Sparc is not going to have MSI properties to begin with. I guess it saves a little bit of code. Though Sparc doesn't need any of this file. Or maybe there's a better kconfig symbol to use here if MSIs are not supported?
I can't think of a better kconfig symbol over here but since Sparc does not have MSI properties, I think following is better:
if (IS_ENABLED(CONFIG_SPARC))
return NULL;
Any other suggestions ?
Regards,
Anup
Quoted 35 lines
Quoted 35 lines
drivers/of/property.c +24
-0+ +if (strcmp (prop_name,"msi-parent" )) +return NULL ; + + msi_np =of_parse_phandle (np, prop_name,0 ); +if (msi_np) { +if (!of_property_read_bool (msi_np,"#msi-cells" )) { +if (index) { +of_node_put (msi_np); +return NULL ; + } +return msi_np; + } +of_node_put (msi_np); + } + +if (of_parse_phandle_with_args (np, prop_name,"#msi-cells" , index, + &sup_args)) +return NULL ; + +return sup_args.np; +} +static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_clocks, }, { .parse_prop = parse_interconnects, },@@ -1359,6 +1390,7 @@ static const struct supplier_bindings of_supplier_bindings[] = { { .parse_prop = parse_regulators, }, { .parse_prop = parse_gpio, }, { .parse_prop = parse_gpios, }, + { .parse_prop = parse_msi_parent, }, {} };
Quoted 3 lines
Quoted 3 lines
--
2.34.1
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 3/14 drivers: irqchip/riscv-intc: Mark all INTC nodes as initialized
In reply to Anup PatelThe RISC-V INTC local interrupts are per-HART (or per-CPU) so we create INTC IRQ domain only for the INTC node belonging to the boot HART. This means only the boot HART INTC node will be marked as initialized and other INTC nodes won't be marked which results downstream interrupt controllers (such as IMSIC and APLIC direct-mode) not being probed due to missing device suppliers.
To address this issue, we mark all INTC node for which we don't create IRQ domain as initialized.
--- drivers/irqchip/irq-riscv-intc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/irqchip/irq-riscv-intc.c +9 -1
@@ -155,8 +155,16 @@ static int __init riscv_intc_init(struct device_node *node,* for each INTC DT node. We only need to do INTC initialization * for the INTC DT node belonging to boot CPU (or boot HART). */ -if (riscv_hartid_to_cpuid (hartid) !=smp_processor_id ()) +if (riscv_hartid_to_cpuid (hartid) !=smp_processor_id ()) { +/* +* The INTC nodes of each CPU are suppliers for downstream +* interrupt controllers (such as IMSIC and APLIC direct-mode) +* so we should mark an INTC node as initialized if we are +* not creating IRQ domain for it. +*/ +fwnode_dev_initialized (of_fwnode_handle (node), true);return 0 ; + }return riscv_intc_init_common (of_node_to_fwnode (node)); }
Signature · 1 line
2.34.1
Re: [PATCH v6 03/14] drivers: irqchip/riscv-intc: Mark all INTC nodes as initialized
Quoted 22 lines · Anup Patel
The RISC-V INTC local interrupts are per-HART (or per-CPU) so we create INTC IRQ domain only for the INTC node belonging to the boot HART. This means only the boot HART INTC node will be marked as initialized and other INTC nodes won't be marked which results downstream interrupt controllers (such as IMSIC and APLIC direct-mode) not being probed due to missing device suppliers.
To address this issue, we mark all INTC node for which we don't create IRQ domain as initialized.
Signed-off-by Anup Patel <[email protected]>--- drivers/irqchip/irq-riscv-intc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)drivers/irqchip/irq-riscv-intc.c +0
-0@@ -155,8 +155,16 @@ static int __init riscv_intc_init(struct device_node *node,* for each INTC DT node. We only need to do INTC initialization
drivers/irqchip/irq-riscv-intc.c static int __init riscv_intc_init(struct device_node *node, · line 164
Quoted 10 lines
drivers/irqchip/irq-riscv-intc.c +7
-1* for the INTC DT node belonging to boot CPU (or boot HART). */ -if (riscv_hartid_to_cpuid (hartid) !=smp_processor_id ()) +if (riscv_hartid_to_cpuid (hartid) !=smp_processor_id ()) { +/* +* The INTC nodes of each CPU are suppliers for downstream +* interrupt controllers (such as IMSIC and APLIC direct-mode) +* so we should mark an INTC node as initialized if we are +* not creating IRQ domain for it. +*/
I'm a bit confused by this. If those non-boot CPUs INTC doesn't have an IRQ domain, why are the downstream interrupt controllers listing these non-boot CPU INTCs as an upstream interrupt controller?
This is more of a question of the existing behavior that this patch, but this patch highlights the existing oddity.
-Saravana
Quoted 9 lines
drivers/irqchip/irq-riscv-intc.c +2
-1+fwnode_dev_initialized (of_fwnode_handle (node), true);return 0 ; + }return riscv_intc_init_common (of_node_to_fwnode (node)); } --2.34.1
Re: [PATCH v6 03/14] drivers: irqchip/riscv-intc: Mark all INTC nodes as initialized
Quoted 30 lines · Saravana Kannan
Quoted 28 lines · Anup Patel
The RISC-V INTC local interrupts are per-HART (or per-CPU) so we create INTC IRQ domain only for the INTC node belonging to the boot HART. This means only the boot HART INTC node will be marked as initialized and other INTC nodes won't be marked which results downstream interrupt controllers (such as IMSIC and APLIC direct-mode) not being probed due to missing device suppliers.
To address this issue, we mark all INTC node for which we don't create IRQ domain as initialized.
Signed-off-by Anup Patel <[email protected]>--- drivers/irqchip/irq-riscv-intc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)drivers/irqchip/irq-riscv-intc.c +3
-1@@ -155,8 +155,16 @@ static int __init riscv_intc_init(struct device_node *node,* for each INTC DT node. We only need to do INTC initialization * for the INTC DT node belonging to boot CPU (or boot HART). */ -if (riscv_hartid_to_cpuid (hartid) !=smp_processor_id ()) +if (riscv_hartid_to_cpuid (hartid) !=smp_processor_id ()) { +/* +* The INTC nodes of each CPU are suppliers for downstream
Quoted 8 lines
drivers/irqchip/irq-riscv-intc.c static int __init riscv_intc_init(struct device_node *node, · line 164
Quoted 4 lines
drivers/irqchip/irq-riscv-intc.c +4
-0+* interrupt controllers (such as IMSIC and APLIC direct-mode) +* so we should mark an INTC node as initialized if we are +* not creating IRQ domain for it. +*/ I'm a bit confused by this. If those non-boot CPUs INTC doesn't have an IRQ domain, why are the downstream interrupt controllers listing these non-boot CPU INTCs as an upstream interrupt controller?
Downstream interrupt controllers (such as PLIC, APLIC direct-mode, or IMSIC) use "interrupts-extended" DT property to associate their MMIO resources with target CPU.
For example: If we have 4 CPUs then PLIC will typically have 2 PLIC MMIO contexts for each CPU where one context is for M-mode and another context is for S-mode. In this case, there are total 8 PLIC MMIO contexts and the arrangement of these MMIO resources is platform specific so "interrupts-extended" DT property is used by PLIC driver to discover the arrangement of PLIC MMIO contexts and their mapping to target CPU.
Similar to the above example, the APLIC direct-mode has per-CPU IDC MMIO registers and "interrupts-extended" DT property is used to discover arrangement of these IDC MMIO registers and their mapping to the target CPU.
Quoted 15 lines
This is more of a question of the existing behavior that this patch, but this patch highlights the existing oddity.
-Saravana
Quoted 9 lines
drivers/irqchip/irq-riscv-intc.c +2
-1+fwnode_dev_initialized (of_fwnode_handle (node), true);return 0 ; + }return riscv_intc_init_common (of_node_to_fwnode (node)); } --2.34.1
Regards,
Anup
PATCH v6 4/14 irqchip/sifive-plic: Use platform driver probing for PLIC
In reply to Anup PatelThe PLIC driver does not require very early initialization so let us replace use of IRQCHIP_DECLARE() with IRQCHIP_PLATFORM_DRIVER_xyz() so that PLIC is probed through platform driver probing.
--- drivers/irqchip/irq-sifive-plic.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/irqchip/irq-sifive-plic.c +8 -4
@@ -569,8 +569,10 @@ static int __init plic_init(struct device_node *node,return __plic_init (node, parent,0 ); } -IRQCHIP_DECLARE (sifive_plic,"sifive,plic-1.0.0" , plic_init); -IRQCHIP_DECLARE (riscv_plic0,"riscv,plic0" , plic_init);/* for legacy systems */ +IRQCHIP_PLATFORM_DRIVER_BEGIN(sifive_plic) +IRQCHIP_MATCH("sifive,plic-1.0.0", plic_init) +IRQCHIP_MATCH("riscv,plic0", plic_init) /* for legacy systems */ +IRQCHIP_PLATFORM_DRIVER_END (sifive_plic) static int __init plic_edge_init(struct device_node *node,struct device_node *parent)
@@ -578,5 +580,7 @@ static int __init plic_edge_init(struct device_node *node,return __plic_init (node, parent,BIT (PLIC_QUIRK_EDGE_INTERRUPT )); } -IRQCHIP_DECLARE (andestech_nceplic100,"andestech,nceplic100" , plic_edge_init); -IRQCHIP_DECLARE (thead_c900_plic,"thead,c900-plic" , plic_edge_init); +IRQCHIP_PLATFORM_DRIVER_BEGIN(edge_plic) +IRQCHIP_MATCH("andestech,nceplic100", plic_edge_init) +IRQCHIP_MATCH("thead,c900-plic", plic_edge_init) +IRQCHIP_PLATFORM_DRIVER_END (edge_plic)
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v6 04/14] irqchip/sifive-plic: Use platform driver probing for PLIC
Hi Anup,
Quoted 14 lines · Anup Patel
The PLIC driver does not require very early initialization so let us replace use of
IRQCHIP_DECLARE()withIRQCHIP_PLATFORM_DRIVER_xyz()so that PLIC is probed through platform driver probing.Signed-off-by Anup Patel <[email protected]>--- drivers/irqchip/irq-sifive-plic.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)drivers/irqchip/irq-sifive-plic.c +0
-0
drivers/irqchip/irq-sifive-plic.c static int __init plic_init(struct device_node *node, · line 576
Quoted 10 lines
drivers/irqchip/irq-sifive-plic.c +4
-2@@ -569,8 +569,10 @@ static int __init plic_init(struct device_node *node,return __plic_init (node, parent,0 ); } -IRQCHIP_DECLARE (sifive_plic,"sifive,plic-1.0.0" , plic_init); -IRQCHIP_DECLARE (riscv_plic0,"riscv,plic0" , plic_init);/* for legacy systems */ +IRQCHIP_PLATFORM_DRIVER_BEGIN(sifive_plic) +IRQCHIP_MATCH("sifive,plic-1.0.0", plic_init) +IRQCHIP_MATCH("riscv,plic0", plic_init) /* for legacy systems */ +IRQCHIP_PLATFORM_DRIVER_END (sifive_plic)
Few observations..
1) IRQCHIP_PLATFORM_DRIVER_xyz work only for DT. Can we have more generic platform driver probe similar to APLIC driver?
2) With platform driver model, there is a crash some times.
[ 0.198665] CPU: 4 PID: 32 Comm: cpuhp/4 Not tainted 6.5.0-rc3-00038-g782440711cdb #42 [ 0.198944] Hardware name: riscv-virtio,qemu (DT) [ 0.199125] epc : plic_starting_cpu+0x60/0xa6 [ 0.199545] ra : plic_starting_cpu+0x58/0xa6 [ 0.199676] epc : ffffffff8047396e ra : ffffffff80473966 sp : ff20000000173d80 [ 0.199899] gp : ffffffff81501740 tp : ff600000019bde00 t0 : ffffffff81200800 [ 0.200112] t1 : 0000000000000000 t2 : 0000000000001000 s0 : ff20000000173db0 [ 0.200324] s1 : ff6000007ef91eb0 a0 : ff600000019690b0 a1 : 0000000200000020 [ 0.200502] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.200678] a5 : 0000000000000000 a6 : ff6000000184a108 a7 : ff6000000184a100 [ 0.200855] s2 : 000000000000000b s3 : ffffffff8153a550 s4 : 0000000000000004 [ 0.201032] s5 : 0000000000000001 s6 : 0000000000000002 s7 : ffffffff8047390e [ 0.201210] s8 : ffffffff80033f8a s9 : ffffffff80033f64 s10: 0000000000000000 [ 0.201392] s11: 0000000000000000 t3 : 0000000000000000 t4 : ffffffff81486c20 [ 0.201567] t5 : 0000000000000002 t6 : 0000000000000002 [ 0.201702] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000f [ 0.201962] [<ffffffff8047396e>] plic_starting_cpu+0x60/0xa6 [ 0.202184] [<ffffffff8001069e>] cpuhp_invoke_callback+0xb4/0x164 [ 0.202346] [<ffffffff80010972>] cpuhp_thread_fun+0x8a/0x11c [ 0.202493] [<ffffffff80033f62>] smpboot_thread_fn+0xe4/0x1be [ 0.202639] [<ffffffff8003042a>] kthread+0xc4/0xe0 [ 0.202759] [<ffffffff8000355e>] ret_from_fork+0xa/0x1c [ 0.203038] Code: 89bd 854a 3097 ffbf 80e7 51e0 000f 0140 4781 6498
(c31c) 2703
3) Looks like an existing issue but I get below warning also.
[ 0.207677] list_add double add: new=ffffffff814a0798, prev=ffffffff814a0798, next=ffffffff814be638. [ 0.208243] WARNING: CPU: 4 PID: 1 at lib/list_debug.c:33 __list_add_valid+0x46/0xac [ 0.208677] Modules linked in: [ 0.208780] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00038-g782440711cdb #28 [ 0.208862] Hardware name: riscv-virtio,qemu (DT) [ 0.208926] epc : __list_add_valid+0x46/0xac [ 0.208961] ra : __list_add_valid+0x46/0xac [ 0.208983] epc : ffffffff803cb356 ra : ffffffff803cb356 sp : ff200000000439f0 [ 0.208994] gp : ffffffff81501740 tp : ff600000018f0000 t0 : 2000000000000000 [ 0.209005] t1 : 000000000000006c t2 : 206464615f747369 s0 : ff20000000043a00 [ 0.209015] s1 : ffffffff814a0798 a0 : 0000000000000058 a1 : ffffffff81486828 [ 0.209025] a2 : 0000000000000000 a3 : fffffffffffffffe a4 : 0000000000000000 [ 0.209034] a5 : 0000000000000000 a6 : 0000000000000068 a7 : 0000000000000038 [ 0.209044] s2 : ffffffff814be5f8 s3 : ffffffff814a0798 s4 : ffffffff814be638 [ 0.209053] s5 : ff6000007fff75c0 s6 : 0000000000000060 s7 : ffffffff80c20eb0 [ 0.209063] s8 : 0000000000000008 s9 : 0000000000000004 s10: ffffffff80c20eb0 [ 0.209072] s11: ffffffff81038e80 t3 : ffffffff815159d7 t4 : ffffffff815159d7 [ 0.209081] t5 : ffffffff815159d8 t6 : ff200000000437f8 [ 0.209090] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 0.209167] [<ffffffff803cb356>] __list_add_valid+0x46/0xac [ 0.209219] [<ffffffff805812d4>] register_syscore_ops+0x3e/0x70 [ 0.209245] [<ffffffff80a1fd0c>] __plic_init.isra.0+0x3e0/0x4e2 [ 0.209267] [<ffffffff80a1fe3a>] plic_init+0x12/0x1a [ 0.209281] [<ffffffff80470c10>] platform_irqchip_probe+0x82/0xb4 [ 0.209292] [<ffffffff80582aa8>] platform_probe+0x4e/0xa6 [ 0.209301] [<ffffffff805805a4>] really_probe+0x86/0x242 [ 0.209308] [<ffffffff805807bc>] __driver_probe_device+0x5c/0xda [ 0.209316] [<ffffffff80580866>] driver_probe_device+0x2c/0xb2 [ 0.209324] [<ffffffff805809e6>] __driver_attach+0x6c/0x11a [ 0.209331] [<ffffffff8057e73a>] bus_for_each_dev+0x60/0xae [ 0.209343] [<ffffffff8057fff6>] driver_attach+0x1a/0x22 [ 0.209352] [<ffffffff8057f956>] bus_add_driver+0xd0/0x1ba [ 0.209362] [<ffffffff80581634>] driver_register+0x3e/0xd8 [ 0.209370] [<ffffffff805827c0>] __platform_driver_register+0x1c/0x24 [ 0.209378] [<ffffffff80a1f902>] sifive_plic_driver_init+0x1a/0x22 [ 0.209389] [<ffffffff8000212c>] do_one_initcall+0x58/0x19c [ 0.209399] [<ffffffff80a01056>] kernel_init_freeable+0x20c/0x276 [ 0.209410] [<ffffffff808d6686>] kernel_init+0x1e/0x10a [ 0.209421] [<ffffffff8000355e>] ret_from_fork+0xa/0x1c [ 0.209477] ---[ end trace 0000000000000000 ]---
Thanks,
Sunil
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v6 04/14] irqchip/sifive-plic: Use platform driver probing for PLIC
Hi Sunil,
Quoted 30 lines · Sunil V L
Hi Anup,
Quoted 14 lines · Anup Patel
The PLIC driver does not require very early initialization so let us replace use of
IRQCHIP_DECLARE()withIRQCHIP_PLATFORM_DRIVER_xyz()so that PLIC is probed through platform driver probing.Signed-off-by Anup Patel <[email protected]>--- drivers/irqchip/irq-sifive-plic.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)drivers/irqchip/irq-sifive-plic.c +0
-0drivers/irqchip/irq-sifive-plic.c static int __init plic_init(struct device_node *node, · line 576
Quoted 10 lines
drivers/irqchip/irq-sifive-plic.c +4
-2@@ -569,8 +569,10 @@ static int __init plic_init(struct device_node *node,return __plic_init (node, parent,0 ); } -IRQCHIP_DECLARE (sifive_plic,"sifive,plic-1.0.0" , plic_init); -IRQCHIP_DECLARE (riscv_plic0,"riscv,plic0" , plic_init);/* for legacy systems */ +IRQCHIP_PLATFORM_DRIVER_BEGIN(sifive_plic) +IRQCHIP_MATCH("sifive,plic-1.0.0", plic_init) +IRQCHIP_MATCH("riscv,plic0", plic_init) /* for legacy systems */ +IRQCHIP_PLATFORM_DRIVER_END (sifive_plic)Few observations..
Quoted 2 lines
1)
IRQCHIP_PLATFORM_DRIVER_xyzwork only for DT. Can we have more generic platform driver probe similar to APLIC driver?
Okay, I will convert it into generic platform driver which will work for ACPI as well.
Quoted 38 lines
2) With platform driver model, there is a crash some times.
[ 0.198665] CPU: 4 PID: 32 Comm: cpuhp/4 Not tainted 6.5.0-rc3-00038-g782440711cdb #42 [ 0.198944] Hardware name: riscv-virtio,qemu (DT) [ 0.199125] epc : plic_starting_cpu+0x60/0xa6 [ 0.199545] ra : plic_starting_cpu+0x58/0xa6 [ 0.199676] epc : ffffffff8047396e ra : ffffffff80473966 sp : ff20000000173d80 [ 0.199899] gp : ffffffff81501740 tp : ff600000019bde00 t0 : ffffffff81200800 [ 0.200112] t1 : 0000000000000000 t2 : 0000000000001000 s0 : ff20000000173db0 [ 0.200324] s1 : ff6000007ef91eb0 a0 : ff600000019690b0 a1 : 0000000200000020 [ 0.200502] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.200678] a5 : 0000000000000000 a6 : ff6000000184a108 a7 : ff6000000184a100 [ 0.200855] s2 : 000000000000000b s3 : ffffffff8153a550 s4 : 0000000000000004 [ 0.201032] s5 : 0000000000000001 s6 : 0000000000000002 s7 : ffffffff8047390e [ 0.201210] s8 : ffffffff80033f8a s9 : ffffffff80033f64 s10: 0000000000000000 [ 0.201392] s11: 0000000000000000 t3 : 0000000000000000 t4 : ffffffff81486c20 [ 0.201567] t5 : 0000000000000002 t6 : 0000000000000002 [ 0.201702] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000f [ 0.201962] [<ffffffff8047396e>] plic_starting_cpu+0x60/0xa6 [ 0.202184] [<ffffffff8001069e>] cpuhp_invoke_callback+0xb4/0x164 [ 0.202346] [<ffffffff80010972>] cpuhp_thread_fun+0x8a/0x11c [ 0.202493] [<ffffffff80033f62>] smpboot_thread_fn+0xe4/0x1be [ 0.202639] [<ffffffff8003042a>] kthread+0xc4/0xe0 [ 0.202759] [<ffffffff8000355e>] ret_from_fork+0xa/0x1c [ 0.203038] Code: 89bd 854a 3097 ffbf 80e7 51e0 000f 0140 4781 6498
Quoted 1 line
(c31c) 2703
The cpuhp setup needed to change since as platform driver the PLIC is probed after all CPUs are brought-up. I will fix this in the next revision.
Quoted 49 lines
3) Looks like an existing issue but I get below warning also.
[ 0.207677] list_add double add: new=ffffffff814a0798, prev=ffffffff814a0798, next=ffffffff814be638. [ 0.208243] WARNING: CPU: 4 PID: 1 at lib/list_debug.c:33 __list_add_valid+0x46/0xac [ 0.208677] Modules linked in: [ 0.208780] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.5.0-rc3-00038-g782440711cdb #28 [ 0.208862] Hardware name: riscv-virtio,qemu (DT) [ 0.208926] epc : __list_add_valid+0x46/0xac [ 0.208961] ra : __list_add_valid+0x46/0xac [ 0.208983] epc : ffffffff803cb356 ra : ffffffff803cb356 sp : ff200000000439f0 [ 0.208994] gp : ffffffff81501740 tp : ff600000018f0000 t0 : 2000000000000000 [ 0.209005] t1 : 000000000000006c t2 : 206464615f747369 s0 : ff20000000043a00 [ 0.209015] s1 : ffffffff814a0798 a0 : 0000000000000058 a1 : ffffffff81486828 [ 0.209025] a2 : 0000000000000000 a3 : fffffffffffffffe a4 : 0000000000000000 [ 0.209034] a5 : 0000000000000000 a6 : 0000000000000068 a7 : 0000000000000038 [ 0.209044] s2 : ffffffff814be5f8 s3 : ffffffff814a0798 s4 : ffffffff814be638 [ 0.209053] s5 : ff6000007fff75c0 s6 : 0000000000000060 s7 : ffffffff80c20eb0 [ 0.209063] s8 : 0000000000000008 s9 : 0000000000000004 s10: ffffffff80c20eb0 [ 0.209072] s11: ffffffff81038e80 t3 : ffffffff815159d7 t4 : ffffffff815159d7 [ 0.209081] t5 : ffffffff815159d8 t6 : ff200000000437f8 [ 0.209090] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 0.209167] [<ffffffff803cb356>] __list_add_valid+0x46/0xac [ 0.209219] [<ffffffff805812d4>] register_syscore_ops+0x3e/0x70 [ 0.209245] [<ffffffff80a1fd0c>] __plic_init.isra.0+0x3e0/0x4e2 [ 0.209267] [<ffffffff80a1fe3a>] plic_init+0x12/0x1a [ 0.209281] [<ffffffff80470c10>] platform_irqchip_probe+0x82/0xb4 [ 0.209292] [<ffffffff80582aa8>] platform_probe+0x4e/0xa6 [ 0.209301] [<ffffffff805805a4>] really_probe+0x86/0x242 [ 0.209308] [<ffffffff805807bc>] __driver_probe_device+0x5c/0xda [ 0.209316] [<ffffffff80580866>] driver_probe_device+0x2c/0xb2 [ 0.209324] [<ffffffff805809e6>] __driver_attach+0x6c/0x11a [ 0.209331] [<ffffffff8057e73a>] bus_for_each_dev+0x60/0xae [ 0.209343] [<ffffffff8057fff6>] driver_attach+0x1a/0x22 [ 0.209352] [<ffffffff8057f956>] bus_add_driver+0xd0/0x1ba
Quoted 8 lines
[ 0.209362] [<ffffffff80581634>] driver_register+0x3e/0xd8 [ 0.209370] [<ffffffff805827c0>] __platform_driver_register+0x1c/0x24 [ 0.209378] [<ffffffff80a1f902>] sifive_plic_driver_init+0x1a/0x22 [ 0.209389] [<ffffffff8000212c>] do_one_initcall+0x58/0x19c [ 0.209399] [<ffffffff80a01056>] kernel_init_freeable+0x20c/0x276 [ 0.209410] [<ffffffff808d6686>] kernel_init+0x1e/0x10a [ 0.209421] [<ffffffff8000355e>] ret_from_fork+0xa/0x1c [ 0.209477] ---[ end trace 0000000000000000 ]---
This is a bug in current PLIC driver where it unconditionally registers syscore ops which breaks on multi-socket systems having multiple PLICs. I will add a separate patch in the next revision to fix this issue.
Regards,
Anup
PATCH v6 5/14 irqchip/riscv-intc: Add support for RISC-V AIA
In reply to Anup PatelThe RISC-V advanced interrupt architecture (AIA) extends the per-HART local interrupts in following ways:
1. Minimum 64 local interrupts for both RV32 and RV64
2. Ability to process multiple pending local interrupts in same interrupt handler
3. Priority configuration for each local interrupts
4. Special CSRs to configure/access the per-HART MSI controller
We add support for #1 and #2 described above in the RISC-V intc driver.
--- drivers/irqchip/irq-riscv-intc.c | 34 ++++++++++++++++++++++++++------ 1 file changed, 28 insertions(+), 6 deletions(-)
drivers/irqchip/irq-riscv-intc.c +28 -6
@@ -17,6 +17,7 @@#include <linux/module.h> #include <linux/of.h> #include <linux/smp.h> +#include <asm/hwcap.h> static struct irq_domain *intc_domain;
@@ -30,6 +31,15 @@ static asmlinkage void riscv_intc_irq(struct pt_regs *regs)generic_handle_domain_irq (intc_domain, cause); } +static asmlinkage void riscv_intc_aia_irq(struct pt_regs *regs) +{ +unsigned long topi; + +while ((topi =csr_read (CSR_TOPI ))) +generic_handle_domain_irq (intc_domain, + topi >>TOPI_IID_SHIFT ); +} +/* * On RISC-V systems local interrupts are masked or unmasked by writing * the SIE (Supervisor Interrupt Enable) CSR. As CSRs can only be written
@@ -39,12 +49,18 @@ static asmlinkage void riscv_intc_irq(struct pt_regs *regs)static void riscv_intc_irq_mask (struct irq_data *d) { -csr_clear (CSR_IE ,BIT (d->hwirq)); +if (IS_ENABLED (CONFIG_32BIT ) && d->hwirq >=BITS_PER_LONG ) +csr_clear (CSR_IEH ,BIT (d->hwirq -BITS_PER_LONG )); +else +csr_clear (CSR_IE ,BIT (d->hwirq)); }static void riscv_intc_irq_unmask (struct irq_data *d) { -csr_set (CSR_IE ,BIT (d->hwirq)); +if (IS_ENABLED (CONFIG_32BIT ) && d->hwirq >=BITS_PER_LONG ) +csr_set (CSR_IEH ,BIT (d->hwirq -BITS_PER_LONG )); +else +csr_set (CSR_IE ,BIT (d->hwirq)); }static void riscv_intc_irq_eoi (struct irq_data *d)
@@ -115,16 +131,20 @@ static struct fwnode_handle *riscv_intc_hwnode(void)static int __init riscv_intc_init_common (struct fwnode_handle *fn) { -int rc; +int rc, nr_irqs =riscv_isa_extension_available (NULL , SxAIA) ? +64 :BITS_PER_LONG ; - intc_domain =irq_domain_create_linear (fn,BITS_PER_LONG , + intc_domain =irq_domain_create_linear (fn, nr_irqs, &riscv_intc_domain_ops,NULL );if (!intc_domain) {pr_err ("unable to add IRQ domain\n" );return -ENXIO ; } - rc =set_handle_irq (&riscv_intc_irq); +if (riscv_isa_extension_available (NULL , SxAIA)) + rc =set_handle_irq (&riscv_intc_aia_irq); +else + rc =set_handle_irq (&riscv_intc_irq);if (rc) {pr_err ("failed to set irq handler\n" );return rc;
@@ -132,7 +152,9 @@ 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 ); +pr_info ("%d local interrupts mapped%s\n" , + nr_irqs,riscv_isa_extension_available (NULL , SxAIA) ? +" using AIA" :"" );return 0 ; }
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 6/14 dt-bindings: interrupt-controller: Add RISC-V incoming MSI controller
In reply to Anup PatelWe add DT bindings document for the RISC-V incoming MSI controller (IMSIC) defined by the RISC-V advanced interrupt architecture (AIA) specification.
--- .../interrupt-controller/riscv,imsics.yaml | 172 ++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml
Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml new file +172 -0
@@ -0,0 +1,172 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/riscv,imsics.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V Incoming MSI Controller (IMSIC) + +maintainers: + - Anup Patel <[email protected]> + +description: | + The RISC-V advanced interrupt architecture (AIA) defines a per-CPU incoming + MSI controller (IMSIC) for handling MSIs in a RISC-V platform. The RISC-V + AIA specification can be found at https://github.com/riscv/riscv-aia. + + The IMSIC is a per-CPU (or per-HART) device with separate interrupt file + for each privilege level (machine or supervisor). The configuration of + a IMSIC interrupt file is done using AIA CSRs and it also has a 4KB MMIO + space to receive MSIs from devices. Each IMSIC interrupt file supports a + fixed number of interrupt identities (to distinguish MSIs from devices) + which is same for given privilege level across CPUs (or HARTs). + + The device tree of a RISC-V platform will have one IMSIC device tree node + for each privilege level (machine or supervisor) which collectively describe + IMSIC interrupt files at that privilege level across CPUs (or HARTs). + + The arrangement of IMSIC interrupt files in MMIO space of a RISC-V platform + follows a particular scheme defined by the RISC-V AIA specification. A IMSIC + group is a set of IMSIC interrupt files co-located in MMIO space and we can + have multiple IMSIC groups (i.e. clusters, sockets, chiplets, etc) in a + RISC-V platform. The MSI target address of a IMSIC interrupt file at given + privilege level (machine or supervisor) encodes group index, HART index, + and guest index (shown below). + + XLEN-1 > (HART Index MSB) 12 0 + | | | | + ------------------------------------------------------------- + |xxxxxx|Group Index|xxxxxxxxxxx|HART Index|Guest Index| 0 | + ------------------------------------------------------------- + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + +properties: + compatible: + items: + - enum: + - qemu,imsics + - const: riscv,imsics + + reg: + minItems: 1 + maxItems: 16384 + description: + Base address of each IMSIC group. + + interrupt-controller: true + + "#interrupt-cells": + const: 0 + + msi-controller: true + + "#msi-cells": + const: 0 + + interrupts-extended: + minItems: 1 + maxItems: 16384 + description: + This property represents the set of CPUs (or HARTs) for which given + device tree node describes the IMSIC interrupt files. Each node pointed + to should be a riscv,cpu-intc node, which has a CPU node (i.e. RISC-V + HART) as parent. + + riscv,num-ids: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 63 + maximum: 2047 + description: + Number of interrupt identities supported by IMSIC interrupt file. + + riscv,num-guest-ids: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 63 + maximum: 2047 + description: + Number of interrupt identities are supported by IMSIC guest interrupt + file. When not specified it is assumed to be same as specified by the + riscv,num-ids property. + + riscv,guest-index-bits: + minimum: 0 + maximum: 7 + default: 0 + description: + Number of guest index bits in the MSI target address. + + riscv,hart-index-bits: + minimum: 0 + maximum: 15 + description: + Number of HART index bits in the MSI target address. When not + specified it is calculated based on the interrupts-extended property. + + riscv,group-index-bits: + minimum: 0 + maximum: 7 + default: 0 + description: + Number of group index bits in the MSI target address. + + riscv,group-index-shift: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 55 + default: 24 + description: + The least significant bit position of the group index bits in the + MSI target address. + +required: + - compatible + - reg + - interrupt-controller + - msi-controller + - "#msi-cells" + - interrupts-extended + - riscv,num-ids + +unevaluatedProperties: false + +examples: + - | + // Example 1 (Machine-level IMSIC files with just one group): + + interrupt-controller@24000000 { + compatible = "qemu,imsics", "riscv,imsics"; + interrupts-extended = <&cpu1_intc 11>, + <&cpu2_intc 11>, + <&cpu3_intc 11>, + <&cpu4_intc 11>; + reg = <0x28000000 0x4000>; + interrupt-controller; + #interrupt-cells = <0>; + msi-controller; + #msi-cells = <0>; + riscv,num-ids = <127>; + }; + + - | + // Example 2 (Supervisor-level IMSIC files with two groups): + + interrupt-controller@28000000 { + compatible = "qemu,imsics", "riscv,imsics"; + interrupts-extended = <&cpu1_intc 9>, + <&cpu2_intc 9>, + <&cpu3_intc 9>, + <&cpu4_intc 9>; + reg = <0x28000000 0x2000>, /* Group0 IMSICs */ + <0x29000000 0x2000>; /* Group1 IMSICs */ + interrupt-controller; + #interrupt-cells = <0>; + msi-controller; + #msi-cells = <0>; + riscv,num-ids = <127>; + riscv,group-index-bits = <1>; + riscv,group-index-shift = <24>; + }; +...
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 7/14 irqchip: Add RISC-V incoming MSI controller early driver
In reply to Anup PatelThe RISC-V advanced interrupt architecture (AIA) specification defines a new MSI controller called incoming message signalled interrupt controller (IMSIC) which manages MSI on per-HART (or per-CPU) basis. It also supports IPIs as software injected MSIs. (For more details refer https://github.com/riscv/riscv-aia)
Let us add an early irqchip driver for RISC-V IMSIC which sets up the IMSIC state and provide IPIs.
--- drivers/irqchip/Kconfig | 7 +- drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-riscv-imsic-early.c | 258 ++++++++++++ drivers/irqchip/irq-riscv-imsic-state.c | 523 ++++++++++++++++++++++++ drivers/irqchip/irq-riscv-imsic-state.h | 66 +++ include/linux/irqchip/riscv-imsic.h | 86 ++++ 6 files changed, 940 insertions(+), 1 deletion(-) create mode 100644 drivers/irqchip/irq-riscv-imsic-early.c create mode 100644 drivers/irqchip/irq-riscv-imsic-state.c create mode 100644 drivers/irqchip/irq-riscv-imsic-state.h create mode 100644 include/linux/irqchip/riscv-imsic.h
drivers/irqchip/Kconfig +6 -1
@@ -30,7 +30,6 @@ config ARM_GIC_V2M config GIC_NON_BANKED bool - config ARM_GIC_V3 bool select IRQ_DOMAIN_HIERARCHY
@@ -545,6 +544,12 @@ config SIFIVE_PLIC select IRQ_DOMAIN_HIERARCHY select GENERIC_IRQ_EFFECTIVE_AFF_MASK if SMP +config RISCV_IMSIC + bool + depends on RISCV + select IRQ_DOMAIN_HIERARCHY + select GENERIC_MSI_IRQ + config EXYNOS_IRQ_COMBINER bool "Samsung Exynos IRQ combiner support" if COMPILE_TEST depends on (ARCH_EXYNOS && ARM) || COMPILE_TEST
drivers/irqchip/Makefile +1 -0
@@ -95,6 +95,7 @@ obj-$(CONFIG_QCOM_MPM) += irq-qcom-mpm.o obj-$(CONFIG_CSKY_MPINTC) += irq-csky-mpintc.o obj-$(CONFIG_CSKY_APB_INTC) += irq-csky-apb-intc.o obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o +obj-$(CONFIG_RISCV_IMSIC) += irq-riscv-imsic-state.o irq-riscv-imsic-early.o obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o obj-$(CONFIG_IMX_INTMUX) += irq-imx-intmux.o
drivers/irqchip/irq-riscv-imsic-early.c new file +258 -0
258 lines not on this page · raw message
drivers/irqchip/irq-riscv-imsic-state.c new file +523 -0
523 lines not on this page · raw message
drivers/irqchip/irq-riscv-imsic-state.h new file +66 -0
66 lines not on this page · raw message
include/linux/irqchip/riscv-imsic.h new file +86 -0
86 lines not on this page · raw message
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 8/14 irqchip/riscv-imsic: Add support for platform MSI irqdomain
In reply to Anup PatelThe Linux platform MSI support requires a platform MSI irqdomain so let us add a platform irqchip driver for RISC-V IMSIC which provides a base IRQ domain and platform MSI domain. This driver assumes that the IMSIC state is already initialized by the IMSIC early driver.
--- drivers/irqchip/Makefile | 2 +- drivers/irqchip/irq-riscv-imsic-platform.c | 280 +++++++++++++++++++++ 2 files changed, 281 insertions(+), 1 deletion(-) create mode 100644 drivers/irqchip/irq-riscv-imsic-platform.c
drivers/irqchip/Makefile +1 -1
@@ -95,7 +95,7 @@ obj-$(CONFIG_QCOM_MPM) += irq-qcom-mpm.o obj-$(CONFIG_CSKY_MPINTC) += irq-csky-mpintc.o obj-$(CONFIG_CSKY_APB_INTC) += irq-csky-apb-intc.o obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o -obj-$(CONFIG_RISCV_IMSIC) += irq-riscv-imsic-state.o irq-riscv-imsic-early.o +obj-$(CONFIG_RISCV_IMSIC) += irq-riscv-imsic-state.o irq-riscv-imsic-early.o irq-riscv-imsic-platform.o obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o obj-$(CONFIG_IMX_INTMUX) += irq-imx-intmux.o
drivers/irqchip/irq-riscv-imsic-platform.c new file +280 -0
280 lines not on this page · raw message
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 9/14 irqchip/riscv-imsic: Add support for PCI MSI irqdomain
In reply to Anup PatelThe Linux PCI framework requires it's own dedicated MSI irqdomain so let us create PCI MSI irqdomain as child of the IMSIC base irqdomain.
--- drivers/irqchip/Kconfig | 7 ++++ drivers/irqchip/irq-riscv-imsic-platform.c | 48 ++++++++++++++++++++++ drivers/irqchip/irq-riscv-imsic-state.h | 1 + 3 files changed, 56 insertions(+)
drivers/irqchip/Kconfig +7 -0
@@ -550,6 +550,13 @@ config RISCV_IMSIC select IRQ_DOMAIN_HIERARCHY select GENERIC_MSI_IRQ +config RISCV_IMSIC_PCI + bool + depends on RISCV_IMSIC + depends on PCI + depends on PCI_MSI + default RISCV_IMSIC + config EXYNOS_IRQ_COMBINER bool "Samsung Exynos IRQ combiner support" if COMPILE_TEST depends on (ARCH_EXYNOS && ARM) || COMPILE_TEST
drivers/irqchip/irq-riscv-imsic-platform.c +48 -0
72 lines not on this page · raw message
drivers/irqchip/irq-riscv-imsic-state.h +1 -0
@@ -31,6 +31,7 @@ struct imsic_priv {/* IRQ domains (created by platform driver) */ struct irq_domain *base_domain; +struct irq_domain *pci_domain;struct irq_domain *plat_domain; };
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 10/14 dt-bindings: interrupt-controller: Add RISC-V advanced PLIC
In reply to Anup PatelWe add DT bindings document for RISC-V advanced platform level interrupt controller (APLIC) defined by the RISC-V advanced interrupt architecture (AIA) specification.
--- .../interrupt-controller/riscv,aplic.yaml | 172 ++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml
Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml new file +172 -0
@@ -0,0 +1,172 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/riscv,aplic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RISC-V Advanced Platform Level Interrupt Controller (APLIC) + +maintainers: + - Anup Patel <[email protected]> + +description: + The RISC-V advanced interrupt architecture (AIA) defines an advanced + platform level interrupt controller (APLIC) for handling wired interrupts + in a RISC-V platform. The RISC-V AIA specification can be found at + https://github.com/riscv/riscv-aia. + + The RISC-V APLIC is implemented as hierarchical APLIC domains where all + interrupt sources connect to the root APLIC domain and a parent APLIC + domain can delegate interrupt sources to it's child APLIC domains. There + is one device tree node for each APLIC domain. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - enum: + - qemu,aplic + - const: riscv,aplic + + reg: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts-extended: + minItems: 1 + maxItems: 16384 + description: + Given APLIC domain directly injects external interrupts to a set of + RISC-V HARTS (or CPUs). Each node pointed to should be a riscv,cpu-intc + node, which has a CPU node (i.e. RISC-V HART) as parent. + + msi-parent: + description: + Given APLIC domain forwards wired interrupts as MSIs to a AIA incoming + message signaled interrupt controller (IMSIC). If both "msi-parent" and + "interrupts-extended" properties are present then it means the APLIC + domain supports both MSI mode and Direct mode in HW. In this case, the + APLIC driver has to choose between MSI mode or Direct mode. + + riscv,num-sources: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 1023 + description: + Specifies the number of wired interrupt sources supported by this + APLIC domain. + + riscv,children: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 1024 + items: + maxItems: 1 + description: + A list of child APLIC domains for the given APLIC domain. Each child + APLIC domain is assigned a child index in increasing order, with the + first child APLIC domain assigned child index 0. The APLIC domain child + index is used by firmware to delegate interrupts from the given APLIC + domain to a particular child APLIC domain. + + riscv,delegation: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 1024 + items: + items: + - description: child APLIC domain phandle + - description: first interrupt number of the parent APLIC domain (inclusive) + - description: last interrupt number of the parent APLIC domain (inclusive) + description: + A interrupt delegation list where each entry is a triple consisting + of child APLIC domain phandle, first interrupt number of the parent + APLIC domain, and last interrupt number of the parent APLIC domain. + Firmware must configure interrupt delegation registers based on + interrupt delegation list. + +dependencies: + riscv,delegation: [ "riscv,children" ] + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + - riscv,num-sources + +anyOf: + - required: + - interrupts-extended + - required: + - msi-parent + +unevaluatedProperties: false + +examples: + - | + // Example 1 (APLIC domains directly injecting interrupt to HARTs): + + interrupt-controller@c000000 { + compatible = "qemu,aplic", "riscv,aplic"; + interrupts-extended = <&cpu1_intc 11>, + <&cpu2_intc 11>, + <&cpu3_intc 11>, + <&cpu4_intc 11>; + reg = <0xc000000 0x4080>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + riscv,children = <&aplic1>, <&aplic2>; + riscv,delegation = <&aplic1 1 63>; + }; + + aplic1: interrupt-controller@d000000 { + compatible = "qemu,aplic", "riscv,aplic"; + interrupts-extended = <&cpu1_intc 9>, + <&cpu2_intc 9>; + reg = <0xd000000 0x4080>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + }; + + aplic2: interrupt-controller@e000000 { + compatible = "qemu,aplic", "riscv,aplic"; + interrupts-extended = <&cpu3_intc 9>, + <&cpu4_intc 9>; + reg = <0xe000000 0x4080>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + }; + + - | + // Example 2 (APLIC domains forwarding interrupts as MSIs): + + interrupt-controller@c000000 { + compatible = "qemu,aplic", "riscv,aplic"; + msi-parent = <&imsic_mlevel>; + reg = <0xc000000 0x4000>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + riscv,children = <&aplic3>; + riscv,delegation = <&aplic3 1 63>; + }; + + aplic3: interrupt-controller@d000000 { + compatible = "qemu,aplic", "riscv,aplic"; + msi-parent = <&imsic_slevel>; + reg = <0xd000000 0x4000>; + interrupt-controller; + #interrupt-cells = <2>; + riscv,num-sources = <63>; + }; +...
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 11/14 irqchip: Add RISC-V advanced PLIC driver for direct-mode
In reply to Anup PatelThe RISC-V advanced interrupt architecture (AIA) specification defines advanced platform-level interrupt controller (APLIC) which has two modes of operation: 1) Direct mode and 2) MSI mode.
(For more details, refer https://github.com/riscv/riscv-aia)
In APLIC direct-mode, wired interrupts are forwared to CPUs (or HARTs) as a local external interrupt.
We add a platform irqchip driver for the RISC-V APLIC direct-mode to support RISC-V platforms having only wired interrupts.
--- drivers/irqchip/Kconfig | 5 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-riscv-aplic-direct.c | 326 +++++++++++++++++++++++ drivers/irqchip/irq-riscv-aplic-main.c | 240 +++++++++++++++++ drivers/irqchip/irq-riscv-aplic-main.h | 45 ++++ include/linux/irqchip/riscv-aplic.h | 119 +++++++++ 6 files changed, 736 insertions(+) create mode 100644 drivers/irqchip/irq-riscv-aplic-direct.c create mode 100644 drivers/irqchip/irq-riscv-aplic-main.c create mode 100644 drivers/irqchip/irq-riscv-aplic-main.h create mode 100644 include/linux/irqchip/riscv-aplic.h
drivers/irqchip/Kconfig +5 -0
@@ -544,6 +544,11 @@ config SIFIVE_PLIC select IRQ_DOMAIN_HIERARCHY select GENERIC_IRQ_EFFECTIVE_AFF_MASK if SMP +config RISCV_APLIC + bool + depends on RISCV + select IRQ_DOMAIN_HIERARCHY + config RISCV_IMSIC bool depends on RISCV
drivers/irqchip/Makefile +1 -0
@@ -95,6 +95,7 @@ obj-$(CONFIG_QCOM_MPM) += irq-qcom-mpm.o obj-$(CONFIG_CSKY_MPINTC) += irq-csky-mpintc.o obj-$(CONFIG_CSKY_APB_INTC) += irq-csky-apb-intc.o obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o +obj-$(CONFIG_RISCV_APLIC) += irq-riscv-aplic-main.o irq-riscv-aplic-direct.o obj-$(CONFIG_RISCV_IMSIC) += irq-riscv-imsic-state.o irq-riscv-imsic-early.o irq-riscv-imsic-platform.o obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
drivers/irqchip/irq-riscv-aplic-direct.c new file +326 -0
326 lines not on this page · raw message
drivers/irqchip/irq-riscv-aplic-main.c new file +240 -0
240 lines not on this page · raw message
drivers/irqchip/irq-riscv-aplic-main.h new file +45 -0
45 lines not on this page · raw message
include/linux/irqchip/riscv-aplic.h new file +119 -0
119 lines not on this page · raw message
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 12/14 irqchip/riscv-aplic: Add support for MSI-mode
In reply to Anup PatelThe RISC-V advanced platform-level interrupt controller (APLIC) has two modes of operation: 1) Direct mode and 2) MSI mode. (For more details, refer https://github.com/riscv/riscv-aia)
In APLIC MSI-mode, wired interrupts are forwared as message signaled interrupts (MSIs) to CPUs via IMSIC.
We extend the existing APLIC irqchip driver to support MSI-mode for RISC-V platforms having both wired interrupts and MSIs.
--- drivers/irqchip/Kconfig | 6 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-riscv-aplic-main.c | 2 +- drivers/irqchip/irq-riscv-aplic-main.h | 8 + drivers/irqchip/irq-riscv-aplic-msi.c | 285 +++++++++++++++++++++++++ 5 files changed, 301 insertions(+), 1 deletion(-) create mode 100644 drivers/irqchip/irq-riscv-aplic-msi.c
drivers/irqchip/Kconfig +6 -0
@@ -549,6 +549,12 @@ config RISCV_APLIC depends on RISCV select IRQ_DOMAIN_HIERARCHY +config RISCV_APLIC_MSI + bool + depends on RISCV_APLIC + select GENERIC_MSI_IRQ + default RISCV_APLIC + config RISCV_IMSIC bool depends on RISCV
drivers/irqchip/Makefile +1 -0
@@ -96,6 +96,7 @@ obj-$(CONFIG_CSKY_MPINTC) += irq-csky-mpintc.o obj-$(CONFIG_CSKY_APB_INTC) += irq-csky-apb-intc.o obj-$(CONFIG_RISCV_INTC) += irq-riscv-intc.o obj-$(CONFIG_RISCV_APLIC) += irq-riscv-aplic-main.o irq-riscv-aplic-direct.o +obj-$(CONFIG_RISCV_APLIC_MSI) += irq-riscv-aplic-msi.o obj-$(CONFIG_RISCV_IMSIC) += irq-riscv-imsic-state.o irq-riscv-imsic-early.o irq-riscv-imsic-platform.o obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
drivers/irqchip/irq-riscv-aplic-main.c +1 -1
@@ -203,7 +203,7 @@ static int aplic_probe(struct platform_device *pdev)* otherwise setup APLIC direct mode. */ if (fwnode_property_present (dev->fwnode,"msi-parent" )) - rc = -ENODEV ; + rc =aplic_msi_setup (dev, regs);else rc =aplic_direct_setup (dev, regs);if (rc) {
drivers/irqchip/irq-riscv-aplic-main.h +8 -0
@@ -41,5 +41,13 @@ void aplic_init_hw_global(struct aplic_priv *priv, bool msi_mode);int aplic_setup_priv (struct aplic_priv *priv,struct device *dev,void __iomem *regs);int aplic_direct_setup (struct device *dev,void __iomem *regs); +#ifdef CONFIG_RISCV_APLIC_MSI +int aplic_msi_setup (struct device *dev,void __iomem *regs); +#else +static inline int aplic_msi_setup (struct device *dev,void __iomem *regs) +{ +return -ENODEV ; +} +#endif #endif
drivers/irqchip/irq-riscv-aplic-msi.c new file +285 -0
285 lines not on this page · raw message
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 13/14 RISC-V: Select APLIC and IMSIC drivers
In reply to Anup PatelThe QEMU virt machine supports AIA emulation and we also have quite a few RISC-V platforms with AIA support under development so let us select APLIC and IMSIC drivers for all RISC-V platforms.
--- arch/riscv/Kconfig | 2 ++ 1 file changed, 2 insertions(+)
arch/riscv/Kconfig +2 -0
@@ -148,6 +148,8 @@ config RISCV select PCI_DOMAINS_GENERIC if PCI select PCI_MSI if PCI select RISCV_ALTERNATIVE if !XIP_KERNEL + select RISCV_APLIC + select RISCV_IMSIC select RISCV_INTC select RISCV_TIMER if RISCV_SBI select SIFIVE_PLIC
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv
PATCH v6 14/14 MAINTAINERS: Add entry for RISC-V AIA drivers
In reply to Anup PatelAdd myself as maintainer for RISC-V AIA drivers including the RISC-V INTC driver which supports both AIA and non-AIA platforms.
--- MAINTAINERS | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
MAINTAINERS +14 -0
@@ -18256,6 +18256,20 @@ S: Maintained F: drivers/mtd/nand/raw/r852.c F: drivers/mtd/nand/raw/r852.h +RISC-V AIA DRIVERS +M: Anup Patel <[email protected]> +L: [email protected] +S: Maintained +F: Documentation/devicetree/bindings/interrupt-controller/riscv,aplic.yaml +F: Documentation/devicetree/bindings/interrupt-controller/riscv,imsics.yaml +F: drivers/irqchip/irq-riscv-aplic-*.c +F: drivers/irqchip/irq-riscv-aplic-*.h +F: drivers/irqchip/irq-riscv-imsic-*.c +F: drivers/irqchip/irq-riscv-imsic-*.h +F: drivers/irqchip/irq-riscv-intc.c +F: include/linux/irqchip/riscv-aplic.h +F: include/linux/irqchip/riscv-imsic.h + RISC-V ARCHITECTURE M: Paul Walmsley <[email protected]> M: Palmer Dabbelt <[email protected]>
Signature · 7 lines
2.34.1 _______________________________________________ linux-riscv mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-riscv