On Fri, 12 Jun 2009 01:18:20 +0200, Hans Verkuil wrote: > On Friday 12 June 2009 01:07:46 Mauro Carvalho Chehab wrote: > > I suspect that we'll need to work with the initialization order after the new > > i2c binding model to avoid such troubles. > > > > I remember that we had a similar issue with alsa and saa7134. At the end, Linus [1] > > had to do add this, as a quick hack (unfortunately, it is still there - it > > seems that alsa guys forgot about that issue): > > > > late_initcall(saa7134_alsa_init); > > > > On that time, he suggested the usage of subsys_initcall() for alsa. I suspect > > that we'll need to do the same for I2C and for V4L core. I'm not sure what > > would be the alternative to be done with i2c ancillary drivers. > > > > Maybe one alternative would be to use fs_initcall, that seems to be already > > used by some non-fs related calls, like cpu governor [2]. > > As long as the i2c modules come first there shouldn't be any problem. That's > pretty easy to arrange. So the i2c core inits first, then i2c drivers, then > v4l2 drivers. That's the proper order. This is already what we have in 2.6.30 as far as I can see. > The ir-kbd-i2c module needed to be after the v4l2 modules since that still > relies on autoprobing. If it comes first, then it seems to mess up tveeprom > for some reason. Once ir-kbd-i2c no longer does autoprobing, then it probably > should move back to the other i2c modules. Hopefully this will happen in the next few days :) -- Jean Delvare -- 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
