> > *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. *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. On Wed, Dec 16, 2015 at 3:47 PM, John Syne <[email protected]> wrote: > > > On Dec 16, 2015, at 2:38 PM, Robert Nelson <[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 > >>> > >>> "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/ > > > > -- > > For more options, visit http://beagleboard.org/discuss > > --- > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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.
