pvrxxx, linux code and modules
usleepless at gmail.com
usleepless at gmail.com
Mon Apr 16 11:48:24 UTC 2007
On 4/16/07, Greg 'groggy' Lehey <grog at freebsd.org> wrote:
> On Monday, 16 April 2007 at 0:08:14 +0200, Jan Branbergen wrote:
> > Greg,
> > i am writing you because i know you are an experienced freebsd
> > developer and you are the maintainer of the mythtv port.
> > i am trying to get the pvrxxx port to support as many cards as possible.
> > in the process, i have been using linux source code to get the job
> > done. i have defined a .h file full of defines and redefines so i can
> > include linux-source with as little altertation as possible:
> > - include fbsd-compat.h file
> > - run sed over the source-file to replace "struct i2c_client" by
> > - uncomment some stuff i can't solve with the fbsd-compat.h file (
> > the linux attach routines )
> > - add some stuff ( couple of lines ) to support fbsd-compat.h
> > - create an entry point to call the main function of the linux-module
> > - link it in
> This is all quite interesting. Can you point me to the code
> (privately if you prefer)? What state is the code in?
this is in the pvrxxx driver, even the one in ports tree. i'll
demonstrate this by using the last module i linked in: tuner.c. the
linux tuner.c normally compiles into a kernel module wich operates on
a i2c bus. it is used by ivtv, but i suppose all capturecards with
builtin tuners use it.
it looks like a huge diff, but think away all:
< static void set_tv_freq(device_t c, unsigned int freq)
> static void set_tv_freq(struct i2c_client *c, unsigned int freq)
these are changed by a sed "s/struct i2c_client \*/device_t /"
STEP 1: replace all "struct i2c_client *" by "device_t " ( automated )
what is left are compiler errors:
- there was an issue with "strlcpy". i commented it out.
- there were a handfull of unused variables: i commented them out.
- i don't know how to define "ARRAY_SIZE": i replaced it with a constant.
- device doesn't have a member "adapter". i commented those references out
- i don't use the attach/detach routines and they give compiler
errors : i #ifdef'ed them out
so STEP 2: fix compiler errors ( manually ). if it can be fixed by
redefining something in fbsd-compat.h ( check any pvrxxx port ), do
so. i just checked the linux-kmod-compat for ARRAY_SIZE btw, and it
has a proper definition for ARRAY_SIZE. one manual patch less to worry
about. thanks for that pointer btw.
- make the static entry point ( "tuner_command" ) public by removing
"static" and creating a corresponding header file
- assign the chip's address to an exported variable of
fbsd-compat.c, so the i2c-emulation knows which chip to address (
"i2c_cl[device_get_unit(client)] = 0xc2" )
- alter makefile of your project to link in the object file.
- include header file in source file from which you want to call the
- call the entrypoint with an iicbus reference as the first parameter
this has been done for cx25840, tda9887, tuner, tveeprom and wm8775.
so what luigi has done for usb devices, i have done for i2c devices.
> > however, i feel that it should be possible to create separate
> > kernel-modules of these linux-modules: tuner.ko, tveeprom.ko,
> > cx25840.ko etc....
> > but i don't have the knowledge to make this happen:
> > - how do i create an entry point into the module ( which i can call
> > to get work done? )
> I could tell you for storage devices (I wrote the corresponding code
> for Vinum), but I'm not very well informed about tuners. Your best
> bet here is to look at existing code. Take a look at
> bktr_mem_modevent in /usr/src/sys/dev/bktr/bktr_mem.c. At the very
> end of this file you'll also find the declaration for the module. The
> variables SI_SUB_DRIVERS and SI_ORDER_FIRST determine the sequence in
> which the driver is called for probing. Both are deefined in
> > i would appreciate if you would take a look at what i have done with
> > tuner.c, tveeprom.c, tda9887.c, cx25840-core.c etc in the pvrxxx
> > port.
> Can you point me to the latest version (preferably a static URL)?
> I've put in a link to the latest version I know in
> multimedia/mythtv/pkg-descr, but it's related to a date.
if i could only define symlinks with this hosting provider.... anyway:
is supposed to point to the latest release from now on.
> > would it be possible to create an automated procedure to transform
> > these linux-modules to freebsd-modules at the source level?
> Everything's possible, but I'd expect that to be far more work than
> would be worthwhile.
you are right, some manual editting will always be necessary and is
not that bad.
> > for example: the bktr driver would be able to use the same tuner.ko
> > as the pvrxxx driver does ( a module based on the linux source ).
> One big problem we'd have with this kind of code is the licensing
> issue. I started preparing to import your code to the tree, but
> there's so much GPL stuff in there that it's a real problem.
ehhh, i have tried understanding this, but have a hard time. i also
read the discussing about "viral stuff" on the list recently. as far
as i understand, it should not be a problem for a kernel module to be
licensed non-bsd wise ( in this case, gpl'ed ).
what are your thoughts on this?
> I've been thinking around this general issue for a while, and haven't
> come to any concrete conclusions. Thoughts:
> - I need to understand better how tuners work. I've been thinking of
> writing a document on the subject, something that people could use
> for help when writing drivers. If you know of anything, even
> partial or badly laid out, please let me know.
your choice of words is confusing me. what do you mean by tuner? a
tv-card? a chip on a tv-card which tunes to the correct frequency for
the frame-grabber to use?
tuners are not very difficult. the problem is that there are so many
of them. but all tuners seem to be i2c devices. and 90% of the tuners
are programmed by a 4 byte sequence ( 2 bytes for frequency, 2 bytes
for config ).
> - We need to decide on the driver architecture we use. Our current
> tuner drivers (both of them!) use an interface that is incompatible
> with V4L. V4L has a number of advantages, including complexity and
> likelihood of change, but it's the de facto standard, and if we get
> involved, we may be able to help improve the definition.
this is what i am aiming on with the pvrxxx port:
- support as many cards as possible. if i have make it gpl, so be it.
- support V4L(2) interface to make the card usable for linux
software ( mythtv etc )
V4L(2): if you can't beat them, join them! we can harvest support for
all known tuners, all kinds of i2c video chips... get access to
applications using those drivers.
> - Luigi has done some related work on USB webcams. Take a look at
> http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html . I've
> been meaning to read it for a while, but haven't got a round tuit
> yet. I expect two advantages from this approach:
> - It should be relatively easy to add new drivers.
luigi's work seems to overlap with my work: luigi did this for usb, i
did it for i2c. there is stuff to learn from luigi though, thanks for
pointing it out
> - It should get round the GPL can of worms.
why? and why do you see problems for the pvrxxx port? what's the difference?
thanks for thinking along,
> See complete headers for address and phone numbers.
More information about the freebsd-multimedia