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

[Mike Isely]

On Mon, 16 Mar 2009, Xavier Gnata wrote:

> 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

-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8