Hi,
On 2013-01-14 08:48, Peter Ujfalusi wrote:
On 01/11/2013 05:27 PM, Paul Barker wrote:
<snip>
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.
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.
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
--
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
