> On Dec 16, 2015, at 3:07 PM, William Hermans <[email protected]> wrote: > > No need to bitbang unless you want additional SPI ports available. Simply use > the McSPI port controlled from the PRU. > > If the module is true hardware SPI, you do not even need a PRU involved. > Except perhaps to move the data into LInux through some form of shared memory. It does if the PRU is controlling a SPI type device that needs real-time control loop. Nothing to do with Linux. > > That doesn’t make sense to me. I know a few months ago I was working on a SPI > driver and I had the same issue when my buffer exceeded 160 bytes. When I > used a DMA-coherent buffer, my driver worked fine. I was using an overlay to > load my driver during testing. My driver did not use SPIDEV. > > > It makes perfect sense. One way it using the hardware through it's registers > directly, while the other way is essentially bit banged master mode only SPI. Now you have lost me. In my case, I have a kernel module that talks to McSPI directly and that works with devicetree overlay and transfer sizes larger than 160 bytes. In Robert’s case, a user space application uses SPIDEV to transfer data to/from SPI, but it dies if the buffer is larger than 160 bytes and he uses devicetree overlay. If the SPIDEV device is in the initial *.dtb, it works fine for buffers larger than 160 bytes. I don’t know where a bitbang comes into this.
Regards, John > > On Wed, Dec 16, 2015 at 3:47 PM, John Syne <[email protected] > <mailto:[email protected]>> wrote: > > > On Dec 16, 2015, at 2:38 PM, Robert Nelson <[email protected] > > <mailto:[email protected]>> wrote: > > > >>> > >>> SPI works great on v4.1.x now, just pay attention this this little > >>> spi-dma-disable hack: > >>> > >>> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L54 > >>> > >>> <https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts#L54> > >>> > >>> "ti,pio-mode;" > >>> > >>> Otherwise, the spidev interface will lock up on the 160'th bit... > >>> > >>> (3.8 never used dma on spi, so this isn't a regression in speed..) > >> I believe the problem is in spidev which probably doesn't allocate > >> DMA-coherent memory for the buffer. If you use McSPI and allocate > >> DMA-coherent memory for the buffer it works just fine for > 160 bytes. > > > > But it works when the "spi & spidev" node is in the initial *.dtb, but > > not as an overlay. It seems like when loaded as an overlay we aren't > > getting the correct dma channel/memory/etc.. > That doesn’t make sense to me. I know a few months ago I was working on a SPI > driver and I had the same issue when my buffer exceeded 160 bytes. When I > used a DMA-coherent buffer, my driver worked fine. I was using an overlay to > load my driver during testing. My driver did not use SPIDEV. > > Regards, > John > > > > Regards, > > > > > > -- > > Robert Nelson > > https://rcn-ee.com/ <https://rcn-ee.com/> > > > > -- > > For more options, visit http://beagleboard.org/discuss > > <http://beagleboard.org/discuss> > > --- > > You received this message because you are subscribed to the Google Groups > > "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected] > > <mailto:beagleboard%[email protected]>. > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. > > -- > For more options, visit http://beagleboard.org/discuss > <http://beagleboard.org/discuss> > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:beagleboard%[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <http://beagleboard.org/discuss> > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
