I find it likely there's some things that must be worked out about the register operation - especially re: the PP5020. Don't you find it odd that frequency scaling requires CPU/COP_INT_EN |= TIMER1_IRQ and not CPU/COP_INT_EN = TIMER1_IRQ to keep timers running? This is of course only supposed to be relevant to PP5020 but a core patch that doesn't bang cpsr constantly finds that IRQs die out and the cores to not wake again in sleep_cores (this really seems to be the reason).

Is this only COP related?

Keys bang cpsr when posting to the message queues via set_irq_level.

Is cpsr really independent on each core? It would seem there's a tie in somehow.

Hopefully this investigation can also help get dual core working on PP5020. Something sounds relevant.

I also noticed from your last bl/fw transition dump that the *_INT_EN registers are sometimes read then written and not just written. Testing a read on them seems to always read zero but that doesn't mean it has no effect.

Another question is: why do interrupts on the COP even read keys? This is not a good condition at all. That code should absolutely be removed. COP_TIMER1 and CPU_TIMER1 and other core specific handlers should be used.

----- Original Message -----
  From: Antonius Hellmann
  To: Rockbox development
  Sent: Tuesday, May 08, 2007 5:08 AM
  Subject: Sansa (PP502x?) GPIO interrupts in rockbox software

  I evaluated the cop interrupts in the current rockbox software:
  After enabling the interrupts on the cop (resetting bit7 in the corresponding cpsr)
  The TIMER1 interrupts correctly lead to a call to irq().
  But there are two interesting things:
  1. During the measurement period the corresponding COP_INT_STAT does not always show the bit0 set.
  In fact neither COP_INT_STAT nor COP_HI_INT_STAT is set. But the timings of the irq()-calls correspond
  to the TIMER1 interrupts.
  2. Pushing a key or moving the scroll wheel sets the HI_INT_STAT (and only this register) to 0x40.
   
Received on 2007-05-08