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
> beaglebo...@googlegroups.com 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to