• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 493 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

tvp514x driver

Marco Braga
Expert 1780 points
Other Parts Discussed in Thread: TVP5150

Hi,

while tesing the EVM board with tvp514x driver I've noticed that the "open" of "/dev/video0" fails when no input is connected. This also makes the call to DMAI's Capture_create and Capture_detectVideoStd.

I've traced this to "tvp514x_initialize" function that does basic initialization of video inputs. This function calls tvp514x_setinput and this function fails if no input is connected. So "tvp514x_initialize" fails too and following the chain the open to the video0 driver fails too. I'm not sure if this is the wanted behavior. I'm asking because in some project we cannot be sure if video input is actually connected and we cannot rely on v4l to know since open fails.

I can solve the problem by customizing the driver to create a char device I can rely on to know the video lock status through i2c, but is this the intended behavior of the v4l davinci driver or just a bug?

 

  • 0
    TI__Mastermind 41665 points

    This seems to be the way that the driver was architected, in other words returning a fail to open with no input seems to be expected operation as opposed to a bug. Your feedback would be that the open should succeed with some sort of status bit returned that specifies if the video is really there or not and have an ioctl to check status later on?

  • 0 in reply to Bernie Thompson TI
    Expert 1780 points

    At the moment I am working on expanding the tvp51xx module (for TVP5150 but the concept is the same) so that I can check if video is connected and know the video standard before actually opening v4l "video0" driver.

    I've done this by creating a separate character device that the application can open and ioctl to check the lock and video standard.

    Basically I've appreciated the presence of a "standard detect" function in DMAI, but it's usefulness is really diminished by the fact that it fails if no video is connected. Ok, if no video is connected there is no standard to detect, but the point is that it would be great to be able to open the driver, check if there is video and what standard, configure the app for it and start capturing (all in DMAI and with a consisent interface). So I'd like to Capture_create even if no video is present, check if/when a video input is connected, and then start capturing, all with the same interface.

    At the moment this is impossible.

    So my solution is to check those info separately (on a separate character device created by a modified version of the same module that instances the tvp decoder for v4l) and then, when I know what to do, I call Capture_create.

    Also notice that in some situations Capture_get can lock forever if video source is disconnected, depending on decoder specs. My solution is to add to DMAI a new "Caputre_get_timeout" function that issues a "poll()" on the v4l file descriptor. This allows at least to timeout if video capture stalls.

    Too bad all those functionalities are missing in the TI package, but with a bit of work they can be added. :)

     

  • 0 in reply to Marco Braga
    Expert 2315 points

    Marco, is the above from your previous post still the solution for this problem with the driver or have you invented/fixed something in the mean time?  I am having the same hassle as you currently and as a linux newbie am struggling a bit but making progress slowly.... at least finding this thread which I remember stumbled across a while ago.  Help much appreciated.

    Hijn

  • 0 in reply to Jinh
    Expert 1780 points

    Yes, I've decided to go that way. Basically the rationale is this:

    When there is no video, /dev/video0 returns an error when openend, but there is no point in asking the standard. If there is video then /dev/video0 can be opened. The problem is that I don't like continuing calling "Capture_create" until it succeeds. This call does a lot of things before discovering that there is no video.

    Another point is that the driver call to request the real video standard when the decoder is in auto pauses the capture, so you can't use it when capturing. This is a big point, since the video source can change standard without causing a video loss.

    Last point is that if you disconnect the video when capturing, some decoders will continue to provide a black image in the last standard the locked in or will stop sending video. In the first case you won't notice the video loss, in the second Capture_get will block indefinitely.

    My solution has been to add a timeout to Capture_get and to bypass the v4l driver.

  • 0 in reply to Marco Braga
    Expert 2315 points

    Hi Marco,

    hope you still remember some dm365 stuff as I am still busy with it and now near the end it seems like my development setup is falling apart.  I have just now made another post on the forum regarding an issue which seems to make my /dev/video0 corrupt or something.  Would you please have a look if you don't mind as I am also at the point of implementing something that checks /dev/video0 for video present as we have discussed previously i this thread.

    The other post is at: http://e2e.ti.com/support/embedded/linux/f/354/t/165834.aspx

    Thanks, Jinh T.