Sensor Driver Pin Muxing

Hello guys,

I have a pig problem concerning a driver used for communicating with some MEMS components via SPI. The driver was developed for a Gumstix platform with OMAP34… processor running a 3.3 kernel. The driver muxes the pins using “iowrite16” functions. Some sample code can be seen below:

###Mux values sample :
#define SPI_OE_MUX_OFFSET (0x48002A1A - OMAP34XX_PADCONF_START)
#define SPI_CLK_MUX_OFFSET (0x480021C8 - OMAP34XX_PADCONF_START)

As far as I know you have to be in the priviledged mode to change mux value of pins (or you can use PRU to do this) which means
you have to write kernel module like this (https://github.com/chunsj/nxctrl/blob/master/nxpmx/nxpmx.c).

https://github.com/cdsteinkuehler/beaglebone-universal-io

And I believe this is already in the latest 3.8.x kernel demo images.

Could you elaborate on the being privileged part i am new to this and don’t know a lot. As i know the old drivers have been made for the 3.3 kernel and didn’t use device tree overlays. I was thinking that since the function calls are reallly standard (iowirte16 and ioremap etc) that the only changes would be done to the values of pinmuxing themselves. I would just like to know what exactly i would have to change. If you want i can send you the hole code pertaining to the sensors. As far as i can see this SPI driver they made is actually handling the adding of multiple spi devices and writing and reading to them but somewhere they also use a header file from <linux/spi/spi.h> which makes me think that there is another driver that handles the communication itself (timing, sending receiving data etc). Am i wrong in thinking this? Please tell if it is not too much trouble and sorry if this is too nooby :slight_smile:
.

If the only thing you want is using SPI in usermode, then just use Linux SPI driver with proper device tree setting; google enable Beaglebone Black SPI.

But what you want is proper pinmuxing - not limited to SPI device - during runtime, then you have to write some kernel module so that it can write control register in privileged mode; to write on control register for pinmuxing, you have to be in privileged mode, refer technical reference manual or TRM on this.

Reading your message agin, It seems that you already have linux driver code then you don’t have to mind privileged mode thing for you already in it. I’m afraid that I can provide any meaningful help on your driver code, however.