Hi, On 01/15/2013 06:43 PM, Paul Barker wrote: > I've written a quick driver which issues SPI reads in response to hrtimer events > to see if this is possible. I'm getting a rough average latency of 100us between > calling spi_async() and the clock signal changing. This is no use for reading a > single sample at a time at a rate of 625kHz. Even ignoring this problem, I > imagine there would be at least a few microseconds of latency between a GPIO pin > changing and an interrupt handler being executed by the kernel. My transfer > takes 1us and I have a new data word every 1.6us. So I think issuing single SPI > read requests each time I get an interrupt isn't going to work for me. > > With the hrtimer interval set to 1.6us my board completely locks up (probably > has no free time to handle anything else). I don't think Linux was designed to > respond to these sorts of requests in real-time. I need to offload this to the > DMA system, but I can't see any way to do that (with a 600ns gap between > transfers) using the Linux SPI API. McSPI can also use DMA. You need to have >160 bytes in one transfer to use the sDMA. Under 160 bytes the drivers switches to PIO mode. To understand your setup: how did you wired the ADS1672 with McBSP? I assume that McBSP is slave. ADS's CS is grounded, SCLK_SEL is 0, you use the DRDY signal as FS and configure the McBSP in kind of DSP (or PCM mode) to read the data. McSPI can be used in this mode. When McSPI is slave it looks for the edge on the CS0 line. This can be the DRDY signal. It will start to shift in the data when it detect the edge. According to the ADS datasheet it generates the DRDY signal (pulse) before when the data is available. So if you hook up the ADS with McSPI: McSPI is slave, DRDY is used as CS0, clock is coming from ADS, you prepare a transfer for more than 160 bytes (McSPI can handle 65535 words in a transfer). This case you will offload the read to sDMA. You will be notified when the message has been retrieved, you can place another read and while you are collecting data you can process the already received buffer. Or as Jarkko already mentioned there might be a way to use ALSA API from userspace to fetch the data. >> I don't see how it could help custom boards. For audio all boards can just >> happily use the McBSP stack + omap-pcm. It could help with boards where the >> McBSP is not used for audio. But I think those users could use McSPI instead >> of McBSP for their needs. >> >> As a sidenote: The support for SPI like protocols in McBSP only existed on >> OMAP1 where we had a stop clocks possibility. In all latest versions of OMAP >> removed this possibility and McBSP officially only supports I2S, PCM, TDM >> protocols. This was another reason to move the McBSP under sound. > > The ADS1672 shouldn't care if the clock stops or not, it has the ability to > output its own clock signal and that runs continuously. > > My understanding of the McBSP using DMA is that a read would be issued as soon > as a frame sync pulse is detected, with no processor involvement, and I can get > an interrupt from the DMA controller once every few thousand samples or so and > so the OS can just get on with running in the meantime. It looks like that is > what I need to happen here. > > I'm going to go back to using kernel 3.2 and check that this actually works > with the McBSP. If it does, how much hassle is it to export the required symbols > in more recent kernels? I'll happily write the patch, I just don't want to > introduce too much more maintenance overhead going forward. > > Thanks, > > Paul Barker -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
