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
_______________________________________________
pvrusb2 mailing list
[email protected]
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
