linux kernel: what imx6-specific code is called with gpio_set_value()?

cancel
Showing results for 
Search instead for 
Did you mean: 

linux kernel: what imx6-specific code is called with gpio_set_value()?

123 Views
Senior Contributor II

I am debugging an issue on an imx6dl based system running a relatively old kernel/uboot.  I have a device tied to ecspi5 that works as expected, but I just noticed that the first access to this device corrupts a few -other- bits in a GPIO data register.  In the process of debugging this, I see that spi_imx_chipselect() (in {KERNEL}/devices/spi/spi-imx.c) calls gpio_set_value() and it appears that it is this call that mucks up a few other bits in GPIO1_DR.

I'm not really sure if my problem is in my device tree or possibly just an issue with my kernel.

So, right now I'm just trying to figure out what device-specific code is actually called below gpio_set_value() that actually sets the chipselect bit used with SPI.  I'm hoping to find a problem there (but not sure)...

Any thoughts?

Ed

PS... If there are any good documents on device tree and IMX6 specifics, I could use a pointer to that as well.

Labels (2)
Tags (2)
0 Kudos
1 Reply

1 View
Senior Contributor II

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?

0 Kudos