Hi Gražvydas
On Tue, 31 Jan 2012, Grazvydas Ignotas wrote:
> On Tue, Jan 31, 2012 at 1:34 AM, Paul Walmsley <paul@xxxxxxxxx> wrote:
>
> > So apparently, looking at these references, the following registers should
> > be configured:
> >
> > 1. at least one of GPIO_LEVELDETECT{0,1} or GPIO_{RISING,FALLING}DETECT
> >
> > 2. GPIO_WAKEUPENABLE
> >
> > 3. GPIO_IRQENABLE1
>
> According to some /dev/mem hacking, all these have corresponding bits
> set.. And as soon as I clear corresponding bit in GPIO_DEBOUNCENABLE
> (using the same /dev/mem hacking method), it starts working. When it's
> set, even GPIO_DATAIN isn't updating in realtime.
Hmm so I may have misunderstood the problem...
If the DEBOUNCENABLE bit is set and the debounce clock is off and the GPIO
IP block is idle, then yeah, I'd assume that GPIO wakeups would not
work.
But it sounds like they are working for you when DEBOUNCENABLE is set and
the debounce clock is on and the GPIO IP block is idle and CORE & PER are
ON?
And when DEBOUNCENABLE is clear and the debounce clock is off and the GPIO
IP block is idle and CORE & PER are still ON, then they work?
If the answer to those two latter questions are true, then it sounds like
the hardware is working more or less as expected...
Of course our software support probably still isn't right. We probably
should keep the debounce clock enabled as long as some GPIO has debounce
support enabled. And probably provide some way for GPIO users to indicate
whether they are okay with debounce support being disabled when the
rest of the CORE/PER can enter a low-power state. The motivating
principle being that PM shouldn't violate a requirement from the rest of
the system...
Anyway, just thinking out loud.
- Paul
