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.
