On Sun, 9 Mar 2008, Mark Goldberg wrote: > On Sun, Mar 9, 2008 at 11:18 AM, Mike Isely <[EMAIL PROTECTED]> wrote: > > > > I can tell you however that it's the programming of the video digitizer > > that should be affecting this. That is controlled by either saa7115.ko > > or cx25840.ko (depending on if you are using a 29xxx or a 24xxx device, > > respectively). The pvrusb2 driver itself doesn't directly set up > > details like that - it just tells the module "use video standard XYZ and > > I want the capture resolution to be H x V", the rest is pretty much up > > to the module (i.e. saa7115.ko or cx25840.ko). This is why I'm doubtful > > that recent pvrusb2 driver changes could be responsible. This > > unfortunately doesn't align with your observations, so I really have no > > idea what is going on here. > > It's a cx25840. > > How can I see what is getting passed? When is it done? I can do some > debugging. > > If you remember the order of module loading changed on my system with the new > snapshot and I have to add video_nr=2 to get it to load at the right > time. Maybe the > load order is keeping it from intiializing at the right time or maybe > it is getting initialized > again wrong. Or, is the initialization at capture time?
Initialization order should have nothing to do with it. Once the pvrusb2 driver is told about the new device, it sets up communications with it. As part of that process, the driver initialization an I2C adapter abstraction in the kernel. When that happens, various registered I2C modules (e.g. cx25840) probe the bus and initialize themselves when they find the part they are looking for. So the initialization and operation of the cx25843 chip in your device is pretty much autonomous with respect to the pvrusb2 driver - once the driver initializes that I2C adapter. And in that respect it should not matter if you are dealing with /dev/video0, /dev/video1, or /dev/video2. Once the cx25840 module has begun talking to the chip, then it can do whatever communication it wants with it at any time. It's entirely up to the module. For example, the lirc_i2c module will perform continuous polls of the IR receiver chip in order to catch incoming IR codes. The cx25840 module is going to do a whole pile of transactions up front, first to send its chip a piece of firmware, then to initialize a mess of registers in the chip. This action is *completely* up to the cx25840 module, not the pvrusb2 driver. Once initialization is complete, then generally a module like cx25840 is going to go idle until such time as it sees activity from the pvrusb2 driver - there's a sort of a "bus" where the pvrusb2 where the pvrusb2 driver can put stuff out there to be noticed by these modules. For example, "set frequency" or "set video standard", or "begin capture". When the cx25840 module sees these things it is going to react by performing more transactions with its chip, in order to implement the effect of those actions. For the record, this description also applies to saa7115 (for 29xxx devices), except in that case there's no firmware to load. As for being able to trace the cx25840 module, there are some hackish things we can do in the pvrusb2 driver to snoop the I2C traffic between the cx25840 module and the part it is controlling. I've had to do that in the past in order to debug other problems (usually with stuck hardware). But a more fruitful strategy might be to turn on debugging within the cx2540 module itself. All these modules generally have a "debug" parameter you can set. Depending on the module, that will help show what is going on. However I have to warn you that for the sort of thing you are looking for, you will likely want to have the chip's datasheet in front of you when you do this, and this is not a simple part :-( The PDF I have for it is 289 pages. Does this help with understanding things or have I muddied it up? -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
