> On Tue, 2023-03-14 at 13:37 +0100, Sebastian Huber wrote: > > On 14.03.23 13:31, padmarao.beg...@microchip.com wrote: > > Hi Sebastian, > > > > > On Mon, 2023-03-06 at 14:11 +0100, Sebastian Huber wrote: > > > > > > > > > On 06.03.23 13:00,padmarao.beg...@microchip.com wrote: > > > > > On Mon, 2023-03-06 at 11:19 +0100, Sebastian Huber wrote: > > > > > > > > > > On 06.03.23 10:24,padmarao.beg...@microchip.com wrote: > > > > > > Hi Sebastian, > > > > > > > > > > > > > On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote: > > > > > > > > > > > > > > On 06.03.23 09:37,padmarao.beg...@microchip.com wrote: > > > > > > > > > Is > > > > > > > > > the claim complete message ignored if the interrupt > > > > > > > > > is > > > > > > > > > disabled? > > > > > > > > > > > > > > > > > Yes. > > > > > > > Is this an intended and documented behaviour of the PLIC? > > > > > > Not documented > > > > > Is this a common PLIC behaviour or just the case for the > > > > > MicroChip > > > > > implementation? > > > > > > > > > It's a common PLIC behaviour. > > > It is not implemented in the Qemu PLIC emulation: > > > > > > https://github.com/qemu/qemu/blob/master/hw/intc/sifive_plic.c#L242 > > > > > > Where do I see this behaviour in a PLIC implementation, for > > > example: > > > > > > https://github.com/lowRISC/opentitan/tree/master/hw/ip_templates/rv_plic > > > > > > That the interrupt completion depends on the interrupt > > > enable/disable > > > status is quite unusual. > > > > > https://github.com/riscv/riscv-plic-spec/blob/master/riscv-plic.adoc#8-interrupt-completion > > The interrupt is completed only when the interrupt is enabled but > > not > > when disabled. > > > > Can we clear the interrupt before calling the interrupt handler? > > like > > below > > https://github.com/RTEMS/rtems/blob/master/bsps/riscv/riscv/irq/irq.c#L90 > > > > while ((interrupt_index = plic_hart_regs->claim_complete) != > > 0) { > > + plic_hart_regs->claim_complete = interrupt_index; > > bsp_interrupt_handler_dispatch( > > RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index) > > ); > > > > - plic_hart_regs->claim_complete = interrupt_index; > > > > Also refer > > https://github.com/psherman42/Demonstrating-MTVEC/blob/main/start.s#L307 > > At some point I would like to enable support for nested interrupts. I > guess in this case it is important that you complete the interrupt > after > processing. > The Exception(trap) handler is called when an interrupt occurs and the global interrupt(mie) is disabled automatically at the top-most level–the MIE bit in mstatus and re-enabled after return from machine interrupt instruction "mret".
I think, we will not get any other interrupt while servicing the interrupt handler, we can use the interrupt complete before processing. Regards Padmarao > Ideally, we would return a status in the interrupt handlers to > support > things like the PLIC, however, this would be an API change affecting > all > existing interrupt handlers. This is not an option from my side. > > I would add new BSP interrupt controller methods specifically for the > interrupt server. By default, they do nothing. For the PLIC they do > the > enable and complete once the server task did process the interrupt. > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas > Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel