McBSP functions not exported

McBSP functions not exported

[Paul Barker]

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.

If you have any advice on this or a pointer to a better place to ask
this question please let me know.

Thanks,

-- 
Paul Barker

paul@paulbarker.me.uk
http://www.paulbarker.me.uk/

Re: McBSP functions not exported

[Peter Ujfalusi]

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

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

> 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/

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

Re: McBSP functions not exported

[Paul Barker]

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)?

I'm just using the request, free, start, stop and config functions, 
then
using DMA to copy data.

>> 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.
>
> 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@googlegroups.com list and see what I can come up with as I 
think
that's a bit off topic for this list.

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

Cheers,

Paul Barker

Re: McBSP functions not exported

[Peter Ujfalusi]

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

Re: McBSP functions not exported

[Paul Barker]

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

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

Re: McBSP functions not exported

[Jarkko Nikula]

Hi

On Tue, 15 Jan 2013 17:43:54 +0000
Paul Barker <paul@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

Re: McBSP functions not exported

[Peter Ujfalusi]

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