[Gta04-owner] fm-tuner - was Re: hw routing audio patch removed in 3.7?
christoph.mair at gmail.com
Mon Jun 10 18:52:47 CEST 2013
On Mon, Jun 10, 2013 at 2:50 PM, Andreas Kemnade <andreas at kemnade.info> wrote:
> On Sat, 2013-06-08 at 19:27 +0200, Christoph Mair wrote:
>> I used the McBSP1 in master mode to read data from an analog/digital
>> converter. I did not use the sound API but the corresponding McBSP
>> functions. I'll see if I can dig up the code.
> That would really be helpful.
I uploaded the file here: http://chonyota.net/gta04/mcbsp_test.c
*Big fat warning*:
This is/was work in progress. It is a horrible hack, does not follow
any coding guidelines or provide or use any sane interfaces. Also, I
can't exclude side effects on any life-form. You have been warned!
In addition, the code was written for kernel 2.6.37 and it seems that
newer kernels have reorganized the mcbsp header files.
How it is supposed to work:
The module creates a character device file "mydevice". Commands are
send using the write syscall, the first two ints specify what to do
(see lines 814ff).
In general you start by setting the TX buffer size to some value, for
example 2048 but any other number should work as well. Just don't
start too small. Then call write() again to fill the TX buffer with
some data you'd like to send (in my case to a DAC). The driver expects
16 bit unsigned ints.
Command 4 (startSampling) enables the McBSP and starts to continuously
transmit your TX-Buffer using DMA. It starts again from the beginning
when reaching the end. Command 5 stops this process.
Now the more interesting part: RX
Call read() with a large buffer (I use 2^24 to get lots of data). It
will try to map your buffer into kernel space and start a DMA cycle to
directly fill it with 20 bit data from the RX pin. The data expands to
32bits inside the McBSP FIFO. Since my sample clock is the FSX and the
ADC will take a while to finish the conversion, it requests a read by
asserting the FSR. You can simply change the structure struct
omap_mcbsp_reg_cfg mcbsp_config and uncomment the FSRM bit to enable
the RX frame sync generation from the McBSP core. This should get you
at least some meaningless data from the input pin.
The sample-rate is currently set to 666666Hz: 100Mhz / ( FPER+1) /
The FSX is high(?) for 16 clock cycles (FWID+1) which is somewhat
asymmetric because the frame repeat rate is set to 50 clock cycles.
The TI technical reference manual for the DM3730 gives you all the
register details for this structure.
If you get this thing to compile and load I'll be happy to help
debugging the remaining stuff. If you have any further questions (I'm
sure you will) just ask!
Two more hints: to check if DMA is working, use the printks within the
interrupt function, but it might give strange results due to bad
timing. The driver uses two RX DMA channels which are chained together
to keep up with the high speed serial interface if the buffer is
larger than one page. Oh, the buffer should also be page aligned, so
please use something like posix_memalign(&buffer, 0x10000,
RX_SAMPLES*sizeof(buffer));; in your userspace software instead of
To check if the McBSP is filling its internal FIFO, see line 930 for a
quick and dirty way to read the interrupt status register. It will
tell you about over and underflows. Without DMA, you should get an
overflow rather quick.
> Si4721 does not give FSR. At the moment I would be happy if I see any
> byte coming out of arecord (even it does not come from si4721). But
> arecord enables just the clocks/framesync and nothing arrives, not even
> a bunch of zero bytes. That is so disappointing. If i had at least some
> noise coming in with arecord I would be happy.
Well, this has nothing to do with anything related to alsa, but it
might help debugging things. Maybe the best way is to dump the McBSP
registers which are set up by alsa first and check what might be
wrong. Of course I will try to help if you share the dump ;-)
More information about the Gta04-owner