Fixed some dumb build errors, did some cleanup on the driver. Built the driver as a module, it loads but does nothing. It is probably not finding the spi device.
Using Xenomai 3.0.5. Attaching the .dtsi so show what pins the spidev is mapped to. On Thu, Jul 27, 2017 at 6:29 PM, Jackson Jones <[email protected]> wrote: > Philippe, > > I put together a driver for the i.mx6. The Freescale/NXP driver in the > kernel covered all the imx chips. I whittled that down to just the imx6 to > make things simpler. > > I have gotten the driver to compile in the xenomai/kernel/driver/spi > directory and link, but it does not even load (no messages at boot, no > devices created). I have attached the driver, the modified Kconfig and > Makefile in the spi directory (to enable the imx6 option, compile and link > it). Let me know if anyone sees anything obviously wrong. > > The imx depends on the spi_bitbang layer, but from what I can see, this is > only if you are using DMA. I wrote the driver to be PIO only. There is a > warning in the comments of the mainline imx driver, switching modes > (between master and slave) does not work, there can be a race condition in > the hardware, so I wrote the driver to stay in master mode. > > /* > * The hardware seems to have a race condition when changing modes. The > * current assumption is that the selection of the channel arrives > * earlier in the hardware than the mode bits when they are written at > * the same time. > * So set master mode for all channels as we do not support slave mode. > */ > > spi-imx6.c - Cobalt driver > spi-imx.c - Original Linux driver > Makefile - modified > Kconfig - modified > config - kernel config > > > Thanks for any help or insights, > > Jackson > > > > > On Fri, Jun 30, 2017 at 12:25 PM, Philippe Gerum <[email protected]> wrote: > >> On 06/29/2017 11:15 PM, Jackson Jones wrote: >> > Are there any plans to add a real-time driver for the imx6 spi? >> > >> > >> >> No ongoing work to my knowledge. The ECSPI is fairly straightforward to >> control in PIO mode. FWIW, I believe that writing a backend driving this >> chip on top of Cobalt's generic SPI core should be possible, using the >> bcm2835 implementation we already have in tree as an example. >> >> testsuite/spitest.c illustrates the API exposed to userland by the SPI >> core, which can use read/write calls or a memory-mapped transfer buffer. >> >> -- >> Philippe. >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 246 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170728/53b27a98/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: spi-imx6.c Type: text/x-csrc Size: 19563 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170728/53b27a98/attachment.c> -------------- next part -------------- A non-text attachment was scrubbed... Name: imx6qdl-var-som.dtsi Type: application/octet-stream Size: 19844 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20170728/53b27a98/attachment-0001.obj> _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
