<div dir="ltr"><div><div><div>All,<br><br></div>Based on the replies, my question wasn't phrased precisely enough - possibly by underestimating how different our contexts are that we're operating in. Wouldn't be the first time!<br>
<br></div>What I was really asking was: does RTEMS expect from a BSP that interrupts will nest? Or doesn't it matter to the correct functioning of RTEMS? Or is it something more subtle like 'if interrupt set X is active, interrupt set Y must still be able to occur.' <br>
<br>I gather it's (ideally?) the latter, where Y are based on the highest priority level in X. Which is fine for me, that's pretty close to the current state of the beagle code. I was having a hard time allowing X to occur (without infinite recursion) while X was still active. The active irq was probably masked implicitly in other BSPs I looked at.<br>
<br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 1, 2014 at 7:53 PM, Chris Nott <span dir="ltr"><<a href="mailto:chrisn@vl.com.au" target="_blank">chrisn@vl.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Ben,<br>
      <br>
      Just reviewing interrupts now. I'm not sure your question fully
      makes sense. Unlike smaller embedded arms (eg. Cortex-M3), he
      interrupts on Cortex-A8 are two-phase. There is an external (to
      the ARM core) interrupt controller that feeds interrupts to the
      ARM IRQ and FIRQ lines. The ARM process itself actually only has
      those two interrupt signals.<br>
      <br>
      It looks like the code currently handles IRQ and FIRQ serially, so
      any interrupts at each level would be handled serially regardless
      of priority set in the INTC. Presumably what we eventually want to
      do here for both IRQ and FIRQ handlers is, receive the interrupt,
      immediately set the INTC priority to the received interrupt level
      to block lower priority interrupts (including the current
      interrupt), then acknowledge IRQ/FIRQ and dispatch the actual
      interrupt handler at a lower CPU priority so we can nest IRQ/FIRQ
      and handle higher priority interrupts.<br>
      <br>
      I'm not quite familiar with ARM family yet to be sure how this is
      normally accomplished or if there is an existing supported ARM
      with the same interrupt controller structure. TI provide sample
      source including interrupt handler that supports this stuff. It
      might be a good place to start playing with it, the source pretty
      much compiles fine in the RTEMS environment.<span class="HOEnZb"><font color="#888888"><br>
      <br>
      Chris.</font></span><div><div class="h5"><br>
      <br>
      <br>
      On 28/04/2014 4:32 AM, Ben Gras wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>Dear all,<br>
                  <br>
                </div>
                I have a question about managing interrupts in a BSP
                that I have not been able to answer satisfactorily by
                looking at other BSP code, nor looking throught the
                documentation or googling. Or asking on the IRC channel
                :)<br>
                <br>
              </div>
              My question is: are BSPs expected to allow nested
              interrupts? Specifically, must bsp_interrupt_dispatch()
              turn interrupts on before calling
              bsp_interrupt_handler_dispatch for everything else to work
              properly?<br>
              <br>
            </div>
            <div>Some BSPs do this, some don't. In the Beagle BSP I can
              do this by masking the currently active interrupt and then
              enabling them at the CPU level; but enabling all
              interrupts before the hw-specific handler is called won't
              deassert the irq at the peripheral so I'm having trouble
              seeing how that should work.<br>
              <br>
            </div>
            <div>Example: if we are in a timer ISR and loop on polling
              the uptime ticks, do we expect the ticks to be able to
              increase? I'm wondering if any of the remaining failing
              tests are due to this. But also what the best shape of a
              BSP is.</div>
            <div><br>
            </div>
            <div>Thanks!<br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div class=""><pre>_______________________________________________
rtems-devel mailing list
<a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
rtems-devel mailing list<br>
<a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
<br></blockquote></div><br></div>