<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Till Straumann wrote:
<blockquote cite="mid:482B04F3.4090000@slac.stanford.edu" type="cite">
  <pre wrap="">Sebastian Huber wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi,
I adapted the shared exception and interrupt 
(libcpu/powerpc/new-exceptions/*) code to work with the e200z6 and this 
lead to some comments.

The current code implicitly defines BSP_SHARED_HANDLER_SUPPORT. I 
modified it to support this preprocessor directive. Where is the right 
place to define it?
  
    </pre>
  </blockquote>
</blockquote>
<br>
<blockquote cite="mid:482B04F3.4090000@slac.stanford.edu" type="cite">
  <pre wrap=""><!----><snip> Implementing
shared interrupts (more than 1 handler per IRQ) should be
mandatory. </pre>
</blockquote>
<br>
I'll drink to that idea !<br>
<br>
I've got an application here at the CLS (pc386 BSP, rtems 4.7.1) that
uses 5 PCI cards: one NIC and 4 VME-PCI bridge devices. I hacked the
VME-PCI driver to allow IRQ sharing, but the catch is that the PCI
devices have to be in a specific physical ordering in the PC such that
the devices sharing an IRQ are of the same "species" (i.e. both must be
VME-PCI bridge devices).<br>
<br>
...I did say it was a hack...<br>
<blockquote cite="mid:482B04F3.4090000@slac.stanford.edu" type="cite">
  <pre wrap="">It doesn't consume a lot of resources; especially
if not used (the 'install' routine could be split into a separate
file so that it is not linked if unused).

The current situation is ugly -- if you don't include the file
where BSP_SHARED_HANDLER_SUPPORT is defined prior to
including rtems/irq.h then you don't get the correct declarations
IIRC.
  </pre>
  <blockquote type="cite">
    <pre wrap="">Currently the shared interrupt handler support works like a stack. You 
can push and pop a handler. But in BSP_remove_rtems_irq_handler is also 
code that removes the handler from a list. What was intended?
  
    </pre>
  </blockquote>
</blockquote>
<br>
<blockquote cite="mid:482B04F3.4090000@slac.stanford.edu" type="cite">
  <pre wrap=""><!----><snip> BSP_install_rtems_shared_irq_handler
adds a handler at the head of the list of handlers,
BSP_remove_rtems_irq_handler extracts a handler from the list.
  </pre>
</blockquote>
<br>
This sounds like a prime opportunity for sharing/unifying code across
the PIC-vectored interrupt-handling API... at least between elements of
the PPC and x86 BSPs.<br>
<br>
<blockquote cite="mid:482B04F3.4090000@slac.stanford.edu" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">The interrupt support code only ensures that interrupts are disabled 
during critical sections. May it be useful to add a mutex to support 
usage in multiple threads?
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->No. Protecting a critical section by disabling interrupts is
already thread-safe (and used in many places in RTEMS).
It might also be quicker/cheaper if it protects short sections
of code.

That said - I realize that interrupts were disabled across
malloc and free which is bad. I just fixed this.
  </pre>
  <blockquote type="cite">
    <pre wrap="">The BSP interrupt routines are declared in cpukit/include/rtems/irq.h 
but don't follow the RTEMS naming conventions. A RTEMS interface for 
interrupts would be nice?
  
    </pre>
  </blockquote>
</blockquote>
<br>
<blockquote cite="mid:482B04F3.4090000@slac.stanford.edu" type="cite">
  <pre wrap=""><!---->Oh yes - and a less clumsy one. The existing rtems_interrupt_catch
would be great *if* it supported a user argument to the isr...
  </pre>
</blockquote>
<br>
That's a wonderful suggestion too...<br>
<blockquote cite="mid:482B04F3.4090000@slac.stanford.edu" type="cite">
  <blockquote type="cite">
    <pre wrap="">I found no place where the entry isOn from rtems_irq_connect_data is 
used. We may remove it.
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->Unfortunately, this would break all existing applications which
use the current API. This is IMO not a good idea.

It would be better to come up with a new API, deprecate the old
one and phase it out eventually.
  </pre>
  <blockquote type="cite">
    <pre wrap="">The MPC5566 evaluation board has only 128kB internal RAM. Due to the 328 
interrupt sources the interrupt handler table is quite big: 7896 Bytes 
(6% of internal RAM). The exception handler table is also not very small 
with 896 Bytes (0.7% of internal RAM). Thus I want to introduce two new 
defines BSP_CONFIG_CONSTANT_EXCEPTION_TABLE and 
BSP_CONFIG_CONSTANT_INTERRUPT_TABLE and modify the code to support 
constant tables.
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->This defeats the whole 'new-exceptions' API which provides
methods to change raw exception handlers. Just playing
devil's advocate...

And how can a BSP with a constant interrupt table support
applications which use the calls to install/remove interrupt
handlers? You'd rather have to think of an alternative implementation
of the current API -- since probably most of the 328 sources
are unused e.g., a (smaller) hash table could be used and
the real 'rtems_irq_connect_data' structs be allocated only on demand.

In any case: prior to modifying code I suggest you make
proposals as to how the API must be changed and what
implementation you propose. Any implementation should
be generically useful rather than #ifdef dependent...

Cheers
-- Till
  </pre>
  <blockquote type="cite">
    <pre wrap="">Regards,
    Sebastian

--------------------------------------------
embedded brains GmbH
Sebastian Huber           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-6
Fax  : +49-89-18 90 80 79-9
email: <a class="moz-txt-link-abbreviated" href="mailto:Sebastian.Huber@embedded-brains.de">Sebastian.Huber@embedded-brains.de</a>
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
rtems-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>
<a class="moz-txt-link-freetext" href="http://rtems.rtems.org/mailman/listinfo/rtems-users">http://rtems.rtems.org/mailman/listinfo/rtems-users</a>
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
_______________________________________________
rtems-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>
<a class="moz-txt-link-freetext" href="http://rtems.rtems.org/mailman/listinfo/rtems-users">http://rtems.rtems.org/mailman/listinfo/rtems-users</a>
  </pre>
</blockquote>
<br>
</body>
</html>