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



Chris Morrow <cmorrow@YottaYotta.com> writes:
> On the RM7000, the info register contains a bit which allows for the
> atomic enabling and disabling of interrupts. HAL_MASK_INTERRUPTS()
> can be made to work using this. I'm not familiar enough with
> other mips platforms to know how widely this kind of thing is
> implemented.
> 
> On what may be a related subject, I've never understood the reason
> for cyg_drv_interrupt_mask. Every eCos port seems to just map this
> to cyg_interrupt_mask.

Yes, they all do - /if/ there is a kernel present, you only have
cyg_interrupt_mask() from the KAPI if you have the kernel.  If not it
simply does HAL_INTERRUPT_MASK( vector ), which will mask the interrupt on
that vector number.

>  Was the orignal intent to mask off interrupts at the device instead of
> the CPU?

Nope.

It's to allow the same device driver code (hence _drv_ in the names) to
work with and without a kernel.  The kernel might do different and clever
things when masking an interrupt, depending on the interrupt decoding or
chaining or sharing or whatever scheme is in place.  So if there is a
kernel, there is benefit in calling it.

To be honest, in most cases, just calling HAL_INTERRUPT_MASK( vector ) thus
going directly into the HAL layer would work perfectly well, without all
those function calls through the KAPI and so on.  But that breaks all the
lovely abstraction layers ;-/ and it's not an API that we promise to
support for application code, hence the provision of the other APIs.

HTH,
	- Huge


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