Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Sat, 15 Mar 2008 18:33:56 +0900
timf <[EMAIL PROTECTED]> wrote:

> [   15.00] saa7133[0]: subsystem: 1461:f936, board: AVerMedia Hybrid
> TV/Radio (A16D) [card=137,autodetected]


> [   15.296000] tuner' 2-0061: Setting mode_mask to 0x0e
> [   15.296000] tuner' 2-0061: chip found @ 0xc2 (saa7133[0])
> [   15.296000] tuner' 2-0061: tuner 0x61: Tuner type absent

The above is not right. It should be using type=71 for the tuner.

I think I found the bug: the tuner addresses should be set to ADDR_UNSET,
instead of keeping it blank.

Please do an "hg pull -u" and try again, recompiling and re-installing the 
modules:
hg pull -u
make rmmod
make
make install
modprobe saa7134

> 8) The chip on my card is xc3018. Why does module xc5000 load?

This is an issue on the way cards are attached, at tuner_core. Since they
directly access xc5000 code, with:

if (!xc5000_attach(&t->fe, t->i2c->adapter, &xc5000_cfg)) {

xc5000 module will be loaded, even if not used. It shouldn't be hard to fix
this, by using the macro dvb_attach().



Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Mon, 17 Mar 2008 19:28:32 +
"Richard (MQ)" <[EMAIL PROTECTED]> wrote:

> Mauro Carvalho Chehab wrote:
> 
> > Sorry for a late answer. Too busy from my side :(
> 
> And apologies from me for very slow response too. I've been away, and
> although I'm back I'm now using a different box for this problem, with a
> brand new Linux installation. I'm running OpenSuSE 11.0 Alpha-2 and
> having big problems compiling the hg code - I think it's my (admittedly
> alpha) system.

You could also get the latest tarball via:
http://linuxtv.org/hg/v4l-dvb/archive/tip.tar.bz2

Of course, having mercurial installed is much better ;)
> 
> I'll keep at it and get back to you as soon as I can test your patch.
> Not sure whether timf's issues are the same but I'm following that
> thread too.
> 
> Thanks for your patience ! ;-)
You're welcome.



Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Updated analog only support of Avermedia A700 cards - adds RF input support via XC2028 tuner (untested)

[Mauro Carvalho Chehab]

On Tue, 18 Mar 2008 13:39:12 +0100
Matthias Schwarzott <[EMAIL PROTECTED]> wrote:

> On Dienstag, 18. März 2008, Mauro Carvalho Chehab wrote:
> > On Sun, 16 Mar 2008 11:31:37 +0100
> >
> > For this to work, you'll need to set xc3028 parameters. This device needs a
> > reset during firmware load. This is done via xc3028_callback. To reset, you
> > need to turn some GPIO values, and then, return they back to their original
> > values. The GPIO's are device dependent. So, you'll need to check with some
> > software like Dscaler's regspy.exe what pins are changed during reset.
> 
> I can only have a look at the wiring.

This may help, but should be validated with the hardware test, since it may
need to enable/disable more than one bit.

> > Also, there are two ways for audio to work with xc3028/2028: MTS mode and
> > non-mts. You'll need to test both ways.
> >
> > A final notice: most current devices work fine with firmware v2.7. However,
> > a few devices only work if you use an older firmware version.
> >
> > Could you please send us the logs with i2c_scan=1?
> >
> 
> I do not have that hardware. I only have the A700 without XC2028 soldered on 
> it. But maybe Peter can help out on this.

It would be nice if he could help us.
 
> > Please, use the latest version of v4l-dvb, since I did some fixes for cx88
> > and saa7134 there recently.
> >
> I do use latest v4l-dvb tree and create patches on top of this.
> As this card is labled Hybrid+FM I should also add a radio section, I guess.

Yes, but you've already added it. Radio entry is generally identical to TV, on
the devices with xc3028. I suspect that your radio entry should work.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Updated analog only support of Avermedia A700 cards - adds RF input support via XC2028 tuner (untested)

[Mauro Carvalho Chehab]

On Sun, 16 Mar 2008 11:31:37 +0100
Matthias Schwarzott <[EMAIL PROTECTED]> wrote:

> Hi there!
> 
> I updated this patch to support both Avermedia A700 cards (AverTV DVB-S Pro 
> and AverTV DVB-S Hybrid+FM).
> 
> The RF input of the Hybrid+FM card (with XC2028 tuner) is still untested.
> 
> I would be happy if any of the XC2028 experts could have a look at this patch.

For this to work, you'll need to set xc3028 parameters. This device needs a
reset during firmware load. This is done via xc3028_callback. To reset, you
need to turn some GPIO values, and then, return they back to their original
values. The GPIO's are device dependent. So, you'll need to check with some
software like Dscaler's regspy.exe what pins are changed during reset.

Also, there are two ways for audio to work with xc3028/2028: MTS mode and
non-mts. You'll need to test both ways.

A final notice: most current devices work fine with firmware v2.7. However, a
few devices only work if you use an older firmware version.

Could you please send us the logs with i2c_scan=1?

Please, use the latest version of v4l-dvb, since I did some fixes for cx88 and
saa7134 there recently.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] First patch for Freecom DVB-T (with RTL2831U, usb id 14aa:0160)

[Mauro Carvalho Chehab]

On Mon, 17 Mar 2008 20:36:12 +0100
Jan Hoogenraad <[EMAIL PROTECTED]> wrote:

> Mauro:
> 
> Most of the mail understood.
> 
> Can you put us into contact with the people who did the decoupling to 
> the tuner for for example, with saa711x ?
> We could re-use some of their work, and learn from them.

Several developers ;)

First of all, there are two different behaviors, userspace and kernelspace
API's being one for analog and another for digital. This is due to historic
reasons.

The decoupling is via I2C interface. Basically, each i2c driver is independent.
Kernel Documentation/i2c explains the usage of I2C.

In the case of tuner and saa711x, those are two independent drivers, used
(mostly) by analog mode.

tuner.ko module contains tuner-core.c. There are several other tuner drivers
that can be bound to tuner.ko or to a frontend driver.

On i2c normal way for analog TV, composite/svideo and FM, it probes I2C bus for
the presence of I2C devices by sending a read message with 0 bytes. If some
answer is given, this means that an I2C device is present there. When something
is detected, an attach callback is called. For example, attach_inform(), on
cx88-i2c. The attach_inform() then configures that device, if needed.

A newer method for probing is starting to be implemented, on ivtv driver.

Both tuner and saa711x implements a "command" interface. The command is meant
to receive requests for tuning and other things, like changing video
standard. All I2C devices listen to the I2C command. So, when you change a
video standard, tuner may set the proper IF, while saa711x can send the proper
initialization codes for that video standard.

In order to better support hybrid devices, tuner now is implemented on separate 
files.
tuner.ko is just the core, meant to be use by analog/svideo/composite or radio 
mode.

The tuner, itself, can work with both V4L and DVB API's. This is warranted by
the usage of callbacks.

For digital TV, there are several callbacks. In the case of a tuner, for
example xc2028, the driver fills an structure with the callbacks:

static const struct dvb_tuner_ops xc2028_dvb_tuner_ops = {
.info = {
 .name = "Xceive XC3028",
 .frequency_min = 4200,
 .frequency_max = 86400,
 .frequency_step = 5,
 },

.set_config= xc2028_set_config,
.set_analog_params = xc2028_set_analog_freq,
.release   = xc2028_dvb_release,
.get_frequency = xc2028_get_frequency,
.get_rf_strength   = xc2028_signal,
.set_params= xc2028_set_params,
.sleep = xc2028_sleep,

#if 0
int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
int (*get_status)(struct dvb_frontend *fe, u32 *status);
#endif
};

The above struct contains both callbacks for analog and digital.

dvb core will call the proper callbacks when needed. For example, set_params
select the proper DVB mode, and tune to an specific frequency.

There are similar callbacks also for DVB frontend (a frontend is a tuner plus
a demod - and, for DVB-S, the LNBf control interface).

> A similar thing goes for the IR devices.
> Currently, these sticks are shipped with 3 different IR devices, with 
> different (and sometimes conflicting) IR codes.

IR scan tables can be inside drivers/media/common/ir-keymaps. The hanlding for
gpio RC5 is provided at ir-common.ko.

For I2C, there's a special module for handling this (ir_i2c_kbd). This is also
a generic module. The attach callback is used to setup the specific parameters
for each IR.

> I see that there are two different mechanisms used in the drivers.
> 
> The cxusb.c driver shows how to switch based on the USB ID of the stick.
> 
> The hauppage driver, with ir-kbd-i2c.c and ir-keymaps.c shosw how to 
> switch based on module parameters (mechanism similar to the debug=1).

The usage of module parameters should be used only when other mechanisms aren't
possible. The preferred way is to detect board characteristics via reading the
board eeprom, if available. Hauppauge detection is very good, for most things,
due to tveeprom.ko. There's a parser there to read their info inside the eeprom.

This saves a lot of space inside kernel to handle all differences between the 
boards.

If this is not possible, the next option is to use USB ID or PCI ID. However,
sometimes, unfortunately, a cheap board doesn't have an unique PCI ID. So, the
only way is to provide module options.

> Can you tell me if there is a roadmap for this (e.g. decoupling the 
> mapping from the stick ID and putting the rc_query subroutines together) ?

What do you mean?

> In the next patch, I'll add a file
> /linux/Documentation/dvb/README.rtl2831
> with some data I got from Realtek.

Good.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] First patch for Freecom DVB-T (with RTL2831U, usb id 14aa:0160)

[Mauro Carvalho Chehab]

On Sat, 15 Mar 2008 23:23:51 +0100
Jan Hoogenraad <[EMAIL PROTECTED]> wrote:

> > Due to several issues I've noticed at the driver, I opted, for now, to add 
> > it
> > as a separate tree. This way, we can fix things there, without affecting the
> > staging tree. I've made it available at:
> > http://linuxtv.org/hg/~mchehab/rtl2831
> Thanks a lot. This way, the people involved have a place to focus on.
> Now, I need to find a way to synchronise my tree with this directory.
> I'll do some reading on the mercurial.

Kdiff3 has a very nice algorithm to see the differences on a code with
different CodingStyles. Anyway, this could be a pain.

> I have some scripts to convert things I receive from Realtek.
> I'll add the new directory names and Lindent at least.

> > Also, I noticed that nobody, on RealTek signed it. It would be interesting 
> > if
> > someone there could send us a SOB for the first changeset:
> > http://linuxtv.org/hg/~mchehab/rtl2831/rev/bb7749446173
> Please explain the abbrreviation SOB, and if possible send the text.

SOB - Signed-off-by:

It should be useful for you to take a look on README.patches [1].

[1] http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches

> Would you like to have a paper copy, or is e-mail confirmation to you 
> sufficient ?
Just an e-mail with their SOBs.

> The text I added in the header is vetted by people from Realtek.

They can change the text. The only requirement is that the code should be
licensed with GPLv2.

> They are eager to work together, and willing to learn.

This is very good! With time we will learn how to cope together.

> Unfortunately, I myself am completely new to linux development.

It shouldn't take much time to learn ;) It is a completely different
environment than what you'll have inside a company, since it is a
community-driven work. So, all members of the community are freed to cope,
comment and help with your work, sending you newer patches. Also, since kernel
internal API's change, we need to handle patches that will change the API,
testing they.

> I'll add those specific cases to my import script;
> I think that script should (due to the nature of the driver) get a 
> central role, as to keep updates automated.

Yes, this seems to be the easiest way.

> > 3) Name convention. Names are generally in lower case. Since we try to have 
> > all
> > lines with maxsize=80, the better is trying to have shorter names. 
> > 
> > I don't think that it would be a good idea to replace all names inside the 
> > driver,
> > since this will make your life harder, when receiving patches from Realtek.
> > Anyway, please consider this if you need to touch on some var name. 
> > 
> > There are other comments I want to do, about the integration with the tree. 
> > I
> > intend to do it later, after having a better understanding on how the driver
> > works and what can be done to avoid code duplication with dvb core and to 
> > allow
> > the usage of the tuners by other drivers.
> Some of us have studied this already, and communicated with Realtek on 
> this, For example, they have an improved handling of the mt2060 tuner.
> Decoupling the front end, setting this temporatily up as a new driver 
> (would the naming there be something like mt2060_for_rtl2831 ?) and then 
> integration have been on our wish list already.

We did this kind of things already (for example, with saa711x). While this is
not the ideal way, we can handle this. 

I suspect, however, that it is too late to merge the driver for 2.6.26 (the
window for newer drivers should be opening soon, and the driver reviewing
should happen before the opening of the windows). Considering this, we'll have
a timeframe of about 8-10 weeks before the next merge window (for 2.6.27).
Maybe this timeframe is enough to merge the required newer features on mt2060
and reuse it, instead of adding a newer one. My suggestion is to work with the
separate tree and see the progress.

> > Also, I'll need help from other developers on this large task ;)
> I at least have a lot of people interested already for testing.
> I've cc-ed them.

Great. There are also the other guys from DVB ML that could also help on this.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] First patch for Freecom DVB-T (with usb id 14aa:0160)

[Mauro Carvalho Chehab]

On Fri, 14 Mar 2008 22:24:46 +0100
Jan Hoogenraad <[EMAIL PROTECTED]> wrote:

> Dear v4l maintainer:
Please, just call me by my name ;)

> I have created a first version of the patch for the Freecom stick, based 
> on the latest sources I received today from RealTek.

Due to several issues I've noticed at the driver, I opted, for now, to add it
as a separate tree. This way, we can fix things there, without affecting the
staging tree. I've made it available at:
http://linuxtv.org/hg/~mchehab/rtl2831

Also, I noticed that nobody, on RealTek signed it. It would be interesting if
someone there could send us a SOB for the first changeset:
http://linuxtv.org/hg/~mchehab/rtl2831/rev/bb7749446173

Ah, by convention, we name directories in lowercase. So, I've did an "sed"
before applying your patch, as I've explained at the changeset comments.

> I have received several updates per week from them during the fixing 
> time, so I expect some updates later on.

Ok.

> I'm not very familiar with Mercurial / HG.
> I've put the sources into a separate directory, and created the patch 
> with hg commit / hg export  / hg rollback
This works ;)

> It compiles with the latest v4l.
> It has been tested on my system only yet.
> 
> Please review the way of submission.

In general, patches are sent as in-line. However, for big patches, it is
accepted to have them compressed.

> Mauro:
> 
> Thanks for the help.
> I agree that this is probably the best thing to do.

Ok, this is the Lindent changeset:
http://linuxtv.org/hg/~mchehab/rtl2831/rev/698c1894a3fd

> 
> Unfortunately, Lindent does not fix errors that
>   make checkpatch
> reports like the two below.
> 
> tuner_mxl5005s.h: In '// I2C birdge module demod argument setting':
> tuner_mxl5005s.h:531: ERROR: do not use C99 // comments

I tried to quickfix this with a small perl script, like:

for i in *.c *.h; do perl -ne \
'if (s|//\s*(.*)\n|/* \1 */\n|) { s|/\*\s*\*/||; } print $_' \
$i >/tmp/tmp; mv -f /tmp/tmp $i; done

However, this failed, since there are some comments with // inside. It doesn't
seem to be hard to fix this by a close script.

> tuner_mxl5005s.h: In 'void 
> mxl5005s_SetI2cBridgeModuleTunerArg(TUNER_MODULE * pTuner);':
> tuner_mxl5005s.h:532: ERROR: "foo * bar" should be "foo *bar"

True. Yet, this shows another thing that is forbidden on Linux CodingStyle: the
usage of typedef. While this is valid on a few cases, on most cases we prefer
to use things like "struct foo *foo;".

---

Due to the size of the driver, and the nature of it (a port from other OS), it
is natural that we will have a large amount of issues. Before visiting the code
to check everything, maybe the better approach would be to do some general
comments. 

I'll start commenting some things about CodingStyle. The better is if you could
read kernel Documentation/CodingStyle.

1) Kernel already defines several types. Please use the already defined 
typedefs.
For example:

+typedef unsigned char U8Data;

use, instead __u8

+typedef unsigned int UData_t; /* type must be at least 32 bits */

use, instead __u32

+typedef int SData_t; /* type must be at least 32 bits */

use, instead __s32

+typedef void *Handle_t; /* memory pointer type 

Just use "void *"

2) We don't use "typedef struct foo". Instead, just declare "struct foo" and
replace all "foo *" to "struct foo *":

+typedef struct {
+ UData_t nAS_Algorithm;
+ UData_t f_ref;
+ UData_t f_in;
+ UData_t f_LO1;
+ UData_t f_if1_Center;
+ UData_t f_if1_Request;
+ UData_t f_if1_bw;
+ UData_t f_LO2;
+ UData_t f_out;
+ UData_t f_out_bw;
+ UData_t f_LO1_Step;
+ UData_t f_LO2_Step;
+ UData_t f_LO1_FracN_Avoid;
+ UData_t f_LO2_FracN_Avoid;
+ UData_t f_zif_bw;
+ UData_t f_min_LO_Separation;
+ UData_t maxH1;
+ UData_t maxH2;
+ UData_t bSpurPresent;
+ UData_t bSpurAvoided;
+ UData_t nSpursFound;
+ UData_t nZones;
+ struct MT_ExclZone_t *freeZones;
+ struct MT_ExclZone_t *usedZones;
+ struct MT_ExclZone_t MT_ExclZones[MAX_ZONES];
} MT_AvoidSpursData_t; 

3) Name convention. Names are generally in lower case. Since we try to have all
lines with maxsize=80, the better is trying to have shorter names. 

I don't think that it would be a good idea to replace all names inside the 
driver,
since this will make your life harder, when receiving patches from Realtek.
Anyway, please consider this if you need to touch on some var name. 

There are other comments I want to do, about the integration with the tree. I
intend to do it later, after having a better understanding on how the driver
works and what can be done to avoid code duplication with dvb core and to allow
the usage of the tuners by other drivers.

Also, I'll need help from other developers on this large task ;)

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Sat, 15 Mar 2008 04:34:34 +0900
timf <[EMAIL PROTECTED]> wrote:


> > Now, do two tests, with v4l-dvb tree + the patch:

Of course, you'll need to compile and install v4l-dvb ;)
make
make install

> cx88-dvb or saa7134-dvb ?
saa7134-dvb. 


Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Sat, 15 Mar 2008 03:20:56 +0900
timf <[EMAIL PROTECTED]> wrote:

> Hi Mauro,
> 
> On Fri, 2008-03-14 at 12:14 -0300, Mauro Carvalho Chehab wrote:
> > On Fri, 14 Mar 2008 10:16:48 +0900
> > timf <[EMAIL PROTECTED]> wrote:
> > 
> > > Hi Mauro,
> > > Improved, but still no tuner-xc3028, no dvb.
> > > Relevant part of my dmesg:
> > 
> > > [   15.12] tuner' 2-0061: chip found @ 0xc2 (saa7133[0])
> > > [   15.12] tuner' 2-0061: tuner type not set
> > > [   15.12] tuner' 2-0061: tuner type not set
> > 
> > The above messages are very weird... are you passing any option to saa7134? 
> > It
> > should autodetect tuner=71...
> > 
> > Cheers,
> > Mauro
> 
> OK, I have just done a completely new install of ubuntu 7.10.
> (dmesg1.txt, lspci1.txt, lsmod1.txt)
> 
> Then v4l-dvb via mercurial (download-via-mercurial.txt)
> 
> Then sudo cp xc3028-v27.fw /lib/firmware/2.6.22-14-generic
> (lib-firmware-2.6.22-14-generic.txt)
> 
> Then cd v4l-dvb, make, sudo make install, reboot
> (dmesg2.txt, lspci2.txt, lsmod2.txt)
> 
> Then cd v4l-dvb, patch -p1 < a16d-patch1.diff,
> (patch-result.txt)
> make, sudo make install, reboot
> (dmesg3.txt, lspci3.txt, lsmod3.txt)
> 
> Nothing done to /etc/modprobe.d /etc/modules

Very weird. It shouldn't print that messages.

Please add this at modprobe.conf (or modprobe.d):

options tuner-xc2028 debug=1
options tuner debug=1

Also, let's remove the old v4l modules from your kernel:
make rminstall
make rmmod

Now, do two tests, with v4l-dvb tree + the patch:

1) do a modprobe saa7134 and collect the logs that start after you modprobe 
saa7134;

2) do:
make rmmod
modprobe saa7134 tuner=71 i2c_scan=1

   also, collect the logs

---

You should notice that the driver is currently without support for DVB. After
fixing analog, we will need to patch cx88-dvb to inform the kernel about the
demod chip in use by this board, and provide the proper configuration
parameters for the demod.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Fri, 14 Mar 2008 10:16:48 +0900
timf <[EMAIL PROTECTED]> wrote:

> Hi Mauro,
> Improved, but still no tuner-xc3028, no dvb.
> Relevant part of my dmesg:

> [   15.12] tuner' 2-0061: chip found @ 0xc2 (saa7133[0])
> [   15.12] tuner' 2-0061: tuner type not set
> [   15.12] tuner' 2-0061: tuner type not set

The above messages are very weird... are you passing any option to saa7134? It
should autodetect tuner=71...

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

Hi Richard,

On Tue, 12 Feb 2008 18:15:09 +
"Richard (MQ)" <[EMAIL PROTECTED]> wrote:

Sorry for a late answer. Too busy from my side :(

> > please forward the errors that it might produce. You may forward the full 
> > dmesg
> > errors to me in priv directly. I prefer if you don't generate a tarball, 
> > since
> > makes easier for me to comment, the results, if needed.

> Feb 12 18:03:26 DevBox2400 klogd: saa7133[0]: i2c scan: found device @ 0x1e  
> [???]
> Feb 12 18:03:26 DevBox2400 klogd: saa7133[0]: i2c scan: found device @ 0xa0  
> [eeprom]

The issue here is that tuner-xc3028 weren't detected. It should have found a
device at 0xc2.

This could happen on two cases:

1) Some saa713x GPIO is needed before we can see xc3028. The better would be to
take a look on what windows driver is doing with GPIO's. This link helps you to
understand what should be done on windows:

http://www.linuxtv.org/v4lwiki/index.php/GPIO_pins

2) You need to open an i2c gate on your demod chip. In this case, some commands
need to be sent to your demod for it to open the i2c gate. 

I suspect that, on your case, it is (1). Please try the enclosed patch.

---

Enable GPIO's for AV A16D

From: Mauro Carvalho Chehab <[EMAIL PROTECTED]>

Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>

diff -r 3580392c30da linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 13 10:57:22 
2008 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 13 11:43:45 
2008 -0300
@@ -5499,6 +5499,7 @@ int saa7134_board_init1(struct saa7134_d
case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
case SAA7134_BOARD_AVERMEDIA_M115:
case SAA7134_BOARD_BEHOLD_COLUMBUS_TVFM:
+   case SAA7134_BOARD_AVERMEDIA_A16D:
/* power-up tuner chip */
saa_andorl(SAA7134_GPIO_GPMODE0 >> 2,   0x, 0x);
saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x, 0x);


Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Driver source for Freecom DVB-T (with usb id 14aa:0160) v0.0.2 works

[Mauro Carvalho Chehab]

On Sun, 09 Mar 2008 23:21:17 +0100
Jan Hoogenraad <[EMAIL PROTECTED]> wrote:

> Mauro:
> 
> Thanks a lot for the comments.
> One clear problem with this particular driver is that the code that came 
> from RealTek does not conform to the Linux C coding style.
> Would that be an objection for the steps below ?

Considering that RealTek won't be interested on correcting the CodingStyle,
IMO, the better would be to commit RealTek code as-is, with their SOB, and then
adding an additional patch, authored by somebody else could fix the CodingStyle.

A very simple patch to fix CodingStyle can be created by running kernel
scripts/Lindent. Unfortunately, the results of this automatic tool are not
perfect, but generally are acceptable.

> Furthermore, can you confirm linux-dvb@linuxtv.org as the submission 
> address for the patch ?

Yes. Please C/C me also at the submission e-mail.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH] DMX_OUT_TSDEMUX_TAP: record two streams from same mux, resend

[Mauro Carvalho Chehab]

On Sat, 01 Mar 2008 09:25:58 +0100
Andreas Oberritter <[EMAIL PROTECTED]> wrote:

> Peter Hartley wrote:
> > [Resending patch with proper signed-off-by and updated description, but
> > otherwise unchanged]
> 
> Dear Mauro,
> 
> please apply Peters patch, which allows to utilize the kernel demux
> while recording TS.

Applied, thanks.

Sorry for being late. I was travelling last week.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Driver source for Freecom DVB-T (with usb id 14aa:0160) v0.0.2 works

[Mauro Carvalho Chehab]

On Thu, 21 Feb 2008 00:10:41 +0100
Jan Hoogenraad <[EMAIL PROTECTED]> wrote:

> Great.
> I've compiled it, and found some compilation problems.
> I've fixed those and put them into a zipped patch for the v4l hg 
> management system.
> I've sent it to a couple of people, but did not yet include some 
> copyright message into it.
> Does anybody know how to put it onto the v4l site ?

Sorry, I missed the original thread. 

The procedure is simple: after having it worked and tested, for its
inclusion, you'll need to send it to the DVB ML (also, to V4L ML, if hybrid). 
The better is to c/c me on the e-mail you submit it, for me to be
aware of. After some days, if nobody complains, and if it looks ok, I'll commit.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?

[Mauro Carvalho Chehab]

On Thu, 21 Feb 2008 20:38:09 -0500
Michael Krufky <[EMAIL PROTECTED]> wrote:

> Mauro Carvalho Chehab wrote:
> >>> It is not that simple. Steven patch works for DTV on PCI Nano; Christopher
> >>> patches for some other DiVCO boards (DTV also); my port of Markus patch
> >>>   
> >> for
> >> 
> >>> other boards (tested by Dâniel Fraga - Analog TV).
> >>>   
> >>>   
> >> What does one board have to do with another?  Just because these boards 
> >> all use xceive tuners does not mean that they should be grouped together.
> >> 
> >
> > No, but we have patches for all of them.
> >
> >   
> >> Because the user has the ability to load cx8800 without cx88-dvb, and 
> >> likewise, the user has the ability to load cx88-dvb without cx8800, the 
> >> attach call must be fully qualified such that the other side of the 
> >> driver is not required to be loaded in order for the tuner to work.
> >> 
> >
> > If you take a look at the code, you'll see that all code is at cx88xx. This
> > module is loaded by cx8800, if you're using analog, or by cx8802, if you're
> > using cx88-dvb or cx88-blackbird.
> >
> > The code initializes xc3028 before tuner attach.
> >
> >   
> >> In the case of FusionHDTV5 pci nano, there will never be an attach call 
> >> from the analog side of the driver, since the tuner is hidden behind the 
> >> s5h1409's i2c gate, and analog mode is not supported with the current 
> >> driver.  If you set i2c_scan=1 on the PCI nano, the xceive tuner will 
> >> not even show up in the scan.
> >> 
> >
> > The proper fix is to open the i2c gate before loading tuner. This will allow
> > i2c_scan to work and both analog and digital modes will work. Btw, this
> > somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards.
> >
> > I've added a patch that should open the bridge for s5h1409. Please test. 
> Mauro,
> 
> It does not work.  See my prior email in this thread for the explanation.
> 
> [ 2912.355967] Linux video capture interface: v2.00
> [ 2912.373470] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
> [ 2912.373536] ACPI: PCI Interrupt :02:07.0[A] -> GSI 19 (level,
> low) -> IRQ 17
> [ 2912.373601] cx88[0]: subsystem: 18ac:d530, board: DVICO HDTV5 PCI
> Nano [card=59,autodetected]
> [ 2912.373607] cx88[0]: TV tuner type 71, Radio tuner type -1
> [ 2912.555088] cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw
  
The above message were generated by cx88-cards. So, as I said before, this were
called _before_ running dvb_register, defined at cx88-dvb.

The issue is simple: the i2c gate code were wrong. So, xc3028 is not visible on
that point of the code. With this, analog support will never work. The proper
fix is to enable xc3028 before enabling i2c, meaning to correct the code at
cx88_pci_nano_init().

After re-visiting s5h1409 code, I noticed that I've used the wrong sequence for
the gate. The state should be i2c closed, for xc3028 to work. The following
patch should fix:

http://linuxtv.org/hg/~mchehab/cx88-xc2028/rev/871db4e0451c

Please test it, with i2c_scan=1, and post the results.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: Wh en xc3028/xc2028 will be supported?

[Mauro Carvalho Chehab]

> > It is not that simple. Steven patch works for DTV on PCI Nano; Christopher
> > patches for some other DiVCO boards (DTV also); my port of Markus patch
> for
> > other boards (tested by Dâniel Fraga - Analog TV).
> >   
> 
> What does one board have to do with another?  Just because these boards 
> all use xceive tuners does not mean that they should be grouped together.

No, but we have patches for all of them.

> Because the user has the ability to load cx8800 without cx88-dvb, and 
> likewise, the user has the ability to load cx88-dvb without cx8800, the 
> attach call must be fully qualified such that the other side of the 
> driver is not required to be loaded in order for the tuner to work.

If you take a look at the code, you'll see that all code is at cx88xx. This
module is loaded by cx8800, if you're using analog, or by cx8802, if you're
using cx88-dvb or cx88-blackbird.

The code initializes xc3028 before tuner attach.

> In the case of FusionHDTV5 pci nano, there will never be an attach call 
> from the analog side of the driver, since the tuner is hidden behind the 
> s5h1409's i2c gate, and analog mode is not supported with the current 
> driver.  If you set i2c_scan=1 on the PCI nano, the xceive tuner will 
> not even show up in the scan.

The proper fix is to open the i2c gate before loading tuner. This will allow
i2c_scan to work and both analog and digital modes will work. Btw, this
somewhat similar to what dvico_fusionhdtv_hybrid_init() does on cx88-cards.

I've added a patch that should open the bridge for s5h1409. Please test. 


> > We need one solution that works for all boards, not just yours.
> >
> > That's said, maybe SET_TUNER_CONFIG is being called too early. Maybe the
> way to
> > fix this is to create an special function to initialize it, that would be
> > called later by cx8800 or cx8802.
> both cx8800 *and* cx8802 need this functionality.  Please keep in mind 
> that some users do not ever use analog mode of these cards, and some 
> have even blacklisted cx8800 from loading.  This is fine, because cx8800 
> is not needed for cx88-dvb to function properly.  This is a level of 
> flexibility that we do not want to remove.
> 
> The _real_ problem is that the tuner is being attached to the bridge 
> driver in two locations -- analog side and digital side.  This problem 
> will be entirely avoided once we are attaching the tuner driver in a 
> single location, globally to the entire driver.  Such changes are 
> planned to be dealt with in tuner refactor phase 4, but I am still 
> dealing with refactoring the prerequisites for this scenario, in phase 3 
> -- all will come in due time, but for now, we must provide a fully 
> qualified attachment call each time we attach a tuner driver.

It would be really nice to avoid having to attach it later, on cx88-dvb,
although the double attach won't hurt. I'm not sure on how you want to avoid
this.


Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: When xc3028/xc2028 will be supported?

[Mauro Carvalho Chehab]

Hi Daniel,

On Tue, 19 Feb 2008 09:24:32 -0800
Daniel Gimpelevich <[EMAIL PROTECTED]> wrote:

> On Tue, 19 Feb 2008 13:38:45 -0300, Mauro Carvalho Chehab wrote:
> 
> > Could you please rebase your changesets fixing the gpio's for PowerColor 
> > Real
> > Angel 330 and send them to me?
> 
> I intend to do exactly that sometime within the next couple of weeks.

I've contacted Dâniel Fraga and fixed the remaining issue with his PowerColor
Real Angel 330: firmware should be version 2.5 in order to work. He also
confirmed that the GPIOs are the same as yours for his board.

I've already committed the fixes for it at cx88-xc3028. On his board, both radio
and TV worked fine.

To make easier for all I've changed the firmware extracting tool
to get the firmwares from cx88vid.sys. The extracting tool, and the generated
firmware still needs to be tested.

Dâniel & Daniel, could you please test ? Hopefully, I didn't make any mistake
when changing the extracting tool ;)

The tool is available at:

linuxt/Documentation/video4linux/extract_xc3028.pl

The instructions for usage written at the beginning of the file:

# For firmware version 2.5, you can use the following procedure:
#   1) Download the windows driver with something like:
#   wget 
http://www.power-color.com/drivers/real_angel/RA330_Driver_and_Appl
ication.zip
#   or
#   wget ftp://driver1.cptech.com.tw/Driver/RA330TV/ra330_xp.zip
#
#   2) Extract the file cx88vid.sys from the zip into the current dir:
#   unzip -x RA330_Driver_and_Application.zip "Real Angel Driver & 
Application/Driver/Plug_Play/cx88vid.sys"
#   3) run the script:
#   ./extract_xc3028.pl cx88vid.sys
#   4) copy the generated file:
#   cp xc3028-v25.fw /lib/firmware

The real test were done using Dâniel's cx88vid.sys from his CD. I expect that
the site has the same file, otherwise, md5 will fail, and the firmware won't
be extracted.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: When xc3028/xc2028 will be supported?

[Mauro Carvalho Chehab]

On Tue, 19 Feb 2008 14:43:56 -0300
Dâniel Fraga <[EMAIL PROTECTED]> wrote:

> On Tue, 19 Feb 2008 13:38:45 -0300
> Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> 
> > I've did some changesets fixing both drivers at:
> > http://linuxtv.org/hg/~mchehab/cx88-xc2028/
> 
> > Dâniel Fraga,
> > 
> > Please test if the gpio's from Daniel Gimpelvinch works for you, against the
> > newer tree. I suspect it will work. However, is it not uncommon to have two
> > cards with the same brand name, but needing different gpio settings.
> 
>   Some good news Mauro:

Good news!
 
> cx88[0]: subsystem: 14f1:ea3d, board: PowerColor Real Angel 330
> [card=62,autodetected] cx88[0]: TV tuner type 71, Radio tuner type 0
> tuner' 0-0061: chip found @ 0xc2 (cx88[0])
> xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner
> xc2028 0-0061: xc2028/3028 firmware name not set!
> cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw
> cx88[0]/0: found at :01:08.0, rev: 5, irq: 18, latency: 32, mmio:
> 0xfc00 cx88[0]/0: registered device video0 [v4l2]
> cx88[0]/0: registered device vbi0
> cx88[0]/0: registered device radio0
> xc2028 0-0061: Loading 80 firmware images from xc3028-v27.fw, type:
> xc2028 firmware, ver 2.7 cx88[0]: Calling XC2028/3028 callback
> xc2028 0-0061: Loading firmware for type=BASE MTS (5), id
> . cx88[0]: Calling XC2028/3028 callback
> xc2028 0-0061: Loading firmware for type=MTS (4), id b700.
> xc2028 0-0061: Device is Xceive 3028 version 1.0, firmware version 2.7
> cx88[0]: Calling XC2028/3028 callback
> xc2028 0-0061: Device is Xceive 3028 version 1.0, firmware version 2.7
> cx88[0]: Calling XC2028/3028 callback
> 
>   Notice that it's loading the firmware correctly now ;). I tried
> xawtv and gqradio (and radio from xawtv too). I hear just white noise.

The above logs seems OK to my eyes.

> I tried to change the gpios, but without success...
> 
>   Maybe Daniel Gimpelevich could try on his Powercolor to confirm
> this I think we're almost there... 

It seems so. The bug were trivial: just call request_module("tuner") before
sending commands to tuner ;)

> xc2028 0-0061: Loading firmware for type=BASE FM (401), id .
> cx88[0]: Calling XC2028/3028 callback
> xc2028 0-0061: Loading firmware for type=FM (400), id .
The above logs are OK.

> xc2028 0-0061: Loading SCODE for type=SCODE HAS_IF_3280 (6000), id 
> . 
 ^
 This is wrong.

There's a tuner-xc2028 patch missing on this tree that fixes the above bug.
I've imported the fix patch from master tree. This will avoid to wrongly load an
scode table for FM.

Please update from the tree and try again.

I guess that your device uses input2. However, if I'm wrong, you'll need this
patch for FM:

diff -r 968d9b6b657d linux/drivers/media/video/cx88/cx88-cards.c
--- a/linux/drivers/media/video/cx88/cx88-cards.c   Wed Feb 13 23:52:48 
2008 -0200
+++ b/linux/drivers/media/video/cx88/cx88-cards.c   Tue Feb 19 14:59:44 
2008 -0300
@@ -2430,6 +2430,7 @@ static void cx88_card_setup(struct cx88_
 
ctl.fname   = XC2028_DEFAULT_FIRMWARE;
ctl.max_len = 64;
+   ctl.input1 = 1;
 
switch (core->boardnr) {
case CX88_BOARD_DVICO_FUSIONHDTV_DVB_T_PRO:

Could you also try if TV is properly working?

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: When xc3028/xc2028 will be supported?

[Mauro Carvalho Chehab]

On Tue, 19 Feb 2008 06:51:09 -0300
Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:

> > The repository is broken after and including changeset ce6afd207b71 -
> That's said, maybe SET_TUNER_CONFIG is being called too early. Maybe the way 
> to
> fix this is to create an special function to initialize it, that would be
> called later by cx8800 or cx8802.

After analysing the code, I noticed that "tuner" module is requested too late,
o both cx88 and saa7134 drivers. This explains why there are some instabilities
on those drivers with certain tuners.

I've did some changesets fixing both drivers at:
http://linuxtv.org/hg/~mchehab/cx88-xc2028/

I expect that we should have better results after those changes. I also added
some newer printk's to cx88 driver. This way, we'll have a cleaner idea if an
error is still occurring.

Guys, please test.

Daniel Gimpelevich,

Could you please rebase your changesets fixing the gpio's for PowerColor Real
Angel 330 and send them to me?

Dâniel Fraga,

Please test if the gpio's from Daniel Gimpelvinch works for you, against the
newer tree. I suspect it will work. However, is it not uncommon to have two
cards with the same brand name, but needing different gpio settings.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [EXPERIMENTAL] cx88+xc3028 - tests are required - was: Re: When xc3028/xc2028 will be supported?

[Mauro Carvalho Chehab]

On Mon, 18 Feb 2008 23:44:33 -0500
"Michael Krufky" <[EMAIL PROTECTED]> wrote:

> On Jan 29, 2008 9:25 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > Dâniel and others,
> >
> > > > Having this tested is a very good news! I'll need to merge this patch 
> > > > with two
> > > > other patches that adds DVB support for cx88/xc3028. If I can manage to 
> > > > have
> > > > some time for this merge, I'll commit and ask Linus to add this to 
> > > > 2.6.25.
> > >
> > >   :)
> >
> > I've merged some patches from several authors, that add xc3028 support for
> > cx88.
> >
> > The experimental tree is available at:
> >
> > http://linuxtv.org/hg/~mchehab/cx88-xc2028
> >
> > This patch series adds support for the following boards:
> >
> >  59 -> DVICO HDTV5 PCI Nano[18ac:d530]
> >  60 -> Pinnacle Hybrid PCTV[12ab:1788]
> >  61 -> Winfast TV2000 XP Global[107d:6f18]
> >  62 -> PowerColor Real Angel 330   [14f1:ea3d]
> >  63 -> Geniatech X8000-MT DVBT [14f1:8852]
> >  64 -> DViCO FusionHDTV DVB-T PRO  [18ac:db30]
> >
> > In thesis, both analog and DVB support (for boards with DVB/ATSC) should be
> > working (*). Maybe analog audio may need an additional configuration for 
> > some
> > specific board (since they may require to add cfg.mts = 1 at xc3028
> > initialization code, on cx88-cards).
> >
> > Please test.
> 
> Mauro,
> 
> We spoke on Thursday, and you asked me to take a look at the code in
> your 'cx88-xc2028' tree over the weekend and fix it, if possible.
> 
> The repository is broken after and including changeset ce6afd207b71 -
> "Make xc3028 support more generic"  This changeset moves the
> device-specific configuration out of the cx88-dvb.c device-specific
> switch..case block, into a generic function.  This patch breaks
> functionality, and imho, is not a good idea.
> 
> Your changes assume that the analog side of the driver will come up
> before the digital side of the driver, which is not necessarily the
> case.  Additionally, in some cases, the tuner itself is hidden behind
> an i2c gate that is controlled by the dvb / atsc demodulator.  Because
> of the i2c gate, communication to the tuner might not be available at
> the time that the i2c bus is probed.  For those reasons, the attach
> calls to the tuner driver should be fully qualified, relative to the
> functionality of the side of the driver that is attaching it.
> 
> The device that I used to test is the FusionHDTV 5 PCI nano.  This
> device uses an xc3008 (yes, that is xc3008 -- not a typo) and a
> s5h1409 demod.  The device is capable of receiving ATSC digital
> broadcasts and the driver does not yet support analog television.
> 
> Steve Toth made the patch that adds atsc support for that card, and
> his patch worked without the additional changesets that were added
> afterwards.  I made some small fixes and enabled IR support -- see the
> bottom of this email for my pull request.
> 
> Your email above states that you've "merged some patches from several
> authors".  What I recommend, in order to properly support each device,
> would be to apply each patch for each card separately, as we do with
> all card support additions.  We know that the original patches, as
> submitted by the original authors work properly , since those authors
> have conducted their own tests.
> 
> I understand that you've made some attempts to optimize the code in an
> effort to reduce memory consumption.  Unfortunately, these efforts
> have broken functionality of these devices.  I think that it would
> make more sense to work on optimizations after the basic device
> support patches are first applied in the standard manner.  This way,
> you would have a good point of reference for "before" and "after" that
> testers will be able to use for comparison (and bisection).
> 
> Since the only card that I can test is the PCI nano, please pull these
> changesets into master for now.
> 
> Please pull from:
> 
> http://linuxtv.org/hg/~mkrufky/cx88-xc2028
> 
> for:
> 
> (91113b8955e2) 4 weeks agoSteven Toth cx88: Add support for the
> Dvico PCI Nano.
> (394d249f03f1) 47 hours ago   Michael Krufky  cx88: fix FusionHDTV 5 PCI
> nano name and enable IR support

Michael,

It is not that simple. Steven patch works for DTV on PCI Nano; Christopher
patches for some other

Re: [linux-dvb] [PATCH] support Cinergy HT USB XE (0ccd:0058)

[Mauro Carvalho Chehab]

Hi Albert,

On Thu, 14 Feb 2008 21:20:32 +0100
"Albert Comerma" <[EMAIL PROTECTED]> wrote:

> [ 2251.856000] xc2028 4-0061: Error on line 1063: -5

The above error is really weird. It seems to be related to something that
happened before xc2028, since firmware load didn't start on that point of the
code.


> [ 2289.284000] xc2028 4-0061: Device is Xceive 3028 version 1.0, firmware 
> version 2.7
This message means that xc3028 firmware were successfully loaded and it is
running ok. 

> [ 2282.504000] xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id 
> .
> [ 2289.104000] xc2028 4-0061: Loading firmware for type=D2620 DTV8 (208), id 
> .
> [ 2289.224000] xc2028 4-0061: Loading SCODE for type=DTV8 SCODE HAS_IF_5400 
> (6200), id .

The above messages state what firmware you've loaded.

xc3028 version 2.7 has 80 different firmwares. If you load a wrong one, your
device won't work.

>From the above, the driver is assuming that you're on an area with 8MHz video
channels. Also, your demod should be using IF = 5.4 MHz:

Firmware 64, type: DTV8 CHINA SCODE HAS IF (0x64000200), IF = 5.40 MHz id: 
(), size: 192

Does the above firmware correspond to your configuration?

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] [ANNOUNCE] linux-next and V4L/DVB linux-next

[Mauro Carvalho Chehab]

A recent announce at LKML introduced a new concept of integrated development
between the several subsystem trees, called linux-next.

The basic idea is to have a common tree that merges all development efforts,
helping to solve merge conflicts before arising at Linus main tree. More
details can be seen at the original announce [1].

With this concept, what happens is that a new patch will mature at the
development branches and at linux-next. At the release of a new kernel (let's
say 2.6.25), a merge window will open to the next kernel (2.6.26). The patches
for the next kernel will be submitted by each subsystem maintainer. Since those
patches were already tested on linux-next tree, the merging process will
become easier and the newer kernel will become more stable.

So, linux-next contains the patches for 2.6.25, plus the patches expected to be
added at kernel 2.6.26.

For this to happen, I've created a newer -git tree, containing the committed
changesets that are expected to appear at the next kernel. It contains
basically the same patches already present on -hg and v4l-dvb.git trees, plus
the base patches from linux-next (at 'stable' branch). Another branch
('master') will contain also the merged patches from the other subsystems. 

For those brave enough to test it, the tree is available at [2]. Please be
warned to use this on a testing system, since patches at core subsystems
(ext2, vfs, etc) may be broken there.

In order have a single point where all trees are listed, I've updated
README.patches file, and the main tree at http://linuxtv.org/hg with the newer
tree. I've also added a link to README.patches there.

[1] http://lkml.org/lkml/2008/2/11/512
[2] 
http://www.kernel.org/git/?p=linux/kernel/git/mchehab/linux-next.git;a=summary

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Sat, 09 Feb 2008 21:53:01 +
"Richard (MQ)" <[EMAIL PROTECTED]> wrote:

> Richard (MQ) wrote:
> > Mauro Carvalho Chehab wrote:
> >> If you're not seeing any mesage from tuner-xc2028, it means that the 
> >> driver is
> >> selecting a different tuner.
> >>
> >> Please send me the complete dmesg.
> >>
> >> Also, try to force saa7134 driver to use tuner=71 with:
> >>
> >> modprobe -vv saa7134 tuner=71
> > 
> > Please find attached - not posted to list as I don't think everyone will
> > want this...
> 
> Just tried re-booting the box with the standard OpenSuSE 10.3 partition,
> (and completely re-loaded and re-built the mercurial code) - same odd
> behaviour. Kernel now 2.6.22.16 fwiw
> 
> Also may be worth noting - running "make reload" after "make install"
> produces lots of errors, though neither the initial "make" nor "make
> install" gave any.
> 
> Output of "modprobe -vv saa7134 tuner=71" for this case attached
> (smaller than last time!)

The file got corrupted here :(

If you're getting too much errors, it may mean that you're having some
conflicts on your compilation.

There is a recent patch at the tree that changed the module dependencies.
(before the patch, videodev were dependent on v4l2-common - now, the dependency
is the reverse. Only after "make distclean", the building system will
correctly deal with this change)

Please try to do force a cleanup, with this:
make distclean
make
make rminstall
make rmmod
make install
modprobe saa7134 tuner=71

please forward the errors that it might produce. You may forward the full dmesg
errors to me in priv directly. I prefer if you don't generate a tarball, since
makes easier for me to comment, the results, if needed.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Thu, 07 Feb 2008 20:29:15 +
"Richard (MQ)" <[EMAIL PROTECTED]> wrote:

> Richard (MQ) wrote:
> > Mauro Carvalho Chehab wrote:
> >> "Richard (MQ)" <[EMAIL PROTECTED]> wrote:
> >>>> tuner: Unknown parameter `tuner_xc2028'
> >> Hmm... I suspect you did something wrong at modprobe.conf.local. It seems 
> >> that
> >> it is using tuner_xc2028 as a parameter to tuner module.
> >>
> >> What we need is to have a parameter "debug=1" to both tuner an tuner-xc2028
> >> modules.
> > 
> > I thought I just pasted your lines straight in...
> > 
> > I'll have another try tonight, maybe something is mis-typed. If I load
> > with modprobe -v it will show the options being used.
> 
> After booting:
> DevBox2400:~ # rmmod tuner tuner-xc2028 saa7134 tuner-simple tuner-types
> DevBox2400:~ # modprobe -vv tuner
> insmod /lib/modules/.../media/video/tuner-types.ko
> insmod /lib/modules/.../media/video/tuner-simple.ko
> insmod /lib/modules/.../media/video/tuner-xc2028.ko debug=1
> insmod /lib/modules/.../media/video/tuner.ko debug=1
> DevBox2400:~ # modprobe -vv saa7134
> insmod /lib/modules/.../kernel/drivers/media/video/saa7134/saa7134.ko
> 
> but /var/log/messages shows no sign of the debug messages:
> 
> Feb  7 20:08:49 DevBox2400 kernel: saa7130/34: v4l2 driver version
> 0.2.14 loaded
> Feb  7 20:08:49 DevBox2400 kernel: saa7133[0]: found at :00:0d.0,
> rev: 209, irq: 20, latency: 32, mmio: 0xe200
> Feb  7 20:08:49 DevBox2400 kernel: saa7133[0]: subsystem: 1461:f936,
> board: AVerMedia Hybrid TV/Radio (A16D) [card=133,autodetected]
> Feb  7 20:08:49 DevBox2400 kernel: saa7133[0]: board init: gpio is 2f600
> Feb  7 20:08:50 DevBox2400 kernel: saa7133[0]: i2c eeprom 00: 61 14 36
> f9 00 00 00 00 00 00 00 00 00 00 00 00
> ...
> 
> modinfo confirms that tuner-xc2028 is your code. I'm completely baffled
> by this...

If you're not seeing any mesage from tuner-xc2028, it means that the driver is
selecting a different tuner.

Please send me the complete dmesg.

Also, try to force saa7134 driver to use tuner=71 with:

modprobe -vv saa7134 tuner=71

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

On Wed, 06 Feb 2008 18:49:51 +
"Richard (MQ)" <[EMAIL PROTECTED]> wrote:

> Mauro Carvalho Chehab wrote:
> > I need the tuner-xc2028 dmesg.
> > 
> > Please, add this to /etc/modprobe.conf:
> > options tuner debug=1
> > options tuner-xc2028 debug=1
> 
> Added to /etc/modprobe.conf.local per SuSE scheme
> 
> > DevBox2400:~ # rmmod tuner tuner-xc3028
> > DevBox2400:~ # modprobe -vv tuner
> > insmod 
> > /lib/modules/2.6.24-rc8-git2-5-default/kernel/drivers/media/video/tuner.ko 
> > debug=1
> > DevBox2400:~ # dmesg
> > Linux version 2.6.24-rc8-git2-5-default ([EMAIL PROTECTED]) (gcc version 
> > 4.3.0 20080117 (experimental)
> 
> dmesg shows only:
> 
> > tuner: Unknown parameter `tuner_xc2028'

Hmm... I suspect you did something wrong at modprobe.conf.local. It seems that
it is using tuner_xc2028 as a parameter to tuner module.

What we need is to have a parameter "debug=1" to both tuner an tuner-xc2028
modules.

> modprobe'ing tuner_xc2028 does nothing (no error, nothing added to dmesg)
> 
> No dmesg messages starting "xc2028", in fact
> 
> > DevBox2400:~ # dmesg | grep 2028
> > tuner: Unknown parameter `tuner_xc2028'
> > DevBox2400:~ # dmesg | grep firmw
> > DevBox2400:~ #
> 
> Is it me doing something wrong, or a problem with the code?

The code may have some trouble, since it is not tested yet ;)


Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] BUG in changeset 7157?

[Mauro Carvalho Chehab]

On Tue, 05 Feb 2008 23:44:31 +0100
e9hack <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> compiling of the current HG tree fails on linux 2.6.24. I think it is a bug 
> in changeset 7157:
> 
> --- a/v4l/compat.h Tue Feb 05 07:37:21 2008 +
> +++ b/v4l/compat.h Tue Feb 05 11:21:32 2008 -0200
> @@ -497,6 +497,10 @@ do { \
> #ifndef BIT_MASK
> # define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
> # define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
> +
> +#define i2c_verify_client(dev) \
> + ((dev->bus == &i2c_bus_type) ? to_i2c_client(dev) : NULL)
> +
> #endif
> 
> The definition of i2c_verify_client() should not be inside #ifndef BIT_MASK / 
> #endif. The 
> variable i2c_bus_type is only public on 2.6.23.x (maybe also on earlier 
> versions) but not 
> on 2.6.24. The following patch does fix the problem on 2.6.24 for me:

Committed, thanks!

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Any chance of help with v4l-dvb-experimental / Avermedia A16D please?

[Mauro Carvalho Chehab]

Hi Richard,

On Sun, 03 Feb 2008 15:07:27 +
"Richard (MQ)" <[EMAIL PROTECTED]> wrote:

> I tried contacting Markus with the following but no response - probably
> one of you experienced coders on this list will know what's wrong
> though? As I say below, the 'standard' v4l-dvb builds fine but is no use
> with this card.

I've ported Markus patch for cx88 and saa7134 xc3028-based boards into this
tree:

http://linuxtv.org/hg/~mchehab/cx88-xc2028

Some adjustments may be needed for this to work, since tuner-xc2028 needs
to know what firmware it will load for dvb. This is done by those lines, at
the end of saa7134-cards.c:

/* FIXME: This should be device-dependent */
ctl.demod = XC3028_FE_OREN538;
ctl.mts = 1;

ctl.demod should have the IF of the used tuner. Most current boards use
IF=5.380 MHz. XC3028_FE_OREN538 is an alias for 5380.
Another possible value is XC3028_FE_ZARLINK456 (IF = 4560 KHz).

ctl.mts affects audio decoding. If you don't have audio on
analog mode, you may try to change this to 0.

For the driver to work, you'll need to extract xc3028 firmware. Most devices
works fine with Xceive firmware version 2.7. In order to extract, you should
follow the following procedure:

  1) Download the windows driver with something like:
  wget 
http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip

  2) Extract the file hcw85bda.sys from the zip into the current dir:
  unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip 
Driver85/hcw85bda.sys

  3) run the script:
  ./linux/Documentation/video4linux/extract_xc3028.pl

  4) copy the generated file:
  cp xc3028-v27.fw /lib/firmware

Could you please test it and give us some feedback?

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Pending patches

[Mauro Carvalho Chehab]

Hi guys,

Unfortunately, there were a crash at the server that I use for my inboxes. Due
to that, I lost several non-proccessed pull requests and e-mail patches that
should be committed into v4l-dvb tree and forward to kernel.

While I still hope that people will recover the lost e-mails, it would be safer
if those of you that forwarded me a patch, to re-send they to my inbox.

I kindly ask you to send those requests to me, c/c the lists, with the magic
tags at the subject:
[PATCH (resend)] - for patches that you're re-sending to me
[PULL (resend)] - for hg pull requests that you're re-sending



Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] saa7134-dvb: add missing dvb_attach call (for tda10046_attach)

[Mauro Carvalho Chehab]

On Mon, 28 Jan 2008 00:51:25 +0100
Hartmut Hackmann <[EMAIL PROTECTED]> wrote:

> Hi, Mauro
> 
>
> Can you please integrate this bugfix?
> I think it should go into the next kernel.

Sure. Added.

Thanks,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] [Patch 1/4] saa7134: support for Twinhan Hybrid DTV-DVB 3056 PCI

[Mauro Carvalho Chehab]

On Fri, 25 Jan 2008 23:44:46 +0100
Hartmut Hackmann <[EMAIL PROTECTED]> wrote:

> Hi, Mauro
> 
> Mauro Carvalho Chehab schrieb:
> > On Sun, 20 Jan 2008 00:24:49 +0100
> > Hartmut Hackmann <[EMAIL PROTECTED]> wrote:
> > 
> >> Hi, all
> >>
> >> Please let me integrate these patches in my personal repository first.
> >> Otherwise the Medion / Creatix related changes will cause conflicts.
> > 
> > Hi Hartmut,
> > 
> > Have you integrated this already? The merge window opened today. It would be
> > interesting if we can pull your changesets also.
> > 
> > 
> > Cheers,
> > Mauro
> > 
> 
> They are in my personal repository:
> http://linuxtv.org/hg/~hhackmann/v4l-dvb/
> the changesets:
> f187f7cb9121
> 8d3b6a959187
> 585969f369d7
> 885df3491073
> 
> Can you pull these only?

Pulled, thanks.

> I am afraid the DVB-S support for the Medion / Creatix cards will not make it
> on time and the isl6405 driver is untested.

Ok.


Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] [Patch 1/4] saa7134: support for Twinhan Hybrid DTV-DVB 3056 PCI

[Mauro Carvalho Chehab]

On Sun, 20 Jan 2008 00:24:49 +0100
Hartmut Hackmann <[EMAIL PROTECTED]> wrote:

> Hi, all
> 
> Please let me integrate these patches in my personal repository first.
> Otherwise the Medion / Creatix related changes will cause conflicts.

Hi Hartmut,

Have you integrated this already? The merge window opened today. It would be
interesting if we can pull your changesets also.


Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] ansonic branded dvb-t usb stick support in the af9005 driver

[Mauro Carvalho Chehab]

On Sun, 20 Jan 2008 21:56:43 +0100
Luca Olivetti <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> a user (Marcos Melero, marcosmelero at gmail.com) reported he could make 
> his dvb-t usb stick work with the af9005 driver by changing the device 
> ids (10b9:6000).
> The stick is branded "Ansonic" (one of the brands of a spanish chain of 
> supermarkets) with no other identification of the model.
> Since neither Marcos nor me know the OEM for the stick, in the attached 
> patch I used Ansonic for the ids/description.
> Feel free to change the ids or add to the description if you know the 
> real OEM.
> 
No idea, sorry ;)

I've applied the patch at the tree, with a few changes at the description. If
later someone points us the real vendor, we can replace it or add the OEM at
the tree.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH 1/2] bt878: remove handcrafted PCI subsystem ID check

[Mauro Carvalho Chehab]

On Sun, 20 Jan 2008 15:26:20 -0800 (PST)
Trent Piepho <[EMAIL PROTECTED]> wrote:

> On Sun, 20 Jan 2008, Mauro Carvalho Chehab wrote:
> > On Sat, 19 Jan 2008 05:28:49 -0800 (PST)
> > Trent Piepho <[EMAIL PROTECTED]> wrote:
> >
> > > I wish people would use the patch creating system from Hg, since it would
> > > the format mistakes evident in this patch.
> > >
> > > 1. no patch title
> > > 2. s-o-b's in wrong order
> > > 3. diffstat included
> > > 4. patch against git source and not hg
> > >
> > > On Sat, 19 Jan 2008, Akinobu Mita wrote:
> > > > From: Akinobu Mita <[EMAIL PROTECTED]>
> > > >
> > > > This patch moves the subsystem ID and subsystem vendor ID check from 
> > > > probing
> > > > function to the PCI generic function by describing subsystem IDs in
> > > > pci_device_id table. This enables to add new PCI IDs to a device driver 
> > > > pci_ids
> > > > table at runtime by new_id file in sysfs pci driver tree.
> > >
> > > This patch also changes the driver from having a pci alias to auto-load 
> > > for
> > > all bt878 cards to instead only auto-load for specific cards.  Some
> > > distributions will probably want to adjust their modprobe rules.  I know
> > > some have delt with both snd-bt87x and bt878 loading for the same devices
> > > in various ways, e.g. adding one or the other to their modprobe blacklist
> > > files.
> >
> > The proper solution here seems to be moving snd-bt87x to our tree, and 
> > create
> > some shared code to be used by snd-bt87x, dvb-bt8xx, to avoid the
> > driver conflicts.
> 
> That doesn't solve the problem.  It's inherent in the bt878 design, as it
> uses the same pci function for either sound or dvb.  So a bt878 chip
> function 1 can load one and only one driver from ALSA, OSS, or DVB.  For
> most chips, there is only one driver that applies to a given pci device and
> function.
> 
> In some cases it is possible to tell which driver to use via
> sub-vendor/device data, but not always.  The ALSA driver only auto-loads
> for known good subdata, and has a module option to force loading when that
> won't work.  The DVB driver has the wildcard sub-vendor/device in the alias
> table, IMHO a mistake, and will try to load for for all bt878 chips.
> 
> The DVB driver used to load for cards with sub-vendor/device 0x,0x,
> but a previous patch changed that.  An effect that that _should_ have been
> mentioned in the description of the patch responsible, but was not.
> 
> This patch changes the DVB driver to not auto-load for all bt878 chips.  A
> rather significant change that should be described in the patch
> description, but is not.
> 
> > > > +static const char * __devinit card_name(const struct pci_device_id *id)
> > > > +{
> > > > +   if (id >= bt878_pci_tbl &&
> > > > +   id < bt878_pci_tbl + ARRAY_SIZE(bt878_pci_tbl) - 1)
> > > > +   return (const char *)id->driver_data;
> > >
> > > Are you sure this is safe?  I don't remember reading that the 
> > > pci_device_id
> > > passed to the pci driver probe method must be from the device id table.
> > > Couldn't the device id be a local variable from whatever calls probe, as
> > > long as driver_data is set to the correct value?  I looked at the current
> > > pci bus code, and it does always pass a pointer into the driver's pci id
> > > table.  But that could change.
> > >
> > > It seems like a better method would just be to check if driver_data is 0,
> > > which will be the case if the id was added dynamically.
> >
> > This data can't be changed by pci core, since driver_data is a priv 
> > element. It
> > is used as a pointer on some drivers, while others use it as an integer 
> > value to
> > an array (like most V4L/DVB and ALSA drivers). The above code should work
> > properly. If pci touches on this value, it would break the support for the 
> > rest
> > of v4l/dvb drivers, so I think we don't need to worry about this.
> 
> I don't think you understand.  That code checks if the pci_device_id
> pointer passed to the probe function points to a spot in the driver's pci
> id table.  It has nothing to do with the driver_data field being modified.

I think you didn't understand me ;)

IMO, the check is a little overkill, but I don't think that any future changes
on PCI internal code would affect, since the usage of dr

Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH 1/2] bt878: remove handcrafted PCI subsystem ID check

[Mauro Carvalho Chehab]

On Sat, 19 Jan 2008 05:28:49 -0800 (PST)
Trent Piepho <[EMAIL PROTECTED]> wrote:

> I wish people would use the patch creating system from Hg, since it would
> the format mistakes evident in this patch.
> 
> 1. no patch title
> 2. s-o-b's in wrong order
> 3. diffstat included
> 4. patch against git source and not hg
> 
> On Sat, 19 Jan 2008, Akinobu Mita wrote:
> > From: Akinobu Mita <[EMAIL PROTECTED]>
> >
> > This patch moves the subsystem ID and subsystem vendor ID check from probing
> > function to the PCI generic function by describing subsystem IDs in
> > pci_device_id table. This enables to add new PCI IDs to a device driver 
> > pci_ids
> > table at runtime by new_id file in sysfs pci driver tree.
> 
> This patch also changes the driver from having a pci alias to auto-load for
> all bt878 cards to instead only auto-load for specific cards.  Some
> distributions will probably want to adjust their modprobe rules.  I know
> some have delt with both snd-bt87x and bt878 loading for the same devices
> in various ways, e.g. adding one or the other to their modprobe blacklist
> files.

The proper solution here seems to be moving snd-bt87x to our tree, and create
some shared code to be used by snd-bt87x, dvb-bt8xx, to avoid the
driver conflicts.

> I think that new_id will only work if hotplug is turned on.  Without
> hotplug, there will be no way to load the driver for other devices (such as
> those with eprom trouble).
> 
> > +static const char * __devinit card_name(const struct pci_device_id *id)
> > +{
> > +   if (id >= bt878_pci_tbl &&
> > +   id < bt878_pci_tbl + ARRAY_SIZE(bt878_pci_tbl) - 1)
> > +   return (const char *)id->driver_data;
> 
> Are you sure this is safe?  I don't remember reading that the pci_device_id
> passed to the pci driver probe method must be from the device id table.
> Couldn't the device id be a local variable from whatever calls probe, as
> long as driver_data is set to the correct value?  I looked at the current
> pci bus code, and it does always pass a pointer into the driver's pci id
> table.  But that could change.
>
> It seems like a better method would just be to check if driver_data is 0,
> which will be the case if the id was added dynamically.

This data can't be changed by pci core, since driver_data is a priv element. It
is used as a pointer on some drivers, while others use it as an integer value to
an array (like most V4L/DVB and ALSA drivers). The above code should work
properly. If pci touches on this value, it would break the support for the rest
of v4l/dvb drivers, so I think we don't need to worry about this.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Pinnacle HD 800i - Testers required

[Mauro Carvalho Chehab]

On Tue, 15 Jan 2008 12:50:21 -0500
"James Klaas" <[EMAIL PROTECTED]> wrote:

> /usr/src/video4linux/hd800i/xc5000-analog/v4l/dvb_net.c: In function
> 'wq_set_multicast_list':
> /usr/src/video4linux/hd800i/xc5000-analog/v4l/dvb_net.c:1172: error:
> 'struct net_device' has no member named 'xmit_lock'
> /usr/src/video4linux/hd800i/xc5000-analog/v4l/dvb_net.c:1201: error:
> 'struct net_device' has no member named 'xmit_lock'

Weird... xmit_lock were removed on kernel 2.6.17. 

It seems that your Ubuntu kernel has something weird at 
kernel's include/linux/netdevice.h.

The auto-detection script seems is not finding the newer lock function
netif_tx_lock_bh(), added on 2.6.17.

Try to compile it against a vanilla kernel.


 Cheers,
Mauronetif_tx_lock_bh

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Hauppauge HVR 4000 in Ubuntu 7.10

[Mauro Carvalho Chehab]

On Mon, 14 Jan 2008 15:06:46 +0100
"ga ver" <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> In Ubuntu 7.10 with kernel 2.6.22-14.47 in will install a Hauppauge HVR4000.
> This card is not recognized in the standard kernel.
> I download the latest DVB/V4L sources from
> hg clone http://linuxtv.org/hg/v4l-dvb
> with patch 
> v4l-dvb-hg-2007-12-26.diff
> from http://dev.kewl.org/hauppauge/
> 
> the make gives
> :/usr/local/v4l-dvb# make
> make -C /usr/local/v4l-dvb/v4l
> make[1]: Map '/usr/local/v4l-dvb/v4l' wordt binnengegaan
> creating symbolic links...
> Kernel build directory is /lib/modules/2.6.22-14-generic/build
> make -C /lib/modules/2.6.22-14-generic/build SUBDIRS=/usr/local/v4l-dvb/v4l
> modules
> make[2]: Entering directory `/usr/src/linux-headers-2.6.22-14-generic'
>   CC [M]  /usr/local/v4l-dvb/v4l/stk-webcam.o
> /usr/local/v4l-dvb/v4l/stk-webcam.c:60: warning: implicit declaration of
> function 'USB_DEVICE_AND_INTERFACE_INFO'
> /usr/local/v4l-dvb/v4l/stk-webcam.c:60: error: initializer element is not
> constant
> /usr/local/v4l-dvb/v4l/stk-webcam.c:60: error: (near initialization for
> 'stkwebcam_table[0].match_flags')
> /usr/local/v4l-dvb/v4l/stk-webcam.c:61: error: initializer element is not
> constant
> /usr/local/v4l-dvb/v4l/stk-webcam.c:61: error: (near initialization for
> 'stkwebcam_table[1].match_flags')
> make[3]: *** [/usr/local/v4l-dvb/v4l/stk-webcam.o] Error 1
> make[2]: *** [_module_/usr/local/v4l-dvb/v4l] Error 2
> make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-14-generic'
> make[1]: *** [default] Fout 2
> make[1]: Map '/usr/local/v4l-dvb/v4l' wordt verlaten
> make: *** [all] Fout 2
> 
> what is missing hier, or is their a better solution

What happens is that stk driver (just added) is requiring a newer kernel
version, since it needs a kernel with this patch applied:
http://kerneltrap.org/mailarchive/linux-usb-devel/2007/7/12/339476

I've just updated v4l/versions.txt to add the driver version dependency. If you
update your tree (hg pull -u") and do "make distclean allmodconfig", the tree
should now be compile fine with 2.6.22.

An alternative would be to do make menuconfig and unselect V4L USB STK driver.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] USBVision - YUV Conversion (Using RGB instead of BGR)

[Mauro Carvalho Chehab]

On Sun, 13 Jan 2008 18:35:45 -0500 (EST)
Dwaine Garden <[EMAIL PROTECTED]> wrote:

> Thierry,  I think we need you to sign off on the patch.
> 
> sign-off: Dwaine Garden

I've added your SOB at the patch.

Thanks,
Mauro.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Extract tool for xc3028 firmware

[Mauro Carvalho Chehab]

On Mon, 31 Dec 2007 10:03:38 -0500
"Devin Heitmueller" <[EMAIL PROTECTED]> wrote:

> Hello Mauro,
> 
> Figures.  I spent all day yesterday disassembling the embda.sys for
> the hvr-900 trying to accomplish the same task.

It is hard... It took all day long for me to write a seek tool for detecting the
placements for the firmwares.

> Did you generate the offsets in extract_xc3028.pl using a script
> (knowing what the images to looked like based on the output of a usb
> bus capture)?

See --seek option at v4l2-apps/util/xc3028-firmware.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] South America visible satellites

[Mauro Carvalho Chehab]

On Mon, 31 Dec 2007 18:29:48 +0100
"Christoph Pfister" <[EMAIL PROTECTED]> wrote:

> Hi Mauro,
> 
> 2007/12/28, Mauro Carvalho Chehab <[EMAIL PROTECTED]>:
> >
> > Hi Christoph,
> >
> > I'm enclosing an updated list of Satellites that are visible here in Brazil.
> > Probably, this list is the same for all South America countries.

> The patch is ok apart from a little problem: "L" and "R" for circular
> polarization isn't understood by most (all?) scan apps, so I changed
> them to their equivalents "H" and "V" (although it isn't the same it
> results in the same commands sent to the dish).

I think that dvb-utils tool recognizes L/R polarization. There are a few files
there using this, AFAIK.

Anyway, seems ok to me to replace by H/V.

Thanks,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Extract tool for xc3028 firmware

[Mauro Carvalho Chehab]

On Mon, 31 Dec 2007 14:57:18 +
"Aidan Thornton" <[EMAIL PROTECTED]> wrote:

> 
> 
> On 12/31/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > On Mon, 31 Dec 2007 03:34:56 -0200
> > Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > 
> > > I've just added an extraction tool to allow retrieving xc2028/3028
> > firmwares
> > > from HVR-12x0 windows file.
> > > 
> > > In order to use, you need to:
> > >   1) Download the windows driver with something like:
> > >   wget
> > http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip
> > >   2) Extract the file hcw85bda.sys from the zip into the current dir:
> > >   unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip
> > Driver85/hcw85bda.sys
> > >   3) run the script:
> > >   ./extract_xc3028.pl
> > >   4) copy the generated file:
> > >   cp xc3028-v27.fw /lib/firmware
> > > 
> > > I've also added the tool at linux/Documentation/video4linux.
> > > 
> > > This firmware is known to work with most xc2028/xc3028 devices. Please
> > test.
> > 
> > Sorry for a big message like this. Only after sending, I realized that the
> > extracting tool were so badly optimized.
> > 
> > Anyway, I've optimized the script. It has now only 14Kb. It basically writes
> > the header for each firmware, with the firmware type, supported standard IDs
> > and its size. Then, it copies the entire firmwares from HVR driver.
> > Something
> > like this:
> > #
> > # Firmware 9, type: STD FWMTS (0x0004), id: PAL/BG A2/B
> > (00020007), size: 169
> > #
> > 
> > write_le32(4);  # Type: MTS (0x0004)
> > write_le64(8589934599); # Id: PAL/BG A2/B 
> > (00020007)
> > write_le32(169);# Size: 169
> > write_hunk_fix_endian(865592, 169); # Get the firmware from position
> > 865592
> > 
> > Since ID has 64 bits, I suspect that this perl script works fine only on 64
> > bit kernels. Probably, we need to use Math::BigInt for this to work on 32
> > bit
> > kernels.

OK, I've replaced the 64 bit integer by two 32 bit ints:

# Firmware 77, type: SCODE FW  MONO HAS IF (0x60008000), IF = 6.68 MHz 
id: PAL/DK A2 (000300e0), size: 192
#

write_le32(0x60008000); # Type
write_le64(0x0003, 0x00e0); # ID
write_le16(6680);   # IF
write_le32(192);# Size
write_hunk(810936, 192);

This should work fine also on 32 bit machines. Tested here.

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Extract tool for xc3028 firmware

[Mauro Carvalho Chehab]

On Mon, 31 Dec 2007 03:34:56 -0200
Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:

> I've just added an extraction tool to allow retrieving xc2028/3028 firmwares
> from HVR-12x0 windows file.
> 
> In order to use, you need to:
>   1) Download the windows driver with something like:
>   wget 
> http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip
>   2) Extract the file hcw85bda.sys from the zip into the current dir:
>   unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip 
> Driver85/hcw85bda.sys
>   3) run the script:
>   ./extract_xc3028.pl
>   4) copy the generated file:
>   cp xc3028-v27.fw /lib/firmware
> 
> I've also added the tool at linux/Documentation/video4linux.
> 
> This firmware is known to work with most xc2028/xc3028 devices. Please test.

Sorry for a big message like this. Only after sending, I realized that the
extracting tool were so badly optimized.

Anyway, I've optimized the script. It has now only 14Kb. It basically writes
the header for each firmware, with the firmware type, supported standard IDs
and its size. Then, it copies the entire firmwares from HVR driver. Something
like this:
#
# Firmware 9, type: STD FWMTS (0x0004), id: PAL/BG A2/B 
(00020007), size: 169
#

write_le32(4);  # Type: MTS (0x0004)
write_le64(8589934599); # Id: PAL/BG A2/B 
(00020007)
write_le32(169);# Size: 169
write_hunk_fix_endian(865592, 169); # Get the firmware from 
position 865592

Since ID has 64 bits, I suspect that this perl script works fine only on 64
bit kernels. Probably, we need to use Math::BigInt for this to work on 32 bit
kernels.

> 
> Cheers,
> Mauro




Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] mt312: coding style improvements

[Mauro Carvalho Chehab]

On Fri, 21 Dec 2007 12:02:50 +0100
Matthias Schwarzott <[EMAIL PROTECTED]> wrote:

> So here are they!
> 
> mt312_codingstyle: fix almost all issues listed by checkpatch
> mt312_remove_extra_KERN_DEBUG: removes extra KERN_DEBUG from dprintk calls

Applied, thanks.

> checkpatch also lists this:
> ERROR: do not use assignment in if condition
> if ((ret = mt312_readreg(state, VIT_MODE, &vit_mode)) < 0)
> return ret;
> 
> As this pattern is used in many lines of many drivers I wonder if this also 
> should be changed or not?

Less relevant CodingStyle problems are marked as WARNING. As this is an
"ERROR", seems good to fix.

In the above case, the code is still not so bad, but there are some
constructions that look worse, like:

if ((ret=foo())) { 
bar;
}

(I found this kind of construction on some code I've touched recently on V4L)

While this would be good to fix, I don't see any need for rushing it. 


Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] mt312: coding style improvements

[Mauro Carvalho Chehab]

On Thu, 20 Dec 2007, Andreas Oberritter wrote:

> Matthias Schwarzott wrote:
>> Changing mt312 driver today.
>>
>> The first patch improves codingstyle - I did fix almost all things checkpatch
>> lists.
>> I did not change if ((ret = func(a)) < 0) {
>>
>> The second patch does remove extra KERN_DEBUG from dprintk calls, as dprintk
>> already adds KERN_DEBUG:
>> #define dprintk(args...) \
>> do { \
>> if (debug) printk(KERN_DEBUG "mt312: " args); \
>> } while (0)
>
> Thank you, Matthias!
>
> Mauro, can you please apply both patches to your tree?

Sure.

Mathias/Andreas,

Could you send the patches to me? I couldn't find them on my mailboxes.

-- 
Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Start thinking about potential Google Summer of Code Projects we could run

[Mauro Carvalho Chehab]

On Wed, 19 Dec 2007 11:26:35 -0500
CityK <[EMAIL PROTECTED]> wrote:

> Hi folks,
> 
> Google summer of code will be rolling around in a couple of months.  Now
> I know we've talked a little bit about it before, but I don't recall
> what the thoughts on it were.  In any regard, on the surface of things,
> it would seem a perfect opportunity for the LinuxTV Project to leverage
> -- i.e. enslave a few students to get some desperately needed tasks,
> components, apps, drivers or whatever done.  Side benefit -- it might
> hopefully attact a few more developers to the project too -- get some
> new blood, stir up the pot, chase after nagging/long-time bugs etc, etc.
> 
> So, I suggest we start thinking about or, better yet, discussing
> ideas/projects for which we could make use of the GSOC.
> 
> (I, of course, was kidding about the enslavement part)

The userspace library seems interesting for me.

On kernel side, a good contribution would be the V4L2 conversion. There are
still several V4L1 only drivers that need conversions (mostly webcams).

Another good contribution would be testset tools to allow checking regressions
at the drivers and driver compliance with the API.

This tool should check both DVB and V4L APIs, identifying the differences
between an old version driver and the newer one, running all possible supported
ioctls. I've started working on such tool, for V4L, but never finished, due to
the lack of time (the current work is at v4l2-apps/test/).

Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [BUG] video capture is broken

[Mauro Carvalho Chehab]

Em Seg, 2007-11-19 às 12:02 -0800, Brandon Philips escreveu:
> On 20:02 Mon 19 Nov 2007, e9hack wrote:
> > Brandon Philips schrieb:
> > > I am guessing this a saa7136 based device.  
> > 
> > The card is saa7146 based. I think you mean the saa7146.
> > 
> > > Could you please test this
> > > patch?  If it is in fact not a saa7136, what driver is it?
> > 
> > The patch does fix the problem, thanks!
> 
> Gah, I was not subscribed so my messages never made it to this list.
> 
> For everyones reference this is the patch:
>   http://ifup.org/hg/v4l-dvb?cmd=changeset;node=65d65eecf8a5;style=gitweb
> 
> Mauro has been asked to pull this change into his repository.

Patch applied, thanks.

Btw, maybe, we should remove this code, calling, instead
videobuf_cgmbuf. The implementation seems to be common on all videobuf
clients.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] mt20xx.c code bugs!

[Mauro Carvalho Chehab]

Em Sex, 2007-11-16 às 09:08 +0800, kevin liu escreveu:
> You mean all the c compilers will give 'unknown' a special process???

Huh?

I mean:

{
char *name = "unknown";

and 

{
char *name;

/* some code */

name = "unknown";

are equivalent.

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] mt20xx.c code bugs!

[Mauro Carvalho Chehab]

Em Qui, 2007-11-15 às 09:43 +0800, kevin liu escreveu:
> Dear everyone:
> I am reading v4l2 tuner part code these days, when I come to mt20xx.c,
> in microtune_init(), the use of the char pointer name maybe cause some
> fatal error sometimes for this state:
> ++
> 507 name = "unknown";
> ++
> while pointer name doesn't have its memory.
> And I wonder why gcc can't give any warnings?

Because this works properly and it has a valid syntax/semantic.

Any C compiler will add "unknown" string to the data segment and 'name'
will point to this area.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] HVR1500 status

[Mauro Carvalho Chehab]

Em Ter, 2007-11-13 às 15:05 -0500, Steven Toth escreveu:
> Michel Ludwig wrote:
> > Hi Steven,
> > 
> > On Tuesday 13 November 2007 17:20:56 you wrote:
> >> It's worth pointing out the current state of the HVR1500 support under
> >> Linux.
> >>
> >> 1. None of it's functions are currently supported, they are awaiting a
> >> xc3028 driver change. I have some patchsets which will add support, but
> >> they reply on the xc3028 change.
> > 
> > What changes are you waiting for exactly?
> 
> The xc3028 driver needs more firmware for different I/F's to support the 
> s5h1409 for ATSC.
> 
> Mauro said he'd add them, I offered to integrate once done.

I've added today the capability of supporting the newer I/F's at
tuner-xc2028 driver. Still, we need to work on it to provide a nice
interface inside DVB core and to userspace.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] [RFC: 2.6 patch] remove saa7134-oss

[Mauro Carvalho Chehab]

Hi Adrian,

Em Sex, 2007-11-09 às 07:03 +0100, Adrian Bunk escreveu:
> The saa7134-oss is deprecated for quite some time, it's the only 
> remaining OSS user outside of sound/oss/, and considering how few and 
> what kind of soundcards are left supported by OSS I hardly see any use 
> cases left.

Since saa7134-alsa seems to do the job, it seems ok to remove
saa7134-oss.

> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>

I'll commit this patch soon at my tree.

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] merged tree with newer patch series

[Mauro Carvalho Chehab]

> Looking at tuner-xc2028.c, there seem to be some issues:
> 
> a) priv->count is initialized to zero by the first user. This would
> result in priv either being freed prematurely or never freed at all.
> b) If priv is freed, it doesn't seem to be removed from the global
> xc2028_list list, meaning that this list is left containing dangling
> pointers that will be followed the next time xc2028_attach is called.
> 
> Of course, unless there's more than one user of the same tuner, these
> would mostly cancel each other, leaving nothing but a slight memory
> leak.

Thanks for the finding, Aidan! I've wrote a patch fixing it.

I've already merged all the patch series, including the fix, at v4l-dvb.

A good news is that I had some time to make HVR-950 (Analog part) to
work with tuner-xc2028.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] FWD: [Patch] saa7146/budget*/dvb-ttpci: Remove V4L1 dependencies

[Mauro Carvalho Chehab]

> Basically the enum is not required.
> Everything works fine without replacing VIDEO_MODE_xxx by 
> AV7110_VIDEO_MODE_xxx. (VIDEO_MODE_xxx is defined in videodev.h.)
> 
> On the other hand, I like the enum because it defines the interface
> between firmware and driver in a clean way. video_tuner->mode defines
> should not be used here because anything except VIDEO_MODE_PAL or
> VIDEO_MODE_NTSC are not valid for the firmware. In the future the enum
> might be extended to display NTSC content on a PAL TV...

For me, having the enum is overkill, but this doesn't hurt.
So, let's then keep the enum if you wish.

> > Also, please review the patch with scripts/checkpatch.pl.
> 
> Will do so.

Ok, thanks.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] [RFC] merged tree with newer patch series

[Mauro Carvalho Chehab]

I did a lot of work this weekend merging several patchsets. There are 68
new changesets there.

The resulting tree is available at:
http://linuxtv.org/hg/~mchehab/merge

This tree has:

- one warning fix for pvrusb2;
- bttv and i2c audio decoders conversion to V4L2
- merge was pending for almost 2 years;
- required to fix audio with V4L2 userspace apps;
- hybrid redesign phase 2
- converts demods to the newer design;
- i2c bus conversion
- will improve i2c attachments;
- tuner-xc2028 addition
- needed for tm6000
- may work for em28xx and other drivers - although not yet tested with
non-tm6000 hardware

Since we have too much stuff merged into this series, including some
core changes, I kindly ask you to test this tree.

I intend to merge this at v4l-dvb tree later today.

I've also worked on tm6000 code, although its code is not ready yet.

The patches, including tm6000 ones is also temporarily available as a
series of quilt patches at:
http://linuxtv.org/~mchehab/merge2

Please test and give us some feedback. Big changes like this are subject
to miscellaneous issues, since we're all humans ;)

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] FWD: [Patch] saa7146/budget*/dvb-ttpci: Remove V4L1 dependencies

[Mauro Carvalho Chehab]

Hi Oliver and Marco,

The patch looked good to me. 

Some comments:

IMO, instead of creating an emum for vidmode, I would instead just store
v4l2_std_id there.

> if (std->id & V4L2_STD_PAL) {
> -   av7110->vidmode = VIDEO_MODE_PAL;
> +   av7110->vidmode = AV7110_VIDEO_MODE_PAL;
> av7110_set_vidmode(av7110, av7110->vidmode);
> }
> else if (std->id & V4L2_STD_NTSC) {
> -   av7110->vidmode = VIDEO_MODE_NTSC;
> +   av7110->vidmode = AV7110_VIDEO_MODE_NTSC;
> av7110_set_vidmode(av7110, av7110->vidmode);
> }

I dunno if av7110 does support PAL/60, PAL/M or PAL/N. I did a quick
look on a datasheet I found at the net for
av7110(http://www.cdaniel.de/download/AV711x_3_1.pdfs). It seems that
the only supported PAL ones are PAL/BDGHI. If this is true, the above
code is perfect.

However, if the driver supports other PAL standards, the above code
won't work, since a few PAL standards are not marked as V4L2_STD PAL
[1]. If this the case, the above code is not correct. 

[1] On V4L2, V4L2_STD_PAL means only PAL/BGDKHI. IMHO, this is one of
the weird things at V4L2 API.

To support also PAL/60, and PAL/MN, a better coding would be:

if (std->id & V4L2_STD_SECAM) {
printk(KERN_ERR "Secam is not supported\n");
else if (std->id & V4L2_STD_NTSC) {
av7110->vidmode = AV7110_VIDEO_MODE_NTSC;
av7110_set_vidmode(av7110, av7110->vidmode);
} else {
av7110->vidmode = AV7110_VIDEO_MODE_PAL;
av7110_set_vidmode(av7110, av7110->vidmode);
}

Or to use V4L2_STD_525_60 (for 60 Hz standards) and V4L2_STD_625_50 (for
50 Hz standards).
 
Also, please review the patch with scripts/checkpatch.pl.

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] tuner-refactor-phase-2

[Mauro Carvalho Chehab]

> NO -- the tuner changes do not touch bttv -- they are all internal to
> the tuner code.

Good to know.

> If you have to remove some v4l1 support from tuner-core, that will
> simply be the removal of a few lines, and it can be easily done by hand.
> 
> OTOH, If you push in the v4l1 removal first, and it conflicts with the
> pending tuner changes, that _will_ cause a problem.  It will require for
> the entire patch series to be regenerated, and this will result in
> holding up Hans from moving forward with his work, until I have time to
> regenerate the entire series.

Let's see what'll happen at the merging stage. If you're saying that the
changes are all internal, conflicts shouldn't arrive.

You both should notice that bttv v4l1 tree touches on most i2c audio
drivers, converting driver APIs to V4L2. Currently, except for msp3400,
all other drivers support only V4L1 calls. A V4L2 userspace app won't be
able to properly configure audio on non-msp34xx bttv boards. This is the
main reason for doing this change.

> If you are going to push in the xc2028 stuff, the core changes should go
> in first, then you should alter your new patch as required.  I do not
> expect this xc2028 driver to work with the devices that I have, and I
> believe that you are going to create a large confusion about firmware,
> not to mention that you do not have any legal rights to alter or
> distribute the firmware.

I'm not discussing firmwares. If this can't be solved on a clean way,
there's always the "dirty" way of having a script that extracts the
firmware from the windows driver. Several drivers, including the old
versions of ivtv and pvrusb2, as well as some newer ones, like opera1
uses this approach.

Yet, I really hope that we can have some official permission for
distributing Linux firmwares from all vendors.

> I wouldn't rush in the xc2028 stuff before the other changes.

If not committed, newer changes at tuner API will require more work, and
I don't want to spend my time re-basing it again.

The hybrid design phase 1 changes required me almost 6 hours to port the
driver, just to satisfy the newer API, without adding a single newer
functionality.

Converting it were nice, since I've discovered that there are several
bad things at the current hybrid design.

For example, I had to change several parameter exchanges at the driver
due to things like:

tuner_info("foo")

tuner_info internally depends of a var called "priv->i2c_propos". If you
don't have this declared, the compilation will fail. 

So, it is required to add i2c_propos at the private structure, and to
rename the driver internal structure to "priv", even being a name that
doesn't mean anything inside a driver. 

The tuner core required a hidden "priv" struct is really bad (*)

(*) Ok, the previous tuner_info call also had hidden parameters.

We should avoid this kind of design on newer code. We should, instead,
define tuner_info to be used like:
tuner_info(i2c_propos, "foo")

As the result of this kind of changes, I needed to add 6 newer fields to
my "priv" struct (in fact, struct xc2028_data), and rename it from the
nice "xc2028" name to the meaningless "priv", just to satisfy the newer
hybrid design.

Since there are more phases to happen, if the driver is not inserted on
core, it will mean that more rebase will be needed, for every newer
tuner redesign phase.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] tuner-refactor-phase-2

[Mauro Carvalho Chehab]

Em Sex, 2007-10-26 às 12:09 +0200, Hans Verkuil escreveu:
> On Friday 26 October 2007 06:24, Michael Krufky wrote:
> > Mauro Carvalho Chehab wrote:
> > > Hi Michael,
> > >
> > > Em Seg, 2007-10-22 às 16:03 -0400, [EMAIL PROTECTED] escreveu:
> > >> Mauro & others,
> > >>
> > >> After our conversation last week, I decided to move forward with
> > >> tuner-refactor-phase-2, so that you can have the pathway for your
> > >> tda9887 & tea5767 changes to go in without clashing with my
> > >> pending work.
> > >>
> > >> My code is now ready for review:
> > >>
> > >> http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-2
> > >
> > > I expect a few troubles on merging the newer patches for 2.6.25,
> > > since there are several significant changes that are expected to
> > > happen, during this development period, like:
> > >
> > > - the newer tuner-redesign changesets;
> > > - i2c redesign;
> > > - bttv removal of V4L1 support;
> >
> > ^^^ These above do not conflict with each other. 

I suspect that bttv V4L1 removal will conflict with both changesets.
I'll need to decide what's the better order for merging those 3 changes
to avoid breaking bttv. 

Any decision taken, however, would mean that the newer v4l-dvb tree will
require more tests than it used to require, to be stable.

>  Hans and I have
> > coordinated such that we will not patch clash, and the i2c
> > conversions deal mostly with client modules...  any impact on bttv,
> > if any, will be localized in the i2c code.

bttv has several "hacks" for probing i2c audio devices. Depending on the
way Hans touched bttv, the conflicts will emerge.

> >  The pending bttv patch
> > probably needs updating anyway, due to changes upstream.
Yes. before hybrid redesign, however, the changes at bttv weren't much
significant. I'm counting with you both to help on solving the conflicts
that might emerge.

> I agree with Mike here. My i2c patches do not touch the tuner, nor 
> should they conflict with anything else. It does the initial conversion 
> of a bunch of i2c drivers and installs the framework. No v4l driver is 
> actually using it yet, ivtv will be the first to switch over.
If you didn't touch much on bttv, than it should be easier to solve the
conflicts.

> > The changes above hold priority over the two below.
> >
> > > - xc3028 old code removal;
> > > - tuner-xc2028 addition;
> >
> > Regardless, the xc2028 changes are unlikely to cause any conflict
> > with the other changes.
> >
> > Hans is waiting for the tuner-refactor-phase-2 tree to be merged
> > before he pushes in the i2c changes, and you should wait for those
> > both to be merged before dealing with xc2028, in my opinion.
> 
> Actually, xc2028 can go in before my i2c changes since these i2c changes 
> to not involve the tuner. They are not dependent on one another.

I'll probably try to do xc2028 and hybrid tuner changes about the same
time, since both deals with similar things.

Since I've replaced the CONFIG_TUNER_XC3028 by CONFIG_XC2028 on all
drivers [1], including ivtv, some minor conflicts might arrive. Since
ivtv xc3028 support is based at the userspace module, you will need to
fix ivtv driver later, for it to work with the newer driver.

[1] http://linuxtv.org/hg/~mchehab/tm6000-ng/rev/065874933156

With the new tuner-xc2028, the tuner will only work after receiving a
TUNER_SET_CONFIG, specifying the firmware driver name[2] and the audio
mode (RF or MTS).

[2] from what I got, it seems that different bridge chips may need
different firmwares. TM6000 driver, for example, doesn't work with
xc3028 version 2.7 firmware.

> > > Since those envolves several changes at core, it is likely that
> > > changesets will conflict.
> >
> > anything is possible, but i don't think it's likely :-)
> >
> > > So, I intend to carefully handle the 2.6.25 changesets already
> > > finished during this weekend, hopefully.
> >
> > OK.  I have more changes planned that depend on these... If I add
> > changesets to the tree, i'll send you addendums to my original pull
> > request.
> 
> From my perspective it would be great if the tuner and i2c changes would 
> go in on Saturday, then I can use Sunday to do the tuner i2c 
> conversion, deliver yet another i2c driver for the Mitsubishi M52790 
> A/V switch and add in ivtv patches to support two new boards. It's no 
> wonder ivtv suffers relatively often from i2c detection issues: it 
> supports no less than 15 different i2c devices.

I'll try to finish this on Sat, but I can't promise.

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] tuner-refactor-phase-2

[Mauro Carvalho Chehab]

Hi Michael,

Em Seg, 2007-10-22 às 16:03 -0400, [EMAIL PROTECTED] escreveu:
> Mauro & others,
> 
> After our conversation last week, I decided to move forward with 
> tuner-refactor-phase-2, so that you can have the pathway for your 
> tda9887 & tea5767 changes to go in without clashing with my pending work.
> 
> My code is now ready for review:
> 
> http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-2

I expect a few troubles on merging the newer patches for 2.6.25, since
there are several significant changes that are expected to happen,
during this development period, like:

- the newer tuner-redesign changesets;
- i2c redesign;
- bttv removal of V4L1 support;
- xc3028 old code removal;
- tuner-xc2028 addition;

Since those envolves several changes at core, it is likely that
changesets will conflict.

So, I intend to carefully handle the 2.6.25 changesets already finished
during this weekend, hopefully.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] How could we support a general v4l tuner ops like Linux DVB?

[Mauro Carvalho Chehab]

Em Ter, 2007-10-23 às 10:05 +0800, kevin liu escreveu:
> Dear guys:
>  I think v4l-dvb should support a more general v4l tuner ops, when
> I add my own driver to Linux v4l, I am just confused by the v4l tuner
> architecture.
>  I saw Markus Rechberge's code, he move the xc3028 tuner to the
> tuner dir, i think maybe we could move all v4l tuner to a directory
> like this, are there any guys who would like to talk about this issue?

This seems to be a good idea. IMO, the proper place is to move the newer
tuner drivers to /common/tuner.

However, better to wait for the merge of tuner-refactor phase 2, to
avoid troubles with Michael patches, that should happen soon, after
people analyze it.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] random memory corruptions with asus p7131 (Re: asus p7131 vs ZDF?)

[Mauro Carvalho Chehab]

Wait! Please clarify whether you think that your problem is caused by
the _saa7134_ driver or the _saa7146_ driver.

You wrote 'that  is caused by the saa7146 driver,'
Is this a typo? Did you mean saa7134?


You are right my statement is wrong. To get it right, my asus has the
• tda10046a
• saa7131e
and not the saa7146 (which my brain generated using the numbers 7131 /
10046).

On saa7131 board, the memory corruptions may be caused by V4L overlay 
interface. On overlay mode, the driver sets the device to do a PCI2PCI memory 
transfer. This is known to cause troubles with some VIA and SIS motherboards.


If you load saa7134 with no_overlay=1, overlay mode will be disabled. Could 
you please test if this solves the issue?


AFAIK, some newer motherboards that had this problem can be corrected by 
upgrading its bios.


Cheers,
Mauro___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] [saa7134] Fwd: [PATCH] Spezial Lifeview DVB-S Card without eeprom

[Mauro Carvalho Chehab]

Hi Oliver and Martin,

> since there was no reply on the DVB ML:
> Is anyone maintaining the DVB part of the saa7134 driver?
> Can this patch be accepted?

Hartmut is the guy who did more work at saa7134 dvb. 

Let me contribute with my review.

The patch looks sane for me, except for a few improvements that should
be done.

> -- */
> +
> +static int philips_su1278_ty_ci_tuner_set_params(struct dvb_frontend
> *fe,
> +struct
> dvb_frontend_parameters *params)
> +{
> +   u32 div;
> +   u8 buf[4];
> +   struct saa7134_dev *dev = fe->dvb->priv;
> +   struct i2c_msg msg = {.addr = 0x61,.flags = 0,.buf = buf,.len
> = sizeof(buf) };
> +
> +   if ((params->frequency < 95) || (params->frequency >
> 215))
> +   return -EINVAL;
> +
> +   div = (params->frequency + (125 - 1)) / 125;// round
> correctly
> +   buf[0] = (div >> 8) & 0x7f;
> +   buf[1] = div & 0xff;
> +   buf[2] = 0x80 | ((div & 0x18000) >> 10) | 4;
> +   buf[3] = 0x20;

The Philips su1278 tuner support should be mapped, instead, at
dvb-pll.c. It makes no sense to have tuner-specific stuff inside saa7134
dvb glue. This also means easier usage on other board types that has the
same tuner.

An example of a better implementation is the way saa7134-dvb does for
Philips td1316.

> +   0x10, 0x3f, // AGC2  0x3d

The source code is violating CodingStyle. It should be reviewed using
Kernel scripts/checkpatch.pl. Running "make commit" will automatically
run this script, and adding warnings (as comments) at the commit
message.

In this particular case, C99 comments are forbidden inside kernel.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

> > The proper change is simply doing something like:
> >
> > s/videobuf_queue_init/videobuf_queue_abstract_init/
> >
> > After this, on all places where videobuf stuff is used without
> > conversion, an error will be generated.
> >   
> This wouldn't be a bad idea.

> > After my considerations, if you still think this is important, I'll
> > accept a patch renaming the old videobuf_queue_init to a new name.
> >   
> 
> I think that you've proven that it is NOT important... although, it 
> still might be a good idea.  I'm not sure -- I was only making a
> suggestion.

Agreed. I'll try to do such patch when I have some time.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

> > I don't like to create a video-buf.h header. This will make non-pci
> > devices dependent on PCI, or will require some additional logic for
> > checking kernel Kconfig symbols. I also expect that other newer videobuf
> > methods to be created. So, this header will just generate undesirable
> > mess.
> 
> This would not create dependencies of non-pci devices on pci -- a
> simple header inclusion is optimized by the c compiler -- only needed
> methods are considered and are actually included in the build.

Wrong. This has nothing to do with c optimizer. Try this:

Create this as header.h:

struct foo {
struct some_pci_struct foo;
};

Create this as main.c:

#include "header.h"

int main (void)
{
return 0;
}

You will got the following error:

/tmp/header.h:2: error: field ‘foo’ has incomplete type

If we use your approach, a non-pci videobuf driver will work only at the
architectures where you have a PCI bus (since the pci structs won't
exist on that architecture).

> > What we might do is to rename the generic abstract method to another
> > name. This will generate compilation errors, making easier for people to
> > realize what happened.
> 
> If we rename it to video-buf.h, it would cover the issue that I have in mind.
> 
It is much more clear to include videobuf-vmalloc or videobuf-dma-sg,
depending on the proper videobuf module that will be needed by a driver.

Creating a video-buf.h that just includes the two will be unused by the
drivers. So, what's the sense of creating a header file at the kernel
that aren't used inside kernel?

> > I'm not sure if this is valuable enough, since I don't know any other
> > DMA S/G driver using videobuf being developed for their inclusion at
> > Kernel.
> 
> Maybe an out of tree driver uses it?

Although there's no intention to make life harder for out-of-tree
drivers, they shouldn't be considered on changes made at kernel
internals. The proper place for a kernel driver is in-kernel, not
outside.

Anyway, a compilation with a driver including video-buf.h currently will
generate an error, indicating that something has changed at v4l
infrastructure. By creating a header like you're proposing won't fix
this.
> 
>   Maybe there is an in-tree driver that still might have old methods being 
> used but we didnt hit those bugs yet due to incomplete testing methods?

The only in-kernel drivers that use videobuf infrastructure are:
cx88, saa7134, bttv, saa7146 and, now, cx23885. 

After the patch, all of they are already converted.

grep videobuf_queue_pci_init *.c
bttv-driver.c:  videobuf_queue_pci_init(&fh->cap, &bttv_video_qops,
bttv-driver.c:  videobuf_queue_pci_init(&fh->vbi, &bttv_vbi_qops,
cx23885-dvb.c:  videobuf_queue_pci_init(&port->dvb.dvbq, &dvb_qops,
dev->pci, &port->slock,
cx88-blackbird.c:   videobuf_queue_pci_init(&fh->mpegq,
&blackbird_qops,
cx88-dvb.c: videobuf_queue_pci_init(&dev->dvb.dvbq, &dvb_qops,
cx88-video.c:   videobuf_queue_pci_init(&fh->vidq, &cx8800_video_qops,
cx88-video.c:   videobuf_queue_pci_init(&fh->vbiq, &cx8800_vbi_qops,
saa7134-dvb.c:  videobuf_queue_pci_init(&dev->dvb.dvbq,
&saa7134_ts_qops,
saa7134-empress.c:  videobuf_queue_pci_init(&dev->empress_tsq,
&saa7134_ts_qops,
saa7134-video.c:videobuf_queue_pci_init(&fh->cap, &video_qops,
saa7134-video.c:videobuf_queue_pci_init(&fh->vbi,
&saa7134_vbi_qops,
saa7146_vbi.c:  videobuf_queue_pci_init(&fh->vbi_q, &vbi_qops,
saa7146_video.c:videobuf_queue_pci_init(&fh->video_q,
&video_qops,
videobuf-dma-sg.c:void videobuf_queue_pci_init(struct videobuf_queue* q,

There's no other driver using the abstract videobuf_queue_init.

A final point for your consideration:

videobuf_queue_init is the only function that had its meaning changed
without changing its parameters (currently, it is just an abstract
method. In the past, this were the function that were used to initialize
a videobuf queue). 

The changes you're proposing won't solve the target you've addressed in
the first place, since it will still compile without warning, if you
forget to rename it to videobuf_queue_pci_init.

The proper change is simply doing something like:

s/videobuf_queue_init/videobuf_queue_abstract_init/

After this, on all places where videobuf stuff is used without
conversion, an error will be generated.

After my considerations, if you still think this is important, I'll
accept a patch renaming the old videobuf_queue_init to a new name.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

> Mauro,
> 
> This new patch fixed the problem.  CX23885 functionality is restored!  :-)
Good! If you send your reviewed-by, I'll add at the proper changesets
touching videobuf.

> side note:  If we had left a single header, video-buf.h, we could have
> avoided this problem.  When we rename files like this, we run the risk
> of building against the wrong headers, if errors are not caught &
> corrected quickly enough.
> 
> Are you open to merging the videobuf-*.h into a single video-buf.h
> header file, to match the filename in previous kernel versions so that
> we can avoid this issue from recurring?  Either that, or including the
> current headers into a new video-buf.h would do the same job.
> 
> What do you think?

I don't like to create a video-buf.h header. This will make non-pci
devices dependent on PCI, or will require some additional logic for
checking kernel Kconfig symbols. I also expect that other newer videobuf
methods to be created. So, this header will just generate undesirable
mess.

What we might do is to rename the generic abstract method to another
name. This will generate compilation errors, making easier for people to
realize what happened.

I'm not sure if this is valuable enough, since I don't know any other
DMA S/G driver using videobuf being developed for their inclusion at
Kernel.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

Michael,


> However, cx23885 is now broken.  Upon starting a DVB stream, the
> following OOPS is generated:

I've reviewed cx23885 videobuf stuff. I noticed a problem at the
conversions: It is still using the abstract videobuf constructor,
instead of the pci DMA S/G one. I've just added a patch fixing this at
v4l-dvb tree. Probably, this will fix the issue.

Please test.

- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

> For now, let me give a quick explanation of the basics of videobuf.
> 
> ---
> 
(part 2)

As you know, the original author of videobuf is Gerd. At the changes I
did, I've tried to preserve, as much as possible, the code outside
videobuf without changes(*).

(*) This is also true for the binary code that videobuf-core +
videobuf_dma_sg executes: It is almost the same as the original
videobuf, but separated into two separate modules, with distinct
functions.

a) The first one is about the inherited videobuf_buffer class at each
driver.

The approach used on videobuf is somehow different from what other parts
of the Linux Kernel does. For this to work, the first part of a
videobuf_buffer inherited code should do:

cx23885_buffer {
struct videbuf_buffer;

...
}

Otherwise, the videobuf code will fail.

IMO, it would be better to use container_of as you suggested, but this
would mean rewrite more code at the drivers, and do more tests.

b) The destructor used to free videobuf_buffer memory is just kfree. So,
all memory for the entire class should be allocated with just one
kmalloc. The memory model is something like:

struct derivated_class {
struct cx23885_buffer {
struct videobuf_buffer;
// cx23885 own data
}
// dma s/g own data
};

So, videobuf_pci_malloc do something like:

buf=kmalloc (sizeof(struct derivated_class), GFP_KERNEL);

To free a videobuf, you just need to do:

free (buf);

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

Em Dom, 2007-10-07 às 14:03 -0700, Trent Piepho escreveu:
> On Sun, 7 Oct 2007, Mauro Carvalho Chehab wrote:
> > I took a look at cx23885 code. It seems that there's a serious error on
> > the way you're using cx23885_buffer there:
> >
> > cx23885-dvb.c:  return cx23885_buf_prepare(q, port, (struct
> > cx23885_buffer*)vb, field);
> > cx23885-dvb.c:  cx23885_buf_queue(port, (struct cx23885_buffer*)vb);
> > cx23885-dvb.c:  cx23885_free_buffer(q, (struct cx23885_buffer*)vb);
> >
> > It seems that you are forcing videobuf_buffer to be cx23885_buffer. This
> > is not right!
> >
> > This is what is defined on cx23885.h:
> >
> > struct cx23885_buffer {
> > /* common v4l buffer stuff -- must be first */
> > struct videobuf_buffer vb;
> 
> I'm not sure that it is competely wrong.  Say one has a cx23885_buffer that
> contains a videobuf_buffer.  Now suppose you have a pointer to the
> videobuf_buffer, and you want to get a pointer to the cx23885_buffer that
> contains it.  What you should write is:
> 
> struct videobuf_buffer *vb = ...;
> struct cx23885_buffer *buf = container_of(vb, struct cx23885_buffer, vb);
> 
> But since vb is the first field of the cx23885_buffer struct, the container_of
> will turn into just '(struct cx23885_buffer *)(vb)
>
> This code in videobuf-dma-sg.c looks odd to me:
> 
> /* Allocated area consists on 3 parts:
> struct video_buffer
> struct _buffer (cx88_buffer, saa7134_buf, ...)
> struct videobuf_pci_sg_memory
> 
> static void *__videobuf_alloc(size_t size)
> {
> struct videbuf_pci_sg_memory *mem;
> struct videobuf_buffer *vb;
> 
> vb = kzalloc(size+sizeof(*mem),GFP_KERNEL);
> 
> mem = vb->priv = ((char *)vb)+size;
> 
> What is 'size', is that the size of the driver buffer?  Shouldn't you
> be
> allocating size + sizeof(*vb) + sizeof(*mem)?
> 
> Is there documentation for videobuf anywhere?  It doesn't look like
> any of
> the videobuf functions have descriptions of that they do or what the
> parameters are.

There aren't any videobuf doc yet. I intend to write one, when I have
some time. IMO, this is the most complex part of V4L core.

For now, let me give a quick explanation of the basics of videobuf.

---

Videobuf uses a memory struct that looks what c++ compilers do when you
use inheritances. 

It is something like:

class videobuf_core {
public:
// some data and code
};

class videobuf_dma_sg: public videobuf_core {
private:
// some data and code
}

class foo_buffer: public videobuf_dma_sg {
public:
// some data
}

The "constructor" for any class derivated from videobuf_dma_sg is:
void *videobuf_pci_alloc (size_t size);

Where size is the size of foo_buffer.

The other videobuf_dma methods are the external functions defined on
videobuf-dma-sg.h. All of them start with videobuf_dma_foo.

A similar inehitance concept happens with videobuf_queue. You have an
abstract videobuf_queue class, defined on videobuf-core, where almost
all methods are virtual, and, currently, two derivated class, that
implements their methods: a DMA Scatter/Gather one (videobuf-dma-sg) and
a vmalloc one (videobuf-vmalloc).

To use the full functionality of videobuf, you will need the
videobuf_queue, that is responsible for controlling the state machine of
the videobuffers. The videobuf_queue constructor will allocate a
videobuf_buffer inherited class. Also, when you need mmapped buffers,
videobuf core will allocate one additional videobuf_buffer inherited
class by each queue (generally, a driver allocates, by default, 8 queues
for receiving data - this avoids data loss, when the machine is with
high workloads).

It is also possible just to use a videobuf_buffer derivated class. ALSA
saa7134 and cx88 drivers implement this way. They have their own state
machine.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

Hi Michael,
Em Dom, 2007-10-07 às 02:30 -0400, Michael Krufky escreveu:
> Mauro Carvalho Chehab wrote:
> > Hi Michael,
> > 
> > Please try the enclosed patch. It is just a hack. 
> > 
> > Please, post the dmesg, working or not.
> 
> Mauro,
> 
> Your patch touches code that apparently is not being executed in this case.  
> I've enclosed dmesg anyway (see attached)


I took a look at cx23885 code. It seems that there's a serious error on
the way you're using cx23885_buffer there:

cx23885-dvb.c:  return cx23885_buf_prepare(q, port, (struct
cx23885_buffer*)vb, field);
cx23885-dvb.c:  cx23885_buf_queue(port, (struct cx23885_buffer*)vb);
cx23885-dvb.c:  cx23885_free_buffer(q, (struct cx23885_buffer*)vb);

It seems that you are forcing videobuf_buffer to be cx23885_buffer. This
is not right!

This is what is defined on cx23885.h:

struct cx23885_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;

/* cx23885 specific */
unsigned int   bpl;
struct btcx_riscmemrisc;
struct cx23885_fmt *fmt;
u32count;
};

You should notice that cx23885_buffer size is bigger than
videobuf_buffer. If you just force one to be equal to the other, you'll
use more memory than the allocated one! 

Also, videobuf code will also add some extra bytes at the alloced memory
for its own consuption.

The new videobuf code has some magic to protect about this bad usage,
otherwise, you may risk to corrupt other memory areas with dma
transfers. I lost part of my reiserfs btrees once, with a bad code like
this.

What it should be done, is to use the allocated area provided by
videobuf_queue_pci_init.

I dunno how this ever worked!

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

Hi Michael,

Please try the enclosed patch. It is just a hack. 

Please, post the dmesg, working or not.

Cheers,
Mauro.

diff -r 62d749961694 linux/drivers/media/video/videobuf-core.c
--- a/linux/drivers/media/video/videobuf-core.c	Fri Aug 24 02:22:15 2007 +0200
+++ b/linux/drivers/media/video/videobuf-core.c	Sun Oct 07 00:48:50 2007 -0300
@@ -92,10 +92,25 @@ int videobuf_iolock(struct videobuf_queu
 int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb,
 		struct v4l2_framebuffer *fbuf)
 {
+	int rc;
+
+printk("%s: init\n",__FUNCTION__);
+
 	MAGIC_CHECK(vb->magic,MAGIC_BUFFER);
 	MAGIC_CHECK(q->int_ops->magic,MAGIC_QTYPE_OPS);
 
-	return CALL(q,iolock,q,vb,fbuf);
+	schedule();
+
+//	mutex_lock(&q->lock);
+
+printk("%s: calling actual handler\n",__FUNCTION__);
+
+	rc = CALL(q,iolock,q,vb,fbuf);
+//	mutex_unlock(&q->lock);
+
+printk("%s: return\n",__FUNCTION__);
+
+	return rc;
 }
 
 /* - */
@@ -915,12 +930,18 @@ int videobuf_mmap_mapper(struct videobuf
 {
 	int retval;
 
-	MAGIC_CHECK(q->int_ops->magic,MAGIC_QTYPE_OPS);
+printk("%s: init\n",__FUNCTION__);
 
 	mutex_lock(&q->lock);
+
+	MAGIC_CHECK(q->int_ops->magic,MAGIC_QTYPE_OPS);
+printk("%s: calling actual handler\n",__FUNCTION__);
+
 	retval=CALL(q,mmap_mapper,q,vma);
+
 	mutex_unlock(&q->lock);
 
+printk("%s: returning\n",__FUNCTION__);
 	return retval;
 }
 
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC-final] videobuf tree

[Mauro Carvalho Chehab]

> Yes...  I cloned today's master branch, including your changeset cited above. 
> I was sure to do 'make rminstall' in an older tree, to remove all traces of 
> the older video_buf module before installing the new modules.

I suspect that there's a race condition related with the way we do mmap. I 
got a similar issue with MSI TV @nyware AD NB (saa7134) and a dual core 
AMD 64 notebook. The same device on a single core notebook works like a 
charm. I had this trouble with both old and new videobuf.

I also noticed, on tm6000 driver, that, on my tests with newer kernels, 
the calling order for file .mmap handler and videobuf_iolock has changed. 
I did a workaround at videobuf-vmalloc for this case:

 /* It seems that some kernel versions need to do remap *after*
the mmap() call
  */
 if (mem->vma) {


I suspect that this bug happens on certain workloads, and depends on HZ 
value.

Maybe adding a wait_event_timeout() will solve. I'll do some tests here.

-- 
Cheers,
Mauro

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] video-buf redesign

[Mauro Carvalho Chehab]

Em Qua, 2007-09-26 às 22:58 +0200, hermann pitton escreveu:
> Hi,
> 
> Am Mittwoch, den 26.09.2007, 11:25 -0400 schrieb [EMAIL PROTECTED]: 
> > Mauro Carvalho Chehab wrote:
> > >> Unfortunately, I see the same broken behavior in the videobuf tree and
> > >> the tm6000-new tree.  Only the master branch v4l-dvb tree is
> > >> functioning properly.
> > >> 
> > >
> > > Unfortunately, there's nothing I can do without the logs. So, _please_
> > > send the logs also.
> > >
> > > Every test I did here (and also Hermann reports) didn't produce the
> > > issues you're showing. 
> > >
> > > All I get here is clean mpeg streams, with videobuf-dvb and cx88-dvb.
> > >
> > > There is, however, a known issue with IRQ and SMP machines that might be
> > > influencing. So, I need you to do also "cat /proc/cpuinfo". If the
> > > machine you're using to test has more than one CPU core, you may also
> > > need to run irqbalance. Another valuable test would be to disable the
> > > second core, and see what's happening.
> 
> I also conducted the tests only on UP machines on the saa7134 driver.

My tests with cx88-dvb were with dualcore AMD. I noticed some logs,
indicating that irq handling is not fast enough to handle one irq for
every frame buffer. Yet, my machine were capable of not losing any
frames (this happened on both the current videobuf and the newer one).
Probably, if my machine were a little slow, or if the irq where shared
with some other devices, I would lose frames.

I'll re-run the tests disabling the second CPU and with both running,
but without irqbalance. Let's see.

> > I understand that neither you nor Hermann were able to reproduce this 
> > problem, but I assure you, this is indeed a regression, and it's a 
> > show-stopper for 2.6.24 -- it absolutely must be fixed prior to a merge.
> 
> Yes, I agree then. We should be careful with this small testing base we
> have and Mike obviously noticed issues.

Fixing is important.


> Why this happens on his machine with VDR and an additional saa7146
> device, I still don't know. We have also no reports for the new
> video_buf design from saa7146 users.

It may be due to IRQ sharing. If you have two boards receiving
interrupts at the same IRQ line, you may suffer this kind of troubles,
since both drivers will be called, on a serial way, to handle that IRQ
line. This will delay videobuf handling. In this case, a small time
increment at videobuf processing may produce such troubles.

I'm writing a small patch that will reduce a little bit the videobuf
timings. Hopefully, this will fix the issue.
> 
> Just installed the tm6000-new tree on two machines again and xawtv4
> seems to be fine on both, UP, no DVB-T currently, no HD streams.

Thanks, Hermann.
> 
> Cheers,
> Hermann
> 
> 
-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Freecom rev 4 DVB-T USB 2.0 tuner usb id 14aa:0160

[Mauro Carvalho Chehab]

Hi Holger,

> is it that one?
> 
> http://www1.conrad.de/scripts/wgate/zcop_b2c/?~template=pcat_product_details_document&object_guid=F884D044998C7F45E1000A010220&master_guid=&master_typ=&no_brotkrumennavi=&ownrow=6&p_load_area=0417021&p_artikelbilder_mode=Ein&p_sortopt=object_description&page=1&p_catalog_max_results=20&cachedetail=
> 
> And if you download the "datasheet" from there on page 2 it says
> Art.No.EU 27442 ?
> 
> Mauro is currently in Germany for work, not GNU/Linux related, and I
> know every free minutes, he hardly has some, he is working on a driver
> and got PAL-BG working now too, seems there are some issues with the
> buffering left, but good progress so far.

The driver I'm working is for tm5600/6000 chips, that seems to be
present on your device. If I have some time today, I intend to buy
another tm6000 device, if I found a cheap one.

The analog part of the driver is already know to work with NTSC, PAL/BG
and PAL/M (probably, it should work also with other PAL variants). I
still have to figure out a few details for the digital audio part. 

DVB support isn't working fine yet, but this is a matter of time to have
it fixed. Michel Ludwig is working on that part. I hope to have more
contributors soon.
> 
> It is _assumed_ that this device can be supported by that driver too.
> When he is back in Brazil, he probably will enjoy to have further
> feedback from PAL testers.

Yes. It would be really nice if you can help testing with the driver. If
you have programming capabilities, please feel free also to contribute
with the development.

Cheers,
Mauro.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> The reason why there is no single 'format conversion library' that
> everybody uses is because of the large differences between requirements
> for such a thing. The line between 'format conversion' and things such
> as a video codec, or image processing is very vague.

Agreed. What I think it should happen is that the userspace library
should focus at the "weird" codecs. E. g. those which uses some sort of
proprietary format. This way, an userspace app may use the userspace
library as a "fallback method" for unknown FOURCC formats. The result
will be probably far away from an optimal result on some cases (since it
probably mean double buffering), but this will at least allow userspace
apps to work. As performance become an issue, the userspace app
developer may use the GPL code at userspace API as a reference to write
a proper optimized format driver for its apps.

Just my 2 cents.

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [v4l-dvb-maintainer] modpost errors ( Re: 2.6.23-rc6-mm1)

[Mauro Carvalho Chehab]

Applied at my -git tree.

Cheers,
Mauro.

Em Ter, 2007-09-18 às 12:37 -0400, [EMAIL PROTECTED] escreveu:
> Sam Ravnborg wrote:
> > Please cc: relevant people.
> >
> > On Tue, Sep 18, 2007 at 05:43:35PM +0200, Gabriel C wrote:
> >   
> >> Hi,
> >>
> >> I get modpost errors here :
> >>
> >> ...
> >>
> >> ERROR: "dvb_dmx_init" [drivers/media/video/video-buf-dvb.ko] undefined!
> >> ERROR: "dvb_unregister_adapter" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_register_frontend" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_unregister_frontend" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_net_release" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_frontend_detach" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_dmxdev_release" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_dmx_swfilter" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_net_init" [drivers/media/video/video-buf-dvb.ko] undefined!
> >> ERROR: "dvb_dmx_release" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_register_adapter" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> ERROR: "dvb_dmxdev_init" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> >> 
> >
> > dvb issue so dvb added.
> >
> >   
> >> ERROR: "mt2131_attach" [drivers/media/video/cx23885/cx23885.ko]
> undefined!
> >> ERROR: "s5h1409_attach" [drivers/media/video/cx23885/cx23885.ko]
> undefined!
> >> 
> >
> > Was not sure who maintain this stuff..
> > It's not in the git-tree I had around.
> 
> Sam,
> 
> This stuff is in -mm only right now.
> 
> It was a dependency problem, where a new driver (cx23885) is missing the 
> dependency on DVB_CORE.
> 
> The fix is in this changeset:
> 
> http://linuxtv.org/hg/~mkrufky/build-fix/rev/67acaa106a99
> 
> Mauro,
> 
> Please pull from:
> 
> http://linuxtv.org/hg/~mkrufky/build-fix
> 
> for:
> 
> - VIDEO_CX23885 depends on DVB_CORE
> 
>  Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Regards,
> 
> Mike Krufky


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB API update

[Mauro Carvalho Chehab]

Em Ter, 2007-09-18 às 18:33 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:

> > I'm just interested on see things moving forward. Please stop with your
> > flame wars. If you are not interested on serious discussions, you
> > shouldn't have started the thread.
>
> (bla, bla, bla)

If you can't technically argue about DVB API, but just want to play
politics, you don't deserve any attention on that thread.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB API update

[Mauro Carvalho Chehab]

Em Ter, 2007-09-18 às 17:58 +0400, Manu Abraham escreveu:
> Mauro Carvalho Chehab wrote:
> >>>> And I think it would be wrong to delay DVB-S2 support until you
> >>>> have all of DVB-H, DVB-T2, etc. properly hammered out.
> > 
> > I have to agree with Johannes. The current 2.6 development model is
> > based on "Commit earlier and commit often", as stated by Linus.
> > 
> 
> You should be out of your mind. Johannes only stated the one above and
> he alone made the reply for it.
> 
> Moreover you should be just interested in stealing other people's
> credits. Now that many people are complaining on the same.

I'm just interested on see things moving forward. Please stop with your
flame wars. If you are not interested on serious discussions, you
shouldn't have started the thread.

Mauro.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB API update

[Mauro Carvalho Chehab]

> > > And I think it would be wrong to delay DVB-S2 support until you
> > > have all of DVB-H, DVB-T2, etc. properly hammered out.

I have to agree with Johannes. The current 2.6 development model is
based on "Commit earlier and commit often", as stated by Linus.

This means that a big trouble can (and should) be split into smaller
troubles and cleaner solutions.

This also means that the life cycle for adding newer functionalities in
kernel shouldn't take a large amount of time.

If we wait for finishing V4 API to support DVB-S2, some drivers, already
written, should wait, losing their time to market (In fact, they are
already late). I don't see any reason for postponing it more.

On the other hand, userspace API should be forever. So, changes should
be done in a way to avoid breaking binary compatibility with userspace
apps. So, an extra care should be taken to avoid creating APIs that may
need to be changed in a near future. One possible way to try to solve
this dilema is to mark the newer API changes as EXPERIMENTAL, for quite
a few kernel versions.

Anyway, IMO, we should prioritize DVB-S2 and multiple frontend support
(for hybrid DVB-T/DVB-C boards). This doesn't mean that we should forget
the other targets. For example, I'm interested on ARIB extensions, since
we should be working soon on an ISDB-T board for Brazil's market.

Cheers,
Mauro.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

Em Sáb, 2007-09-15 às 16:33 +0200, Markus Rechberger escreveu:
> I'm off for the weekend now so have a nice one :-)

Enjoy your weekend. I really hope that you have some time to reflect and
review your positions during the weekend.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> Everyone knows that there are some issues even some internal
> ones which I'm not part of.

With respect to your kernel-userspace API for xc3028, you made something
that seemed to be a dream: there's a consensus: not a single developer
believed that this is the better way; nobody seems that this is the
better approach.

So, or you are the only media developer with good sense in the face of
the Earth, or you're incapable of understand the obvious: you're wrong
with this approach. IMO, the answer is quite obvious.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> The main discussion in this thread was about drivers in userspace
> are bad because the API will allow binary drivers. 

No. The focus is that userspace API is not needed at all, and the
community believe that this is a regression from all efforts that are
being done by the community to have good quality OSS software.

> The guy
> who works for Hauppauge (again I also have good contacts
> at Hauppauge Europe) writes it's bad - for no technical reason.

Please stop with personal attacks.

> I (again) don't intend to
> release binary drivers. (also keep in mind that ubuntu takes
> everything which makes things work - this matters to the enduser)

Markus, you are thinking that all the community are fool? You used to
state on your website that your intention were to release binary-only
xc5000 drivers. So, please stop with childish and assume what you've
said.

> Mauro is copying the logic of my code and writes I told him I'm ok with
> taking my code without just adding a single line of how his driver
> got developed. (I still wonder why he skipped some significant parts
> of the driver .. because he used the existing one as logic template)
> 
> http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c

The basis for tuner-xc2028 driver is tea5767. The xc2028/xc3028 drivers
is very simple:

a) load the proper firmware;
b) send one 32 bits command to select frequency + the frequency divider.

All the rest is the common logic of a tuner driver.

If you take a look at my driver, you will see that the implementation is
different, providing also those functionalities:

- provides a sync during frequency setting, needed by tm6000;
- has the logic to retrieve signal status;
- part of the firmware need to be reload every time you change a freq
(tm6000 driver needs it);
- supports just the firmwares I've identified as being used by tm6000
driver;

The only thing I used is your usbreplay.pl, as properly stated at
README.first (properly pointing to your site).

Again, please stop with personal attacks. This leads to nowhere.

---

>From my side, I've nacked your userspace tuner.

However, I keep open to accept your kernelspace em28xx/xc3028 drivers,
providing that they fits at the current V4L/DVB core.

Changes at common APIs, and especially at Kernel to userspace API should
be discussed with the community. If you accept this fact, you may also
propose improvements at the APIs.

If, after all that were discussed, you're willing to do a serious work,
please send us the patches for em28xx/xc3028 kernelspace drivers.
Otherwise, I'll kindly ask you to take your own way and stop with those
flamewars.
 
Cheers,
Mauro



___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> Beside that I'm just curious how much did you contribute
> during the last 2 years to the lkml/linux kernel, and how much
> do you want to contribute in future? (also from my side
> talk is cheap (even for me) but getting something done costs
> quite some time and feedback from other people)

Contributing doesn't necessarily means submitting patches. There are
several good guys at the community offering very valuable contributions,
like patchset reviews, good comments, userspace experiences, etc.

Johannes does a very impressive work of maintaining, almost alone,
LinuxTV website, upgrading the system, monitoring disk spaces, taking
backups, etc. Also, he is always available to discuss the most important
changes at APIs and to defend the Open Source community, providing his
very clear point of view.

Thank you, Johannes for all your good work!

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> > There is no reason why the Xceive driver cannot be merged into the
> > current development tree using the hybrid tuner framework as it stands
> > today.
> 
> I'm not convinced this is entirely true. In order to avoid unnecessary
> reinitialisation of the device, the driver needs to know whether the
> device is in analog or digital mode, and I can't see a way of doing it
> with the current API. (I think existing drivers, such as the xc2028
> driver in one branch, use the older analog API and make the digital
> driver a wrapper around it.) Again, I may be missing something.

For sure there are some ways. One dirty way would be to add an static
lock at xc3028 driver. You can rise the lock when firmware is being
uploaded, removing it at the end. This would prevent the troubles you've
mentioned.

A cleaner way would be to create a tasklet for firmware upload. This
will also prevent the driver for a long load time, due to firmware
initialization (a similar change were recently added at ivtv driver).

For sure there are other ways of doing this.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> > - The hybrid tuner support, that where your requirement, when all those
> > discussions started, were already added to the subsystem. So now, an
> > hybrid tuner can be accessed by both DVB and V4L devices;
> >
> 
> It's far more complex as the thing which is implemented there.
> The only thing that has been implemented is that one moduleformat
> can be loaded by the v4l and by the dvb framework nothing else at the
> moment. I told you at the kernel summit about that and I think you
> knew about that before.
> 
> Just to quote some text:
> "Right now, a separate instance of the driver is used for analog /
> digital tuning.  In order to use a single instance, we will have to
> store a pointer to the dvb_frontend structure on the bridge level, but
> there are various other prerequisites that must be dealt with before we
> get to that point.
> 
> We _will_ get there though, eventually."

Maybe it is still not perfect. Feel free to improve it. Several people
from the community, including me, already offered you help to add your
driver, reworking on the 5% of the stuff that aren't compatible with the
V4L/DVB core API design.

> > - Audio standard selection is already possible via S_STD (it is already
> > working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
> > standards should be needed, but hey, we still have 34 bits available at
> > std mask.
> >
> 
> Let me quote some text where you've been in CC and which didn't get
> far enough to get a solution implemented.
> 
> (Michael Schimek)
> 
> "> xc3028_BG_PAL_A2_A.i2c FW_78 > B/G PAL A2
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> > xc3028_BG_PAL_A2_A_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
> > xc3028_BG_PAL_A2_B.i2c FW_78 B/G PAL A2
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> > xc3028_BG_PAL_A2_B_MTS.i2c FW_78_MTS B/G PAL A2 ZWEITON
> 
> > xc3028_BG_PAL_NICAM_A.i2c FW_78 B/G PAL NICAM
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "A"
> > xc3028_BG_PAL_NICAM_A_MTS.i2c FW_78_MTS B/G PAL FM
> > xc3028_BG_PAL_NICAM_B.i2c FW_78 B/G PAL NICAM
> >   Group delay: See RecITU-R BT.470-6 p.21 Response "B"
> > xc3028_BG_PAL_NICAM_B_MTS.i2c FW_78_MTS B/G PAL FM
> 
> We cannot add new standards for each of these files because only six
> bits are unassigned in the lower half of v4l2_std_id. It seems
> unecessary too, please correct me if I'm wrong.
We can use the full 64 bits of v4l2_std_id. We just need to take some
care. 

Due to the lack of __ucmpdi2 on ppc32 architecture, with some gcc
versions, a hack were added at v4l2-common.c, that truncates it to 32
bits, at the function v4l2_norm_to_name():

http://git.kernel.org/?p=linux/kernel/git/mchehab/v4l-dvb.git;a=commit;h=412297d31d439ba56cd4faeb3a49a6f569f40702

So, using more than 32 bits is possible, providing that we change the
implementation of v4l2_norm_to_name() or find a way for it to work with
ppc32.

Instead of just adding a standard for each possible combination, we may
just add bits for the supported audio formats. For example, we can use
the bitmask as:

#define V4L2_STD_AUDIO_NICAM_A  ((v4l2_std_id)0x0400)
#define V4L2_STD_AUDIO_A2_A ((v4l2_std_id)0x0800)

Since for all other chipsets but xc3028, all audio standards are
supported, maybe we can, instead, use a negate bitmap logic for the
non-supported audio standards. Something like:

#define V4L2_STD_AUDIO_NOT_NICAM_A  ((v4l2_std_id)0x0400)
#define V4L2_STD_AUDIO_NOT_A2_A ((v4l2_std_id)0x0800)

And define some macros for the specific standards you need. For example:

#define V4L2_STD_AUDIO_NOT_ALL  V4L2_STD_AUDIO_NOT_A2_A | 
V4L2_STD_AUDIO_NOT_NICAM_A

#define V4L2_STD_PAL_BG_A2  V4L2_STD_PAL_BG | (V4L2_STD_AUDIO_NOT_ALL & 
!V4L2_STD_AUDIO_NOT_A2_A)

This way, V4L2_STD_PAL_BG will mean that this PAL/BG accepts all
possible audio standards (being binary compatible), while
V4L2_STD_PAL_BG_A2_A will mean that only A2 response 'A' audio format is
supported for PAL/BG.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

Markus,

> >
> > Maybe you still don't realize how tiresome it is to talk to you.
> > What you present as "linuxtv people block my contributions" is
> > IMHO "linuxtv people got fed up talking to you". Because when
> > people disagree with you, you keep rambling on and on instead
> > of just accepting it. See, working with an Open source community
> > requires that you don't piss everyone off, but instead find
> > ways to _motivate_ them to help you fix the problems which
> > prevent your code from being merged. When people are doing
> > software development _for fun_, then it should be a _pleasure_
> > for them to work with you, and not a pain in the ass.
> >
> 
> Johannes,
> 
> people do contribute to the em28xx project.
> If noone keeps finding solutions for requirements I will of course
> go on to find my own way.
> Although upcoming and even the current requirements are not met
> by the existing API.
> It's worth nothing to merge what's available now since I'm not even
> ok with how several issues are solved with the driver itself at the
> moment.
> I'm going forward step by step with it now.
> 
> there's also an active and even problem solving oriented ML available:
> http://mcentral.de/pipermail/em28xx/
> 
> Also if you look at the mercurial code you'll see several people
> contributing to that project.

Solutions for your requirements can be reachable via a kernelspace
solution:

- The hybrid tuner support, that where your requirement, when all those
discussions started, were already added to the subsystem. So now, an
hybrid tuner can be accessed by both DVB and V4L devices;

- Audio standard selection is already possible via S_STD (it is already
working for a few standards, like NTSC/M JP and NTSC/M KR). Maybe more
standards should be needed, but hey, we still have 34 bits available at
std mask.

The point is: there's no technical need for userspace. This will just
add userless complexity.

However, you insist with your selfish idea that every other solution,
except the one you're proposing are bogus. This is not the way Open
Source development works. You should listen to people.


Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

Markus,

Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu:
> Following patch adds the possibility to implement tuner drivers in 
> userspace.

As you asked me about userspace driver, at Linux Conf Europe, let me
give you my feedback about it.

On Linux, userspace-to-kernelspace APIs are meant to be forever. This
means that, once a newer API is created, this should remain supported
for all future versions. So, such APIs should be carefully analyzed and
accepted by the community, before going to mainstream.

I don't see any technical reason why tuner drivers should be moved to
userspace. Looking at xc3028 device, the driver is very simple and
doesn't require any special treatment that it isn't possible to be done
at kernel. There are already some implementations on kernelspace that
works fine.

On the other hand, a TV driver without a tuner is a broken driver. With
parts of the driver being at userspace, this means to add undesired
complexity at the drivers architecture, while not bringing any benefit. 

If you look at V4L history, the first drivers started at userspace,
being migrated to kernelspace, where we have the proper scenario for
managing those devices.

Another aspect that should be analyzed is what is desired by the
community: kernelspace tuners or userspace tuners. Keeping support for
both at long term doesn't seem reasonable. The Linux community should
decide what is the better way. Currently, only you are pushing for
userspace tuners, mainly due to non-technical reasons. Almost all the
other developers are comfortable with kernelspace tuners. So, creating
an userspace interface just to make you happy is not the way we should
go.

A final aspect is that having an userspace driver for tuner will mean
that the kernel driver will depend on an userspace counterpart in order
to work. This will allow a vendor with bad intentions to release a
partially broken userspace driver, with limited capabilities, and a
closed source driver for full support. This model is likely to occur, if
you take a look at the past. For example: ATI and Nvidia closed source
drivers, several soft modem drivers, some network drivers, ...

With all those issues, I'm against to add an userspace interface for
tuners.

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Kernelspace floating pointer - was Re: Port of em28xx and xc3028 to new hybrid tuner framework.

[Mauro Carvalho Chehab]

Markus wrote:

> the em28xx uses the userland implementation since the current xceive
> reference drivers use floating point algorithms.

The usage of FP on DVB drivers is something that have been discussed for
quite a long time at the community. I've asked Linus about the
possibility of having a kernelspace driver using floating point. This
may eventually happen (and, in fact, it already happens on a few
drivers). There are, however, two points to consider:

a) care should be taken to preserve FP state by the driver, since kernel
won't do this by itself. This probably means that this may not be so
fast as userspace calculation (although I suspect that it will be faster
enough for the current needs);

b) FP is processor dependent. So, old 80386 processors without FP
instructions shouldn't work (IMO, this is not an issue ). Also, maybe we
may have some troubles on a few non-x86 architectures (ARM ?).

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Port of em28xx and xc3028 to new hybrid tuner framework.

[Mauro Carvalho Chehab]

> > Any suggestions and comments are welcome.
> 
> Please take a look at the xc3028-fe.c file in the following patch:
> 
> http://www.linuxtv.org/~mkrufky/xc-bluebird.patch
> 
> You can use the logic used in that patch to determine ATSC / DVB-T / etc

The tm6000 has a tuner-xc2028 driver that actually works also with
xc3028, for tm6000. It contains both DVB and V4L logic, although yet not
ported to the hybrid driver approach. IMO, shouldn't be hard to port
though.

Cheers,
Mauro.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range

[Mauro Carvalho Chehab]

> This would be easy to do.  There is already a function,
> dvb_frontend_get_frequeny_limits(), that does this.  It prints a warning
> message if neither the demod nor the tuner define a limit.  In this case,
> it returns zero for the max frequency, so any attempt to tune with a driver
> broken like this will fail.  It could easily return ULONG_MAX in this case,
> so tuning would work but there would still be the warning message.

IMO, this seems to be the proper way for handling this. Both tuner and
demod limits are taken into account by this function. It also takes the
minor limits, between demod and tuner. The message may be improved to
ask people to send an e-mail to the maintainers list for a fix to be
applied. Mkrufky added a warning message also asking for report
submission, if a V4L tuner is detected after the maximum expected i2c
range.

Cheers,
Mauro.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range

[Mauro Carvalho Chehab]

> > The limits are comming from the tda10046 info.  I think the correct thing
> > to do here is to not have the tda1004x driver define frequency limits, as
> > it's the tuner that has the limits.
> 
> Nak. You must not remove these limits unless you make sure
> that all tuner drivers which might be attached to this demod
> have non-zero frequency limits.

IMO, the better would be not to initialize frequency ranges at the
demods (since this is tuner stuff). 

If you are afraid of having a tuner driver with improper values, add a
check can be added, at dvb frontend core, to use the maximum allowed
frequency range, if frequency_max is not defined. The better, however,
is to fix the tuner drivers without frequency limits.

Removing the frequency ranges from demods have two advantages:

1) Avoid bogus values at demods;

2) It helps to decrease the BSS size of the module, used initialize
those two variables that are useless at demod context.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Driver for USB ISDB-T 1-Seg

[Mauro Carvalho Chehab]

Hi Patrick,

Em Dom, 2007-08-26 às 18:27 +0200, Patrick Boettcher escreveu:

> Obviously you are from Brasil. What is your current status in your country 
> about DTV?
As Carlos said, the commercial transmissions start at the end of this
year.

>  How much did they modified Japan's ISDB-T implementation? In 
> which flavour it is/will be used in Brasil? Will it be encrypted only? 

The current definitions by the technical committee are not to allow the
usage of encrypted transmissions (apparently, this is the position of
the most relevant broadcasters). However, there are some pressure to
support encryption. AFAIK, the final decision were not taken yet.

The Japanese specs will be used for modulation and streaming. There are
some intentions to use MPEG4 for video encryption, as an option (the
Japanese std currently defines only MPEG2, AFAIK). The remaining changes
for the Brazilian variant are on higher layers, basically focused on
user interactivity. From Kernel driver POV, I doubt that those
differences would be noticeable.

Cheers,
Mauro.


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] add "read_signal_strength" function to dvb_tuner_ops

[Mauro Carvalho Chehab]

Sorry for a late response. I was in transit to participate at Linux Conf
Europe/2007, where I should give a speech about multimidia support on
Linux kernel on this Sunday.

The API seems ok to me. I've added it to v4l-dvb tree.

Guys,

Please test if everything remains correct. Although the patchsets are
not complex, we should take an extra care of testing the affected analog
tuners. From the tests I did up to now, everything seems fine.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

[Mauro Carvalho Chehab]

Hi Michael,

Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu:
> 
> I should review the source code later today.

Ok. Almost everything looked fine to my eyes. 

I have just one comment, about the changesets that added the
MODULE_DESCRIPTION and MODULE_LICENSE macros, like on this changeset:
http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1/rev/ff52de4a4da1

This is required at the moment those files will be converted to modules.
However, as, currently, they are still part of tuner, you shouldn't add
those lines.

On a future changeset where those drivers will be splat, you should also
add MODULE_AUTHOR macro.

So, I have some comments about that future patch:

For tea5767 and tea5761, please add:
MODULE_AUTHOR("Mauro Carvalho Chehab <[EMAIL PROTECTED]>")

For tuner-simple, mt20xx and tda8290, I did some research. Those files
started when Gerd split tuner into smaller drivers, removing tuner.c
file, at -hg changeset 1578:
http://linuxtv.org/hg/v4l-dvb/file/c9083c80e2f0/linux/drivers/media/video/mt20xx.c

Unfortunately, -hg migration didn't preserved the full history (the
tuner.c removal changeset is not there). However, we can see the other
side of the history at CVS:

http://linuxtv.org/cgi-bin/viewcvs.cgi/video4linux/Attic/tuner.c?root=v4l&view=markup

The original module author for tuner.c is marked there as:

MODULE_AUTHOR("Ralph Metzler, Gerd Knorr, Gunther Mayer");

This authorship line were preserved at tuner-core.c.

The splitting work, however, were done by Gerd.

So, IANAL, but, to respect GPL, I can see some ways:

a) Preserve the original tuner.c author at the splat drivers;

b) Add just "Gerd Knorr" to the splat drivers, and adding a comment, at
the header, stating that mt20xx and tuner-simple are splat drivers
originated from tuner.c, originally written by Ralph Metzler, Gerd
Knorr, Gunther Mayer.

c) Ask the authors for their wishes (as both Gerd and Ralph are likely
subscribed at the ML, probably they'll let us know if they opt for an
specific way. I'm not sure if Gunther is subscribed).

For tda8290, maybe Hartmut should also be added, since he reworked some
major parts of the driver logic:

http://linuxtv.org/hg/v4l-dvb/rev/399222ddb2d9

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

[Mauro Carvalho Chehab]

> You say, "there weren't any log messages from tea5767 driver." -- This
> is because the tuner_info line was disabled -- I've re-enabled it just
> now, and push up the changeset.
> 
> Please update your tree and test again -- I believe that the only issue
> here is the missing message from the tea5767 driver -- If you actually
> test radio, I believe that it will work.
> 
> Please test again and get back to me.

I tested it earlier today. All seems fine: the logs and the radio itself
worked as expected. 

I should review the source code later today.

- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

[Mauro Carvalho Chehab]

> >
> > I didn't reviewed yet the tea5767 changes. I expect to do it later this
> > week (maybe today night).
> Thank you -- I appreciate that.

I did just a quick test yesterday. I didn't analyzed the source code
yet. Basically, tea5767 didn't work:

Those are the _normal_ logs from tip:

Linux video capture interface: v2.00
cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
ACPI: PCI Interrupt :05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> 
IRQ 74
cx88[0]: subsystem: :, board: PixelView PlayTV Ultra Pro (Stereo) 
[card=27,insmod option]
cx88[0]: TV tuner type 59, Radio tuner type -1
tveeprom 0-0050: Huh, no eeprom present (err=-121)?
input: cx88 IR (PixelView PlayTV Ultra as /class/input/input7
cx88[0]/0: found at :05:07.0, rev: 5, irq: 74, latency: 32, mmio: 0xc800
tuner 0-0060: TEA5767 detected.
tuner 0-0060: chip found @ 0xc0 (cx88[0])
tuner 0-0060: type set to 62 (Philips TEA5767HN FM Radio)
tuner 0-0061: chip found @ 0xc2 (cx88[0])
tuner 0-0061: type set to 59 (Ymec TVision TVF-5533MF)
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/0: registered device radio0

On this log, tea5767 were correctly autodetected at 0x60 and TVF-5533MF at 0x61.

--

Those are the logs with your patch series applied:

Linux video capture interface: v2.00
cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
ACPI: PCI Interrupt :05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> 
IRQ 74
cx88[0]: subsystem: :, board: PixelView PlayTV Ultra Pro (Stereo) 
[card=27,insmod option]
cx88[0]: TV tuner type 59, Radio tuner type -1
tveeprom 0-0050: Huh, no eeprom present (err=-121)?
input: cx88 IR (PixelView PlayTV Ultra as /class/input/input6
cx88[0]/0: found at :05:07.0, rev: 5, irq: 74, latency: 32, mmio: 0xc800
i2c_adapter i2c-0: sendbytes: error - bailout.
It is not a TEA5767. Received -14 bytes.
tuner 0-0060: chip found @ 0xc0 (cx88[0])
tuner-simple 0-0060: type set to 59 (Ymec TVision TVF-5533MF)
tuner 0-0060: type set to Ymec TVision TVF-5533MF
tuner 0-0061: chip found @ 0xc2 (cx88[0])
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/0: registered device radio0

It seems that I2C reported -EFAULT (-14) to the autoprobe code. Since
tea5767 weren't detected, TVF-5533MF were also missdetected as address
0x60, instead of 0x61.
 

Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

[Mauro Carvalho Chehab]

>  Meanwhile, I 
> do not plan on introducing this idea for many months, probably for 
> 2.6.25 or 2.6.26, maybe 2.6.27... so I would rather not discuss this now 
> -- it is completely irrelevant to the matter at hand.

Agreed.

> When I did my testing of tuner-simple and tda8290 modules, I ran into 
> some OOPS as a result of some simple issue, easily resolved.  As I hit 
> those issues, I was able to take care that the problem would be 
> prevented in all new modules...  If you get an OOPS in your testing of 
> tea5767, just send me the dmesg output -- I'll probably be able to fix 
> it immediately, although I doubt there will be any problem.  Thanks in 
> advance for the testing.

Ok. 

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

[Mauro Carvalho Chehab]

Em Seg, 2007-08-20 às 11:22 -0400, Michael Krufky escreveu:
> Manu Abraham wrote:
> > You will need to handle the IOCTL calls for analog operations some
> > place, whatever you remove.
> >
> > I don't see at any place you are handling the IOCTL's directly in the
> > drivers. So you will be using callbacks from the place where you
> > are applying the ioctl's
> You are getting ahead of things, Manu.  The tuner.ko module will 
> continue to remain as the v4l2 / i2c_client interface to the tuning 
> functionality.

For now, at a first glance, the way it was mapped seems fine. The way
the struct is described, a frontend can handle digital and/or analog
tuning. This seems OK. 

Using void* priv will just create some troubles, since this will avoid
gcc to do typecast checkings for no gain.

>   We do not (yet) have to add these ioctl calls to the 
> card-level drivers, as they will continue to interact with the various 
> tuner modules via tuner.ko's i2c_client interface.
> 
> I do have plans to remove this tuner.ko interface in the future, but 
> that is way way in the future, after most of my planned tuner 
> refactoring work is complete.  There will be a completely separate RFC 
> issued at that time.  When that happens, the card level drivers will 
> include dvb_frontend.h, just as the dvb card drivers do, and access the 
> tuning methods that way, through the dvb_frontend structure.

Removing the common ioctl handling code done by tuner.ko doesn't seem to
be nice, since this would generate overhead on other drivers that will
need to absorb the common tuner handling and probing. However, as
pointed, this should be discussed later, after finishing the tuner
refactoring.

Michael,

I didn't reviewed yet the tea5767 changes. I expect to do it later this
week (maybe today night).
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> Binary releases? Not from myself or Hauppauge. Period. Mark my words, 
> you will not see Hauppauge push binary junk at people just because we 
> want Linux support. That's the kind of thing marketing people like to do 
> and it has no respect within the community.

Acked.

> Besides, who needs all of the binary support headaches.

Binary "supported" Linux driver sucks. You can see all the troubles that
video adapter binary video drivers do. I'm suffering for about one year
expecting a driver that works fine on my notebook (an AMD/ATI X1125). 

The manufacturers generally don't release specs for the FOSS to develop
3D drivers, and provide instead binary only drivers that is a source of
all kind of headaches for the users. So, you have two choices:
a) a good FOSS driver that works fine, well integrated with Xorg, but
lacks several interesting stuff (like 3D);
b) a broken proprietary binary driver that provides all resources, but
are hard to install, require recompiling kernel every time you change
kernel version, and generates all kind of troubles when running
including miscellaneous faults at the applications.

I really don't want this kind of troubles at the subsystem.

Stoth, I'd like to thank you and Hauppauge for all support you're giving
to the FOSS community.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [patch] dvb_net hotplugging support

[Mauro Carvalho Chehab]

Em Ter, 2007-08-14 às 13:54 +0200, Markus Rechberger escreveu:
> Since this didn't get commented here, Trent did that patch already 2
> months ago but it's not included yet. So I recommend to include his
> patch.
> 
> http://article.gmane.org/gmane.linux.kernel/543689
> 
> Acked-by: Markus Rechberger <[EMAIL PROTECTED]>

Trent's patch looks ok. However, he didn't tested with a DVB Net
configuration. Could someone test it and give us a feedback if it works?

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] function for checking if the dvb framework is idle

[Mauro Carvalho Chehab]

> 
> Allthough this patch is still in the queue of required patches. I
> would still like to see that one upstream since it would be required
> by a few drivers for checking if they're really idle.

I agree with Obi, Mkrufky and Christoph. It seems to be better to handle
lock control inside your driver.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] dvb freq out of range

[Mauro Carvalho Chehab]

Em Seg, 2007-08-13 às 00:41 -0400, Michael Krufky escreveu:
> Jonathan Isom wrote:
> > Hi
> > 
> > I just tried today's hg and now i get in dmesg
> > 
> > DVB: frontend 0 frequency 521028615 out of range (86400..86000)
> > DVB: frontend 0 frequency 677028615 out of range (86400..86000)
> 
> Jonathan,
> 
> This is known bug -- the fix is already available, but just hasn't yet been 
> merged into the master repository.
> 
> I suspect Mauro might be away from email right now... Most likely the fix 
> will be merged sometime tomorrow.

Yes. I've committed the pending requests earlier today.
 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-S2 support

[Mauro Carvalho Chehab]

> Why not merge DVB-S support only, into the master branch, so that users of 
> that
> card can use the features of it that are NOT still up in the air?

Receiving the changes splitted into smaller pieces means easier work to
me. I prefer, however, that the DVB-S2 stuff would be into a second
patch, kept into a separated tree. This will make easier to understand
the patch when they arrive at the mainstream. Also, I don't like the
idea of having a patch at the tree depending on some other patch not yet
committed.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Doubt about the file: dvb-usb-dvb.c

[Mauro Carvalho Chehab]

Em Qui, 2007-08-02 às 09:39 +0800, lwtbenben escreveu:
> >a) create a newer dir with your driver: 
> > /linux/drivers/media/dvb/mydriver
> >b) Under /linux/drivers/media/dvb/mydriver:
> > create a Kconfig and a Makefile 
> > You may use another Kconfig/Makefile as example (for example,
> pluto2)
> >c) Add your driver directory at /linux/drivers/media/dvb/Makefile:
> > obj-y := dvb-core/ frontends/ ttpci/ ttusb-dec/ ttusb-budget/ >b2c2/
> bt8xx/ cinergyT2/ dvb-usb/ pluto2/ mydriver/
> >d) Add a source line for your driver
> at /linux/drivers/media/dvb/Kconfig:
> > source "drivers/media/dvb/mydriver/Kconfig"
> >After that, you will be able to use v4l-dvb makefile to compile your
> >driver. With
> > make help
> >you'll see some useful syntax that may help your development.
> 
> Dear Mauro:
> I had my problem solved last week, thank you all the same for clear
> answer.
> And I compile my module in the 2.6.20-15 kernel. 
> Now I want to compile the module in v4l-dvb tree, I did it this way:
> I put my usb adapter program named usb-adapter.c in
> linux/drivers/media/dvb/dvb-usb, and I modified the Makefile and
> Kconfig to add my usb adapter module;
> I put my frontend program named my-frontend.c in
> linux/drivers/media/dvb/frontend and I modified the Makefile and
> Kconfig to add my frontend module;
> But the v4l-dvb tree can't compile.
> There is some problem with the script make_myconfig.pl.
> Do you have any advice about this issue? 

It is very unlikely to have a bug on make_myconfig.pl for such a simple
task. Probably, you didn't selected the newer module with "make
menuconfig".

One alternative to avoid needing to manually select, is to indicate the
minimum kernel version that the module requires. This is done
via /v4/versions.txt file.

-- 
Cheers,
Mauro


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb