No subject

there is a hardware scaler in the chip.  The cx25840 driver always sets 
the "native" capture resolution to be 720 pixels wide.  So, when we 
capture 720, there's no scaling needed and the scaler is apparently left 
disabled.  But when the horizontal capture resolution is set to 
something else, the cx25840 module programs the scaler appropriately to 
generate that result.

When I last looked at this in 2006, the best I could figure was that the 
chip's hardware scaler was not being correctly programmed, thus anything 
but 720 produced corrupted video.  Another mystery at the time was why 
only the pvrusb2 driver was being affected by this.  A little while 
later it was discovered that triggering the cx25840 driver's VBI 
initialization caused the problem to go away - which is why only the 
pvrusb2 driver was being burned.  Other drivers had VBI support but 
since the pvrusb2 driver did not, I never bothered with that setup.  
The "fix" I did in 2006 was to trigger essentially a dummy VBI 
initialization within the cx25840 driver.  I really did not understand 
that chip very well and so I considered myself lucky that this was 
enough to fix it.

Fast forward to now, and things have changed.

With stock kernels 2.6.26 -> 2.6.28 (and probably higher - it's all I've 
tested so far), this problem exists for the HVR-1950 (which also has a 
cx25843).  In fact, since 2.6.26 was the first kernel whose pvrusb2 
driver included support for the HVR-1950, that hardware has basically 
been broken all along :-( However at the same time, the 24xxx device 
continues to work fine.  This is very strange because it's the same chip 
in both so I really would expect it to either work in both types of 
hardware or fail in both types.

It's even stranger that nobody noticed this until now - HVR-1950 was 
declared supported well over a year ago.  But likely most people using 
the HVR-1950 are probably only running it in digital mode and thus don't 
get hit by this.  Or maybe others have independantly figured out that 
720 works and just haven't bothered to warn me about it.  The fact that 
24xxx devices worked all along is probably why I missed this.

I then discovered that with the current v4l-dvb snapshot, the 24xxx 
device is also broken the same way!  (And given this discovery I 
strongly suspect that anything but 720 horizontal resolution for the 
24xxx is probably broken once again starting with kernel 2.6.30.)

That pissed me off.  I ended up spending far too much time last night in 
v4l-dvb trying to figure out when it broke.  I basically binary-searched 
my way through a thousand or so revisions of that repository in an 
attempt to find when the problem was reintroduced.  What fun.  But I got 
my answer (and if I had put a little more thought into it earlier I 
could have found it quicker).  Just now I confirmed it, though 
unfortunately this does not yet lead to a solution.

Last March I made a bunch of pvrusb2 driver changes to support a new 
driver binding model in v4l-dvb.  There is now a concept of a 
"sub-device" in v4l-dvb, and along with it a new way to link up 
sub-device drivers when bringing up a driver such as pvrusb2.  
Previously those sub-device drivers were just I2C client drivers and we 
used kernel I2C mechanisms to send commands to those client drivers.  
But now with the new mechanism in place, there is an entirely different 
means for issuing commands.

About 15 minutes ago I wound my v4l-dvb repo back to the point just 
after I had added sub-device support in the pvrusb2 driver.  I also did 
the same thing with the standalone driver.  Then I compiled the 
standalone driver against that v4l-dvb snapshot and tried the whole 
thing in kernel 2.6.28.10.  I tried it twice.  The first time I tried it 
using the sub-device communication / binding mechanism.  Then - with the 
SAME repository and standalone driver - I did it again using the old 
mechanism.  Unlike the in-V4L version of the pvrusb2 driver, the 
standalone pvrusb2 driver includes both implementations, selectable at 
compile time via an ifdef - I do this in order to continue supporting 
older stock kernels where the new mechanism doesn't exist.  So guess 
what: The problem cleared when I shifted back to the old binding 
mechanism!

I did verify that even with the new sub-device binding mechanism that 
I'm still issuing that VBI setup command.  So that's not the problem.  
Something else is going on.  Either I'm missing something in my use of 
the new mechanism or the cx25840 driver itself is missing some critical 
behavior with the new mechanism.  I'm going to try to solve that now.  
The solution, whatever it is, should restore correct 24xxx device 
behavior.  And I'm *hoping* that in fixing this I'm going to then learn 
enough to understand why HVR-1950 has been broken independant of the 
binding mechanism in use.

If we're lucky I (or somebody) will figure this out before the end of 
the day today.  I think I understand the cx25840 a little better now 
than 2 years ago so I might be able to get to the bottom of it this 
time.  I welcome help from anyone who might have a good understanding of 
the cx25840 chip architecture.  Cross your fingers.

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8