[Gta04-owner] fm-tuner - was Re: hw routing audio patch removed in 3.7?
Dr. H. Nikolaus Schaller
hns at goldelico.com
Mon Jun 10 19:14:46 CEST 2013
Am 10.06.2013 um 18:52 schrieb Christoph Mair:
> 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) /
> (CLKGDV+1): 100Mhz/50/3
> 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
So it is a "pure" adn "direct" McBSP driver?
Wouldn't it be easier to write a kernel module that allows to control a
DAI from /sysfs? Or add some debugging mode to the existing OMAP
McBSP driver? This would remove the need to handle McBSP registers
> 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 ;-)
My idea would be to solder some thin wires to the McBSP interface
and connect a scope. This was the way I was able to debug the camera
interface (and identify an undocumented frequency scaling factor).
But to start this work I need to get the Si47xx to tune to some reasonable
More information about the Gta04-owner