On Monday 13 April 2009 03:14:13 Alexey Klimov wrote: > Hello, Tobias > > On Mon, Apr 13, 2009 at 12:56 AM, Tobias Lorenz <tobias.lorenz@xxxxxxx> wrote: > > Hi Joonyoung, > > > > Hi Alexey, > > > > I've split the driver into a couple of segments: > > > > - radio-si470x-common.c is for common functions > > > > - radio-si470x-usb.c are the usb support functions > > > > - radio-si470x-i2c.c is an untested prototyped file for your i2c > > support functions > > > > - radio-si470x.h is a header file with everything required by the > > c-files > > > > I hope this is a basis we can start on with i2c support. What do you > > think? > > > > The URL is: > > > > http://linuxtv.org/hg/~tlorenz/v4l-dvb > > > > Bye, > > > > Toby > > Great! It's always interesting to see big changes. > I understand i2c interface not so good and have only general questions. > > Many (most?) drivers in v4l tree were converted to use new v4l2- > framework. For example, dsbr100 was converted to v4l2_device > http://linuxtv.org/hg/v4l-dvb/rev/77f37ad5dd0c and em28xx was > converted to v4l2_subdev > http://linuxtv.org/hg/v4l-dvb/rev/00525b115901 > As i remember, Hans Verkuil said that all v4l drivers should be > converted to new framework. Is it time to switch to this new interface > ? Probably, there are a lot of code examples in current tree that can > help.. Any new v4l2 i2c driver must use v4l2_subdev in order to be reusable by v4l2 drivers. All 'legacy' i2c drivers are now converted and only soc-camera and v4l2-int-device.h based drivers remain unconverted, although I expect that those will also be moved to v4l2_subdev in 2.6.31. What complicates matters here is that the si470x is a radio tuner, and as such should be implemented as a tuner device (common/tuners) which have their own framework. But if memory serves the si470x can also do RDS for which there is no support in the tuner framework. I'm leaning towards implementing this i2c driver as a normal v4l2_subdev driver, rather than making it part of the tuner driver/framework. Actually, I suspect that the tuner driver/framework can be substantially simplified with this new framework: much of the complexity there is related to the autoprobing crap, and that no longer applies. This is an interesting future research topic :-) > And second question. About lock/unlock_kernel in open functions. > Please, take a look at > http://www.spinics.net/lists/linux-media/msg04057.html > Well, is it time to do something with this? Yes, please remove/replace these calls. Regards, Hans > Well, my questions about improving functionality, not about mistakes or > bugs :) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
