Sensor Driver Pin Muxing

46 views
Skip to first unread message

Cristian Mitu

unread,
Aug 26, 2014, 11:40:59 AM8/26/14
to beagl...@googlegroups.com
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)
.................
######

### Pin mode sample:
#define OE_ENABLE_MUX            0x010C    /* IEN  | PTD | EN  | M4 */
#define SPI_ENABLE_MUX            0x0100    /* IEN  | PTD | DIS | M0 */
######


//  Multiplexing the pins  code sample:
base = ioremap(OMAP34XX_PADCONF_START, OMAP34XX_PADCONF_SIZE);

        if (!base)
            return -ENOMEM;

        old_spi_mux.oe_offset = ioread16(base + SPI_OE_MUX_OFFSET);
        iowrite16(OE_ENABLE_MUX, base + SPI_OE_MUX_OFFSET);
######

Now i understand how the offsets are calculated and  how the I/O memory is beeing used. What i want to know is if i can reuse this code for the BeagleBone Black ( of course i know that i have to modify the mux values and pin modes to match to the BBB). My BBB is running a 3.8 kernel and as i know there is the major change with switching to the Device Tree system.

Also if i use this method will i still need to write a device tree overlay setting the pins up there or is this done directly by using this code ( i feel this is a stupid question seeing as the DT is used specifically for setting up the pins so this code should do that instead but asking just so i know for sure). I thank you in advance for the response.

Sungjin Chun

unread,
Aug 26, 2014, 7:46:33 PM8/26/14
to beagl...@googlegroups.com
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).


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

William Hermans

unread,
Aug 27, 2014, 2:16:11 AM8/27/14
to beagl...@googlegroups.com
And I believe this is already in the latest 3.8.x kernel demo images.

Cristian Mitu

unread,
Aug 31, 2014, 5:22:47 PM8/31/14
to beagl...@googlegroups.com
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 :-)
.


You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/H2-Xgjkgnbc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

Sungjin Chun

unread,
Aug 31, 2014, 7:37:31 PM8/31/14
to beagl...@googlegroups.com
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.

Sent from my iPad
Reply all
Reply to author
Forward
0 new messages