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.

Thank you.

We are using the 2.6.32 kernel. The 5158 audio driver has been changed a little.

I feel like we are close but there must be a setting or two that are off just enough to cause problems.

Cheers,

Brian

Thank you.

We are using the 2.6.32 kernel. The 5158 audio driver has been changed a little.

I feel like we are close but there must be a setting or two that are off just enough to cause problems.

Cheers,

Brian

Mark,

Do you remember if you kept the changes for the higher priority EDMA channel in your device that used the 5158? I am digging into the EDMA code now to see how to change the priority. I am concerned about changing the priority and mucking up something else.

Thanks,

Brian

Brian,

Unfortunately, I did not keep those changes and I didn't happen to put them in my git repository.  Are you having trouble with channel swaps while capturing video or just trying to capture audio by itself?

-M

Mark,

Thanks for looking for your changes.

Yes I am still having channel swaps when I use arecord to record audio. I feel that the McBSP settings and 5158 settings are correct. Could this be related to the EDMA settings and priorities? I am working through the kernel code to understand how to change the EDMA priority. I am also trying not to muck up anything by making inadvertent changes.

Any insight you can share is appreciated.

Brian

Brian,

I would highly advise using TDM on McBSP and DSP mode on the TVP5158.

Mark

Mark,

I think I am. 

On the 5158, I am using DSP mode with 2 phases of 2 16-bit samples per phase.

On the McBSP, I am set up for the same.  We only receive data, no transmission.

Here are my register settings:

--------McBSP REGISTER DUMP ----------
DRR : 0x49b
DXR : 0x0
SPCR : 0x200003f
RCR : 0x81410140      (dual phase frame, 2 words in phase 1 and 2, receive word length 16bits, 1 bit delay, no companding)
XCR : 0x440140
SRGR : 0x101f0f00
MCR : 0x0
PCR : 0x85                    (receive data on rising edge of clk_r, frame sync pulse active low, input clock from 5158)

Here are my 5158 settings:

REG 0xc0 => 0          (16 khz sampling rate)
REG 0xc1 => 88        (0 db audio gain for channels 1 and 2)
REG 0xc2 => 88        (0 db audio gain for channels 3 and 4)
REG 0xc3 => 78        (SD-R output enabled, Master mode, DSP justified mode, 64 fs, 16-bit PCM, SD-R only)
REG 0xc4 => 9          (Channel 1 Audio mixer, four TDM channels)
REG 0xc5 => 0          (Audio mutes Off)
REG 0xc6 => 0          (Audio mixing ratio default)
REG 0xc7 => 0          (Audio mixing ratio default)
REG 0xc8 => 0          (First stage default)

I know this is tedious looking at these register settings. Do you see anything that may be incorrect?

Did you have to change any EDMA settings for your system to work correctly?

Thanks,

Brian

Brian,

DSP mode on the TVP5158 would be a single clock pulse followed by 4 frames of data; there is no phase or left/right channels.

I did not have to change EDMA for audio to work.

Mark

Mark,

I can try a single phase on the McBSP with 4 words in phase 0 of 16 bits each and see how it does. When I load down the system with video encoding, the sound clicks and seems to jump around.

Thanks for your help,

Brian

Mark,

My system is now set for 1 phase, 4 16-bit channels, 1 bit delay,  I am using arecord to record audio on my platform and aplay to play back the files on my workstation.

The audio sounds good but I recorded twice and the channels jumped. I don't know if this could be an issue with arecord.

Here is my command line:

arecord -f S16_LE -c 4 -d 10 -I -s 16000 <filename>

This creates four files of audio. 

Is this how you tested?

Thanks,

Brian

Brian,

I did not use arecord, but instead read the data using the alsa api.  The end result should be the same, though.

I don't see how it can get out of sync, though, since missed frames would always resync on a clock pulse.  If I remember correctly, there is a bit in a registers which tells the McBSP to ignore extra clock pulses?  That might be important if you are unable to keep up with the data.

When using arecord (and nothing else), what does top show for cpu usage?  It should be very low, less than 2%.

Mark

Mark,

I just ran top while recording some audio. The CPU utilization is low ~2% so I am not slamming the system. Audio sounds good and clear.

Can you think of any other system parameters that you tweaked? Any dma parameters? I have tried changing the dma_params->data_type before but there may have been other settings that weren't optimum previously. I'll try that again.

Thanks,

Brian

Brian,

Yes!  I enabled SRAM DMA ping-pong buffers.  I don't know if this is available in the 2.6.32 kernel (I'm using 2.6.37), but I believe that there is a patch for it if it is not already present.  It uses SRAM for the DMA buffers instead of DDR.  Be careful with this one, because it might conflict with a cmem buffer and things get really trippy because you end up encoding audio data as video.

All you need to do is adjust the cmem pool to avoid the first 8 kilobytes of SRAM, or whatever DMA buffer size you select to avoid this conflict.

Mark

Thanks.

I put in the SRAM ping-pong buffer patches into my kernel. I can hear the audio fine when I don't stream video with it. The video buffers are being affected by the audio. The video is fouled up and the audio sounds like before with the repetitive clicks.  I have tried moving the CMEM start address with no luck. I added 8K and then 16K to the start address with no luck.  If you think of anything else I should try, let me know. I will continue to dig on this one.

Cheers,

Brian

Brian,

You're on the right path, and you're listening to video and h.264 encoding sound.  What you need to do is move the base address of the first CMEM pool, the one which is located in SRAM, since this resource is now used by the i2s ping-pong buffers.  The rest of the CMEM stuff can stay as-is.  Just verify your addresses and you should be good to go!

Mark

Mark,

I tried changing the start location of the CMEM module with no success. I moved it by 8K and 16K and still had poor video. The video is mucked up by the audio data as you suspected. When you used CMEM, did you use the TCM (tightly-coupled memory) mode of the H.264 encoder?  This utilizes the internal RAM of the DM368. The instructions use the memory at 0x0 to 0x7fff for instructions and 0x10000 to 0x17fff for data by the encoder.

I looked at the sram dma address of the sram ping-pong buffer code I added. The base address is 0x10000. To me it looks like the audio buffer memory is stomping on top of the memory used by the H.264 encoder.  

Here is my CMEM line:

modprobe cmemk phys_start=<0x82604000> phys_end=<0x88000000> useHeapIfPoolUnavailable=1 allowOverlap=1 phys_start_1=0x00001000 phys_end_1=0x00008000 pools_1=1x28672

The phys_start and end values are shown in hex. I normally start it at 0x82600000 but I shifted it 16K. We limit the kernel memory to 32Meg for our application.

Does any of this make sense?

Thanks,

Brian

Brian,

You're changing the wrong pool, 0x82600000 would be DDR and not SRAM.  You want to change pool 1, the one you have starting at 0x00001000.

The DM36x has 32K of internal SRAM, and you're using 28K for the TCM pool.  You can use the rest for the ping-pong buffers.

Mark

Mark,

Thanks for your help. Where is that assigned? davinci_i2s_probe in davinci-i2s.c? I have been calling the internal RAM of the chip IRAM and the external memory SRAM.

Brian

Mark,

So I should make the capture buffer size 4K and point the dma address to 0x0 in my scenario. I am currently leaving 4K empty at the start of the physical address space. How does that look? Anything else I am missing?

Thanks for your guidance.

Brian

Brian,

I figured that there was a confusion between DDR and SRAM.

That should be fine.  You can see where sram will be allocated in sound/soc/davinci/davinci-pcm.c, the allocate_sram function.  It's pretty simple and just allocates some sram starting at address 0x00.

-M

Mark,

I placed the ping-pong buffers of 4K total size at SRAM address 0x0. Right now I am getting a bumble bee sound and the video freezes. Is this where you placed your ping-pong buffers? 

I have wondered if they should be somewhere in the address range 0x10000 to 0x17FFF. 

Thanks,

Brian

Brian,

Yes, 0x0.  I am using a DM365 & 2.6.37, and I'm wondering if there is a difference there?  With that being said, what you are describing suggests that there is a resource conflict somewhere.  I was under the impression that the TCM interface of the codec used cmem pool 1, given the following from the XDC config:

var MEMTCM = xdc.useModule('ti.sdo.fc.ires.memtcm.MEMTCM');

MEMTCM.cmemBlockId = 1; //Since we use _1 in our insmod command.

So, as long as pool 1 and your sram allocation in linux do not conflict, things should be perfectly fine.  If you disable TCM in your codec, do things work as expected?

Mark

Mark,

I am using DM368 and 2.6.32 kernel. My MEMTCM settings match yours. How do I disable the TCM in the codec? I have looked for "useARM926Tcm" and I can't find it. (I inherited this code.)

Brian

Brian,

Without getting too detailed, it is a member of the IH264VENC_Params structure.  This is passed in to the codec as a VIDENC1_Params with the size member set so that the codec knows that you are passing in a IH264VENC_Params struct.

Mark

Thanks Mark.

From what I can tell, TCM is not being used by the encoder now. There is a variable called enableARM926Tcm that is not set anywhere.  I will have to poke around and see what is going on.

Cheers and thanks for your help,

Brian

Mark,

Using arecord, I have been able to get sound via the SRAM ping-pong buffers but only if I set the sram ping-pong buffer address to 0x10000. Unfortunately, this is in the tightly coupled memory data location. This of course mucks up the video as this location is used by the h.264 video encoder. . When I try to move it to 0x0 (beginning of the TCM instruction memory), I get all zeros for data. I am setting the location of the sram to 0x00000000 in the dm365.c file in the davinci_soc_info_dm365 data structure. This is the value that is used in sram_alloc in sram.c. I also comment out the check for a zero dma_base value in the function since this is where I want it to go.  Is this what you did or am I missing something?

Can you check and see if you TCM support configured in your kernel? I am wondering if I am not getting access to the low memory because support is not compiled into the kernel (2.6.32) that I have. I did find in /arch/arm/kernel files tcm.c and tcm.h that were not compiled.

Thanks,

Brian

My build is not using tcm.c, and audio is at 0x0.  Perhaps there is some other more hidden difference between 2.6.32 and 2.6.37.

-M

Mark,

Thanks for the info. I decided to remove the SRAM ping-pong buffer patch. I did discover that the audio was on Event Queue 0. When I moved it to Event Queue 3, things are working much better, I am still getting the channel jumping problem when under stress but the sound is clear along with the video.  Perhaps I can figure out why moving the SRAM buffers to 0x0 didn't work on my system.

Cheers,

Brian

Mark,

i think that the EDMA can not access the memory at offset 0x0 in my system due to kernel settings. In DM365.c, there is a data structure called dm365_io_desc and the section for SRAM has a several settings. One has a _phys_to_pfn(0x00010000) setting. 

When you get a chance, can you check in your code and see what you have in this data structure?

Here is what I have:

{

   .virtual    = SRAM_VIRT

   .pfn         = __phys_to_pfn(0x00010000),

   .length   =   SZ_32K,

    .type = MT_DEVICE

}

Thanks,

Brian

Brian,

My structure is slightly different:

    {  
        .virtual    = SRAM_VIRT,
        .pfn        = __phys_to_pfn(0x00010000),
        .length     = SZ_32K,
        .type       = MT_MEMORY_NONCACHED,
    },

The 0x00010000 value looks to be correct, by the way, after reading section 3.7 in the ARM Subsystem manual (sprufg5a).

A quick search on this revealed a patch which enabled the change between MT_DEVICE and MT_MEMORY_NONCACHED, but I'm not entirely clear on what the difference is between these types.

-M 

One last thing, here is the contents of sram.c from my kernel: http://pastebin.com/raw.php?i=K71ikpCq

-M

Mark,

Your Sram.c matches mine except that I commented out the test in sram_alloc that tested to see if sram_pool is 0 or dma and !dma_base.

I set the sram_dma to 0x0 and .sram_len to 32K in the dm365.c file in the davinici_soc_info_dm365 data structure.  Does that match your settings?

Thanks,

Brian

Brian,

Nope.  My sram_dma is 0x00010000, which should point to the DTCM base address.  0x0 here would be the ITCM base address, which is reserved for instructions and not data.

-M

Brian,

One last thing.  I think that we are getting mixed up a bit between physical and virtual addresses here, and what 0x0 actually represents in the sram allocation.

-M

Mark,

I don't understand your allocation of sram at physical address 0x0 for 4K.  My allocate_sram function gives me an iram_phys (address) of 0x10000 which is DTCM. The iram_virt is 0xfffe 0000 which is the virtual address. 

What is your understanding of 0x0 in the sram allocation?

Thanks,

Brian