On Sun, 2009-09-20 at 20:50 +0200, Martin Dauskardt wrote: > Hi Andy, > > > > > I'll have to look into this more. If you turn on the info and mailbox > > flags with the debug module option to ivtv, then speed settings and > > commands to the decoder will get logged. You can see the difference in > > what is happening in the ioctl() command sequences you mention above. > > I never really understand this bitmask stuff > parm: debug:Debug level (bitmask). Default: 0 > 1/0x0001: warning > 2/0x0002: info > 4/0x0004: mailbox > 8/0x0008: ioctl > 16/0x0010: file > 32/0x0020: dma > 64/0x0040: irq > 128/0x0080: decoder > 256/0x0100: yuv > 512/0x0200: i2c > 1024/0x0400: high volume > > What value do I need to activate both info and mailbox? Can I simply add 1 + > 4, and use "modprobe ivtv debug= 5 " ?
Martin, Yes that is almost correct. Info => 2 and Mailbox => 4 so you would use 2 + 4 = 6 # modprobe ivtv debug=6 Also logging debug warnings usually doesn't hurt, so maybe you would want to use debug=7. > What would be the value for info,mailbox, ioctl and decoder? 2+4+8+128 = 142 # modprobe debug=142 Perhaps that will provide more insight. I won't have time to look into any of this deeply until after I get back from the LPC this week. > > > > > There is only one place in ivtv_v4l2_write where EAGAIN can be returned: > > > if (filp->f_flags & O_NONBLOCK) > > > return -EAGAIN; > > > > > > I open the /dev/video16 with O_WRONLY | O_NONBLOCK > > > > When most people open with O_NONBLOCK, they call select() on the file > > descriptor, to wait until it is ready and avoid EAGAIN. If you are not > > already, maybe you should call select() to wait until the fd is > > writable. If given a very long timeout, select() times out , then the > > problem may be that the Decoder is stopped for some unknown reason. > > The /dev/video16 is opened only once at plugin start and keeps open during > runtime. A device node being open for a long time doesn't mean the driver is always ready to accept more data for writing. As you hypothesized earlier, if the decoder hardware and firmware "owns" all the buffers at a moment in time, there is no buffer into which an application can write data. If you try an write(), when the driver is not ready to accept write() data, the application will either block in the write() call or, if you have O_NONBLOCK set on the fd, the write() call will return immediately with an errno of EAGAIN. Regards, Andy > I should note that vdr is frequently calling VIDEO_GET_PTS during trickmode > playback. > > Greets, > Martin > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
