On Mar 9, 2011, at 7:00 PM, <jean.bruenn@xxxxxxxxxxx> wrote: > >> This may already be fixed, just not in 2.6.37.x yet. Can you give >> 2.6.38-rc8 (or later) a try and/or the media_build bits? > > Tried - Nope, same behaviour (same error messages in dmesg, no results by > scan) > >> > http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers > > I was unable to get that working; tried with 2.6.37.2 and 2.6.37.3 always > getting "invalid module format" and yeah, i tried with reboot, i tried > with a > fresh variant.. Also tried ./build.sh and make install and such stuff in > 2.6.38-rc8, same. As discovered on irc, seems to be a mismatch between the headers that were being built against and the running kernel. That aside, given that this is a cx23885-based device, I suspect that this commit may be relevant to the regression in functionality: commit 44835f197bf1e3f57464f23dfb239fef06cf89be Author: Jean Delvare <khali@xxxxxxxxxxxx> Date: Sun Jul 18 16:52:05 2010 -0300 V4L/DVB: cx23885: Check for slave nack on all transactions Don't just check for nacks on zero-length transactions. Check on other transactions too. Signed-off-by: Jean Delvare <khali@xxxxxxxxxxxx> Signed-off-by: Andy Walls <awalls@xxxxxxxxxxxxxxxx> Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> The retval the xc2028 firmware load routine is getting is -ENXIO, which seems to possibly be new behavior as a result of that patch. However, it may actually be that the xc2028 driver needs to add some delays or retries in its firmware load function, as this change *is* technically correct (Jean is the i2c subsystem maintainer, so we can be pretty sure he knows how i2c stuff is *supposed* to behave). :) You could try hard-coding a sleep and/or retries into the inner while loop near the bottom of load_firmware() in tuner-xc2028.c... That's definitely where things are falling down, anyway. -- Jarod Wilson jarod@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
