logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.
Question

TLV320AIC3106 second alsa card & kernel

posted in Linux Kernel
Wednesday, December 04 2013, 12:32 PM
0
Dear isee forum

I was wondering if someone can help on how to start enabling TLV320AIC3106 in the kernel
I've use beaglebone audio cape schema Title, to do my own implementation. Right now I've a PCB with TLV320AIC3106 codec conected to BSP3 lines (DX, CLKX,FSX,DR) AND I2C2 lines
C:\fakepath\TLV320AIC.png

Please, are there some guide/post I can use in order to enable TLV320 codec?

Cheers!
Sergio
Attachments:

Accepted Answer

Tuesday, December 09 2014, 07:41 AM - #permalink
0
Hi Forum

I forget to mention that the board it's working flawlessly.

Finally, I figured out what was wrong by myself :) As soon I've got spare time, I will fill this post with the details.
Meanwhile, you can find my board and kernel files modifications attached, if interested.

Sergio
  • pau pajuelo
    more than a month ago
    Hi sergio,

    This sounds really well
The reply is currently minimized Show
Responses (16)
  • Accepted Answer

    Thursday, December 05 2013, 09:07 AM - #permalink
    0
    Hi Sergio,

    I'm not 100% sure about this, but these are the steps that I think you should do:

    0. Create a new expansion board (http://labs.isee.biz/index.php/Linux_Kernel_2.6.37.y#Adding_New_Expansion_Boards), as example you can see any arch/arm/mach-omap2/exp-* file.
    1. Mux the pins connected to your board (mcbsp3, etc.)
    2. Search if your device is supported by the kernel and enable it (maybe is CONFIG_SND_SOC_TLV320AIC3X )
    3. Set the specific platform data for your driver and register the driver (include/sound/tlv320aic3x.h)
    4. Modify the sound/soc/omap/igep0020.c to connect the mcbsp3 to your codec.

    Hope it helps you.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, December 05 2013, 09:14 AM - #permalink
    0
    Thank you eballetbo

    Helps a lot! :)
    The reply is currently minimized Show
  • Accepted Answer

    Monday, December 09 2013, 08:51 AM - #permalink
    0
    Hi eballetbo & forum

    In order to configure mux for MCBSP3 I've followed arch/arm/mach-omap2/exp-igep0022.c as starting point. Basically I want MCBSP3 as master mode:

    #ifdef CONFIG_OMAP_MUX
    static struct omap_board_mux ixonplay_mux[] __initdata = {
            /* McSPI 1 */
            OMAP3_MUX(MCBSP1_DX,    OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT),
            OMAP3_MUX(MCBSP1_CLKX,  OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT),
            OMAP3_MUX(MCBSP1_FSX,   OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT),
            OMAP3_MUX(MCBSP1_DR,    OMAP_MUX_MODE2 | OMAP_PIN_INPUT),
    
            { .reg_offset = OMAP_MUX_TERMINATOR },
    };
    #else
    #define igep0022_mux    NULL
    #endif
    
    void __init ixonplay_init(void)
    {
            mux_partition = omap_mux_get("core");
    
    
            pr_info("ixonplay partition=%08X mux=%08X\n", mux_partition, ixonplay_mux);
    
            /* Mux initialitzation for igep0022 */
            omap_mux_write_array(mux_partition, ixonplay_mux);
    }


    When I boot I can see debug lines (pr_info) as expected, but running "cat /sys/kernel/debug/omap_mux/mcbsp1_clkx" it is showing MODE4 for MCBSP3_CLKX :(

    My question: there are some other place that overwrites my mux configuration?
    I've had a look to arch/arm/mach-omap2/board-igep0020.c but it doesn't seems to do nothing with MCBSP3 lines

    thanks!

    Sergio
    The reply is currently minimized Show
  • Accepted Answer

    Monday, December 09 2013, 10:54 AM - #permalink
    0
    Hi sergio,

    Can you attach all your modified board files ?

    Cheers!
    The reply is currently minimized Show
  • Accepted Answer

    Monday, December 09 2013, 12:05 PM - #permalink
    0
    Hi Pau

    Please, find it attached (I've compressed all files due to a restricition in number of attached files):


    arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
    arch/arm/mach-omap2/exp-ixonplay.c
    arch/arm/mach-omap2/board-igep00x0.h
    arch/arm/mach-omap2/board-igep0020.c
    arch/arm/mach-omap2/board-igep00x0.c

    And also igep.ini

    Sorry attachments doesn't work


    Sergio
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 10 2013, 10:42 AM - #permalink
    0
    Hi sergio,

    I applied your modified files to 2.6.37 and mcbsp1_clkx mux is configured correctly:

    root@igep00x0:/sys/kernel/debug/omap_mux# cat mcbsp1_clkx
    name: mcbsp1_clkx.mcbsp3_clkx (0x48002198/0x168 = 0x0002), b w21, t NA
    mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE2
    signals: mcbsp1_clkx | NA | mcbsp3_clkx | NA | gpio_162 | NA | NA | safe_mode
    root@igep00x0:/sys/kernel/debug/omap_mux# dmesg | grep ixonplay
    [ 0.000000] IGEP: IGEP0020 machine + ixonplay
    [ 0.000000] Kernel command line: console=ttyO2,115200n8 console=tty0 mem=430M smsc911x.mac=0x02,0x7a,0x2f,0x97,0x99,0x5b omapfb.mode=dvi:1024x768MR-16@60 vram=40M omapfb.vram=0:12M,1:16M,2:12M root=/dev/mmcblk0p2 rw rootwait buddy=ixonplay
    [ 0.000000] ixonplay partition=D801D140 mux=C003640C
    root@igep00x0:/sys/kernel/debug/omap_mux#


    I edited igep.ini file to boot from uSD card and solve some incongruent lines (see attached file). Can you test it with this file?
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 10 2013, 01:11 PM - #permalink
    0
    thank you pau

    Please, can you share igep.ini? ;)
    Also, when I compile the kernel, at the end it is showing lines like:

    OBJCOPY arch/arm/boot/zImage
    Kernel: arch/arm/boot/zImage is ready
    Building modules, stage 2.
    MODPOST 224 modules
    WARNING: modpost: Found 3 section mismatch(es).
    To see full details build your kernel with:
    'make CONFIG_DEBUG_SECTION_MISMATCH=y'

    This could be a problem?? I've do a quick google research and it doesn't seems to me problematic

    BTW, my output for your commands are:
    root@ixon:~# uname -a
    Linux ixon 2.6.37 #8 Mon Dec 9 08:06:04 CET 2013 armv7l armv7l armv7l GNU/Linux
    root@ixon:~#
    root@ixon:~# dmesg | grep ixonplay
    [ `0.000000] IGEP: IGEP0020 machine + ixonplay
    [ 0.000000] Kernel command line: console=ttyO2,115200n8 console=tty0 mem=430M smsc911x.mac=0x02,0x7a,0x2f,0x97,0x99,0x5b omapfb.mode=dvi:1024x768MR-16@60 vram=40M omapfb.vram=0:12M,1:16M,2:12M ip=192.168.0.169:192.168.0.169:192.168.0.99:255.255.255.0::eth0: root=/dev/nfs nfsroot=192.168.0.228:/srv/nfs/linaro/binary_compile buddy=ixonplay
    [ 0.000000] ixonplay partition=D801D140 mux=C0036B7C
    root@ixon:~#
    root@ixon:~# cat /sys/kernel/debug/omap_mux/mcbsp1_clkx
    name: mcbsp1_clkx.gpio_162 (0x48002198/0x168 = 0x0104), b w21, t NA
    mode: OMAP_PIN_INPUT | OMAP_MUX_MODE4
    signals: mcbsp1_clkx | NA | mcbsp3_clkx | NA | gpio_162 | NA | NA | safe_mode
    root@ixon:~#
    root@ixon:~#



    Sergio
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 10 2013, 01:25 PM - #permalink
    0
    Hi sergio,

    The igep.ini file is attached above your last reply. There was an error into attachment option.

    Cheers!
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, December 10 2013, 02:17 PM - #permalink
    0
    Thank you Pau

    I've had a look into your igep.ini. Sorry, there were errors in my igep.ini attached (not my igep.ini in igepv2 flash) due to copy/paste
    The only difference is in:

    your:
    root=/dev/mmcblk0p2 rw rootwait

    mine:
    ip=192.168.0.169:192.168.0.169:192.168.0.99:255.255.255.0::eth0:
    root=/dev/nfs
    nfsroot=192.168.0.228:/srv/nfs/linaro/binary_compile

    And of course I'm modifiying zImage on mtdblock1

    Anyway, please, look this:
    root@ixon:~# dmesg | grep ixonplay
    [    0.000000] IGEP: IGEP0020 machine + ixonplay
    [    0.000000] Kernel command line: console=ttyO2,115200n8 console=tty0 mem=430M smsc911x.mac=0x02,0x7a,0x2f,0x97,0x99,0x5b omapfb.mode=dvi:1024x768MR-16@60 vram=40M omapfb.vram=0:12M,1:16M,2:12M ip=192.168.0.169:192.168.0.169:192.168.0.99:255.255.255.0::eth0: root=/dev/nfs nfsroot=192.168.0.228:/srv/nfs/linaro/binary_compile buddy=ixonplay 
    [    0.000000] ixonplay/partition=D801D140 mux=C0036B7C
    root@ixon:~# cat /sys/kernel/debug/omap_mux/mcbsp1_clkx
    name: mcbsp1_clkx.gpio_162 (0x48002198/0x168 = 0x0104), b w21, t NA
    mode: OMAP_PIN_INPUT | OMAP_MUX_MODE4
    signals: mcbsp1_clkx | NA | mcbsp3_clkx | NA | gpio_162 | NA | NA | safe_mode
    root@ixon:~# uname -a
    Linux ixon 2.6.37 #9 Tue Dec 10 13:19:48 CET 2013 armv7l armv7l armv7l GNU/Linux
    root@ixon:~# 
    


    I've recompiled (at 13:19:48), but still it is showing MODE4 for mcbsp1_clkx line
    Please, do you know some method to debug this?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 11 2013, 10:33 AM - #permalink
    0
    Hi pau

    Finally I've upgrade my board firmware and copied rootfs to NFS server
    It works as expected.

    The only difference is rootfs. For linaro it doens't work. For yocto it works perfectly

    Some screen shots!

    IGEP Firmware Yocto 1.2.2-3 igep00x0 ttyO2
    
    igep00x0 login: root
    root@igep00x0:~# mount
    rootfs on / type rootfs (rw)
    192.168.0.228:/srv/nfs/linaro/fresh_rootfs on / type nfs (rw,relatime,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nolock,proto=udp,timeo=10,retrans=3,sec=sys,mountaddr=192.168.0.228,mountvers=1,mountproto=udp,local_lock=all,addr=192.168.0.228)
    proc on /proc type proc (rw,relatime)
    tmpfs on /mnt/.psplash type tmpfs (rw,relatime,size=40k)
    sysfs on /sys type sysfs (rw,relatime)
    none on /dev type tmpfs (rw,relatime,mode=755)
    devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
    tmpfs on /var/volatile type tmpfs (rw,relatime)
    tmpfs on /media/ram type tmpfs (rw,relatime)
    root@igep00x0:~# uname -a
    Linux igep00x0 2.6.37 #9 Tue Dec 10 13:19:48 CET 2013 armv7l GNU/Linux
    root@igep00x0:~# mount
    root@igep00x0:~# mount -t debugfs none /sys/kernel/debug
    root@igep00x0:~# cat /sys/kernel/debug/omap_mux/mcbsp1_clkx
    name: mcbsp1_clkx.mcbsp3_clkx (0x48002198/0x168 = 0x0002), b w21, t NA
    mode: OMAP_PIN_OUTPUT | OMAP_MUX_MODE2
    signals: mcbsp1_clkx | NA | mcbsp3_clkx | NA | gpio_162 | NA | NA | safe_mode
    root@igep00x0:~# 
    


    I'll continue testing I2S using yocto:o

    Thank you for your support
    Sergio
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 11 2013, 11:13 AM - #permalink
    0
    Ok,

    That's good news
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 04 2014, 08:46 AM - #permalink
    0
    Dear ISEE team,

    Let me continue with the purpose of this thread...
    IGEPv2 + TVL320AIC3X audio codec


    Finally, I've put all the pieces together (with some help from eballetbo and pau ;) ):

    Added my expansion board file "arch/arm/mach-omap2/exp-playpro.c", register I2C device and set McBSP pin direction as needed
    Added support for TLV320AIC3X using menuconfig
    Modified sound/soc/omap/igep0020.c to connect McBSP with codec and set some TLV320AIC3X registers as needed


    As a result, when I run aplay command to show up alsa devices I can see:
    iPRO:~$ aplay -L
    null
        Discard all samples (playback) or generate zero samples (capture)
    sysdefault:CARD=igep
        igep, 
        Default Audio Device
    iPRO:~$ aplay -l
    **** List of PLAYBACK Hardware Devices ****
    card 0: igep [igep], device 0: TWL4030 twl4030-hifi-0 []
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 0: igep [igep], device 1: AIC3X tlv320aic3x-hifi-1 []
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    


    Should not it display different devices/cards?

    Instead of define snd_soc_dai_link like this one:
    static struct snd_soc_dai_link igep2_dai[] = {
    	{
    		.name = "TWL4030",
    		.stream_name = "TWL4030",
    		.cpu_dai_name = "omap-mcbsp-dai.1",
    		.codec_dai_name = "twl4030-hifi",
    		.platform_name = "omap-pcm-audio",
    		.codec_name = "twl4030-codec",
    		.ops = &igep2_ops,
    	},
    	{
    		.name = "TLV320AIC3X",
    		.stream_name = "AIC3X",
    		.cpu_dai_name = "omap-mcbsp-dai.2",			// does it make reference to mcbsp3
    		.codec_dai_name = "tlv320aic3x-hifi", 		//
    		.platform_name = "omap-pcm-audio",			//
    		.codec_name = "tlv320aic3x-codec.2-001b",	// I2C2 @base=0x1b. Case sensitive!!!
    		.init=tlv_aic3x_init,
    		.ops = &tlv_ops,
    	}
    };


    Let me share my thought...
    Should I define two different structures one per card (original TWL and a new one for TLV320AIC3X)?
    Something like simone.c
    In consequence there should be two platform_device_alloc, platform_set_drvdata, platform_device_add?
    And finally if it's correct, what's the best practice, use sound/soc/omap/igep0020.c for TWL and another file for TVL320AIC3X or share same file for both cards?

    Thank you
    Sergio
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 04 2014, 09:24 AM - #permalink
    0
    IMHO the best practice is use a different cards, but to understand the concept use the same file is more easy ;-) Note that I'm not a big expert with soc drivers ...
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, November 04 2014, 09:57 AM - #permalink
    0
    Hi eballetbo

    In the lag before you answer me I've included a second source file for my board PLAYPRO

    Now it seems to work... I'm sure that there is still a bunch of work, but I'm happy :D with these results...

    iPRO:~$ aplay -L
    null
        Discard all samples (playback) or generate zero samples (capture)
    sysdefault:CARD=igep
        igep, 
        Default Audio Device
    sysdefault:CARD=playpro
        playpro, 
        Default Audio Device
    iPRO:~$ aplay -l
    **** List of PLAYBACK Hardware Devices ****
    card 0: igep [igep], device 0: TWL4030 twl4030-hifi-0 []
      Subdevices: 1/1
      Subdevice #0: subdevice #0
    card 1: playpro [playpro], device 0: AIC3X tlv320aic3x-hifi-0 []
      Subdevices: 1/1
      Subdevice #0: subdevice #0


    Sometimes we need some extra push, thank you for share your thoughts!!

    cheers!
    Sergio
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 06 2014, 03:21 PM - #permalink
    0
    Hi Forum!

    Finally I've got the igepv2 board and TLV320AIC3106 codec working together with the only issue that I can not capture data (playback works flawlessly).
    The final final initialization are:

    static struct i2c_board_info __initdata igep2_i2c2_boardinfo[] = {
    	{
    		I2C_BOARD_INFO("tlv320aic3x", 0x1B),
    	}
    };
    
    #ifdef CONFIG_OMAP_MUX
    static struct omap_board_mux playpro_mux[] __initdata = {
    	OMAP3_MUX(MCBSP1_DX, 	OMAP_MUX_MODE2 | OMAP_PIN_OUTPUT),
    	OMAP3_MUX(MCBSP1_CLKX, 	OMAP_MUX_MODE2 | OMAP_PIN_INPUT),		// bit clock			
    	OMAP3_MUX(MCBSP1_FSX, 	OMAP_MUX_MODE2 | OMAP_PIN_INPUT),		// word clock
    	OMAP3_MUX(MCBSP1_DR, 	OMAP_MUX_MODE2 | OMAP_PIN_INPUT),
    	{ .reg_offset = OMAP_MUX_TERMINATOR },
    };
    #else
    #define igep0022_mux	NULL
    #endif
    
    void playpro_init(void)
    {
    	pr_info("Initializing expansion board PLAYPRO...");
    	mux_partition = omap_mux_get("core");
    	pr_info("PLAYPRO partition=%p mux=%p\n", mux_partition, playpro_mux);
    
    	/* Mux initialitzation for igep0022 */
    	omap_mux_write_array(mux_partition, playpro_mux);
    	omap_register_i2c_bus(2, 100, igep2_i2c2_boardinfo, ARRAY_SIZE(igep2_i2c2_boardinfo));
    }


    ...said that, if I run a command like "arecord -Dplughw:1,0 foo.wav" it generates a file without wave data, only I can see wave header "RIFF$�WAVEfmt @data�".
    Another clue, BLCK and WCLK remains at 0 level (in playback mode it runs as expected).

    Please, someone can help me with this? ppajuel has mention some possible issue in IRC, but I'm not quite sure I understand...

    Sergio
    PS: find attached amixer output file log
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 13 2014, 03:20 PM - #permalink
    0
    Hi all!

    I've post this issue in the TI Community forum, in the hope that it could help.
    Also, it would fantastic if some ISEE staff member, can lend a helping hand or could provide any pointers further to debug this issue.

    BR,
    Sergio
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat