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 > On Sep 1, 2014, at 6:22 AM, Cristian Mitu <[email protected]> wrote: > > 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 :-) > . > > > 2014-08-27 1:45 GMT+02:00 Sungjin Chun <[email protected]>: >> 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). >> >> >>> On Wed, Aug 27, 2014 at 12:40 AM, Cristian Mitu <[email protected]> >>> wrote: >>> 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. >>> -- >>> 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 [email protected]. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> 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 >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
