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.

TVP5146 Driver Bug??

Other Parts Discussed in Thread: TVP5146

The TVP5146 datasheet (Page 30) says that "After reset, the user must write the following I2C commands tot he TVP5146:"

I2C Sub Address, Value

0xE8, 0x02
0xE9, 0x00
0xEA, 0x80
0xE0, 0x01
0xE8, 0x60
0xE9, 0x00
0xEA, 0xB0
0xE0, 0x01
0xE0, 0x00
0x03, 0x01
0x03, 0x00

The current tvp5146.c driver does not seem to be doing this.  The first address looks like an undocumented control address and the second address is the interrupt control address, but it writes to bit 1, which is reserved.  I'm not sure exactly what this is doing, but the datasheet clearly says it needs to be done and the driver is not performing this function.

 

Can anyone clarify what the reason for this setup is and if it really needs to be added into the driver?

 

  • Which release you are using? Can you provide more details?

    I checked the tvp514x.c at Davinci GIT tree in kernel.org and I can see the initialization sequence correctly done - look for the structure tvp5146_init_reg_seq in the code. The driver file I refer to is available here. Let me know if I am missing anything.

  • I'm using the DM357 DVSDK 2.05.01.14.  The driver is date stamped 2006.  The one you send me is stamped 2008 and obviously has some code in it for initalization.

    Is there a newer version I should be using for DM357 development?

  • Latest DVSDK software is available here. Please note the comment on DM357 here

  • That is the DVSDK I was looking at and the driver for the tvp5146 does not have the init sequence implemented.

     

    Are you referring to the "not recommended for new design" statement?  It's too late for that, design is already done.

  • I do not know the history of this driver but can you move to latest DVSDK or try using the latest driver. Are you facing any specific issue with the current driver code you have?

  • Yes, without that initialization code, I intermittently see a dark video output.

    The frequency of the problem is approximately once every 12-75 resets of the device.  Once the initialization was added to the driver, I was unable to reproduce the problem in over 150 attempts.  After pulling out the initialization sequence and attempting to reproduce the problem again, it was reproduced 12 resets later.

    You suggested moving to the latest DVSDK, but I am noting that the latest DVSDK (2.05 for the DM357) does NOT have this initialization sequence implemented.

    For now I just modified the driver and we can run with that, but it would be nice to get some of these driver updates into an official DVSDK release.

    I also have an email in to my local FAE trying to understand what exactly this initialization sequence even does since the registers/bits is uses are not documented in the datasheet.

  • DVSDK 3.10 is the latest software - unless you are using a feature very specific to DM357 the latest software should work. Good to hear your modified driver with the init code resolves your current issue.

    PS: Please mark this post as verified if you think this has answered your question. Thanks.

  • The tvp514x.c driver I have in DVSDK_2_10_01_18 for evmdm365 starts off with the same commands as per tvp5146 datasheet but does not do all 11 of them and switches over to do its own thing - in total 16 cmd's.  Can I assume this is correct as dm357 is an old device and all new ones should be okay?  I am back at the vpfe and vpbe again to get my output video in sync with the input and looks like I need to configure some more signals to emerge from the tvp so I can use them in the dm365 to generate the output.  Any help which signals to use and what to do with them will be appreciated. I am looking at vsync for a start.

    Thanks, Jinh T.