Re: [PATCH] zr36067: Debugging cleanups (updated again)

Hi Trent,

On May 23, 2007, at 4:12 PM, Trent Piepho wrote:
> This looks good to me.  Ronald, if you send me your ack, I will  
> pull this into
> the v4l-dvb repository.

"Ack" :-).

> I've also got a question about the internal driver operation.
>
> The private data for the file handled passed to file opts functions  
> (e.g.
> ioctl) is a struct zoran_fh.  One of the fields in this struct is  
> "struct
> zoran_v4l_struct v4l_buffers", which describes the state of the v4l 
> (2) capture
> buffers.
>
> The zoran_fh also has a pointer to a "struct zoran", which has the  
> state for
> the chip.  This struct _also_ has a v4l_buffers field for the same  
> information
> as the field in the file handle specific data.
>
> What is the difference between the two different places the v4l  
> buffers are
> described?  From what I can tell, the v4l_buffers in the struct  
> zoran is the
> real one.  The copy in the file handle appears to never change  
> during capture.

According to the v4l2 specs, each file handle can allocate their own  
buffers. We support that by putting it in the zoran_fh. There's two  
ways to sync the device to the actively capturing fh, one is to  
provide a pointer, one is to copy the data. We copy, b/c that  
prevents any possibility of crashing the kernel in case of a race/bug/ 
etc. Call it paranoia, it is. The device updates that one, and the  
actively capturing one syncs with it in the DQBUF operation. The  
other way around also works, the apps update the zoran_fh and we  
merge it with the device state in QBUF. So both are real, they're  
just copies for security, it's intentional.

Ronald


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/