[pvrusb2] New driver snapshot: pvrusb2-mci-20090315

[Xavier Gnata]

Hi,

Thanks!
It is really pleasant so see that one liners questions to you always 
trigger very clear and detailed answers :)
I'm gonna read the v4l documentaiton within the kernel source.

Xavier
>
>   
>> Hi Mike,
>>
>> Would you say that this new intermediate layer is a good thing?
>>     
>
> Yes.
>
>
>   
>> What is the purpose of this?
>>     
>
> In terminology used elsewhere in v4l-dvb, the pvrusb2 driver is a 
> "bridge" driver.  This means that it effectively bridges together other 
> drivers (e.g. tuner, video digitizer, sound processing, audio switching, 
> etc) in the v4l-dvb core in order to implement unified control of the 
> device.  In the pvrusb2 driver online documentation, those other drivers 
> are referred to as "chip-level drivers".
>
> When I first took on this driver in early 2005, this bridge concept did 
> not exist within the driver.  Rather, the original author had simply 
> copied in the code for each "chip level driver" straight into the 
> pvrusb2 driver and directly integrated code to operate each piece.  
> This had all manner of problems - the first of which is that it's all 
> forked code which would be a pain to maintain going forward.  Plus it 
> did not exploit the principles behind the architecture of V4L.  And it 
> made it difficult to integrate support for newer hardware that itself 
> might require different such drivers to be used.
>
> As I worked through the pvrusb2 driver in that first year, I ended up 
> eventually writing a whole framework that managed the pvrusb2 driver's 
> run-time association, control, and feedback from those modules.  Every 
> V4L driver effectively has had to solve this issue; the level of 
> difficulty varies with the hardware in question.  For something like the 
> pvrusb2 driver which supports a number of different device variants with 
> different hardware requirements, the problem is a bit harder.  This is 
> because the knowledge of what modules to attach and how to control each 
> module depends on the detected hardware.  This means that the driver 
> really needs to keep tracking data on each attached module.  The driver 
> has to adapt at run-time depending on which modules it is dealing with.  
>
> The i2c infrastructure (not a V4L specific thing) in the Linux kernel 
> helps in this regard but there are still specific modules that one ends 
> up keeping specific track of in the bridge driver's code (i.e. pvrusb2).  
> The framework I wrote was general in nature and it did all this.  But it 
> was highly specific to the pvrusb2 driver itself and deliberately 
> avoided assumptions about the run-time environment, to a fault.  At the 
> time, I wasn't sure what else I was going to encounter so I designed it 
> very conservatively - maximum flexibility.  For example, with the 
> framework I had in place, you could actually "modprobe -r tuner" then 
> later "modprobe tuner" to bring it back into the fold and the pvrusb2 
> driver would notice its (re)appearance and immediately "bring it up to 
> speed" with the rest of the state of the bridge driver.  This is really 
> not a common use-case for end users (but it is handy when debugging 
> those modules).  Anyway the bulk of that framework appeared in December 
> 2005 and it's been in use within the pvrusb2 driver ever since.  There 
> have been changes / tweaks over time, but the over-arching concept has 
> remained unchanged and the framework has worked well.
>
> Recently a new framework has appeared in the v4l-dvb core.  It defines a 
> concept of "V4L sub-devices", and builds upon other changes / 
> enhancements that have since been built into the kernel's i2c 
> infrastructure.  The net effect of this new framework is that now 
> there's a common V4L way to manage all these associations and to do the 
> management in a way to removes a lot of house-keeping in the bridge 
> driver.  Essentially it functions as a replacement for what I did 
> initially in the pvrusb2 driver back in 2005.  It doesn't do some stuff 
> that I did - but that's OK because over time it's become clear that such 
> things aren't needed.  What it does do, it implements in a fairly simple 
> straight-forward manner.  The changes I've described here in the pvrusb2 
> driver basically remove the old chip-level driver module framework and 
> in its place is simply code that uses the new V4L sub-device framework.
>
> Now, up until now I didn't "have to" make these changes.  However there 
> is a plan afoot that removes support for the "old way" of doing things 
> within v4l-dvb.  What I implemented back in Dec 2005 relies on certain 
> features of the Linux kernel i2c framework and that's all deprecated 
> now.  The desire is to remove that old functionality starting with the 
> 2.6.30 kernel.  So the pvrusb2 driver has to move forward here, and thus 
> you see these changes.  The sub-device framework (minus one little 
> feature but I'm not worried about that bit) is available in 2.6.29 so I 
> configured the standalone build to switch to the new framework any time 
> it is built against 2.6.29 or later (or if built against a v4l-dvb 
> snapshot).  Making these changes now - even before 2.6.29 is released - 
> means that a significant pile of changesets will be immediately ready 
> for inclusion once the 2.6.30 merge window opens.  This (hopefully) 
> avoids considerable hair-pulling and angst on my part when trying to 
> quickly finish it all later under the gun of the merge window :-)
>
> If you are curious to learn about sub-devices in the V4L context, 
> there's a writeup available in the kernel documentation tree.  It should 
> be present starting at least with 2.6.29 (honestly I haven't checked), 
> but it's also in the v4l-dvb repository, as
> linux/Documentation/video4linux/v4l2-framework.txt
>
>
>   
>> Does it really avoid a lot a code duplication?
>>     
>
> Yes.
>
> This moves what effectively was a roll-your-own solution for every 
> driver into the v4l-dvb core logic.  The sub-device framework is an 
> attempt to make common what was previously duplicated everywhere.
>
> For the moment, the pvrusb2 standalone driver contains BOTH 
> implementations - the old stuff from Dec 2005 and the new code to use 
> the sub-device API.  They are ifdef'ed appropriately.  (It's actually 
> possible under certain conditions to run both frameworks at once, which 
> is something I did to help incrementally debug the new stuff.)  The old 
> code will probably be there - though not compiled for new kernels - for 
> quite a while.  Right now the pvrusb2 driver is still compilable all the 
> way back to 2.6.12.3 (yes I'm sure - I just went through that exercise 
> earlier today).  If / when I ever physically remove the old controlling 
> framework from the driver, then driver viability will break for any 
> kernel version older than 2.6.29.  Obviously we don't want that to 
> happen so for now it stays.
>
> The pvrusb2 driver as it exists in v4l-dvb will only have the new 
> sub-device implementation physically present.  The current v4l-dvb 
> repository doesn't have the changes yet, but I've already prepared the 
> changesets and will submit them for inclusion once another minor change 
> has first been pulled in (a new API for disassociating a device cleanly 
> after a hotplug removal - I have a hack in place to work around it for 
> the moment but the real solution needs to be put into place).
>
> Of course, the VAST lion's share of the changes in this driver snapshot 
> all have to do with this framework change.  And NONE of it will even be 
> compiled unless you build against 2.6.29 or later.  So in reality it's a 
> giant NOP right now.  (But I have beat on the changes considerably over 
> the past few weeks and it all works great.)
>
> No, I haven't forgotten about raw mode support.  That's going to be a 
> big change, probably the biggest change coming since I did the control 
> state machine rework back in the fall of 2007.  So it's going to be a 
> while yet before I have something there.
>
>   
>> Anyhow thanks  for this release :)
>>     
>
> You're welcome.
>
>   -Mike
>
>