On Tue, Dec 17, 2013 at 4:09 PM, Antti Palosaari <crope@xxxxxx> wrote: > That shared DVB / V4L2 tuner is one problem that I have also currently (SDR > is on V4L2 API and DTV is provided via DVB API). I have decided to try model > where I separate RF tuner totally independent used DVB / V4L2 APIs, just to > plain I2C driver model. Idea is here to provide needed set of general > callbacks and communication and device binding is done via I2C driver model. > I am not sure though if there is any big caveats I haven't realized yet... It's a tough problem - a more strictly defined API in theory allows for better uniformity across drivers (although admittedly we've done a piss-poor job in practice). However such a strictly defined API makes it harder to add hacks that are sometimes required by the silicon. The additional abstractions provided by v4l2 subdev and tuner-core just make it that much harder to get past those layers and poke the device directly (which as much as I hate to admit it, is sometimes required to work around bugs and weird edge cases in the silicon not addressable via the API). These problems are exacerbated by cases where there are order-of-operations requirements that cannot be accommodated by the API. All that said though, moving to an entirely I2C based API feels like to provides "too much flexibility" such that every bridge will talk a little differently to every tuner. Given what a crappy job we've done in the past even with a strict framework, I cringe to think how much worse the problem would be if every developer took a different approach. I'm not against implementing a callback which allows you to feed arbitrary I2C commands to a device, to be used *sparingly* for those cases where it is *really* required to do something not supported via the framework's API. But I don't see it as a replacement for the existing frameworks for addressing tuners. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
