* AM335x BeagleBone SPI Issues @ 2012-12-10 13:23 Jack Mitchell 2012-12-10 13:53 ` Felipe Balbi 0 siblings, 1 reply; 27+ messages in thread From: Jack Mitchell @ 2012-12-10 13:23 UTC (permalink / raw) To: linux-omap Hi, I am currently having issues with the SPI driver on the beaglebone using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have found that writing works however reading doesn't. When using DMA the program seems to lock hard and no data is sent on the bus. I am testing the bus using spidev and the spidev_test[2] application, however I first came across spi issues with a custom spi driver which stopped working when I transitioned from 3.2-psp to 3.7-rc8. The current output I am seeing from the spidev_test program is just a series of 0x00 data, which looks to me like no data is getting in at all. The spidev_test program is not using DMA as the buffer size is too low, so I forced the dma on when buffer size is > 1 and the program hangs hard with the system still responding to other commands.I have briged the pins 18 and 21 on the BeagleBone P9 header. Has anyone seen issues like this, or if not if someone could please test the latest 3.7-rc8 from [1] and let me know if it works for them and the issue is at my end. To get spidev working with devicetree I applied the patch from [3] and changed the dtb as in the patch pasted below. [1] https://github.com/beagleboard/kernel/tree/3.7 [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c [3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi index 543365d..8fff665 100644 --- a/arch/arm/boot/dts/am335x-bone-common.dtsi +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi @@ -440,10 +440,19 @@ }; &spi0 { + status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; + + spidev: spidev@0 { + compatible = "linux,spidev"; + reg = <0>; + spi-max-frequency = <24000000>; + }; + }; + &spi1 { pinctrl-names = "default"; pinctrl-0 = <&spi1_pins>; -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 13:23 AM335x BeagleBone SPI Issues Jack Mitchell @ 2012-12-10 13:53 ` Felipe Balbi 2012-12-10 14:50 ` Jack Mitchell 0 siblings, 1 reply; 27+ messages in thread From: Felipe Balbi @ 2012-12-10 13:53 UTC (permalink / raw) To: Jack Mitchell; +Cc: linux-omap [-- Attachment #1: Type: text/plain, Size: 1786 bytes --] Hi, On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: > Hi, > > I am currently having issues with the SPI driver on the beaglebone > using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have > found that writing works however reading doesn't. When using DMA the > program seems to lock hard and no data is sent on the bus. I am > testing the bus using spidev and the spidev_test[2] application, > however I first came across spi issues with a custom spi driver which > stopped working when I transitioned from 3.2-psp to 3.7-rc8. > > The current output I am seeing from the spidev_test program is just a > series of 0x00 data, which looks to me like no data is getting in at > all. The spidev_test program is not using DMA as the buffer size is > too low, so I forced the dma on when buffer size is > 1 and the > program hangs hard with the system still responding to other > commands.I have briged the pins 18 and 21 on the BeagleBone P9 > header. > > Has anyone seen issues like this, or if not if someone could please > test the latest 3.7-rc8 from [1] and let me know if it works for them > and the issue is at my end. > > To get spidev working with devicetree I applied the patch from [3] > and changed the dtb as in the patch pasted below. > > [1] https://github.com/beagleboard/kernel/tree/3.7 > [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c > [3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html do you have any debugging output from that driver ? It would be cool to see if DMA is at least being kicked properly for small transfers. It would also be nice to have a clear picture of what "custom spi driver" you're talking about. cheers -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 13:53 ` Felipe Balbi @ 2012-12-10 14:50 ` Jack Mitchell 2012-12-10 14:59 ` Felipe Balbi 0 siblings, 1 reply; 27+ messages in thread From: Jack Mitchell @ 2012-12-10 14:50 UTC (permalink / raw) To: balbi; +Cc: linux-omap Hi Felipe, On 10/12/12 13:53, Felipe Balbi wrote: > Hi, > > On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: >> Hi, >> >> I am currently having issues with the SPI driver on the beaglebone >> using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have >> found that writing works however reading doesn't. When using DMA the >> program seems to lock hard and no data is sent on the bus. I am >> testing the bus using spidev and the spidev_test[2] application, >> however I first came across spi issues with a custom spi driver which >> stopped working when I transitioned from 3.2-psp to 3.7-rc8. >> >> The current output I am seeing from the spidev_test program is just a >> series of 0x00 data, which looks to me like no data is getting in at >> all. The spidev_test program is not using DMA as the buffer size is >> too low, so I forced the dma on when buffer size is > 1 and the >> program hangs hard with the system still responding to other >> commands.I have briged the pins 18 and 21 on the BeagleBone P9 >> header. >> >> Has anyone seen issues like this, or if not if someone could please >> test the latest 3.7-rc8 from [1] and let me know if it works for them >> and the issue is at my end. >> >> To get spidev working with devicetree I applied the patch from [3] >> and changed the dtb as in the patch pasted below. >> >> [1] https://github.com/beagleboard/kernel/tree/3.7 >> [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c >> [3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html > do you have any debugging output from that driver ? It would be cool to > see if DMA is at least being kicked properly for small transfers. When I run the spidev program with dma for transfers > 1, the program hangs and the only output in dmesg is: [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <---- Last line from initial log in [2] [ 47.669202] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 [ 47.669260] spidev spi1.0: spi mode 00 [ 47.669283] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 [ 47.669312] spidev spi1.0: 16 bits per word [ 47.669330] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 [ 47.669358] spidev spi1.0: 24000000 Hz (max) [ 47.673811] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal The initial dmesg statup log is at [2]. > > It would also be nice to have a clear picture of what "custom spi > driver" you're talking about. The custom SPI driver is for connecting and reading registers from an in house FPGA design and can be found at [1]. It's fairly rudimentary and also in the development stages, I'm very new to Linux kernel programming so please take that into account :) However it did work flawlessly with 3.2-psp. > > cheers > [1] http://embed.me.uk/fpgaSPI.c [2] http://embed.me.uk/bone-log.1 Cheers, -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 14:50 ` Jack Mitchell @ 2012-12-10 14:59 ` Felipe Balbi 2012-12-10 15:19 ` Jack Mitchell 0 siblings, 1 reply; 27+ messages in thread From: Felipe Balbi @ 2012-12-10 14:59 UTC (permalink / raw) To: Jack Mitchell; +Cc: balbi, linux-omap [-- Attachment #1: Type: text/plain, Size: 6708 bytes --] Hi, On Mon, Dec 10, 2012 at 02:50:16PM +0000, Jack Mitchell wrote: > >On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: > >>Hi, > >> > >>I am currently having issues with the SPI driver on the beaglebone > >>using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have > >>found that writing works however reading doesn't. When using DMA the > >>program seems to lock hard and no data is sent on the bus. I am > >>testing the bus using spidev and the spidev_test[2] application, > >>however I first came across spi issues with a custom spi driver which > >>stopped working when I transitioned from 3.2-psp to 3.7-rc8. > >> > >>The current output I am seeing from the spidev_test program is just a > >>series of 0x00 data, which looks to me like no data is getting in at > >>all. The spidev_test program is not using DMA as the buffer size is > >>too low, so I forced the dma on when buffer size is > 1 and the > >>program hangs hard with the system still responding to other > >>commands.I have briged the pins 18 and 21 on the BeagleBone P9 > >>header. > >> > >>Has anyone seen issues like this, or if not if someone could please > >>test the latest 3.7-rc8 from [1] and let me know if it works for them > >>and the issue is at my end. > >> > >>To get spidev working with devicetree I applied the patch from [3] > >>and changed the dtb as in the patch pasted below. > >> > >>[1] https://github.com/beagleboard/kernel/tree/3.7 > >>[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c > >>[3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html > >do you have any debugging output from that driver ? It would be cool to > >see if DMA is at least being kicked properly for small transfers. > > When I run the spidev program with dma for transfers > 1, the program > hangs and the only output in dmesg is: > > [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <---- > Last line from initial log in [2] > [ 47.669202] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 > [ 47.669260] spidev spi1.0: spi mode 00 > [ 47.669283] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 > [ 47.669312] spidev spi1.0: 16 bits per word > [ 47.669330] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 > [ 47.669358] spidev spi1.0: 24000000 Hz (max) > [ 47.673811] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > > The initial dmesg statup log is at [2]. can you apply the debugging patch below to spi driver and show me the output again ? Note that I'm allowing DMA for as small as 1-byte transfers (as you needed) and I'm also disabling DMA Request line before calling complete() as I think the current way could race, but likely wouldn't cause issues. Anyway, please show me the output. diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index 3542fdc..d2b1af2 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -108,7 +108,7 @@ struct omap2_mcspi_dma { /* use PIO for small transfers, avoiding DMA setup/teardown overhead and * cache operations; better heuristics consider wordsize and bitrate. */ -#define DMA_MIN_BYTES 160 +#define DMA_MIN_BYTES 1 /* @@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; - complete(&mcspi_dma->dma_rx_completion); - /* We must disable the DMA RX request */ + dev_info(&spi->dev, "Disabling RX Request Line\n"); omap2_mcspi_set_dma_req(spi, 1, 0); + + complete(&mcspi_dma->dma_rx_completion); } static void omap2_mcspi_tx_callback(void *data) @@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data) struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; - complete(&mcspi_dma->dma_tx_completion); - /* We must disable the DMA TX request */ + dev_info(&spi->dev, "Disabling TX Request Line\n"); omap2_mcspi_set_dma_req(spi, 0, 0); + + complete(&mcspi_dma->dma_tx_completion); } static void omap2_mcspi_tx_dma(struct spi_device *spi, @@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, void __iomem *chstat_reg; struct omap2_mcspi_cs *cs = spi->controller_state; + dev_info(&spi->dev, "kicking TX DMA\n"); mcspi = spi_master_get_devdata(spi->master); mcspi_dma = &mcspi->dma_channels[spi->chip_select]; count = xfer->len; @@ -359,7 +362,9 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, dma_async_issue_pending(mcspi_dma->dma_tx); omap2_mcspi_set_dma_req(spi, 0, 1); + dev_info(&spi->dev, "Waiting for TX Completion\n"); wait_for_completion(&mcspi_dma->dma_tx_completion); + dev_info(&spi->dev, "TX Completed\n"); dma_unmap_single(mcspi->dev, xfer->tx_dma, count, DMA_TO_DEVICE); @@ -392,6 +397,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, word_len = cs->word_len; l = mcspi_cached_chconf0(spi); + dev_info(&spi->dev, "kicking RX DMA\n"); if (word_len <= 8) element_count = count; else if (word_len <= 16) @@ -428,7 +434,9 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, dma_async_issue_pending(mcspi_dma->dma_rx); omap2_mcspi_set_dma_req(spi, 1, 1); + dev_info(&spi->dev, "Waiting for RX Completion\n"); wait_for_completion(&mcspi_dma->dma_rx_completion); + dev_info(&spi->dev, "RX Completed\n"); dma_unmap_single(mcspi->dev, xfer->rx_dma, count, DMA_FROM_DEVICE); omap2_mcspi_set_enable(spi, 0); > >It would also be nice to have a clear picture of what "custom spi > >driver" you're talking about. > > The custom SPI driver is for connecting and reading registers from an > in house FPGA design and can be found at [1]. It's fairly rudimentary > and also in the development stages, I'm very new to Linux kernel > programming so please take that into account :) no problem ;-) > However it did work flawlessly with 3.2-psp. yeah, it could be some regression introduced somewhere, or just a bugfix which was done on 3.2-psp and was missed upstream... annoying when those happen :-p -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 14:59 ` Felipe Balbi @ 2012-12-10 15:19 ` Jack Mitchell 2012-12-10 15:26 ` Shubhrajyoti Datta 2012-12-10 18:35 ` Felipe Balbi 0 siblings, 2 replies; 27+ messages in thread From: Jack Mitchell @ 2012-12-10 15:19 UTC (permalink / raw) To: balbi; +Cc: linux-omap On 10/12/12 14:59, Felipe Balbi wrote: > Hi, > > On Mon, Dec 10, 2012 at 02:50:16PM +0000, Jack Mitchell wrote: >>> On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: >>>> Hi, >>>> >>>> I am currently having issues with the SPI driver on the beaglebone >>>> using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have >>>> found that writing works however reading doesn't. When using DMA the >>>> program seems to lock hard and no data is sent on the bus. I am >>>> testing the bus using spidev and the spidev_test[2] application, >>>> however I first came across spi issues with a custom spi driver which >>>> stopped working when I transitioned from 3.2-psp to 3.7-rc8. >>>> >>>> The current output I am seeing from the spidev_test program is just a >>>> series of 0x00 data, which looks to me like no data is getting in at >>>> all. The spidev_test program is not using DMA as the buffer size is >>>> too low, so I forced the dma on when buffer size is > 1 and the >>>> program hangs hard with the system still responding to other >>>> commands.I have briged the pins 18 and 21 on the BeagleBone P9 >>>> header. >>>> >>>> Has anyone seen issues like this, or if not if someone could please >>>> test the latest 3.7-rc8 from [1] and let me know if it works for them >>>> and the issue is at my end. >>>> >>>> To get spidev working with devicetree I applied the patch from [3] >>>> and changed the dtb as in the patch pasted below. >>>> >>>> [1] https://github.com/beagleboard/kernel/tree/3.7 >>>> [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c >>>> [3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html >>> do you have any debugging output from that driver ? It would be cool to >>> see if DMA is at least being kicked properly for small transfers. >> When I run the spidev program with dma for transfers > 1, the program >> hangs and the only output in dmesg is: >> >> [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <---- >> Last line from initial log in [2] >> [ 47.669202] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 >> [ 47.669260] spidev spi1.0: spi mode 00 >> [ 47.669283] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 >> [ 47.669312] spidev spi1.0: 16 bits per word >> [ 47.669330] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 >> [ 47.669358] spidev spi1.0: 24000000 Hz (max) >> [ 47.673811] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> >> The initial dmesg statup log is at [2]. > can you apply the debugging patch below to spi driver and show me the > output again ? > > Note that I'm allowing DMA for as small as 1-byte transfers (as you > needed) and I'm also disabling DMA Request line before calling > complete() as I think the current way could race, but likely wouldn't > cause issues. Anyway, please show me the output. > > diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c > index 3542fdc..d2b1af2 100644 > --- a/drivers/spi/spi-omap2-mcspi.c > +++ b/drivers/spi/spi-omap2-mcspi.c > @@ -108,7 +108,7 @@ struct omap2_mcspi_dma { > /* use PIO for small transfers, avoiding DMA setup/teardown overhead and > * cache operations; better heuristics consider wordsize and bitrate. > */ > -#define DMA_MIN_BYTES 160 > +#define DMA_MIN_BYTES 1 > > > /* > @@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data) > struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); > struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > > - complete(&mcspi_dma->dma_rx_completion); > - > /* We must disable the DMA RX request */ > + dev_info(&spi->dev, "Disabling RX Request Line\n"); > omap2_mcspi_set_dma_req(spi, 1, 0); > + > + complete(&mcspi_dma->dma_rx_completion); > } > > static void omap2_mcspi_tx_callback(void *data) > @@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data) > struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); > struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > > - complete(&mcspi_dma->dma_tx_completion); > - > /* We must disable the DMA TX request */ > + dev_info(&spi->dev, "Disabling TX Request Line\n"); > omap2_mcspi_set_dma_req(spi, 0, 0); > + > + complete(&mcspi_dma->dma_tx_completion); > } > > static void omap2_mcspi_tx_dma(struct spi_device *spi, > @@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, > void __iomem *chstat_reg; > struct omap2_mcspi_cs *cs = spi->controller_state; > > + dev_info(&spi->dev, "kicking TX DMA\n"); > mcspi = spi_master_get_devdata(spi->master); > mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > count = xfer->len; > @@ -359,7 +362,9 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, > dma_async_issue_pending(mcspi_dma->dma_tx); > omap2_mcspi_set_dma_req(spi, 0, 1); > > + dev_info(&spi->dev, "Waiting for TX Completion\n"); > wait_for_completion(&mcspi_dma->dma_tx_completion); > + dev_info(&spi->dev, "TX Completed\n"); > dma_unmap_single(mcspi->dev, xfer->tx_dma, count, > DMA_TO_DEVICE); > > @@ -392,6 +397,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, > word_len = cs->word_len; > l = mcspi_cached_chconf0(spi); > > + dev_info(&spi->dev, "kicking RX DMA\n"); > if (word_len <= 8) > element_count = count; > else if (word_len <= 16) > @@ -428,7 +434,9 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, > dma_async_issue_pending(mcspi_dma->dma_rx); > omap2_mcspi_set_dma_req(spi, 1, 1); > > + dev_info(&spi->dev, "Waiting for RX Completion\n"); > wait_for_completion(&mcspi_dma->dma_rx_completion); > + dev_info(&spi->dev, "RX Completed\n"); > dma_unmap_single(mcspi->dev, xfer->rx_dma, count, > DMA_FROM_DEVICE); > omap2_mcspi_set_enable(spi, 0); > >>> It would also be nice to have a clear picture of what "custom spi >>> driver" you're talking about. >> The custom SPI driver is for connecting and reading registers from an >> in house FPGA design and can be found at [1]. It's fairly rudimentary >> and also in the development stages, I'm very new to Linux kernel >> programming so please take that into account :) > no problem ;-) > >> However it did work flawlessly with 3.2-psp. > yeah, it could be some regression introduced somewhere, or just a bugfix > which was done on 3.2-psp and was missed upstream... annoying when those > happen :-p > Your patch didn't apply cleanly but I hacked it in and got the following: [ 40.434566] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal [ 40.434609] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 [ 40.434622] spidev spi1.0: spi mode 00 [ 40.434645] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal [ 40.434661] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 [ 40.434673] spidev spi1.0: 16 bits per word [ 40.434692] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal [ 40.434708] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 [ 40.434720] spidev spi1.0: 24000000 Hz (max) [ 40.439300] spidev spi1.0: setup: speed 24000000, sample leading edge, clk normal [ 40.439397] spidev spi1.0: kicking TX DMA [ 40.443797] spidev spi1.0: Waiting for TX Completion Cheers, -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 15:19 ` Jack Mitchell @ 2012-12-10 15:26 ` Shubhrajyoti Datta 2012-12-10 16:18 ` Jack Mitchell 2012-12-10 18:35 ` Felipe Balbi 1 sibling, 1 reply; 27+ messages in thread From: Shubhrajyoti Datta @ 2012-12-10 15:26 UTC (permalink / raw) To: ml; +Cc: balbi, linux-omap On Mon, Dec 10, 2012 at 8:49 PM, Jack Mitchell <ml@communistcode.co.uk> wrote: > On 10/12/12 14:59, Felipe Balbi wrote: >> >> Hi, >> >> On Mon, Dec 10, 2012 at 02:50:16PM +0000, Jack Mitchell wrote: >>>> >>>> On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am currently having issues with the SPI driver on the beaglebone >>>>> using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have >>>>> found that writing works however reading doesn't. When using DMA the >>>>> program seems to lock hard and no data is sent on the bus. I am >>>>> testing the bus using spidev and the spidev_test[2] application, >>>>> however I first came across spi issues with a custom spi driver which >>>>> stopped working when I transitioned from 3.2-psp to 3.7-rc8. >>>>> >>>>> The current output I am seeing from the spidev_test program is just a >>>>> series of 0x00 data, which looks to me like no data is getting in at >>>>> all. The spidev_test program is not using DMA as the buffer size is >>>>> too low, so I forced the dma on when buffer size is > 1 and the >>>>> program hangs hard with the system still responding to other >>>>> commands.I have briged the pins 18 and 21 on the BeagleBone P9 >>>>> header. >>>>> >>>>> Has anyone seen issues like this, or if not if someone could please >>>>> test the latest 3.7-rc8 from [1] and let me know if it works for them >>>>> and the issue is at my end. >>>>> >>>>> To get spidev working with devicetree I applied the patch from [3] >>>>> and changed the dtb as in the patch pasted below. >>>>> >>>>> [1] https://github.com/beagleboard/kernel/tree/3.7 >>>>> [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c >>>>> [3] >>>>> http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html >>>> >>>> do you have any debugging output from that driver ? It would be cool to >>>> see if DMA is at least being kicked properly for small transfers. >>> >>> When I run the spidev program with dma for transfers > 1, the program >>> hangs and the only output in dmesg is: >>> >>> [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <---- >>> Last line from initial log in [2] >>> [ 47.669202] spidev spi1.0: setup: speed 24000000, sample leading >>> edge, clk normal >>> [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> >>> 0 >>> [ 47.669260] spidev spi1.0: spi mode 00 >>> [ 47.669283] spidev spi1.0: setup: speed 24000000, sample leading >>> edge, clk normal >>> [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max >>> --> 0 >>> [ 47.669312] spidev spi1.0: 16 bits per word >>> [ 47.669330] spidev spi1.0: setup: speed 24000000, sample leading >>> edge, clk normal >>> [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max >>> --> 0 >>> [ 47.669358] spidev spi1.0: 24000000 Hz (max) >>> [ 47.673811] spidev spi1.0: setup: speed 24000000, sample leading >>> edge, clk normal >>> >>> The initial dmesg statup log is at [2]. >> >> can you apply the debugging patch below to spi driver and show me the >> output again ? >> >> Note that I'm allowing DMA for as small as 1-byte transfers (as you >> needed) and I'm also disabling DMA Request line before calling >> complete() as I think the current way could race, but likely wouldn't >> cause issues. Anyway, please show me the output. >> >> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c >> index 3542fdc..d2b1af2 100644 >> --- a/drivers/spi/spi-omap2-mcspi.c >> +++ b/drivers/spi/spi-omap2-mcspi.c >> @@ -108,7 +108,7 @@ struct omap2_mcspi_dma { >> /* use PIO for small transfers, avoiding DMA setup/teardown overhead and >> * cache operations; better heuristics consider wordsize and bitrate. >> */ >> -#define DMA_MIN_BYTES 160 >> +#define DMA_MIN_BYTES 1 >> /* >> @@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data) >> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); >> struct omap2_mcspi_dma *mcspi_dma = >> &mcspi->dma_channels[spi->chip_select]; >> - complete(&mcspi_dma->dma_rx_completion); >> - >> /* We must disable the DMA RX request */ >> + dev_info(&spi->dev, "Disabling RX Request Line\n"); >> omap2_mcspi_set_dma_req(spi, 1, 0); >> + >> + complete(&mcspi_dma->dma_rx_completion); >> } >> static void omap2_mcspi_tx_callback(void *data) >> @@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data) >> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); >> struct omap2_mcspi_dma *mcspi_dma = >> &mcspi->dma_channels[spi->chip_select]; >> - complete(&mcspi_dma->dma_tx_completion); >> - >> /* We must disable the DMA TX request */ >> + dev_info(&spi->dev, "Disabling TX Request Line\n"); >> omap2_mcspi_set_dma_req(spi, 0, 0); >> + >> + complete(&mcspi_dma->dma_tx_completion); >> } >> static void omap2_mcspi_tx_dma(struct spi_device *spi, >> @@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, >> void __iomem *chstat_reg; >> struct omap2_mcspi_cs *cs = spi->controller_state; >> + dev_info(&spi->dev, "kicking TX DMA\n"); >> mcspi = spi_master_get_devdata(spi->master); >> mcspi_dma = &mcspi->dma_channels[spi->chip_select]; >> count = xfer->len; >> @@ -359,7 +362,9 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, >> dma_async_issue_pending(mcspi_dma->dma_tx); >> omap2_mcspi_set_dma_req(spi, 0, 1); >> + dev_info(&spi->dev, "Waiting for TX Completion\n"); >> wait_for_completion(&mcspi_dma->dma_tx_completion); >> + dev_info(&spi->dev, "TX Completed\n"); >> dma_unmap_single(mcspi->dev, xfer->tx_dma, count, >> DMA_TO_DEVICE); >> @@ -392,6 +397,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct >> spi_transfer *xfer, >> word_len = cs->word_len; >> l = mcspi_cached_chconf0(spi); >> + dev_info(&spi->dev, "kicking RX DMA\n"); >> if (word_len <= 8) >> element_count = count; >> else if (word_len <= 16) >> @@ -428,7 +434,9 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct >> spi_transfer *xfer, >> dma_async_issue_pending(mcspi_dma->dma_rx); >> omap2_mcspi_set_dma_req(spi, 1, 1); >> + dev_info(&spi->dev, "Waiting for RX Completion\n"); >> wait_for_completion(&mcspi_dma->dma_rx_completion); >> + dev_info(&spi->dev, "RX Completed\n"); >> dma_unmap_single(mcspi->dev, xfer->rx_dma, count, >> DMA_FROM_DEVICE); >> omap2_mcspi_set_enable(spi, 0); >> >>>> It would also be nice to have a clear picture of what "custom spi >>>> driver" you're talking about. >>> >>> The custom SPI driver is for connecting and reading registers from an >>> in house FPGA design and can be found at [1]. It's fairly rudimentary >>> and also in the development stages, I'm very new to Linux kernel >>> programming so please take that into account :) >> >> no problem ;-) >> >>> However it did work flawlessly with 3.2-psp. >> >> yeah, it could be some regression introduced somewhere, or just a bugfix >> which was done on 3.2-psp and was missed upstream... annoying when those >> happen :-p >> Can you try the following git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git spi-next Alternatively you can use the linux-next. And let me know if you still see the issue. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 15:26 ` Shubhrajyoti Datta @ 2012-12-10 16:18 ` Jack Mitchell 0 siblings, 0 replies; 27+ messages in thread From: Jack Mitchell @ 2012-12-10 16:18 UTC (permalink / raw) To: Shubhrajyoti Datta; +Cc: balbi, linux-omap On 10/12/12 15:26, Shubhrajyoti Datta wrote: > On Mon, Dec 10, 2012 at 8:49 PM, Jack Mitchell <ml@communistcode.co.uk> wrote: >> On 10/12/12 14:59, Felipe Balbi wrote: >>> Hi, >>> >>> On Mon, Dec 10, 2012 at 02:50:16PM +0000, Jack Mitchell wrote: >>>>> On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: >>>>>> Hi, >>>>>> >>>>>> I am currently having issues with the SPI driver on the beaglebone >>>>>> using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have >>>>>> found that writing works however reading doesn't. When using DMA the >>>>>> program seems to lock hard and no data is sent on the bus. I am >>>>>> testing the bus using spidev and the spidev_test[2] application, >>>>>> however I first came across spi issues with a custom spi driver which >>>>>> stopped working when I transitioned from 3.2-psp to 3.7-rc8. >>>>>> >>>>>> The current output I am seeing from the spidev_test program is just a >>>>>> series of 0x00 data, which looks to me like no data is getting in at >>>>>> all. The spidev_test program is not using DMA as the buffer size is >>>>>> too low, so I forced the dma on when buffer size is > 1 and the >>>>>> program hangs hard with the system still responding to other >>>>>> commands.I have briged the pins 18 and 21 on the BeagleBone P9 >>>>>> header. >>>>>> >>>>>> Has anyone seen issues like this, or if not if someone could please >>>>>> test the latest 3.7-rc8 from [1] and let me know if it works for them >>>>>> and the issue is at my end. >>>>>> >>>>>> To get spidev working with devicetree I applied the patch from [3] >>>>>> and changed the dtb as in the patch pasted below. >>>>>> >>>>>> [1] https://github.com/beagleboard/kernel/tree/3.7 >>>>>> [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c >>>>>> [3] >>>>>> http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html >>>>> do you have any debugging output from that driver ? It would be cool to >>>>> see if DMA is at least being kicked properly for small transfers. >>>> When I run the spidev program with dma for transfers > 1, the program >>>> hangs and the only output in dmesg is: >>>> >>>> [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <---- >>>> Last line from initial log in [2] >>>> [ 47.669202] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> >>>> 0 >>>> [ 47.669260] spidev spi1.0: spi mode 00 >>>> [ 47.669283] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max >>>> --> 0 >>>> [ 47.669312] spidev spi1.0: 16 bits per word >>>> [ 47.669330] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max >>>> --> 0 >>>> [ 47.669358] spidev spi1.0: 24000000 Hz (max) >>>> [ 47.673811] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> >>>> The initial dmesg statup log is at [2]. >>> can you apply the debugging patch below to spi driver and show me the >>> output again ? >>> >>> Note that I'm allowing DMA for as small as 1-byte transfers (as you >>> needed) and I'm also disabling DMA Request line before calling >>> complete() as I think the current way could race, but likely wouldn't >>> cause issues. Anyway, please show me the output. >>> >>> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c >>> index 3542fdc..d2b1af2 100644 >>> --- a/drivers/spi/spi-omap2-mcspi.c >>> +++ b/drivers/spi/spi-omap2-mcspi.c >>> @@ -108,7 +108,7 @@ struct omap2_mcspi_dma { >>> /* use PIO for small transfers, avoiding DMA setup/teardown overhead and >>> * cache operations; better heuristics consider wordsize and bitrate. >>> */ >>> -#define DMA_MIN_BYTES 160 >>> +#define DMA_MIN_BYTES 1 >>> /* >>> @@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data) >>> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); >>> struct omap2_mcspi_dma *mcspi_dma = >>> &mcspi->dma_channels[spi->chip_select]; >>> - complete(&mcspi_dma->dma_rx_completion); >>> - >>> /* We must disable the DMA RX request */ >>> + dev_info(&spi->dev, "Disabling RX Request Line\n"); >>> omap2_mcspi_set_dma_req(spi, 1, 0); >>> + >>> + complete(&mcspi_dma->dma_rx_completion); >>> } >>> static void omap2_mcspi_tx_callback(void *data) >>> @@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data) >>> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); >>> struct omap2_mcspi_dma *mcspi_dma = >>> &mcspi->dma_channels[spi->chip_select]; >>> - complete(&mcspi_dma->dma_tx_completion); >>> - >>> /* We must disable the DMA TX request */ >>> + dev_info(&spi->dev, "Disabling TX Request Line\n"); >>> omap2_mcspi_set_dma_req(spi, 0, 0); >>> + >>> + complete(&mcspi_dma->dma_tx_completion); >>> } >>> static void omap2_mcspi_tx_dma(struct spi_device *spi, >>> @@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, >>> void __iomem *chstat_reg; >>> struct omap2_mcspi_cs *cs = spi->controller_state; >>> + dev_info(&spi->dev, "kicking TX DMA\n"); >>> mcspi = spi_master_get_devdata(spi->master); >>> mcspi_dma = &mcspi->dma_channels[spi->chip_select]; >>> count = xfer->len; >>> @@ -359,7 +362,9 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, >>> dma_async_issue_pending(mcspi_dma->dma_tx); >>> omap2_mcspi_set_dma_req(spi, 0, 1); >>> + dev_info(&spi->dev, "Waiting for TX Completion\n"); >>> wait_for_completion(&mcspi_dma->dma_tx_completion); >>> + dev_info(&spi->dev, "TX Completed\n"); >>> dma_unmap_single(mcspi->dev, xfer->tx_dma, count, >>> DMA_TO_DEVICE); >>> @@ -392,6 +397,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct >>> spi_transfer *xfer, >>> word_len = cs->word_len; >>> l = mcspi_cached_chconf0(spi); >>> + dev_info(&spi->dev, "kicking RX DMA\n"); >>> if (word_len <= 8) >>> element_count = count; >>> else if (word_len <= 16) >>> @@ -428,7 +434,9 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct >>> spi_transfer *xfer, >>> dma_async_issue_pending(mcspi_dma->dma_rx); >>> omap2_mcspi_set_dma_req(spi, 1, 1); >>> + dev_info(&spi->dev, "Waiting for RX Completion\n"); >>> wait_for_completion(&mcspi_dma->dma_rx_completion); >>> + dev_info(&spi->dev, "RX Completed\n"); >>> dma_unmap_single(mcspi->dev, xfer->rx_dma, count, >>> DMA_FROM_DEVICE); >>> omap2_mcspi_set_enable(spi, 0); >>> >>>>> It would also be nice to have a clear picture of what "custom spi >>>>> driver" you're talking about. >>>> The custom SPI driver is for connecting and reading registers from an >>>> in house FPGA design and can be found at [1]. It's fairly rudimentary >>>> and also in the development stages, I'm very new to Linux kernel >>>> programming so please take that into account :) >>> no problem ;-) >>> >>>> However it did work flawlessly with 3.2-psp. >>> yeah, it could be some regression introduced somewhere, or just a bugfix >>> which was done on 3.2-psp and was missed upstream... annoying when those >>> happen :-p >>> > Can you try the following > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git spi-next > > Alternatively you can use the linux-next. > > And let me know if you still see the issue. > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Neither of those trees seem to have SPI enabled via device tree, how can I make the same use case as I also cannot see a board file to enable the spi? Sorry, I'm quite new at this so bear with me if I'm being a bit naive! Cheers, -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 15:19 ` Jack Mitchell 2012-12-10 15:26 ` Shubhrajyoti Datta @ 2012-12-10 18:35 ` Felipe Balbi 2012-12-11 6:39 ` Shubhrajyoti Datta 2012-12-11 10:17 ` Jack Mitchell 1 sibling, 2 replies; 27+ messages in thread From: Felipe Balbi @ 2012-12-10 18:35 UTC (permalink / raw) To: Jack Mitchell; +Cc: balbi, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 11467 bytes --] Hi, On Mon, Dec 10, 2012 at 03:19:15PM +0000, Jack Mitchell wrote: > On 10/12/12 14:59, Felipe Balbi wrote: > >Hi, > > > >On Mon, Dec 10, 2012 at 02:50:16PM +0000, Jack Mitchell wrote: > >>>On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: > >>>>Hi, > >>>> > >>>>I am currently having issues with the SPI driver on the beaglebone > >>>>using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have > >>>>found that writing works however reading doesn't. When using DMA the > >>>>program seems to lock hard and no data is sent on the bus. I am > >>>>testing the bus using spidev and the spidev_test[2] application, > >>>>however I first came across spi issues with a custom spi driver which > >>>>stopped working when I transitioned from 3.2-psp to 3.7-rc8. > >>>> > >>>>The current output I am seeing from the spidev_test program is just a > >>>>series of 0x00 data, which looks to me like no data is getting in at > >>>>all. The spidev_test program is not using DMA as the buffer size is > >>>>too low, so I forced the dma on when buffer size is > 1 and the > >>>>program hangs hard with the system still responding to other > >>>>commands.I have briged the pins 18 and 21 on the BeagleBone P9 > >>>>header. > >>>> > >>>>Has anyone seen issues like this, or if not if someone could please > >>>>test the latest 3.7-rc8 from [1] and let me know if it works for them > >>>>and the issue is at my end. > >>>> > >>>>To get spidev working with devicetree I applied the patch from [3] > >>>>and changed the dtb as in the patch pasted below. > >>>> > >>>>[1] https://github.com/beagleboard/kernel/tree/3.7 > >>>>[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c > >>>>[3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html > >>>do you have any debugging output from that driver ? It would be cool to > >>>see if DMA is at least being kicked properly for small transfers. > >>When I run the spidev program with dma for transfers > 1, the program > >>hangs and the only output in dmesg is: > >> > >>[ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <---- > >>Last line from initial log in [2] > >>[ 47.669202] spidev spi1.0: setup: speed 24000000, sample leading > >>edge, clk normal > >>[ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 > >>[ 47.669260] spidev spi1.0: spi mode 00 > >>[ 47.669283] spidev spi1.0: setup: speed 24000000, sample leading > >>edge, clk normal > >>[ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 > >>[ 47.669312] spidev spi1.0: 16 bits per word > >>[ 47.669330] spidev spi1.0: setup: speed 24000000, sample leading > >>edge, clk normal > >>[ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 > >>[ 47.669358] spidev spi1.0: 24000000 Hz (max) > >>[ 47.673811] spidev spi1.0: setup: speed 24000000, sample leading > >>edge, clk normal > >> > >>The initial dmesg statup log is at [2]. > >can you apply the debugging patch below to spi driver and show me the > >output again ? > > > >Note that I'm allowing DMA for as small as 1-byte transfers (as you > >needed) and I'm also disabling DMA Request line before calling > >complete() as I think the current way could race, but likely wouldn't > >cause issues. Anyway, please show me the output. > > > >diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c > >index 3542fdc..d2b1af2 100644 > >--- a/drivers/spi/spi-omap2-mcspi.c > >+++ b/drivers/spi/spi-omap2-mcspi.c > >@@ -108,7 +108,7 @@ struct omap2_mcspi_dma { > > /* use PIO for small transfers, avoiding DMA setup/teardown overhead and > > * cache operations; better heuristics consider wordsize and bitrate. > > */ > >-#define DMA_MIN_BYTES 160 > >+#define DMA_MIN_BYTES 1 > > /* > >@@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data) > > struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); > > struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > >- complete(&mcspi_dma->dma_rx_completion); > >- > > /* We must disable the DMA RX request */ > >+ dev_info(&spi->dev, "Disabling RX Request Line\n"); > > omap2_mcspi_set_dma_req(spi, 1, 0); > >+ > >+ complete(&mcspi_dma->dma_rx_completion); > > } > > static void omap2_mcspi_tx_callback(void *data) > >@@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data) > > struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); > > struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > >- complete(&mcspi_dma->dma_tx_completion); > >- > > /* We must disable the DMA TX request */ > >+ dev_info(&spi->dev, "Disabling TX Request Line\n"); > > omap2_mcspi_set_dma_req(spi, 0, 0); > >+ > >+ complete(&mcspi_dma->dma_tx_completion); > > } > > static void omap2_mcspi_tx_dma(struct spi_device *spi, > >@@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, > > void __iomem *chstat_reg; > > struct omap2_mcspi_cs *cs = spi->controller_state; > >+ dev_info(&spi->dev, "kicking TX DMA\n"); > > mcspi = spi_master_get_devdata(spi->master); > > mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > > count = xfer->len; > >@@ -359,7 +362,9 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, > > dma_async_issue_pending(mcspi_dma->dma_tx); > > omap2_mcspi_set_dma_req(spi, 0, 1); > >+ dev_info(&spi->dev, "Waiting for TX Completion\n"); > > wait_for_completion(&mcspi_dma->dma_tx_completion); > >+ dev_info(&spi->dev, "TX Completed\n"); > > dma_unmap_single(mcspi->dev, xfer->tx_dma, count, > > DMA_TO_DEVICE); > >@@ -392,6 +397,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, > > word_len = cs->word_len; > > l = mcspi_cached_chconf0(spi); > >+ dev_info(&spi->dev, "kicking RX DMA\n"); > > if (word_len <= 8) > > element_count = count; > > else if (word_len <= 16) > >@@ -428,7 +434,9 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, > > dma_async_issue_pending(mcspi_dma->dma_rx); > > omap2_mcspi_set_dma_req(spi, 1, 1); > >+ dev_info(&spi->dev, "Waiting for RX Completion\n"); > > wait_for_completion(&mcspi_dma->dma_rx_completion); > >+ dev_info(&spi->dev, "RX Completed\n"); > > dma_unmap_single(mcspi->dev, xfer->rx_dma, count, > > DMA_FROM_DEVICE); > > omap2_mcspi_set_enable(spi, 0); > > > >>>It would also be nice to have a clear picture of what "custom spi > >>>driver" you're talking about. > >>The custom SPI driver is for connecting and reading registers from an > >>in house FPGA design and can be found at [1]. It's fairly rudimentary > >>and also in the development stages, I'm very new to Linux kernel > >>programming so please take that into account :) > >no problem ;-) > > > >>However it did work flawlessly with 3.2-psp. > >yeah, it could be some regression introduced somewhere, or just a bugfix > >which was done on 3.2-psp and was missed upstream... annoying when those > >happen :-p > > > > Your patch didn't apply cleanly but I hacked it in and got the following: > > [ 40.434566] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > [ 40.434609] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 > [ 40.434622] spidev spi1.0: spi mode 00 > [ 40.434645] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > [ 40.434661] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 > [ 40.434673] spidev spi1.0: 16 bits per word > [ 40.434692] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > [ 40.434708] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 > [ 40.434720] spidev spi1.0: 24000000 Hz (max) > [ 40.439300] spidev spi1.0: setup: speed 24000000, sample leading > edge, clk normal > [ 40.439397] spidev spi1.0: kicking TX DMA > [ 40.443797] spidev spi1.0: Waiting for TX Completion so TX dma never completes... perhaps all you need is Shubhro's commit reordering TX and RX calls ?? commit e47a682ace0cd56eb8e09b806c2b0f034b491520 Author: Shubhrajyoti D <shubhrajyoti@ti.com> Date: Tue Nov 6 14:30:19 2012 +0530 spi: omap2-mcspi: Reorder the wait_for_completion for tx The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] changed the wait_for_completion order. Move the wait so that the rx doesnot wait for the tx to complete. Reported-and-tested-by: Sørensen, Stefan <Sorensen@polycom.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index 3542fdc..b1a651e 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -323,18 +323,13 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, struct omap2_mcspi *mcspi; struct omap2_mcspi_dma *mcspi_dma; unsigned int count; - u8 * rx; const u8 * tx; - void __iomem *chstat_reg; - struct omap2_mcspi_cs *cs = spi->controller_state; mcspi = spi_master_get_devdata(spi->master); mcspi_dma = &mcspi->dma_channels[spi->chip_select]; count = xfer->len; - rx = xfer->rx_buf; tx = xfer->tx_buf; - chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0; if (mcspi_dma->dma_tx) { struct dma_async_tx_descriptor *tx; @@ -359,19 +354,6 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, dma_async_issue_pending(mcspi_dma->dma_tx); omap2_mcspi_set_dma_req(spi, 0, 1); - wait_for_completion(&mcspi_dma->dma_tx_completion); - dma_unmap_single(mcspi->dev, xfer->tx_dma, count, - DMA_TO_DEVICE); - - /* for TX_ONLY mode, be sure all words have shifted out */ - if (rx == NULL) { - if (mcspi_wait_for_reg_bit(chstat_reg, - OMAP2_MCSPI_CHSTAT_TXS) < 0) - dev_err(&spi->dev, "TXS timed out\n"); - else if (mcspi_wait_for_reg_bit(chstat_reg, - OMAP2_MCSPI_CHSTAT_EOT) < 0) - dev_err(&spi->dev, "EOT timed out\n"); - } } static unsigned @@ -492,6 +474,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer) struct dma_slave_config cfg; enum dma_slave_buswidth width; unsigned es; + void __iomem *chstat_reg; mcspi = spi_master_get_devdata(spi->master); mcspi_dma = &mcspi->dma_channels[spi->chip_select]; @@ -526,8 +509,24 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer) omap2_mcspi_tx_dma(spi, xfer, cfg); if (rx != NULL) - return omap2_mcspi_rx_dma(spi, xfer, cfg, es); - + count = omap2_mcspi_rx_dma(spi, xfer, cfg, es); + + if (tx != NULL) { + chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0; + wait_for_completion(&mcspi_dma->dma_tx_completion); + dma_unmap_single(mcspi->dev, xfer->tx_dma, xfer->len, + DMA_TO_DEVICE); + + /* for TX_ONLY mode, be sure all words have shifted out */ + if (rx == NULL) { + if (mcspi_wait_for_reg_bit(chstat_reg, + OMAP2_MCSPI_CHSTAT_TXS) < 0) + dev_err(&spi->dev, "TXS timed out\n"); + else if (mcspi_wait_for_reg_bit(chstat_reg, + OMAP2_MCSPI_CHSTAT_EOT) < 0) + dev_err(&spi->dev, "EOT timed out\n"); + } + } return count; } Shubhro, what do you think ? could this be the case ? -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 18:35 ` Felipe Balbi @ 2012-12-11 6:39 ` Shubhrajyoti Datta 2012-12-11 10:17 ` Jack Mitchell 1 sibling, 0 replies; 27+ messages in thread From: Shubhrajyoti Datta @ 2012-12-11 6:39 UTC (permalink / raw) To: balbi; +Cc: Jack Mitchell, linux-omap On Tue, Dec 11, 2012 at 12:05 AM, Felipe Balbi <balbi@ti.com> wrote: > > > Shubhro, what do you think ? could this be the case ? Thats my idea too. Will wait for Jack Mitchell to confirm though. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-10 18:35 ` Felipe Balbi 2012-12-11 6:39 ` Shubhrajyoti Datta @ 2012-12-11 10:17 ` Jack Mitchell 2012-12-11 10:20 ` Felipe Balbi 2012-12-11 15:22 ` Ben Gamari 1 sibling, 2 replies; 27+ messages in thread From: Jack Mitchell @ 2012-12-11 10:17 UTC (permalink / raw) To: balbi; +Cc: linux-omap, Shubhrajyoti Datta On 10/12/12 18:35, Felipe Balbi wrote: > Hi, > > On Mon, Dec 10, 2012 at 03:19:15PM +0000, Jack Mitchell wrote: >> On 10/12/12 14:59, Felipe Balbi wrote: >>> Hi, >>> >>> On Mon, Dec 10, 2012 at 02:50:16PM +0000, Jack Mitchell wrote: >>>>> On Mon, Dec 10, 2012 at 01:23:09PM +0000, Jack Mitchell wrote: >>>>>> Hi, >>>>>> >>>>>> I am currently having issues with the SPI driver on the beaglebone >>>>>> using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have >>>>>> found that writing works however reading doesn't. When using DMA the >>>>>> program seems to lock hard and no data is sent on the bus. I am >>>>>> testing the bus using spidev and the spidev_test[2] application, >>>>>> however I first came across spi issues with a custom spi driver which >>>>>> stopped working when I transitioned from 3.2-psp to 3.7-rc8. >>>>>> >>>>>> The current output I am seeing from the spidev_test program is just a >>>>>> series of 0x00 data, which looks to me like no data is getting in at >>>>>> all. The spidev_test program is not using DMA as the buffer size is >>>>>> too low, so I forced the dma on when buffer size is > 1 and the >>>>>> program hangs hard with the system still responding to other >>>>>> commands.I have briged the pins 18 and 21 on the BeagleBone P9 >>>>>> header. >>>>>> >>>>>> Has anyone seen issues like this, or if not if someone could please >>>>>> test the latest 3.7-rc8 from [1] and let me know if it works for them >>>>>> and the issue is at my end. >>>>>> >>>>>> To get spidev working with devicetree I applied the patch from [3] >>>>>> and changed the dtb as in the patch pasted below. >>>>>> >>>>>> [1] https://github.com/beagleboard/kernel/tree/3.7 >>>>>> [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c >>>>>> [3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html >>>>> do you have any debugging output from that driver ? It would be cool to >>>>> see if DMA is at least being kicked properly for small transfers. >>>> When I run the spidev program with dma for transfers > 1, the program >>>> hangs and the only output in dmesg is: >>>> >>>> [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <---- >>>> Last line from initial log in [2] >>>> [ 47.669202] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 >>>> [ 47.669260] spidev spi1.0: spi mode 00 >>>> [ 47.669283] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 >>>> [ 47.669312] spidev spi1.0: 16 bits per word >>>> [ 47.669330] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 >>>> [ 47.669358] spidev spi1.0: 24000000 Hz (max) >>>> [ 47.673811] spidev spi1.0: setup: speed 24000000, sample leading >>>> edge, clk normal >>>> >>>> The initial dmesg statup log is at [2]. >>> can you apply the debugging patch below to spi driver and show me the >>> output again ? >>> >>> Note that I'm allowing DMA for as small as 1-byte transfers (as you >>> needed) and I'm also disabling DMA Request line before calling >>> complete() as I think the current way could race, but likely wouldn't >>> cause issues. Anyway, please show me the output. >>> >>> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c >>> index 3542fdc..d2b1af2 100644 >>> --- a/drivers/spi/spi-omap2-mcspi.c >>> +++ b/drivers/spi/spi-omap2-mcspi.c >>> @@ -108,7 +108,7 @@ struct omap2_mcspi_dma { >>> /* use PIO for small transfers, avoiding DMA setup/teardown overhead and >>> * cache operations; better heuristics consider wordsize and bitrate. >>> */ >>> -#define DMA_MIN_BYTES 160 >>> +#define DMA_MIN_BYTES 1 >>> /* >>> @@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data) >>> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); >>> struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; >>> - complete(&mcspi_dma->dma_rx_completion); >>> - >>> /* We must disable the DMA RX request */ >>> + dev_info(&spi->dev, "Disabling RX Request Line\n"); >>> omap2_mcspi_set_dma_req(spi, 1, 0); >>> + >>> + complete(&mcspi_dma->dma_rx_completion); >>> } >>> static void omap2_mcspi_tx_callback(void *data) >>> @@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data) >>> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master); >>> struct omap2_mcspi_dma *mcspi_dma = &mcspi->dma_channels[spi->chip_select]; >>> - complete(&mcspi_dma->dma_tx_completion); >>> - >>> /* We must disable the DMA TX request */ >>> + dev_info(&spi->dev, "Disabling TX Request Line\n"); >>> omap2_mcspi_set_dma_req(spi, 0, 0); >>> + >>> + complete(&mcspi_dma->dma_tx_completion); >>> } >>> static void omap2_mcspi_tx_dma(struct spi_device *spi, >>> @@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, >>> void __iomem *chstat_reg; >>> struct omap2_mcspi_cs *cs = spi->controller_state; >>> + dev_info(&spi->dev, "kicking TX DMA\n"); >>> mcspi = spi_master_get_devdata(spi->master); >>> mcspi_dma = &mcspi->dma_channels[spi->chip_select]; >>> count = xfer->len; >>> @@ -359,7 +362,9 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, >>> dma_async_issue_pending(mcspi_dma->dma_tx); >>> omap2_mcspi_set_dma_req(spi, 0, 1); >>> + dev_info(&spi->dev, "Waiting for TX Completion\n"); >>> wait_for_completion(&mcspi_dma->dma_tx_completion); >>> + dev_info(&spi->dev, "TX Completed\n"); >>> dma_unmap_single(mcspi->dev, xfer->tx_dma, count, >>> DMA_TO_DEVICE); >>> @@ -392,6 +397,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, >>> word_len = cs->word_len; >>> l = mcspi_cached_chconf0(spi); >>> + dev_info(&spi->dev, "kicking RX DMA\n"); >>> if (word_len <= 8) >>> element_count = count; >>> else if (word_len <= 16) >>> @@ -428,7 +434,9 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct spi_transfer *xfer, >>> dma_async_issue_pending(mcspi_dma->dma_rx); >>> omap2_mcspi_set_dma_req(spi, 1, 1); >>> + dev_info(&spi->dev, "Waiting for RX Completion\n"); >>> wait_for_completion(&mcspi_dma->dma_rx_completion); >>> + dev_info(&spi->dev, "RX Completed\n"); >>> dma_unmap_single(mcspi->dev, xfer->rx_dma, count, >>> DMA_FROM_DEVICE); >>> omap2_mcspi_set_enable(spi, 0); >>> >>>>> It would also be nice to have a clear picture of what "custom spi >>>>> driver" you're talking about. >>>> The custom SPI driver is for connecting and reading registers from an >>>> in house FPGA design and can be found at [1]. It's fairly rudimentary >>>> and also in the development stages, I'm very new to Linux kernel >>>> programming so please take that into account :) >>> no problem ;-) >>> >>>> However it did work flawlessly with 3.2-psp. >>> yeah, it could be some regression introduced somewhere, or just a bugfix >>> which was done on 3.2-psp and was missed upstream... annoying when those >>> happen :-p >>> >> Your patch didn't apply cleanly but I hacked it in and got the following: >> >> [ 40.434566] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> [ 40.434609] spidev spi1.0: setup mode 0, 8 bits/w, 24000000 Hz max --> 0 >> [ 40.434622] spidev spi1.0: spi mode 00 >> [ 40.434645] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> [ 40.434661] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 >> [ 40.434673] spidev spi1.0: 16 bits per word >> [ 40.434692] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> [ 40.434708] spidev spi1.0: setup mode 0, 16 bits/w, 24000000 Hz max --> 0 >> [ 40.434720] spidev spi1.0: 24000000 Hz (max) >> [ 40.439300] spidev spi1.0: setup: speed 24000000, sample leading >> edge, clk normal >> [ 40.439397] spidev spi1.0: kicking TX DMA >> [ 40.443797] spidev spi1.0: Waiting for TX Completion > so TX dma never completes... perhaps all you need is Shubhro's commit > reordering TX and RX calls ?? > > commit e47a682ace0cd56eb8e09b806c2b0f034b491520 > Author: Shubhrajyoti D <shubhrajyoti@ti.com> > Date: Tue Nov 6 14:30:19 2012 +0530 > > spi: omap2-mcspi: Reorder the wait_for_completion for tx > > The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] > changed the wait_for_completion order. Move the wait so that the > rx doesnot wait for the tx to complete. > > Reported-and-tested-by: Sørensen, Stefan <Sorensen@polycom.com> > Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> > > diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c > index 3542fdc..b1a651e 100644 > --- a/drivers/spi/spi-omap2-mcspi.c > +++ b/drivers/spi/spi-omap2-mcspi.c > @@ -323,18 +323,13 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, > struct omap2_mcspi *mcspi; > struct omap2_mcspi_dma *mcspi_dma; > unsigned int count; > - u8 * rx; > const u8 * tx; > - void __iomem *chstat_reg; > - struct omap2_mcspi_cs *cs = spi->controller_state; > > mcspi = spi_master_get_devdata(spi->master); > mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > count = xfer->len; > > - rx = xfer->rx_buf; > tx = xfer->tx_buf; > - chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0; > > if (mcspi_dma->dma_tx) { > struct dma_async_tx_descriptor *tx; > @@ -359,19 +354,6 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi, > dma_async_issue_pending(mcspi_dma->dma_tx); > omap2_mcspi_set_dma_req(spi, 0, 1); > > - wait_for_completion(&mcspi_dma->dma_tx_completion); > - dma_unmap_single(mcspi->dev, xfer->tx_dma, count, > - DMA_TO_DEVICE); > - > - /* for TX_ONLY mode, be sure all words have shifted out */ > - if (rx == NULL) { > - if (mcspi_wait_for_reg_bit(chstat_reg, > - OMAP2_MCSPI_CHSTAT_TXS) < 0) > - dev_err(&spi->dev, "TXS timed out\n"); > - else if (mcspi_wait_for_reg_bit(chstat_reg, > - OMAP2_MCSPI_CHSTAT_EOT) < 0) > - dev_err(&spi->dev, "EOT timed out\n"); > - } > } > > static unsigned > @@ -492,6 +474,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer) > struct dma_slave_config cfg; > enum dma_slave_buswidth width; > unsigned es; > + void __iomem *chstat_reg; > > mcspi = spi_master_get_devdata(spi->master); > mcspi_dma = &mcspi->dma_channels[spi->chip_select]; > @@ -526,8 +509,24 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer) > omap2_mcspi_tx_dma(spi, xfer, cfg); > > if (rx != NULL) > - return omap2_mcspi_rx_dma(spi, xfer, cfg, es); > - > + count = omap2_mcspi_rx_dma(spi, xfer, cfg, es); > + > + if (tx != NULL) { > + chstat_reg = cs->base + OMAP2_MCSPI_CHSTAT0; > + wait_for_completion(&mcspi_dma->dma_tx_completion); > + dma_unmap_single(mcspi->dev, xfer->tx_dma, xfer->len, > + DMA_TO_DEVICE); > + > + /* for TX_ONLY mode, be sure all words have shifted out */ > + if (rx == NULL) { > + if (mcspi_wait_for_reg_bit(chstat_reg, > + OMAP2_MCSPI_CHSTAT_TXS) < 0) > + dev_err(&spi->dev, "TXS timed out\n"); > + else if (mcspi_wait_for_reg_bit(chstat_reg, > + OMAP2_MCSPI_CHSTAT_EOT) < 0) > + dev_err(&spi->dev, "EOT timed out\n"); > + } > + } > return count; > } > > > Shubhro, what do you think ? could this be the case ? > Shubhro, Felipe, Thank you, the reordering dma patch fixed the dma issue I was having! However, the bad news, I now get the same results for the dma and non-dma spidev test. While the scope shows the SPI clk and data is fine, the reading from the program still shows 0x00 for all words. root@beaglebone:~# ./spidev spi mode: 0 bits per word: 16 max speed: 24000000 Hz (24000 KHz) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@beaglebone:~# ./spidev_dma spi mode: 0 bits per word: 8 max speed: 500000 Hz (500 KHz) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@beaglebone:~# dmesg shows nothing of interest apart from the spi bus setting up. Any ideas? To iterate for my own sanity; I have bridged pins 18 and 21 on the P9 header which should be the d0 and d1 spi data pins for spi0. This result of 0x00 usually comes from a result of not joining the pins, but I can assure you they are joined! Thank you for the help so far. -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 10:17 ` Jack Mitchell @ 2012-12-11 10:20 ` Felipe Balbi 2012-12-11 10:38 ` Jack Mitchell 2012-12-11 15:22 ` Ben Gamari 1 sibling, 1 reply; 27+ messages in thread From: Felipe Balbi @ 2012-12-11 10:20 UTC (permalink / raw) To: Jack Mitchell; +Cc: balbi, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 1149 bytes --] Hi, On Tue, Dec 11, 2012 at 10:17:42AM +0000, Jack Mitchell wrote: <big snip> > Shubhro, Felipe, > > Thank you, the reordering dma patch fixed the dma issue I was having! > However, the bad news, I now get the same results for the dma and > non-dma spidev test. While the scope shows the SPI clk and data is > fine, the reading from the program still shows 0x00 for all words. <removed spidev_test output> > dmesg shows nothing of interest apart from the spi bus setting up. > Any ideas? > > To iterate for my own sanity; I have bridged pins 18 and 21 on the P9 > header which should be the d0 and d1 spi data pins for spi0. This > result of 0x00 usually comes from a result of not joining the pins, > but I can assure you they are joined! > > Thank you for the help so far. according to the schematics [1], those pins are muxed as UART2_TXD and I2C1_SDA, have you remuxed them properly ? Can you try with pins 29 and 30 on the same header ? That's SPI1, so you will have to add DT data for spidev on that bus too. [1] http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 10:20 ` Felipe Balbi @ 2012-12-11 10:38 ` Jack Mitchell 2012-12-11 11:48 ` Felipe Balbi 0 siblings, 1 reply; 27+ messages in thread From: Jack Mitchell @ 2012-12-11 10:38 UTC (permalink / raw) To: balbi; +Cc: linux-omap, Shubhrajyoti Datta On 11/12/12 10:20, Felipe Balbi wrote: > Hi, > > On Tue, Dec 11, 2012 at 10:17:42AM +0000, Jack Mitchell wrote: > > <big snip> > >> Shubhro, Felipe, >> >> Thank you, the reordering dma patch fixed the dma issue I was having! >> However, the bad news, I now get the same results for the dma and >> non-dma spidev test. While the scope shows the SPI clk and data is >> fine, the reading from the program still shows 0x00 for all words. > <removed spidev_test output> > >> dmesg shows nothing of interest apart from the spi bus setting up. >> Any ideas? >> >> To iterate for my own sanity; I have bridged pins 18 and 21 on the P9 >> header which should be the d0 and d1 spi data pins for spi0. This >> result of 0x00 usually comes from a result of not joining the pins, >> but I can assure you they are joined! >> >> Thank you for the help so far. > according to the schematics [1], those pins are muxed as UART2_TXD and > I2C1_SDA, have you remuxed them properly ? Can you try with pins 29 and > 30 on the same header ? That's SPI1, so you will have to add DT data for > spidev on that bus too. > > [1] http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf > No change unfortunately: root@beaglebone:~# ./spidev spi mode: 0 bits per word: 16 max speed: 24000000 Hz (24000 KHz) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@beaglebone:~# ./spidev -D /dev/s shm/ spidev1.0 spidev2.0 stderr stdin stdout root@beaglebone:~# ./spidev -D /dev/spidev2.0 spi mode: 0 bits per word: 16 max speed: 24000000 Hz (24000 KHz) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 root@beaglebone:~# Cheers, Jack. -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 10:38 ` Jack Mitchell @ 2012-12-11 11:48 ` Felipe Balbi 2012-12-11 14:27 ` Felipe Balbi 0 siblings, 1 reply; 27+ messages in thread From: Felipe Balbi @ 2012-12-11 11:48 UTC (permalink / raw) To: Jack Mitchell; +Cc: balbi, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 2094 bytes --] Hi, On Tue, Dec 11, 2012 at 10:38:58AM +0000, Jack Mitchell wrote: > On 11/12/12 10:20, Felipe Balbi wrote: > >Hi, > > > >On Tue, Dec 11, 2012 at 10:17:42AM +0000, Jack Mitchell wrote: > > > ><big snip> > > > >>Shubhro, Felipe, > >> > >>Thank you, the reordering dma patch fixed the dma issue I was having! > >>However, the bad news, I now get the same results for the dma and > >>non-dma spidev test. While the scope shows the SPI clk and data is > >>fine, the reading from the program still shows 0x00 for all words. > ><removed spidev_test output> > > > >>dmesg shows nothing of interest apart from the spi bus setting up. > >>Any ideas? > >> > >>To iterate for my own sanity; I have bridged pins 18 and 21 on the P9 > >>header which should be the d0 and d1 spi data pins for spi0. This > >>result of 0x00 usually comes from a result of not joining the pins, > >>but I can assure you they are joined! > >> > >>Thank you for the help so far. > >according to the schematics [1], those pins are muxed as UART2_TXD and > >I2C1_SDA, have you remuxed them properly ? Can you try with pins 29 and > >30 on the same header ? That's SPI1, so you will have to add DT data for > >spidev on that bus too. > > > >[1] http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf > > > > No change unfortunately: > > root@beaglebone:~# ./spidev > spi mode: 0 > bits per word: 16 > max speed: 24000000 Hz (24000 KHz) > > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 > > root@beaglebone:~# ./spidev -D /dev/s > shm/ spidev1.0 spidev2.0 stderr stdin stdout > root@beaglebone:~# ./spidev -D /dev/spidev2.0 > spi mode: 0 > bits per word: 16 > max speed: 24000000 Hz (24000 KHz) > > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 00 00 00 00 > 00 00 > root@beaglebone:~# weird... I'll try to test with my pandaboard and see what's the outcome of that. -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 11:48 ` Felipe Balbi @ 2012-12-11 14:27 ` Felipe Balbi 2012-12-11 15:23 ` Jack Mitchell 0 siblings, 1 reply; 27+ messages in thread From: Felipe Balbi @ 2012-12-11 14:27 UTC (permalink / raw) To: Felipe Balbi; +Cc: Jack Mitchell, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 3425 bytes --] Hi again, On Tue, Dec 11, 2012 at 01:48:10PM +0200, Felipe Balbi wrote: > On Tue, Dec 11, 2012 at 10:38:58AM +0000, Jack Mitchell wrote: > > On 11/12/12 10:20, Felipe Balbi wrote: > > >Hi, > > > > > >On Tue, Dec 11, 2012 at 10:17:42AM +0000, Jack Mitchell wrote: > > > > > ><big snip> > > > > > >>Shubhro, Felipe, > > >> > > >>Thank you, the reordering dma patch fixed the dma issue I was having! > > >>However, the bad news, I now get the same results for the dma and > > >>non-dma spidev test. While the scope shows the SPI clk and data is > > >>fine, the reading from the program still shows 0x00 for all words. > > ><removed spidev_test output> > > > > > >>dmesg shows nothing of interest apart from the spi bus setting up. > > >>Any ideas? > > >> > > >>To iterate for my own sanity; I have bridged pins 18 and 21 on the P9 > > >>header which should be the d0 and d1 spi data pins for spi0. This > > >>result of 0x00 usually comes from a result of not joining the pins, > > >>but I can assure you they are joined! > > >> > > >>Thank you for the help so far. > > >according to the schematics [1], those pins are muxed as UART2_TXD and > > >I2C1_SDA, have you remuxed them properly ? Can you try with pins 29 and > > >30 on the same header ? That's SPI1, so you will have to add DT data for > > >spidev on that bus too. > > > > > >[1] http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf > > > > > > > No change unfortunately: > > > > root@beaglebone:~# ./spidev > > spi mode: 0 > > bits per word: 16 > > max speed: 24000000 Hz (24000 KHz) > > > > 00 00 00 00 00 00 > > 00 00 00 00 00 00 > > 00 00 00 00 00 00 > > 00 00 00 00 00 00 > > 00 00 00 00 00 00 > > 00 00 00 00 00 00 > > 00 00 > > > > root@beaglebone:~# ./spidev -D /dev/s > > shm/ spidev1.0 spidev2.0 stderr stdin stdout > > root@beaglebone:~# ./spidev -D /dev/spidev2.0 one thing caught my attention, shouldn't you be passing '-l' argument here for loopback testing ? That would mean you need to make sure your "spi->mode" has SPI_LOOP flag set. Currently there is no way to do that via DeviceTree (AFAICT), so please apply ths patch to your tree and set spi-loopback; property for your spidev entry: diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index 296015e..1949586 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -55,6 +55,8 @@ contain the following properties. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-loopback - (optional) Empty property indicating device requires + loopback mode. If a gpio chipselect is used for the SPI slave the gpio number will be passed via the cs_gpio diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 3f1b9ee..6bcdc03 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -868,6 +868,8 @@ static void of_register_spi_devices(struct spi_master *master) spi->mode |= SPI_CS_HIGH; if (of_find_property(nc, "spi-3wire", NULL)) spi->mode |= SPI_3WIRE; + if (of_find_property(nc, "spi-loopback", NULL)) + spi->mode |= SPI_LOOP; /* Device speed */ prop = of_get_property(nc, "spi-max-frequency", &len); -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 14:27 ` Felipe Balbi @ 2012-12-11 15:23 ` Jack Mitchell 2012-12-11 16:15 ` Felipe Balbi 0 siblings, 1 reply; 27+ messages in thread From: Jack Mitchell @ 2012-12-11 15:23 UTC (permalink / raw) To: balbi; +Cc: linux-omap, Shubhrajyoti Datta On 11/12/12 14:27, Felipe Balbi wrote: > Hi again, > > On Tue, Dec 11, 2012 at 01:48:10PM +0200, Felipe Balbi wrote: >> On Tue, Dec 11, 2012 at 10:38:58AM +0000, Jack Mitchell wrote: >>> On 11/12/12 10:20, Felipe Balbi wrote: >>>> Hi, >>>> >>>> On Tue, Dec 11, 2012 at 10:17:42AM +0000, Jack Mitchell wrote: >>>> >>>> <big snip> >>>> >>>>> Shubhro, Felipe, >>>>> >>>>> Thank you, the reordering dma patch fixed the dma issue I was having! >>>>> However, the bad news, I now get the same results for the dma and >>>>> non-dma spidev test. While the scope shows the SPI clk and data is >>>>> fine, the reading from the program still shows 0x00 for all words. >>>> <removed spidev_test output> >>>> >>>>> dmesg shows nothing of interest apart from the spi bus setting up. >>>>> Any ideas? >>>>> >>>>> To iterate for my own sanity; I have bridged pins 18 and 21 on the P9 >>>>> header which should be the d0 and d1 spi data pins for spi0. This >>>>> result of 0x00 usually comes from a result of not joining the pins, >>>>> but I can assure you they are joined! >>>>> >>>>> Thank you for the help so far. >>>> according to the schematics [1], those pins are muxed as UART2_TXD and >>>> I2C1_SDA, have you remuxed them properly ? Can you try with pins 29 and >>>> 30 on the same header ? That's SPI1, so you will have to add DT data for >>>> spidev on that bus too. >>>> >>>> [1] http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf >>>> >>> No change unfortunately: >>> >>> root@beaglebone:~# ./spidev >>> spi mode: 0 >>> bits per word: 16 >>> max speed: 24000000 Hz (24000 KHz) >>> >>> 00 00 00 00 00 00 >>> 00 00 00 00 00 00 >>> 00 00 00 00 00 00 >>> 00 00 00 00 00 00 >>> 00 00 00 00 00 00 >>> 00 00 00 00 00 00 >>> 00 00 >>> >>> root@beaglebone:~# ./spidev -D /dev/s >>> shm/ spidev1.0 spidev2.0 stderr stdin stdout >>> root@beaglebone:~# ./spidev -D /dev/spidev2.0 > one thing caught my attention, shouldn't you be passing '-l' argument > here for loopback testing ? That would mean you need to make sure your > "spi->mode" has SPI_LOOP flag set. Currently there is no way to do that > via DeviceTree (AFAICT), so please apply ths patch to your tree and set > spi-loopback; property for your spidev entry: > > diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt > index 296015e..1949586 100644 > --- a/Documentation/devicetree/bindings/spi/spi-bus.txt > +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt > @@ -55,6 +55,8 @@ contain the following properties. > chip select active high > - spi-3wire - (optional) Empty property indicating device requires > 3-wire mode. > +- spi-loopback - (optional) Empty property indicating device requires > + loopback mode. > > If a gpio chipselect is used for the SPI slave the gpio number will be passed > via the cs_gpio > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > index 3f1b9ee..6bcdc03 100644 > --- a/drivers/spi/spi.c > +++ b/drivers/spi/spi.c > @@ -868,6 +868,8 @@ static void of_register_spi_devices(struct spi_master *master) > spi->mode |= SPI_CS_HIGH; > if (of_find_property(nc, "spi-3wire", NULL)) > spi->mode |= SPI_3WIRE; > + if (of_find_property(nc, "spi-loopback", NULL)) > + spi->mode |= SPI_LOOP; > > /* Device speed */ > prop = of_get_property(nc, "spi-max-frequency", &len); > I get the following error when I apply this patch and add spi-loopback. &spi0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; spidev0: spidev@0 { compatible = "linux,spidev"; reg = <0>; spi-max-frequency = <24000000>; spi-loopback; }; }; [ 1.093565] omap2_mcspi 48030000.spi: registered master spi1 [ 1.094491] spi spi1.0: setup: unsupported mode bits 20 [ 1.100035] omap2_mcspi 48030000.spi: can't setup spi1.0, status -22 [ 1.106715] spi_master spi1: spi_device register error /ocp/spi@48030000/spidev@0 [ 1.115030] omap2_mcspi 481a0000.spi: registered master spi2 [ 1.115710] spi spi2.0: setup: unsupported mode bits 20 [ 1.121225] omap2_mcspi 481a0000.spi: can't setup spi2.0, status -22 [ 1.127903] spi_master spi2: spi_device register error /ocp/spi@481a0000/spidev@0 I have run this test many times before and have never needed to use a loopback... -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 15:23 ` Jack Mitchell @ 2012-12-11 16:15 ` Felipe Balbi 0 siblings, 0 replies; 27+ messages in thread From: Felipe Balbi @ 2012-12-11 16:15 UTC (permalink / raw) To: Jack Mitchell; +Cc: balbi, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 5021 bytes --] Hi, On Tue, Dec 11, 2012 at 03:23:48PM +0000, Jack Mitchell wrote: > On 11/12/12 14:27, Felipe Balbi wrote: > >Hi again, > > > >On Tue, Dec 11, 2012 at 01:48:10PM +0200, Felipe Balbi wrote: > >>On Tue, Dec 11, 2012 at 10:38:58AM +0000, Jack Mitchell wrote: > >>>On 11/12/12 10:20, Felipe Balbi wrote: > >>>>Hi, > >>>> > >>>>On Tue, Dec 11, 2012 at 10:17:42AM +0000, Jack Mitchell wrote: > >>>> > >>>><big snip> > >>>> > >>>>>Shubhro, Felipe, > >>>>> > >>>>>Thank you, the reordering dma patch fixed the dma issue I was having! > >>>>>However, the bad news, I now get the same results for the dma and > >>>>>non-dma spidev test. While the scope shows the SPI clk and data is > >>>>>fine, the reading from the program still shows 0x00 for all words. > >>>><removed spidev_test output> > >>>> > >>>>>dmesg shows nothing of interest apart from the spi bus setting up. > >>>>>Any ideas? > >>>>> > >>>>>To iterate for my own sanity; I have bridged pins 18 and 21 on the P9 > >>>>>header which should be the d0 and d1 spi data pins for spi0. This > >>>>>result of 0x00 usually comes from a result of not joining the pins, > >>>>>but I can assure you they are joined! > >>>>> > >>>>>Thank you for the help so far. > >>>>according to the schematics [1], those pins are muxed as UART2_TXD and > >>>>I2C1_SDA, have you remuxed them properly ? Can you try with pins 29 and > >>>>30 on the same header ? That's SPI1, so you will have to add DT data for > >>>>spidev on that bus too. > >>>> > >>>>[1] http://beagleboard.org/static/beaglebone/latest/Docs/Hardware/BONE_SCH.pdf > >>>> > >>>No change unfortunately: > >>> > >>>root@beaglebone:~# ./spidev > >>>spi mode: 0 > >>>bits per word: 16 > >>>max speed: 24000000 Hz (24000 KHz) > >>> > >>>00 00 00 00 00 00 > >>>00 00 00 00 00 00 > >>>00 00 00 00 00 00 > >>>00 00 00 00 00 00 > >>>00 00 00 00 00 00 > >>>00 00 00 00 00 00 > >>>00 00 > >>> > >>>root@beaglebone:~# ./spidev -D /dev/s > >>>shm/ spidev1.0 spidev2.0 stderr stdin stdout > >>>root@beaglebone:~# ./spidev -D /dev/spidev2.0 > >one thing caught my attention, shouldn't you be passing '-l' argument > >here for loopback testing ? That would mean you need to make sure your > >"spi->mode" has SPI_LOOP flag set. Currently there is no way to do that > >via DeviceTree (AFAICT), so please apply ths patch to your tree and set > >spi-loopback; property for your spidev entry: > > > >diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt > >index 296015e..1949586 100644 > >--- a/Documentation/devicetree/bindings/spi/spi-bus.txt > >+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt > >@@ -55,6 +55,8 @@ contain the following properties. > > chip select active high > > - spi-3wire - (optional) Empty property indicating device requires > > 3-wire mode. > >+- spi-loopback - (optional) Empty property indicating device requires > >+ loopback mode. > > If a gpio chipselect is used for the SPI slave the gpio number will be passed > > via the cs_gpio > >diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > >index 3f1b9ee..6bcdc03 100644 > >--- a/drivers/spi/spi.c > >+++ b/drivers/spi/spi.c > >@@ -868,6 +868,8 @@ static void of_register_spi_devices(struct spi_master *master) > > spi->mode |= SPI_CS_HIGH; > > if (of_find_property(nc, "spi-3wire", NULL)) > > spi->mode |= SPI_3WIRE; > >+ if (of_find_property(nc, "spi-loopback", NULL)) > >+ spi->mode |= SPI_LOOP; > > /* Device speed */ > > prop = of_get_property(nc, "spi-max-frequency", &len); > > > > I get the following error when I apply this patch and add spi-loopback. > > &spi0 { > status = "okay"; > pinctrl-names = "default"; > pinctrl-0 = <&spi0_pins>; > > spidev0: spidev@0 { > compatible = "linux,spidev"; > reg = <0>; > spi-max-frequency = <24000000>; > spi-loopback; > }; > > }; > > [ 1.093565] omap2_mcspi 48030000.spi: registered master spi1 > [ 1.094491] spi spi1.0: setup: unsupported mode bits 20 > [ 1.100035] omap2_mcspi 48030000.spi: can't setup spi1.0, status -22 > [ 1.106715] spi_master spi1: spi_device register error > /ocp/spi@48030000/spidev@0 > [ 1.115030] omap2_mcspi 481a0000.spi: registered master spi2 > [ 1.115710] spi spi2.0: setup: unsupported mode bits 20 > [ 1.121225] omap2_mcspi 481a0000.spi: can't setup spi2.0, status -22 > [ 1.127903] spi_master spi2: spi_device register error > /ocp/spi@481a0000/spidev@0 > > I have run this test many times before and have never needed to use a > loopback... I finally managed to test with my pandaboard and I have same results as yourself (btw you need to SPI_LOOP to mode_bits on drivers/spi/spi-omap2-mcspi.c for this to probe fine, my bad). I have looked at the pins over and over again and I'm sure I'm shorting the correct pins... Oh well, time to debug :-p -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 10:17 ` Jack Mitchell 2012-12-11 10:20 ` Felipe Balbi @ 2012-12-11 15:22 ` Ben Gamari 2012-12-11 16:24 ` Jack Mitchell 1 sibling, 1 reply; 27+ messages in thread From: Ben Gamari @ 2012-12-11 15:22 UTC (permalink / raw) To: ml, balbi; +Cc: linux-omap, Shubhrajyoti Datta Jack Mitchell <ml@communistcode.co.uk> writes: > Shubhro, Felipe, > > Thank you, the reordering dma patch fixed the dma issue I was having! > However, the bad news, I now get the same results for the dma and > non-dma spidev test. While the scope shows the SPI clk and data is fine, > the reading from the program still shows 0x00 for all words. > Just to make sure this has been thought of: I've seen this sort of behavior in the past when the CLK pin wasn't configured as an input. Cheers, - Ben ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 15:22 ` Ben Gamari @ 2012-12-11 16:24 ` Jack Mitchell 2012-12-11 16:36 ` Jack Mitchell ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Jack Mitchell @ 2012-12-11 16:24 UTC (permalink / raw) To: Ben Gamari; +Cc: balbi, linux-omap, Shubhrajyoti Datta On 11/12/12 15:22, Ben Gamari wrote: > Jack Mitchell <ml@communistcode.co.uk> writes: > >> Shubhro, Felipe, >> >> Thank you, the reordering dma patch fixed the dma issue I was having! >> However, the bad news, I now get the same results for the dma and >> non-dma spidev test. While the scope shows the SPI clk and data is fine, >> the reading from the program still shows 0x00 for all words. >> > Just to make sure this has been thought of: I've seen this sort of > behavior in the past when the CLK pin wasn't configured as an input. > > Cheers, > > - Ben > Ok, Ben, well spotted indeed! I changed the dtsi to use INPUT_PULLUP instead of OUTPUT_PULLUP and wallah! am3358_pinmux: pinmux@44e10800 { spi0_pins: pinmux_spi0_pins { pinctrl-single,pins = < 0x150 *0x30* /* spi0_sclk.gpio0_2, INPUT_PULLUP | MODE0 */<------------ changed to INPUT 0x154 0x30 /* spi0_d0.gpio0_3, INPUT_PULLUP | MODE0 */ 0x158 0x10 /* spi0_d1.i2c1_sda, OUTPUT_PULLUP | MODE0 */ 0x15c 0x10 /* spi0_cs0.i2c1_scl, OUTPUT_PULLUP | MODE0 */ >; }; spi1_pins: pinmux_spi1_pins { pinctrl-single,pins = < 0x190 *0x33* /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 */ <------------ changed to INPUT 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */ 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */ >; }; root@beaglebone:~# ./spidev spi mode: 0 bits per word: 16 max speed: 24000000 Hz (24000 KHz) FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF DE AD BE EF BA AD F0 0D root@beaglebone:~# ./spidev_dma spi mode: 0 bits per word: 8 max speed: 500000 Hz (500 KHz) FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 We are in business! Almost. I then tried spi1 and received: root@beaglebone:~# ./spidev -D /dev/spidev2.0 spi mode: 0 bits per word: 16 max speed: 24000000 Hz (24000 KHz) FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF root@beaglebone:~# ./spidev_dma -D /dev/spidev2.0 spi mode: 0 bits per word: 8 max speed: 500000 Hz (500 KHz) FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF root@beaglebone:~# -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 16:24 ` Jack Mitchell @ 2012-12-11 16:36 ` Jack Mitchell 2012-12-11 17:02 ` Jack Mitchell 2012-12-11 17:03 ` Felipe Balbi 2 siblings, 0 replies; 27+ messages in thread From: Jack Mitchell @ 2012-12-11 16:36 UTC (permalink / raw) To: ml; +Cc: Ben Gamari, balbi, linux-omap, Shubhrajyoti Datta On 11/12/12 16:24, Jack Mitchell wrote: > On 11/12/12 15:22, Ben Gamari wrote: >> Jack Mitchell <ml@communistcode.co.uk> writes: >> <snip> > > Almost. > > I then tried spi1 and received: > > root@beaglebone:~# ./spidev -D /dev/spidev2.0 > spi mode: 0 > bits per word: 16 > max speed: 24000000 Hz (24000 KHz) > > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF > root@beaglebone:~# ./spidev_dma -D /dev/spidev2.0 > spi mode: 0 > bits per word: 8 > max speed: 500000 Hz (500 KHz) > > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > root@beaglebone:~# > > My bad! The jumper bridge had come loose, it works now! Yippee! root@beaglebone:~# ./spidev -D /dev/spidev2.0 spi mode: 0 bits per word: 16 max speed: 24000000 Hz (24000 KHz) FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF DE AD BE EF BA AD F0 0D root@beaglebone:~# Thanks everyone, and do I need to submit any patches to clear this all up? Currently all I see is changing the clk pins from output to input (if this is a valid change?). ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 16:24 ` Jack Mitchell 2012-12-11 16:36 ` Jack Mitchell @ 2012-12-11 17:02 ` Jack Mitchell 2013-01-04 14:46 ` Jan Lübbe 2012-12-11 17:03 ` Felipe Balbi 2 siblings, 1 reply; 27+ messages in thread From: Jack Mitchell @ 2012-12-11 17:02 UTC (permalink / raw) To: ml; +Cc: Ben Gamari, balbi, linux-omap On 11/12/12 16:24, Jack Mitchell wrote: > On 11/12/12 15:22, Ben Gamari wrote: >> Jack Mitchell <ml@communistcode.co.uk> writes: >> >>> Shubhro, Felipe, >>> >>> Thank you, the reordering dma patch fixed the dma issue I was having! >>> However, the bad news, I now get the same results for the dma and >>> non-dma spidev test. While the scope shows the SPI clk and data is >>> fine, >>> the reading from the program still shows 0x00 for all words. >>> >> Just to make sure this has been thought of: I've seen this sort of >> behavior in the past when the CLK pin wasn't configured as an input. >> >> Cheers, >> >> - Ben >> > > Ok, Ben, well spotted indeed! I changed the dtsi to use INPUT_PULLUP > instead of OUTPUT_PULLUP and wallah! > > am3358_pinmux: pinmux@44e10800 { > spi0_pins: pinmux_spi0_pins { > pinctrl-single,pins = < > 0x150 *0x30* /* spi0_sclk.gpio0_2, INPUT_PULLUP | MODE0 > */<------------ changed to INPUT > 0x154 0x30 /* spi0_d0.gpio0_3, INPUT_PULLUP | MODE0 */ > 0x158 0x10 /* spi0_d1.i2c1_sda, OUTPUT_PULLUP | MODE0 */ > 0x15c 0x10 /* spi0_cs0.i2c1_scl, OUTPUT_PULLUP | MODE0 */ > >; > }; > spi1_pins: pinmux_spi1_pins { > pinctrl-single,pins = < > 0x190 *0x33* /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 > */ <------------ changed to INPUT > 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */ > 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */ > 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */ > >; > }; > > > root@beaglebone:~# ./spidev > spi mode: 0 > bits per word: 16 > max speed: 24000000 Hz (24000 KHz) > > FF FF FF FF FF FF > 40 00 00 00 00 95 > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > DE AD BE EF BA AD > F0 0D > root@beaglebone:~# ./spidev_dma > spi mode: 0 > bits per word: 8 > max speed: 500000 Hz (500 KHz) > > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > FF 00 FF 00 FF 00 > > We are in business! > > Almost. > > I then tried spi1 and received: > > root@beaglebone:~# ./spidev -D /dev/spidev2.0 > spi mode: 0 > bits per word: 16 > max speed: 24000000 Hz (24000 KHz) > > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF > root@beaglebone:~# ./spidev_dma -D /dev/spidev2.0 > spi mode: 0 > bits per word: 8 > max speed: 500000 Hz (500 KHz) > > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > root@beaglebone:~# > > My bad! The jumper bridge had come loose, it works now! Yippee! root@beaglebone:~# ./spidev -D /dev/spidev2.0 spi mode: 0 bits per word: 16 max speed: 24000000 Hz (24000 KHz) FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF DE AD BE EF BA AD F0 0D root@beaglebone:~# Thanks everyone, and do I need to submit any patches to clear this all up? Currently all I see is changing the clk pins from output to input (if this is a valid change?). -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 17:02 ` Jack Mitchell @ 2013-01-04 14:46 ` Jan Lübbe 2013-01-04 16:21 ` Jack Mitchell 0 siblings, 1 reply; 27+ messages in thread From: Jan Lübbe @ 2013-01-04 14:46 UTC (permalink / raw) To: ml; +Cc: Ben Gamari, balbi, linux-omap Hi, On Tue, 2012-12-11 at 17:02 +0000, Jack Mitchell wrote: > On 11/12/12 16:24, Jack Mitchell wrote: > > On 11/12/12 15:22, Ben Gamari wrote: > >> Jack Mitchell <ml@communistcode.co.uk> writes: > >>> Thank you, the reordering dma patch fixed the dma issue I was having! > >>> However, the bad news, I now get the same results for the dma and > >>> non-dma spidev test. While the scope shows the SPI clk and data is > >>> fine, > >>> the reading from the program still shows 0x00 for all words. > >>> > >> Just to make sure this has been thought of: I've seen this sort of > >> behavior in the past when the CLK pin wasn't configured as an input. *snip* > My bad! The jumper bridge had come loose, it works now! Yippee! > > root@beaglebone:~# ./spidev -D /dev/spidev2.0 > spi mode: 0 > bits per word: 16 > max speed: 24000000 Hz (24000 KHz) > > FF FF FF FF FF FF > 40 00 00 00 00 95 > FF FF FF FF FF FF > FF FF FF FF FF FF > FF FF FF FF FF FF > DE AD BE EF BA AD > F0 0D > root@beaglebone:~# > > Thanks everyone, and do I need to submit any patches to clear this all up? > > Currently all I see is changing the clk pins from output to input (if > this is a valid change?). I just stumbled over the same problem and have not seen any patch for this fix. Have I missed something or should I send a patch? Which would be the correct base for such a patch? Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2013-01-04 14:46 ` Jan Lübbe @ 2013-01-04 16:21 ` Jack Mitchell 2013-01-04 16:36 ` Jack Mitchell 0 siblings, 1 reply; 27+ messages in thread From: Jack Mitchell @ 2013-01-04 16:21 UTC (permalink / raw) To: Jan Lübbe; +Cc: Ben Gamari, balbi, linux-omap On 04/01/13 14:46, Jan Lübbe wrote: > Hi, > > On Tue, 2012-12-11 at 17:02 +0000, Jack Mitchell wrote: >> On 11/12/12 16:24, Jack Mitchell wrote: >>> On 11/12/12 15:22, Ben Gamari wrote: >>>> Jack Mitchell <ml@communistcode.co.uk> writes: >>>>> Thank you, the reordering dma patch fixed the dma issue I was having! >>>>> However, the bad news, I now get the same results for the dma and >>>>> non-dma spidev test. While the scope shows the SPI clk and data is >>>>> fine, >>>>> the reading from the program still shows 0x00 for all words. >>>>> >>>> Just to make sure this has been thought of: I've seen this sort of >>>> behavior in the past when the CLK pin wasn't configured as an input. > *snip* > >> My bad! The jumper bridge had come loose, it works now! Yippee! >> >> root@beaglebone:~# ./spidev -D /dev/spidev2.0 >> spi mode: 0 >> bits per word: 16 >> max speed: 24000000 Hz (24000 KHz) >> >> FF FF FF FF FF FF >> 40 00 00 00 00 95 >> FF FF FF FF FF FF >> FF FF FF FF FF FF >> FF FF FF FF FF FF >> DE AD BE EF BA AD >> F0 0D >> root@beaglebone:~# >> >> Thanks everyone, and do I need to submit any patches to clear this all up? >> >> Currently all I see is changing the clk pins from output to input (if >> this is a valid change?). > I just stumbled over the same problem and have not seen any patch for > this fix. Have I missed something or should I send a patch? Which would > be the correct base for such a patch? > > Regards, > Jan I didn't submit a patch for this but easily could. I was confused about what tree to base it against as at the time (may still be the same) DT SPI for AM335x was not in a mainline tree. I hoped someone would pick it up when posting DT SPI for mainline.... -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2013-01-04 16:21 ` Jack Mitchell @ 2013-01-04 16:36 ` Jack Mitchell 0 siblings, 0 replies; 27+ messages in thread From: Jack Mitchell @ 2013-01-04 16:36 UTC (permalink / raw) To: ml; +Cc: Jan Lübbe, Ben Gamari, balbi, linux-omap, mporter On 04/01/13 16:21, Jack Mitchell wrote: > On 04/01/13 14:46, Jan Lübbe wrote: >> Hi, >> >> On Tue, 2012-12-11 at 17:02 +0000, Jack Mitchell wrote: >>> On 11/12/12 16:24, Jack Mitchell wrote: >>>> On 11/12/12 15:22, Ben Gamari wrote: >>>>> Jack Mitchell <ml@communistcode.co.uk> writes: >>>>>> Thank you, the reordering dma patch fixed the dma issue I was >>>>>> having! >>>>>> However, the bad news, I now get the same results for the dma and >>>>>> non-dma spidev test. While the scope shows the SPI clk and data is >>>>>> fine, >>>>>> the reading from the program still shows 0x00 for all words. >>>>>> >>>>> Just to make sure this has been thought of: I've seen this sort of >>>>> behavior in the past when the CLK pin wasn't configured as an input. >> *snip* >> >>> My bad! The jumper bridge had come loose, it works now! Yippee! >>> >>> root@beaglebone:~# ./spidev -D /dev/spidev2.0 >>> spi mode: 0 >>> bits per word: 16 >>> max speed: 24000000 Hz (24000 KHz) >>> >>> FF FF FF FF FF FF >>> 40 00 00 00 00 95 >>> FF FF FF FF FF FF >>> FF FF FF FF FF FF >>> FF FF FF FF FF FF >>> DE AD BE EF BA AD >>> F0 0D >>> root@beaglebone:~# >>> >>> Thanks everyone, and do I need to submit any patches to clear this >>> all up? >>> >>> Currently all I see is changing the clk pins from output to input (if >>> this is a valid change?). >> I just stumbled over the same problem and have not seen any patch for >> this fix. Have I missed something or should I send a patch? Which would >> be the correct base for such a patch? >> >> Regards, >> Jan > > I didn't submit a patch for this but easily could. I was confused > about what tree to base it against as at the time (may still be the > same) DT SPI for AM335x was not in a mainline tree. I hoped someone > would pick it up when posting DT SPI for mainline.... > I've just had confirmation from Matt Porter on IRC that this change will be present in the next iteration of his DMA Engine series, which I believe brings in the DT SPI support. Cheers All, Jack -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 16:24 ` Jack Mitchell 2012-12-11 16:36 ` Jack Mitchell 2012-12-11 17:02 ` Jack Mitchell @ 2012-12-11 17:03 ` Felipe Balbi 2012-12-11 17:52 ` Felipe Balbi 2 siblings, 1 reply; 27+ messages in thread From: Felipe Balbi @ 2012-12-11 17:03 UTC (permalink / raw) To: Jack Mitchell; +Cc: Ben Gamari, balbi, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 2276 bytes --] Hi, On Tue, Dec 11, 2012 at 04:24:52PM +0000, Jack Mitchell wrote: > On 11/12/12 15:22, Ben Gamari wrote: > >Jack Mitchell <ml@communistcode.co.uk> writes: > > > >>Shubhro, Felipe, > >> > >>Thank you, the reordering dma patch fixed the dma issue I was having! > >>However, the bad news, I now get the same results for the dma and > >>non-dma spidev test. While the scope shows the SPI clk and data is fine, > >>the reading from the program still shows 0x00 for all words. > >> > >Just to make sure this has been thought of: I've seen this sort of > >behavior in the past when the CLK pin wasn't configured as an input. > > > >Cheers, > > > >- Ben > > > > Ok, Ben, well spotted indeed! I changed the dtsi to use INPUT_PULLUP > instead of OUTPUT_PULLUP and wallah! > > am3358_pinmux: pinmux@44e10800 { > spi0_pins: pinmux_spi0_pins { > pinctrl-single,pins = < > 0x150 *0x30* /* spi0_sclk.gpio0_2, INPUT_PULLUP | MODE0 > */<------------ changed to INPUT > 0x154 0x30 /* spi0_d0.gpio0_3, INPUT_PULLUP | MODE0 */ > 0x158 0x10 /* spi0_d1.i2c1_sda, OUTPUT_PULLUP | MODE0 */ > 0x15c 0x10 /* spi0_cs0.i2c1_scl, OUTPUT_PULLUP | MODE0 */ > >; > }; > spi1_pins: pinmux_spi1_pins { > pinctrl-single,pins = < > 0x190 *0x33* /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 > */ <------------ changed to INPUT > 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */ > 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */ > 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */ > >; > }; funny, I did the same on my pandaboard and it still didn't work :-s @@ -321,6 +322,10 @@ static struct omap_board_mux board_mux[] __initdata = { OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), + + /* SPI1 */ + OMAP4_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), + /* gpio 0 - TFP410 PD */ OMAP4_MUX(KPD_COL1, OMAP_PIN_OUTPUT | OMAP_MUX_MODE3), /* dispc2_data23 */ -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 17:03 ` Felipe Balbi @ 2012-12-11 17:52 ` Felipe Balbi 2012-12-12 8:07 ` Felipe Balbi 0 siblings, 1 reply; 27+ messages in thread From: Felipe Balbi @ 2012-12-11 17:52 UTC (permalink / raw) To: Felipe Balbi; +Cc: Jack Mitchell, Ben Gamari, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 2472 bytes --] Hi, On Tue, Dec 11, 2012 at 07:03:14PM +0200, Felipe Balbi wrote: > Hi, > > On Tue, Dec 11, 2012 at 04:24:52PM +0000, Jack Mitchell wrote: > > On 11/12/12 15:22, Ben Gamari wrote: > > >Jack Mitchell <ml@communistcode.co.uk> writes: > > > > > >>Shubhro, Felipe, > > >> > > >>Thank you, the reordering dma patch fixed the dma issue I was having! > > >>However, the bad news, I now get the same results for the dma and > > >>non-dma spidev test. While the scope shows the SPI clk and data is fine, > > >>the reading from the program still shows 0x00 for all words. > > >> > > >Just to make sure this has been thought of: I've seen this sort of > > >behavior in the past when the CLK pin wasn't configured as an input. > > > > > >Cheers, > > > > > >- Ben > > > > > > > Ok, Ben, well spotted indeed! I changed the dtsi to use INPUT_PULLUP > > instead of OUTPUT_PULLUP and wallah! > > > > am3358_pinmux: pinmux@44e10800 { > > spi0_pins: pinmux_spi0_pins { > > pinctrl-single,pins = < > > 0x150 *0x30* /* spi0_sclk.gpio0_2, INPUT_PULLUP | MODE0 > > */<------------ changed to INPUT > > 0x154 0x30 /* spi0_d0.gpio0_3, INPUT_PULLUP | MODE0 */ > > 0x158 0x10 /* spi0_d1.i2c1_sda, OUTPUT_PULLUP | MODE0 */ > > 0x15c 0x10 /* spi0_cs0.i2c1_scl, OUTPUT_PULLUP | MODE0 */ > > >; > > }; > > spi1_pins: pinmux_spi1_pins { > > pinctrl-single,pins = < > > 0x190 *0x33* /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 > > */ <------------ changed to INPUT > > 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */ > > 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */ > > 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */ > > >; > > }; > > funny, I did the same on my pandaboard and it still didn't work :-s > > @@ -321,6 +322,10 @@ static struct omap_board_mux board_mux[] __initdata = { > OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), > OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), > OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), > + > + /* SPI1 */ > + OMAP4_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), hehe, I'll reply to my own nonsense. Of course this won't work, I'm not muxing the other MCSPI pins :-p I'll do that tomorrow and test, cheers -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: AM335x BeagleBone SPI Issues 2012-12-11 17:52 ` Felipe Balbi @ 2012-12-12 8:07 ` Felipe Balbi 0 siblings, 0 replies; 27+ messages in thread From: Felipe Balbi @ 2012-12-12 8:07 UTC (permalink / raw) To: Felipe Balbi; +Cc: Jack Mitchell, Ben Gamari, linux-omap, Shubhrajyoti Datta [-- Attachment #1: Type: text/plain, Size: 2737 bytes --] Hi, On Tue, Dec 11, 2012 at 07:52:16PM +0200, Felipe Balbi wrote: > Hi, > > On Tue, Dec 11, 2012 at 07:03:14PM +0200, Felipe Balbi wrote: > > Hi, > > > > On Tue, Dec 11, 2012 at 04:24:52PM +0000, Jack Mitchell wrote: > > > On 11/12/12 15:22, Ben Gamari wrote: > > > >Jack Mitchell <ml@communistcode.co.uk> writes: > > > > > > > >>Shubhro, Felipe, > > > >> > > > >>Thank you, the reordering dma patch fixed the dma issue I was having! > > > >>However, the bad news, I now get the same results for the dma and > > > >>non-dma spidev test. While the scope shows the SPI clk and data is fine, > > > >>the reading from the program still shows 0x00 for all words. > > > >> > > > >Just to make sure this has been thought of: I've seen this sort of > > > >behavior in the past when the CLK pin wasn't configured as an input. > > > > > > > >Cheers, > > > > > > > >- Ben > > > > > > > > > > Ok, Ben, well spotted indeed! I changed the dtsi to use INPUT_PULLUP > > > instead of OUTPUT_PULLUP and wallah! > > > > > > am3358_pinmux: pinmux@44e10800 { > > > spi0_pins: pinmux_spi0_pins { > > > pinctrl-single,pins = < > > > 0x150 *0x30* /* spi0_sclk.gpio0_2, INPUT_PULLUP | MODE0 > > > */<------------ changed to INPUT > > > 0x154 0x30 /* spi0_d0.gpio0_3, INPUT_PULLUP | MODE0 */ > > > 0x158 0x10 /* spi0_d1.i2c1_sda, OUTPUT_PULLUP | MODE0 */ > > > 0x15c 0x10 /* spi0_cs0.i2c1_scl, OUTPUT_PULLUP | MODE0 */ > > > >; > > > }; > > > spi1_pins: pinmux_spi1_pins { > > > pinctrl-single,pins = < > > > 0x190 *0x33* /* mcasp0_aclkx.spi1_sclk, INPUT_PULLUP | MODE3 > > > */ <------------ changed to INPUT > > > 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */ > > > 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */ > > > 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */ > > > >; > > > }; > > > > funny, I did the same on my pandaboard and it still didn't work :-s > > > > @@ -321,6 +322,10 @@ static struct omap_board_mux board_mux[] __initdata = { > > OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), > > OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), > > OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), > > + > > + /* SPI1 */ > > + OMAP4_MUX(MCSPI1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), > > hehe, I'll reply to my own nonsense. Of course this won't work, I'm not > muxing the other MCSPI pins :-p > > I'll do that tomorrow and test, cheers fyi, after muxing all lines correctly it works just fine on my panda. -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* AM335x BeagleBone SPI Issues @ 2012-12-10 13:17 Jack Mitchell 0 siblings, 0 replies; 27+ messages in thread From: Jack Mitchell @ 2012-12-10 13:17 UTC (permalink / raw) To: linux-omap Hi, I am currently having issues with the SPI driver on the beaglebone using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have found that writing works however reading doesn't. When using DMA the program seems to lock hard and no data is sent on the bus. I am testing the bus using spidev and the spidev_test[2] application, however I first came across spi issues with a custom spi driver which stopped working when I transitioned from 3.2-psp to 3.7-rc8. The current output I am seeing from the spidev_test program is just a series of 0x00 data, which looks to me like no data is getting in at all. The spidev_test program is not using DMA as the buffer size is too low, so I forced the dma on when buffer size is > 1 and the program hangs hard with the system still responding to other commands.I have briged the pins 18 and 21 on the BeagleBone P9 header. Has anyone seen issues like this, or if not if someone could please test the latest 3.7-rc8 from [1] and let me know if it works for them and the issue is at my end. To get spidev working with devicetree I applied the patch from [3] and changed the dtb as in the patch pasted below. [1] https://github.com/beagleboard/kernel/tree/3.7 [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c [3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi index 543365d..8fff665 100644 --- a/arch/arm/boot/dts/am335x-bone-common.dtsi +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi @@ -440,10 +440,19 @@ }; &spi0 { + status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; + + spidev: spidev@0 { + compatible = "linux,spidev"; + reg = <0>; + spi-max-frequency = <24000000>; + }; + }; + &spi1 { pinctrl-names = "default"; pinctrl-0 = <&spi1_pins>; -- Jack Mitchell (jack@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- ^ permalink raw reply related [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-01-04 16:34 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-10 13:23 AM335x BeagleBone SPI Issues Jack Mitchell 2012-12-10 13:53 ` Felipe Balbi 2012-12-10 14:50 ` Jack Mitchell 2012-12-10 14:59 ` Felipe Balbi 2012-12-10 15:19 ` Jack Mitchell 2012-12-10 15:26 ` Shubhrajyoti Datta 2012-12-10 16:18 ` Jack Mitchell 2012-12-10 18:35 ` Felipe Balbi 2012-12-11 6:39 ` Shubhrajyoti Datta 2012-12-11 10:17 ` Jack Mitchell 2012-12-11 10:20 ` Felipe Balbi 2012-12-11 10:38 ` Jack Mitchell 2012-12-11 11:48 ` Felipe Balbi 2012-12-11 14:27 ` Felipe Balbi 2012-12-11 15:23 ` Jack Mitchell 2012-12-11 16:15 ` Felipe Balbi 2012-12-11 15:22 ` Ben Gamari 2012-12-11 16:24 ` Jack Mitchell 2012-12-11 16:36 ` Jack Mitchell 2012-12-11 17:02 ` Jack Mitchell 2013-01-04 14:46 ` Jan Lübbe 2013-01-04 16:21 ` Jack Mitchell 2013-01-04 16:36 ` Jack Mitchell 2012-12-11 17:03 ` Felipe Balbi 2012-12-11 17:52 ` Felipe Balbi 2012-12-12 8:07 ` Felipe Balbi -- strict thread matches above, loose matches on Subject: below -- 2012-12-10 13:17 Jack Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).