Anshuman,I'm reposting this. I have questions regarding the TVP5158 driver release that was announced in June 2011:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/118704.aspx.It appears that the TVP5158 driver requires a significant level of effort to integrate into a udworks DM36x reference DVR. See the following forum threads:
Because I was under the impression that this 5158 driver release was developed & validated on the DM36x DVR platform - the release notes state that the release 00.02.00 was validated on a DM365 DVR - these issues come as a surprise and concern to me. I've been working on the 5158 driver for several weeks w/a Leopardboard 368, and I'm not seeing that the current driver fits at all well on that platform either.At this point, it's clear that I need to better understand the current state of development on the 5158 driver. I've been using the DM365_DVR_DVSDK3_00.02.00.00.zip release package that you announced in June 2011, on the 4.02 DVSDK for the DM368. In the TVP5158 driver announcement, you state that this driver is for the DM36x, based on DVSDK 3.x and kernel 2.6.32, and again, the release notes state that the release was validated on a DM365 DVR.- On what specific DM36x platform did TI develop and validate this driver release?- This driver release from last summer has missing components, such as audio support, and is filled w/personalizations, including multiple references to user 'deepu' and his/her home directory. The driver comes across as incomplete and a work-in-progress. Are there plans and a timeline for an updated release?regards,gifford scott
I'm also interest in that driver.
Gifford, Have you got any reply?
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.
I'll do the same, if we decide to take the risk and bet on that platform...
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.
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
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.
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.
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'...
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.
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.
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.
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:
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.