Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
On 14.03.23 14:37, padmarao.beg...@microchip.com wrote:
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.comwrote:
Hi Sebastian,
On Mon, 2023-03-06 at 09:41 +0100, Sebastian Huber wrote:
On 06.03.23 09:37,padmarao.beg...@microchip.comwrote:
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.
Currently yes, however, if we support nested interrupts then it would
look like this:
} else if (mcause == (RISCV_INTERRUPT_EXTERNAL_MACHINE << 1)) {
volatile RISCV_PLIC_hart_regs *plic_hart_regs;
uint32_t interrupt_index;
plic_hart_regs = cpu_self->cpu_per_cpu.plic_hart_regs;
while ((interrupt_index = plic_hart_regs->claim_complete) != 0) {
ENABLE MIE
bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
);
DISABLE MIE
plic_hart_regs->claim_complete = interrupt_index;
/*
* FIXME: It is not clear which fence is necessary here or if a
fence is
* necessary at all. The goal is that the complete signal is somehow
* recognized by the PLIC before the next claim is issued.
*/
__asm__ volatile ("fence o, i" : : : "memory");
}
The PLIC/CLINT combination is not really well suited for systems which
want to use interrupt priorities since the software and timer interrupts
bypass the PLIC interrupt priority handling. I don't know why hardware
developers can't stick with the best existing solutions instead of
reinventing the next second best solution.
--
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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
> 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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.
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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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
Regards
Padmarao
> --
> 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
> 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. > I will look into above links, mean while you can check the implemention of external interrupt service in the PolarFire SoC with same the siFive PLIC core. https://github.com/polarfire-soc/hart-software-services/blob/master/baremetal/polarfire-soc-bare-metal-library/src/platform/mpfs_hal/common/mss_mtrap.c#L623 Regards Padmarao > -- > 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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. -- 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
> 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. Regards Padmarao > > > This is a > > > hardware bug from my point of view. If we really need a software > > > workround just for the PLIC to work with the interrupt server, > > > then > > > we > > > should add a new function for this and keep the interrupt disable > > > as > > > is. > > > > Ok > > You could for example add a bsp_interrupt_vector_server_disable() > which > defaults to bsp_interrupt_vector_disable(). > > -- > 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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? This is a hardware bug from my point of view. If we really need a software workround just for the PLIC to work with the interrupt server, then we should add a new function for this and keep the interrupt disable as is. Ok You could for example add a bsp_interrupt_vector_server_disable() which defaults to bsp_interrupt_vector_disable(). -- 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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 > This is a > hardware bug from my point of view. If we really need a software > workround just for the PLIC to work with the interrupt server, then > we > should add a new function for this and keep the interrupt disable as > is. Ok Regards Padmarao > > -- > 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
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? This is a hardware bug from my point of view. If we really need a software workround just for the PLIC to work with the interrupt server, then we should add a new function for this and keep the interrupt disable as is. -- 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
Hi Sebastian,
> On Mon, 2023-03-06 at 08:01 +0100, Sebastian Huber wrote:
>
> Hello Padmarao,
>
> On 03.03.23 15:55, padmarao.beg...@microchip.com wrote:
> > > On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote:
> > >
> > >
> > > On 27.02.23 16:51, Padmarao Begari wrote:
> > > > The interrupt complete should clear with the interrupt
> > > > number before disabling the interrupt in the PLIC to
> > > > get the next interrupt.
> > > Which problem does this patch address?
> > >
> > The problem occurs when the interrupt register(enabled) in the
> > RTEMS-
> > LIBBSD drivers and want to serve the interrupt subroutine in the
> > RTEMS.
> >
> > Example : CGEM driver
> >
> > When the application running to test the CGEM driver with RTEMS +
> > RTEMS-LIBBSD, The interrupt is occurred while transmiting the
> > ethernet
> > pocket, the RTEMS is received the interrupt but not served with the
> > register interrupt subroutine instead it disable the interrupt and
> > set
> > the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is
> > clearing the interrupt complete register but there is no effect and
> > the
> > next transmit pocket intereupt is not occurred because the
> > interrupt is
> > disabled before the interrupt complete clear.
> >
> > RISC-V interrupt stacktrace
> > **
> > _RISCV_Exception_handler()
> > _RISCV_Interrupt_dispatch()
> > bsp_interrupt_handler_dispatch_unchecked()
> > bsp_interrupt_dispatch_entries()
> > ( *entry->handler )( entry->arg ); ->
> > bsp_interrupt_server_trigger()
> > bsp_interrupt_server_trigger()
> > bsp_interrupt_is_valid_vector()
> > bsp_interrupt_vector_disable()
> > rtems_event_system_send()
> > *
>
> The claim complete register is written after the interrupt handler
> dispatch:
>
> while ((interrupt_index = plic_hart_regs->claim_complete) != 0)
> {
>bsp_interrupt_handler_dispatch(
> RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
>);
>
>plic_hart_regs->claim_complete = interrupt_index;
>
> If you write to the claim complete register also in the interrupt
> disable function, then this write is done twice.
>
Yes but no impact on second write.
> The interrupt disable function may be used in other contexts as well
> so
> doing a write to the claim complete register may have unexpected side
> effects.
>
> We should first figure out why the current implementation which works
> with several other interrupt controllers doesn't work with the PLIC.
Current Implemtation is working fine for UART, Timer because the ISR is
installed at the RTEMS source and when the interrupt is occured it is
going to call the ISR and clear the interrupt complete but not disable
the interrupt.
> Is
> the claim complete message ignored if the interrupt is disabled?
>
Yes.
Regards
Padmarao
> --
> 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
Hello Padmarao,
On 03.03.23 15:55, padmarao.beg...@microchip.com wrote:
On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote:
On 27.02.23 16:51, Padmarao Begari wrote:
The interrupt complete should clear with the interrupt
number before disabling the interrupt in the PLIC to
get the next interrupt.
Which problem does this patch address?
The problem occurs when the interrupt register(enabled) in the RTEMS-
LIBBSD drivers and want to serve the interrupt subroutine in the RTEMS.
Example : CGEM driver
When the application running to test the CGEM driver with RTEMS +
RTEMS-LIBBSD, The interrupt is occurred while transmiting the ethernet
pocket, the RTEMS is received the interrupt but not served with the
register interrupt subroutine instead it disable the interrupt and set
the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is
clearing the interrupt complete register but there is no effect and the
next transmit pocket intereupt is not occurred because the interrupt is
disabled before the interrupt complete clear.
RISC-V interrupt stacktrace
**
_RISCV_Exception_handler()
_RISCV_Interrupt_dispatch()
bsp_interrupt_handler_dispatch_unchecked()
bsp_interrupt_dispatch_entries()
( *entry->handler )( entry->arg ); -> bsp_interrupt_server_trigger()
bsp_interrupt_server_trigger()
bsp_interrupt_is_valid_vector()
bsp_interrupt_vector_disable()
rtems_event_system_send()
*
The claim complete register is written after the interrupt handler dispatch:
while ((interrupt_index = plic_hart_regs->claim_complete) != 0) {
bsp_interrupt_handler_dispatch(
RISCV_INTERRUPT_VECTOR_EXTERNAL(interrupt_index)
);
plic_hart_regs->claim_complete = interrupt_index;
If you write to the claim complete register also in the interrupt
disable function, then this write is done twice.
The interrupt disable function may be used in other contexts as well so
doing a write to the claim complete register may have unexpected side
effects.
We should first figure out why the current implementation which works
with several other interrupt controllers doesn't work with the PLIC. Is
the claim complete message ignored if the interrupt is disabled?
--
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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
Hi Sebastian, > On Thu, 2023-03-02 at 15:18 +0100, Sebastian Huber wrote: > > > On 27.02.23 16:51, Padmarao Begari wrote: > > The interrupt complete should clear with the interrupt > > number before disabling the interrupt in the PLIC to > > get the next interrupt. > > Which problem does this patch address? > The problem occurs when the interrupt register(enabled) in the RTEMS- LIBBSD drivers and want to serve the interrupt subroutine in the RTEMS. Example : CGEM driver When the application running to test the CGEM driver with RTEMS + RTEMS-LIBBSD, The interrupt is occurred while transmiting the ethernet pocket, the RTEMS is received the interrupt but not served with the register interrupt subroutine instead it disable the interrupt and set the "RTEMS_EVENT_SYSTEM_SERVER", while completing the ISR it is clearing the interrupt complete register but there is no effect and the next transmit pocket intereupt is not occurred because the interrupt is disabled before the interrupt complete clear. RISC-V interrupt stacktrace ** _RISCV_Exception_handler() _RISCV_Interrupt_dispatch() bsp_interrupt_handler_dispatch_unchecked() bsp_interrupt_dispatch_entries() ( *entry->handler )( entry->arg ); -> bsp_interrupt_server_trigger() bsp_interrupt_server_trigger() bsp_interrupt_is_valid_vector() bsp_interrupt_vector_disable() rtems_event_system_send() * Regards Padmarao -- > 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
Re: [PATCH] bsps/riscv: Clear interrupt complete before disable
On 27.02.23 16:51, Padmarao Begari wrote: The interrupt complete should clear with the interrupt number before disabling the interrupt in the PLIC to get the next interrupt. Which problem does this patch address? -- 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
