Hi, On 01/11/2013 05:27 PM, Paul Barker wrote: >> What functions you were using from the McBSP driver(s)? > > I'm just using the request, free, start, stop and config functions, then > using DMA to copy data. OK. >> I have taken a brief look at ADS1672 datasheet. At first glance I would think >> that if you connect the ADC to SPI port of OMAP3 you should be able to read >> the data out as well. On BeagleBoard-xM you should have access to >> McSPI3 (CS0, >> CS1) and McSPI4 (CS0). > > I've just been having a look at the McSPI interface and SPI code in the kernel. > I can see how to wire this up, use the processor as SPI master and the ADC as > SPI slave, get the clock running, etc. I need the transfers to be synchronised > to the data ready signal from the ADC, or I need them to occur at a guaranteed > frequency. I can't see how to do either of these with the SPI interface provided > by <linux/spi/spi.h>, so looks like I'd have to interface directly with the > McSPI hardware. I'll have a bash around, try to get some advice from the > beagleboard@xxxxxxxxxxxxxxxx list and see what I can come up with as I think > that's a bit off topic for this list. Naturally you would use the data ready line as interrupt source for your driver. When you receive the interrupt you would issue a read via SPI to get the result from the chip. >>> If you have any advice on this or a pointer to a better place to ask >>> this question please let me know. >> >> Can you try to see if you can use McSPI for your application? >> >> As background: we did not had any other uses of McBSP when I have decided to >> merge the code and move it out from arch/arm/plat-omap/ This was needed to be >> done in any ways. The decision back then was that since we don't have users >> for McBSP other than audio, it is going to be moved under sound/soc/omap/ > > This makes sense. The only other benefit I can see from exporting the McBSP > functions again is that audio drivers for custom boards based on OMAP processors > could then be written as external modules. That's not really what I'm doing here > though. 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. -- 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
