It seems you set CPU_INT_EN = 0xc000000 and CPU_HI_INT_EN = 0x40. GPIOH_INT_EN = 0xc0 ... and I'm checking positive on GPIOH_INT_STAT & 0xc0 !!! It's dyning out cause I'm not doing everything right and the interrupt handler is just setup to shut off the scrollwheel light when it gets a wheel interrupt. Well, the light shuts off when I turn the wheel. :D

----- Original Message -----
  From: Antonius Hellmann
  To: Michael Sevakis ; Rockbox development
  Sent: Tuesday, May 08, 2007 3:19 PM
  Subject: Re: Sansa (PP502x?) GPIO interrupts in rockbox software

  Yes, the CPU/COP_INT_EN are write only to my understanding. The results of these operations can be evaluated in the CPU/COP_INT_EN_STAT. I have no idea, why on the PP5020 this doesn't work. What I also don't understand is, that beside CPU-/COP-registers there is a third group of unnamed registers (INT_STAT etc).
  Did you recognize, that there are at least three (may be more) different assembler instructions to set some
  groups in the cpsr data? Also interesting fact in the original sansa code is, that they sometimes stack the spsr register in the interrupt context, probably allowing interrupts in interrupt contexts.

  Yes, I did the same dump for the cpu interrupts, which did not show any anomalies.
  And yes, CPSRs have to be completely independent between COP and CPU, otherwise .... garbage.

  The keys definitely change the HI_INT_STAT bit6. So if someone wants to implement key/scrollwheel interrupt handling, the bit6 in the CPU-/COP_HI_INT_EN register should do it.

  ----- Original Message -----
    From: Michael Sevakis
    To: Rockbox development
    Sent: Tuesday, May 08, 2007 6:57 PM
    Subject: Re: Sansa (PP502x?) GPIO interrupts in rockbox software

    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-09