The issue that I was seeing was that my SPI chipselect was corrupting the GPIO_DR register that the bit was part of.
The problem was that I had written a GPIO device driver that just uses ioremap() and the physical addresses of the GPIO control registers. Apparently this isn't really the way to do it; because what I found was that linux was booting up and apparently reading the GPIO_DR at startup, then my driver would modify a few of the bits, then later the SPI driver used its shadow copy of the GPIO_DR instead of actually reading the GPIO_DR prior to writing to it.
As a result, the settings that I had put in place with my driver were lost.
Then I tried just using /sys/class/gpio to do my GPIO setup and then the SPI access didn't do any damage because apparently /sys/class/gpio uses the same gpio hooks as SPI, so the shadow copy of GPIO_DR was properly updated.
My guess is that linux does an initial read of GPIO_DR and from then on, since it is an output register, it assumes that it knows the content of GPIO_DR based on its shadow copy. This saves a read before the write, but seems kinda dangerous none-the-less. Can anyone confirm that this is a valid conclusion?
