Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 02 Nov 2007 08:02 AM by  jonathankaufmann@gmail.com
Linux LITEKIT Audio ((and LCD) (and more...))
 5 Replies
Sort:
You are not authorized to post a reply.
Author Messages
jonathankaufmann@gmail.com
New Member
New Member
Posts:


--
10 Oct 2007 10:45 AM
    I spent quite a bit of time yesterday evening tweaking w/ printk statements before realizing that the mxc_spi for the audio was not being initialized. In the end, I think it was just one line of code that got everything loaded and working along w/ setting the right Kernel config options. I just got the LITEKIT and am new to Linux Kernel, so excuse me if this is obvious and/or old news, but I just wanted to share my experiences.

    Enable Drivers->Sound->ALSA
    Enable Drivers->SPI
    Enable Drivers->SPI->CSPI2, otherwise the PMIC spi driver doesn't get loaded
    Enable Drivers->MXC->PMIC->{ALL OPTIONS}
    Enable Drivers->MXC->DAM
    Enable Drivers->Sound->{MXC Audio Driver somewhere}

    In the mxc_init_board function (in arch/arm/mach-mx3/mx31lite.c), I added the line:

    spi_init_board_info(mxc_spi_board_info, ARRAY_SIZE(mxc_spi_board_info));


    and then somewhere above that had to create the mxc_spi_board_info structure. This structure was copied verbatim out of the mx31ads.c file from the original (unpatched-for-LITE LTIB kernel)

    All this is off of memory, so names and files may be slightly off. I can post the actual code and structure if anyone needs.

    So w/ that, dmesg shows detected Alsa card, and I was able to do

    aplay /usr/share/sounds/Front_Right.wav

    It only came out of one ear in mono, but after running alsamixer I was able to get it out of both ears in mono.

    Does anyone know how to get stereo sound working in alsa or how to display what is supported? I'm hoping its just some option I need to enable that the driver already supports b/c I saw traces of "stereo" all over the driver source code.

    madplay gives an error saying could not find /dev/dsp, but I'm guessing thats a quickie to fix.

    While I'm posting, I may as well ask if anyone knows a solution to the USB_CLK error b/c I think thats the next thing I am going to tackle. About 10% of the time (it seems to only be when I have recently recompiled the kernel), boot stops after the line reporting something about bad USB_CLK, should be equal to 60MHz. Funny thing is that it always says this (whether boot succeeds or not), and USB still works (when boot succeeds) in spite of the error. Also the source code returns success (I'm sure the patches added this as a fix) even though the error exists. Could it be a coincidence that boot hangs right after this line just w/ no error indicating so? Anyway, if anyone can share any extra info on this boot lockup, let me know.

    While I'm posting... I have the 12.1" LogicPD LCD working flawlessly - if anyone is interested in the structure, let me know. Hell, why doesn't everybody post all 100% working structures for the LogicPD LCDs. If theres a reasonable response, I may update Daniels patches to add LCD support and maybe a menuconfig option to compile in support and choose the appropriate screen.
    OradFarez
    New Member
    New Member
    Posts:


    --
    10 Oct 2007 12:07 PM
    Hello, it sounds like you were using that small patch on Freescale's ltib version, release3. Using Daniel's patch on a fresh kernel puts this code in it already, I think. Maybe I am forgetting how much stuff I have added.

    Here is some code I added to the file usb_lite.c that sets the proper frequency but I don't know if it does anything because of my usb problem:

    static int __init mx3_usb_init(void)
    {
    mxc_pll_set(USBPLL,9,1,987,228);
    mxc_clks_enable(USB_CLK);

    }


    Also, try adding this code to function mx31lite_gpio_init in the file mx31lite_gpio.c:

    /* USB nCS pin enables */
    mxc_request_iomux(MX31_PIN_DTR_DCE1, OUTPUTCONFIG_GPIO, INPUTCONFIG_NONE);
    mxc_iomux_set_pad(MX31_PIN_DTR_DCE1, (PAD_CTL_DRV_NORMAL | PAD_CTL_SRE_FAST | PAD_CTL_HYS_CMOS | PAD_CTL_ODE_CMOS ));
    mxc_set_gpio_direction(MX31_PIN_DTR_DCE1, 0);
    mxc_set_gpio_dataout(MX31_PIN_DTR_DCE1, 1);
    mxc_free_iomux(MX31_PIN_DTR_DCE1, OUTPUTCONFIG_GPIO, INPUTCONFIG_NONE);

    mxc_request_iomux(MX31_PIN_DTR_DCE2, OUTPUTCONFIG_GPIO, INPUTCONFIG_NONE);
    mxc_iomux_set_pad(MX31_PIN_DTR_DCE2, (PAD_CTL_DRV_MAX | PAD_CTL_SRE_FAST | PAD_CTL_HYS_CMOS | PAD_CTL_ODE_CMOS ));
    mxc_set_gpio_direction(MX31_PIN_DTR_DCE2, 0);
    mxc_set_gpio_dataout(MX31_PIN_DTR_DCE2, 1);
    mxc_free_iomux(MX31_PIN_DTR_DCE2, OUTPUTCONFIG_GPIO, INPUTCONFIG_NONE);


    This makes sure the chip select lines to the ISP1504 devices are held active. Since your USB works without changing the clock sometimes, maybe only try this second chunk of code and see if it improves. Please let me know of your results.

    EDIT: Actually, that second block doesn't seem very useful. I got it from LPD, but I think it would be better if direction = 1 and dataout = 0.

    Also, I think that the problem with kernel lock up is due to USB host/NAND interface shared pins and some code in these patched kernels that isn't handling the external pin selection quite right.
    jonathankaufmann@gmail.com
    New Member
    New Member
    Posts:


    --
    10 Oct 2007 01:46 PM
    Orad:

    Thanks for the info on your USB efforts. I will try things out this evening and see if there is any difference. If you send me a compiled zImage with your (always) locking USB code, I'd be happy to try it on my hardware to let you know if its a config problem or some obscure hardware inconsistency. - My email is {my forum username} AT econtrols D0T com

    I just looked at Daniel's patch, and the spi_register_board_info and the mxc_init_fb lines were both removed from mx31lite.c. I hope I haven't been making some big mistake here!

    I wonder if there was a reason those lines were removed? Can you remember adding anything else in the way of SPI or audio?
    paulc@logicpd.com
    New Member
    New Member
    Posts:


    --
    24 Oct 2007 04:10 PM
    Since you have playback operational, can you see if you can record as well?
    lilja.magnus@gmail.com
    New Member
    New Member
    Posts:


    --
    01 Nov 2007 02:05 PM
    I have audio recording working on the Litekit using the latest BSP (rel 5) from Freescale and my quick port of the BSP to the litekit (see the 2.6.22-thread).

    I'm using the audio in jack (line in) on the baseboard and the arecord program. However, in order to route the audio from the line in port to i.MX31 I had to manually set the RXINREC (bit 13) to 1 in the REG_AUDIO_TX register of the PMIC/MC13783.

    It doesn't seem possible to set this bit to one using the alsamixer program, so one has to use the /dev/pmic interface or write a kernel driver to modify it (or make changes to the alsa driver I guess).

    The RXINREC bit has to be changed after arecord has been started (unless the alsa driver or pmic_audio driver is changed) since opening the audio device seems to reset this bit.

    Haven't tried connecting to any of the microphone inputs.
    jonathankaufmann@gmail.com
    New Member
    New Member
    Posts:


    --
    02 Nov 2007 08:02 AM
    Thanks for the info.
    You are not authorized to post a reply.