This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RM7000 interrupt handling



> From: Robin Farine <acnrf@dial.eunet.ch>
> Mark Salter <msalter@redhat.com> writes:
> 
> [...]
> 
> > I think the bug would be an ISR that changes the status register.
> > 
> > There is no atomic way of disabling interrupts on the MIPS architecture.
> > You have to read the status register, modify it, then write it back.
> 
> If I remember well, the restrictions below avoid such problems:
> 
> 1. the startup code presets the per-source interrupt bits and they never change
>    after that; code should use the devices internal interrupt controllers to
>    enable/disable interrupt sources.
> 
> 2. the interrupt VSR and ISRs use the master interrupt bit only => no nested
>    interrupts
> 
> 3. the rest of the code can safely disable and restore interrupts using the
>    master interrupt bit only;

You remember well, I think.

Yes, those conditions would fix the situation - I think that (1.) and (3.)
alone (ie. VSRs and ISRs don't diddle the interrupt bit at all) would be
OK, ISRs must use only the method in (1.)
 
> What do you think, too much restrictive for eCos?

Sadly I do think that; we want HAL_MASK_INTERRUPTS() et al to work!  Having
them be a NOP for the low range of interrupt numbers would be, um, awkward?

We don't want the HAL to have to know about the Ethernet hardware details,
for example, if you're not including the ethernet package; but it would
need to know about the ether control regs to mask its interrupt outside of
the status register.

I'll continue having a think about this and see what we come up with.

	- Huge


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]