From: Michael Sevakis <jethead71_at_sbcglobal.net>
Date: Thu, 10 May 2007 17:24:36 -0400

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.
Received on 2007-05-10