pvrxxx, linux code and modules

[usleepless at gmail.com]

Greg, List,

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
> "device_t"
> > - 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.

original:
  http://usleepless.110mb.com/tuner.c

my version:
  http://usleepless.110mb.com/tuner_fbsd.c

diff:
  http://usleepless.110mb.com/tuner.diff

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.

STEP 3:
  - 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" )

STEP 4:
  - alter makefile of your project to link in the object file.
  - include header file in source file from which you want to call the
entrypoint
  - 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
> /usr/src/sys/sys/kernel.h.
>
> > 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:
  http://usleepless.110mb.com/pvrxxx_port.tgz

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,

regards,

usleep

>
> Greg
> --
> See complete headers for address and phone numbers.
>