On Fri, 15 May 2009, Sven Barth wrote: > Hello again! > > I managed to wrap the cs5345 (at least I hope that I did so... I just copied > the cs53l32a and replaced everything...) and included it everywhere the > cs53l32a is included. I also added the cs5435 to the av400 in devattr.c. The > driver still compiles and works as before, but that's it... > > I need some help from you: > > - Where or how can I check the i2c address of the cs5345 (I copied \x11 from > cs53l32a for now)?
The value \x11 is actually 0x11 of course, which would be the expected I2C address for the cs53l32a (for an OnAir device). You would need to replace that value with the correct one. > dmesg prints this: > cs5345 2-0011: chip found @ 0x22 (pvrusb2_a) > pvrusb2: Attached sub-driver cs5345 Odds are pretty good that the correct value is 0x22. We're in the midst of a change in how v4l-dvb binds client drivers to I2C addresses so it probably worked itself out but in the future we need to make sure that value is correct. > > - How do I disable the audio routing of the cx2584x? Or is that what I hear > the cs5345 initialized with default values? If so, how can I check if I can > control the chip now? Changing the audio bitrate? You don't want to disable audio routing of the cx2584x. Audio is likely still going through this part; but that other chip is probably doing the A/D conversion and feeding that result to the cx2584x. At least that's the way it has worked in every other device I've seen. > > Btw: what does this message in dmesg mean: cx25840 2-0044: 0x0000 is not a > valid video input! > It occurs after loading the firmware. This is probably happening because the cx25840 is being fed an input choice that is invalid. On hybrid devices this can happen when we're in digital mode; in that case the driver is just feeding junk to this chip but that's OK because when in digital mode this chip is not used. In your case there of course is no digital mode, but if I understand that part correctly it lacks an RF tuner. The routing scheme set up for the cx2584x in this case doesn't define a setting for "TV" mode. The driver also should not be selecting the TV input (it is disabled in the device's entry in pvrusb2-devattr.c), but there might be a problem where it is at least momentarily trying to select a TV input right at initialization. Assuming that we've got the right A/D module here, one thing you're going to have to do is figure out how to program its routing scheme. That's the routing_schemeX array in the source file. What was there for the cs53l32a is almost certainly not correct for the cs5345. Providing that routing information to the module in fact is pretty much the whole reason for that wrapper module - unlike most commands given to all the modules which are not module-specific, routing information is a very chip-specific thing. Unfortunately I can't tell you what is correct here. What I usually do is some combination of the following: 1. Find a datasheet for the chip, read it and figure out what kinds of inputs it has. 2. Look at the source for the corresponding v4l-dvb module and examine what it does with any routing information provided. 3. Start taking guesses at it based on (1) and (2) until I get reasonable results. This part is kind of blind because part of this answer is probably going to depend on how the board has been wired, i.e. which inputs are actually wired up and what they are wired to. In your case there's really only one physical audio input so (3) might be easier to guess. -Mike -- Mike Isely isely @ isely (dot) net 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
