Re: zr364xx: Aiptek DV8800 (neo): 08ca:2062: Fails on subsequent zr364xx_open()

[Antoine Jacquet <royale@zerezo.com>]

Hi,

>> Someone reported similar behavior recently, and was apparently able to 
>> fix the issue by adding more delay between open/close sequences.
> 
> No search tags to find it on the list, can You remember device model?

Yes, this was an off-list discussion, available here:
	http://royale.zerezo.com/forum/viewtopic.php?t=355

> Didn't work, same -110 errors, sorry, no v4l-dvb git here, vdr 
> production machine on 2.6.32.7.

Just checked and the differences in the zr364xx driver are minor.
Would be better if you could work on LinuxTV hg/git tree so we have the 
same basis for patches.

> 1. Patch with optimized delay below, slow but works, 1st try was 
> delaying subsequent msg at open sequence i=6, worked until the last 2 
> open() before capture start.
>> From the windows snoopy log I sent yesterday I can see only 1-2 URBs 
>> with relevant delay of ~1s but 
> cannot see the sequence point.

Ok this is a bit hardcore but nice if it works.
What do you mean by "until the last 2 open()"?
Also, you may want to try with simpler tools like "dd" to do only one 
clean open/close.
Ekiga/Cheese/Skype tend to do many open/close and this may not be the 
ideal tools for debugging, but great to trigger the bugs ;-)

> What is error -22, can not find it in errno.h?

I think it's -EINVAL.

> 2. Picture with (640->320) lines alignment error with ekiga+cheese 
> *attached*, wether cam is configured internally for 640x480 or 320x240, 
> not affecting.
> setting the driver to mode=2 fails with libv4l jpeg decoding errors. I 
> try to correct this.

Do you know if the Windows driver support this mode?
If so, it would be helpful to have the snoop too.

> 3. Driver oops on modprobe -r or device firmware crash, I need to unplug 
> first or null pointer fault occours (mutex locks), see below

Ok that's bad, let me know if you find the issue.

Regards,

Antoine


-- 
Antoine "Royale" Jacquet
http://royale.zerezo.com