TVP5158 Driver Validation

I'm also interest in that driver.

Gifford, Have you got any reply?

Amir

Amir,

Our company has discussed this concern w/our local TI FAE, and we have been promised a telephone conference sometime this week w/TI India.  According to our FAE, Anshuman has confirmed that this driver was validated on the udworks DM365 DVR reference platform, using DVSDK 3.x.  But given the issues that other developers have had running the June 2011 driver release on the udworks DVR platform, I want to discuss w/TI the exact set of software that needs to be loaded and run, in order to validate the driver.  At this moment, I'm primarily concerned that the released driver may not properly initialize the TVP5158 driver chip, but instead may need additional application s/w, like mcvip_test.out, to do this work.  I've been trying to port this driver to a Leopardboard368 w/o first testing it out on a udworks DVR platform, and that's been a difficult process.  I'll post an update to this thread when I hear more from TI.

regards,
gifford scott

Thanks Gifford,

I'll do the same, if we decide to take the risk and bet on that platform...

Amir

Gifford,

Any word on this?  I've been attempting to forward port the driver to a 2.6.37 kernel.  One thing that I've learned is that TI should have made a MFD driver to combine audio and video.  I'm investigating how difficult this will be.

Unfortunately, the ASoC layer has changed significantly between 2.6.32 and 2.6.37.  MFD looks to be the way to go -- you pull the core of the driver up into a parent driver.  This driver serializes i/o so that audio and video register writes are not stepping on each other.

-M

Mark,

Thanks very much for hitting this thread again.  I had been holding off on updating this thread until we had completed our conversation w/TI.  We did resolve our show-stopping issue w/the TVP5158 driver, two weeks ago, w/assistance from TI & Anshuman.  I had initially suspected that our issue was w/the TVP5158 register initialization, but we satisfied ourselves that the TVP5158 was initialized and responding correctly, even w/the small subset of registers that the driver was writing to the chip.  After exhausting that possibility, and on TI/Anshuman's recommendation, we looked at the internal ISIF registers and found our issue:

The udWorks DVR swaps the pinning of the high- (Y) and low-byte (Cr/Cb) of the master TVP5158 decoder in its connection to the DM368 video port.  The Leopardboard TVP5146 module and our TVP5158 module don't do this swapping.  The difference was hidden by the fact that the udWorks DVR schematic labeled the video port net names as if no swap had been done.  The 5158 driver required a change, to set the YCINSWP bit in the ISIF CCDCFG register in dm365_ccdc.c.

We lost two weeks on this problem, plus the two weeks that it originally took to clean-up the driver so that it would install correctly on kernel 2.6.32 on the Leopardboard (removal of the slave 5158 support, I2C address issues, restoring support for NTSC 525-line modes, demux threading problems, etc, etc).  I saw the work that you had to do to serialize the audio & video I2C writes under kernel 2.6.32 and the Jun 2011 TVP5158 driver, and re-enabling the audio support on the Jun 2011 TVP5158 driver *is* still on our to-do list.  Other than that, we're not planning to upgrade our kernel to 2.6.37, having seen no pressing need to do so.  Sorry that I cannot be of more assistance, especially given your significant contributions to the TVP5158 knowledge base.

Also, I do have confirmation from TI for my first question above:

- The Jun 2011 TVP5158 driver (DM365_DVR_DVSDK3_00.02.00.00.zip) was validated on the udWorks reference DM365 DVR.

regards,
gifford

Gifford,

Thanks for the update.  Do you have any more information on the demux threading problem?  I haven't run into anything terrible there, and I would rather find the problem sooner than later.

Thanks,

Mark

Mark,

When using the user space mcvip.a lib and API, we thought we had seen race conditions that prevent the consistent release of frame buffers.  We've been reluctant to change much in the TVP5158 driver, ever since it started working :), so I haven't done much in mcvip_demux.c, other than commenting out printfs.  Whether more work is needed, is TBD.

regards,
gifford

I significantly changed libmcvip.a, so it wouldn't surprise me if I fixed a few bugs with the threading.

Thanks for the update.

Yes, linux is all about 'learning by doing'...

Gifford,

I just wanted to let you know that when you get around to tvp5158 audio, you're going to need to modify davinci-i2s.c a bit in order to configure McBSP correctly.  It will work the way you have it now, but your audio channels will not be constant.  That is, you may record channels 1,2,3,4 (in that order) on one try and 3,4,1,2 the next time around.  Also, if there is a buffer overrun, your channels will be all mixed up.

I've configured mine here to capture 1 32 bit word in phase 1 and 1 32 bit word in phase 2.  This is beneficial because it significantly cuts down on the number of interrupts and you end up with your data as follows:

32 bit Left channel has tvp5158 channels 3,1

32 bit Right channel has tvp5158 channels 4,2

However, when recording from something, say, "arecord", it gets it all right if you specify 4 16 bit channels.  You end up with a 4 channel wav file with your channels in 3,1,4,2 order.

-M

Mark,

It's been awhile.  The tips on channel ordering are very much appreciated.  We've only got the 5158 hooked up to the video port on the Leopardboard, for now; looking forward to the fun when we get h/w with a McBSP connection.

regards,
gifford

I am also working on the audio using the 5158 chip and the DM368.  Are there any other changes to the Davinci-i2s.c file other than setting the RCR register in the McBSP to use 2 phases and 32 bits per phase?  I am concerned about the DMA parameters, etc.. Right now everything is set up for 16 bit data.

Thanks,

Brian

Brian,

Even after using 32 bits per phase, I would still occasionally run into situations where the two channels would flip when the DM365 was under load.  I ended up configuring the tvp5158 in dsp mode and the McBSP accordingly.  It was a pain, but I've done hours of recording without channel flips.

This works because there is a single pulse followed by 4 frames of audio.  It's impossible to get out of sync.

Thanks for the reply.

Right now I have the 5158 sending 4 channels at 16 bits each (PCM linear) and the McBSP set for DSP mode, with the RCR register set to 1 bit delay, 2 phases of 2 16 bit words each. When we load down the system, the audio channel can skip to other slots. Right now I am looking at boosting the priority of the EDMA operation. Ultimately I want to use 8 bit uLaw audio for each channel but I am using 16 bit PCM linear for now.

I am not sure if I have the McBSP registers set correctly.

Here are my register settings:

SPCR  0x2000037

RCR  0x81410140

SRGR 0x101F0F00

PCR = 0x85

5158 register 0xC3 is set to 0x78. DSP mode, master, 64fs

If you see anything blatantly fouled up, I am open to correction.

Thanks,

Brian

I went down the same road already.  While switching to a higher priority EDMA channel and using SRAM for the DMA buffers helped, it was still possible to get out of sync.

From what I saw, it was not possible to use 8 bit uLaw in DSP mode on the tvp5158, so take of this what you will.

In short, I set up McBSP in TDM mode and TVP5158 in DSP mode.  I don't have the hardware handy at the moment to output the McBSP register settings, but here's what I can recall:

5158 0xC3 is 0x78

+#define AUDIO_FORMAT (SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_IB_NF)

2 bit RCR delay

TDM mode, with 4x16 bit channels.

If I can get the hardware again, I can dump the register values.  In the mean time, though, I'd advise reading the McBSP docs and understanding how it handles TDM.  It matches the DSP mode of the TVP5158 pretty well, but it can be frustrating to get set up.

I'm also using a 2.6.37 kernel, a 4.0.3 DVSDK "prerelease", and I've made significant changes to the TVP5158 driver, so it is a little difficult to pick apart what I've done to help you.  I'll do my best to get the hardware and dump the McBSP regs, though.