This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

tvp5158 audio for dm365

Other Parts Discussed in Thread: TVP5158

I'm attempting to get tvp5158 capture working in the 2.6.32 kernel, using the DM365 "MCVIP" driver.  I've gone through all of the driver / kernel code many times and I've come to the conclusion that nobody actually uses it for audio on a DM365.  The #ifdef code for TVP5158 audio is not for the DM365, but rather DM6467.  I've taken a stab at correcting this, but I have a few questions and would be very thankful if someone with more knowledge of the davinci line and ASoC audio drivers could weigh in.

 In the kernel / lsp mcvip patch, there are two snd_soc_dai structures with a name of "davinci-i2s".  One is in davinci-mcasp.c and the other is in davinci-i2s.c.  Which should be used?  I'm assuming that I should be using davinci-i2s.c's snd_soc_dai, since that is what the tlv320aic3x uses on the DM365.

Since both the audio and video on the tvp5158 share the same I2C address, there is a conflict in the linux kernel.  As such, I've changed the driver in an attempt to combine them.. saving the i2c handles created during the video probe and reusing them during the audio probe.  This actually works, but I'm crashing the kernel during boot because socdev->dev is null.  From backtracking, I'm having some difficulty figuring out where this is supposed to be set.  It looks like it should happen in the platform bus but, for some reason, is not.

So, in short, I'd like to know if I should be using davinci-i2s.c's dai or davinci-mcasp.c's dai.  I'd also like to know if anyone else was able to get tvp5158 audio on a DM365.

Anshuman, is this really the latest DM365 MCVIP driver?  It feels like the wrong archive was uploaded.

  • I've progressed a little further:

    asoc: tvp5158 <-> davinci-i2s mapping ok 
    ALSA device list:
       #0: DaVinci DM365 EVM (tvp5158) 
    
    
    
    

    However, to get here, I needed to comment out snd_soc_dapm_new_widgets and a few other dapm power management functions. When I looked into this further, though, it appears as if the mcvip driver is missing all of the dapm structures, such as snd_soc_dapm_route and snd_soc_dapm_widget.

    This furthers my suspicion that nobody actually uses this driver or that the wrong archive was uploaded. I'll learn some more about asoc / dapm and attempt to fill out the structures, but it would be very helpful if somebody with more knowledge of the davinci dm36x linux dvsdk / tvp5158 could weigh in on this.

  • I have this working now.  

    In the tvp5158 audio codec (tvp5158_audio.c), in tvp5158_audio_init, the following must be added:

    
    
        INIT_LIST_HEAD(&codec->dapm_widgets);
    INIT_LIST_HEAD(&codec->dapm_paths);
    ... or the kernel will deref a null pointer
    
    

    Then, if you want to get both video and audio working, you'll need to monkey around with the drivers and take advantage of the fact that the V4L2 loads first.  Hold on to the I2C handles, and use those to probe the tvp5158 when the ASoC driver loads.  While this works, I feel that there is a better way of handling the I2C address conflict... but that might be by placing extra hardware, such as an I2C address translator.

    Additionally, you want to use the "davinci-i2s" driver, not the mcasp dai.

    I haven't explored very far yet, but I was able to capture 4 concurrent 16KHz mono  audio channels using arecord while capturing, currently, 1 channel of video.

    Also, TI, this driver is, well, ugly.  I understand that it was a port from the UDWORKS code, but a lot of it ignores long held Kernel conventions such as using struct instead of "typedef struct", function and variable casing, etc.  If the driver was suitably cleaned up, I'm sure that it would be welcome in the mainline kernel tree.

    The TVP5158 is really a remarkable chip.  I'd love to see it used more, and one way to help with that would be quality driver support in Linux.

  • Dear mdeneen,

    how to " Hold on to the I2C handles, and use those to probe the tvp5158 when the ASoC driver loads." i must modify tvp5158.c or tvp5158_audio.c ?

    pls tell me how to do,

    thanks very much

  • Audio and video drivers try to use the same I2C address - it causes issues.

    My solution to force both audio and video works together was:

    1. Init audio driver with INCORRECT i2c address.

    2. First line of tvp5158_audio_codec_probe() is:

    i2c->addr = <correct_i2c_address>;

    I know it's a hack, but anyway.

  • Hello, gurus...

    I am also trying to run this audio driver (on DM368) and can't pass the initialization phase.
    I am stuck trying to do all necessary changes to move from DM6467 to DM365.
    As I understand, the files to be touched are:
    sound/soc/davinci/davinci-evm.c
    sound/soc/codecs/tvp5158_audio.c
    arch/arm/mach-davinci/board-dm365-evm.c

    I will be really thankful, if mdeneen (or some other guru) will be so kind to point out the necessary changes.

  • Hi,

    I am also trying to run the audio driver on DM368, tvp5158 audio device is not getting registered.

    If any one have fixed the problem, please provide the changes done on the auido driver.

    Any help is highly appreciated..

    Thanks in advance.

     

    Regards,

    Kiran