This is the mail archive of the ecos-bugs@sourceware.org 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]
Other format: [Raw text]

[Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:wasted processing power


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456

Bernd Edlinger <bernd.edlinger@hotmail.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger@hotmail.de

--- Comment #28 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-09-27 13:38:45 BST ---
Hi Bernard,

just one thing...

personally I would not like to add more Kernel APIs unless it is absolutely
necessary.

In the hal/arm subtree when there is an interrupt, the function
hal_IRQ_handler() gets called first. This function determines the
highest priority irq, and updates the ISR (in service register),
this would be a place to clear the interrupt pending bit for your architecture.

Suppose the clear pending is done automatically in hal_IRQ_handler()
and hal_interrupt_acknowledge is empty, then this would be a safe way
to write the isr/dsr in the driver:

isr()
{
  HAL_INTERRUPT_MASK(vector);
  HAL_INTERRUPT_ACKNOWLEGE();
  return CALL_DSR;
}


dsr()
{
   now handle interrupt...

   HAL_INTERRUPT_UNMASK(vector);
}

this is in fact how most drivers are already written today.

would'nt that be OK for you too?

Regards,
Bernd Edlinger

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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