Date: Mon, 16 Apr 2007 13:48:22 +0200 From: usleepless@gmail.com To: "Greg 'groggy' Lehey" <grog@freebsd.org> Cc: freebsd-multimedia@freebsd.org Subject: Re: pvrxxx, linux code and modules Message-ID: <c39ec84c0704160448h2d7b0515l8c6e22555d128056@mail.gmail.com> In-Reply-To: <20070416055055.GC1593@wantadilla.lemis.com> References: <c39ec84c0704151508t126cf975gaa1957b9205d3244@mail.gmail.com> <20070416055055.GC1593@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg, List, On 4/16/07, Greg 'groggy' Lehey <grog@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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c39ec84c0704160448h2d7b0515l8c6e22555d128056>