Paul Barker | 11 Jan 12:48 2013
Picon

McBSP functions not exported

Hi,

I'm currently working on a driver to talk to an analog-to-digital
converter (specifically a Texas Instruments ADS1672) connected to the
McBSP port on a Beagleboard-xM. I'm currently building my driver module
against a 3.2 series kernel with Beagleboard patches and config from
https://github.com/beagleboard/kernel (branch beagleboard-3.2). I'd
like to keep up-to-date with the more recent kernels but my module
won't compile with them.

When the OMAP McBSP driver stack was merged into a single driver
(commit 45656b4 by Peter Ujfalusi, looks like it went into linux 3.3)
all the EXPORT_SYMBOL macros were removed so I can no longer call the
functions I was using from my external module. Alternatively I could
just be missing something really obvious, let me know if I am!

I'm just wondering what the best way forward is from here and I'm sure
I can't be the only person who was using the McBSP driver code in the
kernel to interface with external hardware. The two options I can think
of are either that I move my driver into the kernel source tree itself
or the McBSP driver functions are exported again so that they can be
used by external modules. It's easier to maintain an external module
than a series of patches against the kernel, unless a driver for an
analog-to-digital converter connected to the McBSP port is something
that would actually have a chance of being merged into the mainline
kernel. I could look at making this driver more generic once I have the
current hardware/driver combination working, so that it should work
with most analog-to-digital converters - I haven't found such a driver
in my previous googling.

(Continue reading)

Peter Ujfalusi | 11 Jan 14:17 2013
Picon

Re: McBSP functions not exported

Hi,

On 01/11/2013 12:48 PM, Paul Barker wrote:
> Hi,
> 
> I'm currently working on a driver to talk to an analog-to-digital
> converter (specifically a Texas Instruments ADS1672) connected to the
> McBSP port on a Beagleboard-xM. I'm currently building my driver module
> against a 3.2 series kernel with Beagleboard patches and config from
> https://github.com/beagleboard/kernel (branch beagleboard-3.2). I'd
> like to keep up-to-date with the more recent kernels but my module
> won't compile with them.
> 
> When the OMAP McBSP driver stack was merged into a single driver
> (commit 45656b4 by Peter Ujfalusi, looks like it went into linux 3.3)
> all the EXPORT_SYMBOL macros were removed so I can no longer call the
> functions I was using from my external module. Alternatively I could
> just be missing something really obvious, let me know if I am!

Since 3.3 there were even more changes in the McBSP driver stack. We (I) did
removed lot's of code and it is more focused on it's main functionality (ASoC).
What functions you were using from the McBSP driver(s)?

> I'm just wondering what the best way forward is from here and I'm sure
> I can't be the only person who was using the McBSP driver code in the
> kernel to interface with external hardware. The two options I can think
> of are either that I move my driver into the kernel source tree itself
> or the McBSP driver functions are exported again so that they can be
> used by external modules. It's easier to maintain an external module
> than a series of patches against the kernel, unless a driver for an
(Continue reading)

Paul Barker | 11 Jan 17:27 2013
Picon

Re: McBSP functions not exported

On 2013-01-11 13:17, Peter Ujfalusi wrote:
> Hi,
>
> On 01/11/2013 12:48 PM, Paul Barker wrote:
>> Hi,
>>
>> I'm currently working on a driver to talk to an analog-to-digital
>> converter (specifically a Texas Instruments ADS1672) connected to 
>> the
>> McBSP port on a Beagleboard-xM. I'm currently building my driver 
>> module
>> against a 3.2 series kernel with Beagleboard patches and config from
>> https://github.com/beagleboard/kernel (branch beagleboard-3.2). I'd
>> like to keep up-to-date with the more recent kernels but my module
>> won't compile with them.
>>
>> When the OMAP McBSP driver stack was merged into a single driver
>> (commit 45656b4 by Peter Ujfalusi, looks like it went into linux 
>> 3.3)
>> all the EXPORT_SYMBOL macros were removed so I can no longer call 
>> the
>> functions I was using from my external module. Alternatively I could
>> just be missing something really obvious, let me know if I am!
>
> Since 3.3 there were even more changes in the McBSP driver stack. We 
> (I) did
> removed lot's of code and it is more focused on it's main
> functionality (ASoC).
> What functions you were using from the McBSP driver(s)?

(Continue reading)

Peter Ujfalusi | 14 Jan 09:48 2013
Picon

Re: McBSP functions not exported

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 <at> 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.

(Continue reading)

Paul Barker | 15 Jan 18:43 2013
Picon

Re: McBSP functions not exported

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 <at> 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.
(Continue reading)

Jarkko Nikula | 16 Jan 08:44 2013

Re: McBSP functions not exported

Hi

On Tue, 15 Jan 2013 17:43:54 +0000
Paul Barker <paul <at> paulbarker.me.uk> wrote:

> 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.
> 
Quick idea that came to my mind. Hack and I don't know how feasible it is but would it be possible to make that
ADC as a simple ASoC codec driver in your usecase? I.e. using ALSA API for high-rate ADC measurements and
reuse existing serial link and dma drivers.

Anyway I think high-rate ADC falls in gray area in kernel currently. drivers/iio/ seems to not cover them
and does not match exactly with ASoC either.

--

-- 
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Peter Ujfalusi | 16 Jan 10:05 2013
Picon

Re: McBSP functions not exported

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.
(Continue reading)


Gmane