Am Dienstag, 15. Mai 2007 17:55 schrieb Markus Rechberger: > On 5/15/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Hi Michael and others, > > > > > I know we've been over this, but I need to state my feelings on the > > > matter, otherwise I would have to simply keep quiet, and that doesn't > > > help the situation for anybody. I _strongly_ feel that the core changes > > > being proposed here will hurt the integrity of the dvb subsystem. > > > > I don't think they will hurt the integrity of the subsystem, but a large > > amount of changes can really affect the driver stability, even being > > trivial changes. Such patch series, if applied, will need acks for the > > active driver maintainers that should make sure this won't break any > > other driver. > > > > I would, instead, use a different approach, without losing the required > > functionalities for xc3028. > > > > To give my $2 cents of contribution, I've sent a modified version of dvb > > integration for xc3028 sometime ago to Markus, as a sugestion. > > > > It should be noticed that I didn't tested the patchset (as currently I > > don't have em288x+xc3028 DVB hardware). If someone wants to take a look, > > the patch series it is available (at quilt format) at: > > http://linuxtv.org/~mchehab/mrec2/ > > > > The required changes on DVB are minimal (just adding a few newer fields > > at frontend core). Also, there's no need to change any stuff on dvb or > > v4l drivers. So, it wouln't break any existing drivers. > > > > The diffstat for the core changes is: > > > > linux/drivers/media/Kconfig | 2 > > linux/drivers/media/Makefile | 1 > > linux/drivers/media/dvb/dvb-core/dvb_frontend.h | 29 ++ > > linux/drivers/media/video/tuner-core.c | 156 ++++++++++++++- > > linux/include/media/tuner.h | 6 > > linux/include/media/v4l2-common.h | 2 > > v4l/Makefile | 4 > > v4l/scripts/gentree.pl | 1 > > > > All API changes on DVB are at the first patch: > > http://linuxtv.org/~mchehab/mrec2/hg_mrec_01.patch > > > > It should be noticed that the comments at the patches may not be correct > > anymore, since I've folded some patches, and modified some API calls on > > Markus original series to be compatible with the way I did the > > integration on DVB frontend. If we go to this path, some work is still > > required. > > > > > I do frown upon code duplication, however, in this case it is a safer > > > alternative to the one currently on the table. Earlier versions of the > > > xc3028 tuner driver were bound to the video4linux tuner.ko module, for > > > the sake of tuning analog television stations. There was a wrapper > > > present inside the em2880-dvb driver that allowed the dvb subsystem to > > > access the xc3028 via tuner.ko. I am not a big fan of this solution, > > > however, it does not touch any core subsystem code. DVB-only devices > > > can use a separate module in order to access the xc3028 without > > > imposing dependencies on the v4l core. > > > > Duplicating a driver is not a solution, just a terrible hack. We should > > focus on a way to use the same tuner driver for both Analog and Digital > > TV. > > If I compare that solution with the solution I provided your one is > only half way done, you add a dependency for a structure which will > never be fully used (only 1 member of dvb_frontend, dvb_tuner_ops will > be used). > > If you look at v4l_dvb_tuner_ops it's clear what it intends to be and > in no way it adds extra struct definitions which do not belong there, > if you look at dvb_frontend in tuner-core.c it has nothing to do with > the tuner, it also contains the callbacks for the digital demod. > > It also requires all the dvb headers. > #include "dvb_frontend.h" > > #include <linux/dvb/frontend.h> > #include "dvbdev.h" > > dvbdev.h is not needed at all either, even if gcc might wipe out the > defined functions because they're not used. > > We shouldn't care about hacks to keep the noise on the ML low, put the > technical aspect (which includes a solution for all the requirements) > infront of everything then I might agree with your patch. > > Markus >
Hi everybody, This is what I found at http://www.bttv-gallery.de. Perhaps this helps to clear up misunderstandings and helps to finish that discussion / thread – original author of the german text is Peter Hettkamp: Point 4: „Data transfer from QSPK-Chip into the PC-Random Access Memory. All further processings are done by relevant software. To enable that the data must be transferred into RAM over the PCI bus. Within the PCTV SAT this is done by the CN878 chip over its audio DMA.“ Well, and now comes the misleading part: „The whole video part of the chip rests functionless during the DVB capture, and can on the contrary be used parallely for recording analog video (SVHS and Composite input) under Linux. The bttv driver is loaded anyhow....... Done by my driver, API does not exist on that.“ Markus Rechberger said on Monday, May 16th, 16:23: „* full support for some Empiatech em28xx based devices (including devicenode locking, eg. if dvb is used it's not possible to use the analogue part and the other way around).“ As both cards are mainly DVB cards (em28xx as Pinnsat as well) I am inclined to say that this statement is simply wrong. And even if a parallel tasking would be technically possible (i. e. capturing DVB video and audio parallely to capturing analogue video) then the question must be posed: Who does this parallely? Who is capturing dvb tv or radio parallely to analogue video without sound? At least I do not. Markus Rechberger said on Monday, May 16th, 16:36: „TUNER_SET_TYPE_ADDR, seems to break with that approach, it's possible to change the tuner type on the fly with it. There have been some devices around which for example use an xc3028 for analogue TV and a qt1010 for DVB-T, so in that case we wouldn't like the xc3028 hybrid tuner module to attach to the DVB part.“ That statement clearly shows that the author of those lines is no way willing to compromise anyway. Just stubborn. Manu Abraham said on Tuesday, May 15th, 13:07: „The reason being manufacturers are more oriented to making DVB devices with Analog as a small add on feature, not that Analog is the main feature on it.“ This is not only correct for my card, but it is simply correct as analogue TV is vanishing more and more as a matter of fact. Analogue TV will die out soon – everybody knows that. So what is wrong in Peter's decription? After one week of testing and patching the cx878 tree we found out that the following statement is simply wrong: „The whole video part of the chip rests functionless during the DVB capture, and can on the contrary be used parallely for recording analog video (SVHS and Composite input) under Linux.“ The truth is in contrast to that: 1. RISC Audio DMA is on PCI Function 1 (i. e. Audio Controller). 2. I2C is on PCI Function 0 (i. e. Video Controller). The approach to fire up the I2C bus on the Audio controller (i. e. RISC DMA engine in this context) will block the RISC engine's work. There needs to be a solution that elegantly handles both PCI functions by one and the same driver, without including v4l 1/2. What does that mean? It means that it is a waste of dependencies / RAM usage to continue carrying along this whole bunch of bttv dependencies consuming some useless 350 kB of RAM for just handling 2 or 3 different I2C functions on PCI Function 0 (i. e. Video controller part). If anybody has a good idea on how to resolve this you are welcome. Cheers Uwe P. S. 1: Hope that this helped a bit to avoid misunderstandings. P. S. 2: Markus would do well by at least trying to divide his work into smaller parts trying to get people involved who's modules are touched to ensure that nothing is being broken. A strong will to compromise would also help. > _______________________________________________ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb _______________________________________________ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
