Some basic observations and they are confirmed correct after much toil and 
board spamming. :P

Simple to describe:
If I set bits 30 and 38, an endless stream of GPIO interrupts occurrs that I 
can't shut down by acknowledging any known bits. It makes absolutely no 
difference if any of the known GPIO ports has IRQs enabled. Is there some other 
GPIO port somewhere that's unmasked? Where?

Simple to describe:
If I set bit 30 alone, nothing. No GPIO IRQs occur at all or are pollable.

Very involved to describe:
If I set bit 38 alone, I can poll its status on timer interrupts but it's 
setting isn't reliable so can't be read reliably to check the GPIO ports. A few 
dozen to hundreds of timer tick interrupts will occur and the bit will be set 
in the status register and then disappear so long as I keep reenabling bit 38. 
If I don't keep resetting the bit, it's sort of a one shot with random firings 
here and there. Pushing a button or moving the scrollwheel runs it through the 
cycle again (with the port IRQs unmasked of course) but it's always read when 
the timer has fired. No matter about having the GPIOx_INT_EN set here but of 
course the button push won't cycle it again if they aren't so it's just once on 
the splash screen.

The OF sets bits 30 and 38 simultaneously and obviously has no flood 
difficulties...what's it doing? Is it checking anything when status bit 38 gets 
set besides GPIOx_INT_STAT?

The driver I made it seems is really just polling the GPIO IRQ status on timer 
interrupts and not truly receiving GPIO IRQs. I'm suprised it crips up the 
action so much.

Reply via email to