Re: [linux-dvb] TDA10086 with Pinnacle 400e tuning broken

[Oliver Endriss]

Hartmut Hackmann wrote:
> Hi, all
> 
> I pushed the patch to my personal repository at
> 
>   http://linuxtv.org/hg/~hhackmann/v4l-dvb/
> 
> Do you agree that we should ask Linus to pull it as a bug fix?
> 
> Btw: tda10086 contains a number of coding style violations. I did not
> fix them to keep the patch as small as possible.
> 
> Best regards
>   Hartmut

Hi,

since the patch fixes a regression in kernel 2.6.24, it should be
applied to the 2.6.24 series as soon as possible.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] TDA10086 with Pinnacle 400e tuning broken

[Oliver Endriss]

Hi,

Hartmut Hackmann wrote:
> ...
> So here is the patch that make the the 22kHz tone a config option.
> Please be aware that i have no means to test it, so please report
> 
> Signed-off-by: Hartmut Hackmann <[EMAIL PROTECTED]

Acked-by: Oliver Endriss <[EMAIL PROTECTED]>

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] TT-1401 budget card support broken since 2.6.24-rc6

[Oliver Endriss]

Dirk Brenken wrote:
> Hi,
> I'm running a "budget-only" (Technotrend S-1401) vdr system (1.5.13) 
> with xinelibouput plugin (latest cvs checkout).  It's based on debian 
> sid and it runs fine with kernel 2.6.23.14 ... up to kernel 2.6.24-rc5. 
> After that version, my budget card system stops working ... here some 
> log file stuff:
>
> ...
> 
> The problem also occurs with kernel 2.6.23.14 plus latest v4l-dvb 
> checkout. Any idea how to track down this error? Any help is appreciated!

Could you please check whether patch
http://linuxtv.org/hg/v4l-dvb/rev/816f256c2973
broke the driver?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] "Technotrend TT-budget S1500" PCI card and the [EMAIL PROTECTED] software support.

[Oliver Endriss]

CityK wrote:
> Michael Finch wrote:
> > I was imply try to find out if anyone had a recommendation if I should 
> > use the S-1500 card than the S-1401... I was not complaing that there 
> > is no S-1401 support.
> > Sorry to bother you.
> >
> > 
> >
> > > Date: Sun, 20 Jan 2008 17:16:58 -0500
> > > From: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > CC: [EMAIL PROTECTED]
> > > Subject: Re: "Technotrend TT-budget S1500" PCI card and the 
> > [EMAIL PROTECTED] software support.
> > >
> > > Michael Finch wrote:
> > > > I have noticed that there is significant support for the 
> > "Technotrend TT-budget S1500" PCI card, which I am excited to see. My 
> > question is why is there no such support for the "Technotrend 
> > TT-budget S1401" card. I have a client with a new project that 
> > requires using one of these cards (or something similar). Is the S1500 
> > a better choice?
> > >
> > > Playing the role of the list ogre (yet again):
> > >
> > > a) you're asking on the wrong list. Your questions are in regard to two
> > > DVB-S cards whom have nothing to do with V4L ... try linux-dvb instead
> > >
> > > b) in regards to your question as to "why is there no such support",
> > > I'll ask you to consider from where such support should be derived?
> > > Perhaps you are unaware that there aren't a whole lot of developers
> > > around who write drivers for v4l or dvb devices. So, perhaps the
> > > simpler answer/explanation is this: no developer with any interest in
> > > writing drivers for a device = no support for such device  (which I
> > > suppose a real ogre would have eloquently worded as "support doesn't
> > > magically materialise or grow on trees").
> 
> > I was not complaing that there is no S-1401 support.
> I never took it as a complaint.  I took it at its face value -- a 
> question as to why there is no support for the S-1401
> 
> > I was imply try to find out if anyone had a recommendation if I should 
> > use the S-1500 card than the S-1401
> 
> If you already knew that the S1401 is unsupported, then surely you 
> already knew the answer to that question, else you were seeking a rather 
> one sided recommendation or otherwise...

The DVB-S 1401 is supported:

| $ grep 1401 *.c
| budget.c:   case 0x1018: // TT Budget-S-1401 (philips tda10086/philips 
tda8262)
| budget.c:MAKE_BUDGET_INFO(ttbs1401, "TT-Budget-S-1401 PCI", BUDGET_TT);
| budget.c:   MAKE_EXTENSION_PCI(ttbs1401, 0x13c2, 0x1018),

Simply use the budget driver.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Diseqc and TT 3200-S2

[Oliver Endriss]

Manu Abraham wrote:
> Marco Coli wrote:
> > Remy Bohmer ha scritto:
> >> Hello Marco,
> >>
> >>   
> >>> Can you please post the results of lspci -v  concerning your card? Maybe
> >>> mine has something different.
> >>> Thank you.
> >>>
> >>> My lspci -v follows:
> >>>
> >>> 04:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
> >>> Subsystem: Unknown device 5b2f:1081
> >>> Flags: bus master, medium devsel, latency 32, IRQ 5
> >>> Memory at fddfe000 (32-bit, non-prefetchable) [size=512]
> >>> 
> >> FYI: My TT- S2-3200 has subsystem ID: 13c2:1019
> >> So, there really seems to be different boards under the same name out 
> >> there...
> >>
> >>   
> > well well well, mistery revealed!
> > For the developers: are you already aware of these differences? Do you 
> > need more info? Is support for this board planned?
> 
> Well, it looks like you have a broken EEPROM.
> 0x13c2: 1019 is the ID for the TT S2 3200 and Skystar DVB-S2 H Dcards that 
> i have known.
> 
> Oliver has an EEPROM rewriting application somewhere. I remember him talking
> about it sometime back. Alternatively you can search the archives, for fixing 
> the
> EEPROM.
> 
> (Added CC to Oliver. Maybe he can give you more explanations)

Hm, 5b2f:1081 does not look like a typical overwritten subsystem id.
Usually you see byte combinations with a0/a1/ff. Strange.

Anyway, you can download the tool from
http://escape-edv.de/endriss/dvb/fix_eeprom.c

Please follow the instructions at the beginning of the file.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] SATELCO EasyWatch PCI DVB-T

[Oliver Endriss]

Hi,

looks ok.

Please sign your patch ('Signed-off-by: ...')

The developer of a patch should also receive the credits. ;-)

CU
Oliver

Kim Sandberg wrote:
> Hi.
> 
> Replying to myself.
> 
> Created a simple patch and I got the card working. Seems to work ok
> under vdr with 1h of recording done.
> I got no idea of the names that should be used so just picked something 
> similar.
> 
> ---
> diff -u -r orig.v4l-dvb/linux/drivers/media/dvb/ttpci/budget-av.c
> v4l-dvb/linux/drivers/media/dvb/ttpci/budget-av.c
> --- orig.v4l-dvb/linux/drivers/media/dvb/ttpci/budget-av.c
> 2007-11-23 22:08:25.0 +0200
> +++ v4l-dvb/linux/drivers/media/dvb/ttpci/budget-av.c   2007-11-23
> 21:59:09.0 +0200
> @@ -913,6 +913,7 @@
>  #define SUBID_DVBT_KNC1_PLUS   0x0031
>  #define SUBID_DVBT_KNC10x0030
>  #define SUBID_DVBT_CINERGY1200 0x1157
> +#define SUBID_DVBT_EASYWATCH   0x003a
> 
>  static void frontend_init(struct budget_av *budget_av)
>  {
> @@ -1021,6 +1022,7 @@
> case SUBID_DVBT_KNC1:
> case SUBID_DVBT_KNC1_PLUS:
> case SUBID_DVBT_CINERGY1200:
> +   case SUBID_DVBT_EASYWATCH:
> budget_av->reinitialise_demod = 1;
> fe = dvb_attach(tda10046_attach, &philips_tu1216_config,
>  &budget_av->budget.i2c_adap);
> @@ -1248,6 +1250,7 @@
>  MAKE_BUDGET_INFO(satewps, "Satelco EasyWatch DVB-S", BUDGET_KNC1S);
>  MAKE_BUDGET_INFO(satewplc, "Satelco EasyWatch DVB-C", BUDGET_KNC1CP);
>  MAKE_BUDGET_INFO(satewcmk3, "Satelco EasyWatch DVB-C MK3", BUDGET_KNC1C_MK3);
> +MAKE_BUDGET_INFO(satewt, "Satelco EasyWatch DVB-T", BUDGET_KNC1C_MK3);
>  MAKE_BUDGET_INFO(knc1sp, "KNC1 DVB-S Plus", BUDGET_KNC1SP);
>  MAKE_BUDGET_INFO(knc1cp, "KNC1 DVB-C Plus", BUDGET_KNC1CP);
>  MAKE_BUDGET_INFO(knc1cmk3, "KNC1 DVB-C MK3", BUDGET_KNC1C_MK3);
> @@ -1272,6 +1275,7 @@
> MAKE_EXTENSION_PCI(satewps, 0x1894, 0x001b),
> MAKE_EXTENSION_PCI(satewplc, 0x1894, 0x002a),
> MAKE_EXTENSION_PCI(satewcmk3, 0x1894, 0x002c),
> +   MAKE_EXTENSION_PCI(satewt, 0x1894, 0x003a),
> MAKE_EXTENSION_PCI(knc1c, 0x1894, 0x0020),
> MAKE_EXTENSION_PCI(knc1cp, 0x1894, 0x0021),
> MAKE_EXTENSION_PCI(knc1cmk3, 0x1894, 0x0022),
> 
> 
> 
> 
> > Hi.
> >
> > I bought a Satelco dvb-t card and it doesnt seem to be added to budget 
> > drivers.
> >
> > kudzu -p tells me this:
> >
> > class: CAPTURE
> > bus: PCI
> > detached: 0
> > desc: "Philips Semiconductors SAA7146"
> > vendorId: 1131
> > deviceId: 7146
> > subVendorId: 1894
> > subDeviceId: 003a
> > pciType: 1
> > pcidom:0
> > pcibus:  0
> > pcidev:  a
> > pcifn:  0
> >
> >
> > I couldnt find the 003a device id any of the sources.
> >
> > Any hint what to try as many of the similar cards are working ok.
> >
> > Card info: 
> > http://www.dvbshop.net/product_info.php/info/p312_SATELCO-EasyWatch-PCI-DVB-T--Basic-Edition-.html
> >
> >
> > Br,
> > Kim Sandberg
> >
> 
> ___
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] saa7146 vpeirq

[Oliver Endriss]

Simeon Walker wrote:
> Hi,
> 
> Since upgrading to Ubuntu Gutsy (kernel 2.6.22) I see a lot of these
> messages and the stream is badly corrupted:
> 
> saa7146 (0) vpeirq: used 2 times >80%% of buffer (61476 bytes now)

Basically this message means that the interrupt handler is executed very
late. As a workaround you might try to increase the DMA buffer size
('bufsize' module parameter of budget-core).

> The card is an old Win TV Nova-T.
> 
> Reverting to 2.6.20 is ok but I would like to be able to use the
> latest dvb-usb drivers for another card. I tried yesterdays v4l-dvb
> checkout which showed the same problems.

Hm - did you test the checkout with the 2.6.20 kernel?
(Just to find out whether it is the driver's fault or the kernel's.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Review] Multiproto tree

[Oliver Endriss]

Manu Abraham wrote:
> Oliver Endriss wrote:

> > Card drivers (budget-ci, budget-av)
> > ---
> > I didn't check the details, but the extensions look ok.
> > You might consider whether parts of the stb0899/stb6100 stuff could be
> > factored out into a header file. See bsru6.h for an example.
> > It would reduce the file size, and tables etc could be reused.
> 
> I did visit this, but there result looked thus, the device is not specific to 
> a tuner 
> as it is, and in each of the card configurations, the tables do have some 
> changes
> It depends on the card manufacturer.
> 
> Thinking thus, i thought of moving all the tables to a header where, 
> something 
> such as stb0899_config.h where all the card specific tables are thrown in. 
> This 
> doesn't reduce any of the compiled object size, but it does bring in the 
> advantage
> that budget_ci.c, budget_av.c are not cluttered with large tables.
> 
> What do you think of moving all the config's to a public config file ?

Fine. Imho we should focus on maintainability, not on object size.
Maintainer's time is the most valuable ressource. Having the configs in
a central file makes it easier to reuse the tables and to keep them
in-sync.

Otherwise someone would probably just copy/paste the stuff for a new
driver, as it was done in the ttpci driver family. There are tons of
config tables which should be cleaned up and (possibly) merged.
Due to lack of hardware and/or testers this is nearly impossible now
without risking to break a driver... :-(

> > 
> > 
> > +   /* Legacy   */
> > +   if (fe->legacy) {
> > +   if (fe->ops.set_frontend)
> > +   fe->ops.set_frontend(fe, &fepriv->parameters);
> > +   } else {
> > +// if ((dvbfe_sanity_check(fe) == 0)) {
> > +   /* Superseding  */
> > +   if (fe->ops.set_params)
> > +   fe->ops.set_params(fe, &fepriv->fe_params);
> > +// } else
> > +// return -EINVAL;
> > +   }
> > 
> > Sanity checks should be done in FE_SET_FRONTEND/DVBFE_SET_PARAMS ioctls.
> > (See HG master where I added this some time ago.)
> > Otherwise the application would not see an error status.
> 
> Since you already have a check, i guess i can drop the dvbfe_sanity_check()

Yep. Feel free to add more checks to dvb_frontend_check_parameters().
Atm it only checks the limits of frequency and symbol rate.

> >/* don't actually do anything if we're in the LOSTLOCK state,
> > -* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0 */
> > -   if ((fepriv->state & FESTATE_LOSTLOCK) &&
> > -   (fe->ops.info.caps & FE_CAN_RECOVER) && (fepriv->max_drift == 
> > 0)) {
> > -   dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
> > -   return;
> > +* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0
> > +*/
> > +   /* Legacy   */
> > +   if (fe->legacy) {
> > +   if ((fepriv->state & FESTATE_LOSTLOCK) && 
> > (fepriv->max_drift == 0)) {
> > +   if (fe->ops.get_frontend_algo)
> > +   if (fe->ops.get_frontend_algo(fe) == 
> > DVBFE_ALGO_RECOVERY)
> > +   
> > dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
> > +
> > +   return 0;
> > +   }
> > +   } else {
> > +   if (fepriv->state & FESTATE_LOSTLOCK) {
> > +   if (fe->ops.get_frontend_algo) {
> > +   if ((fe->ops.get_frontend_algo(fe) == 
> > DVBFE_ALGO_RECOVERY) &&
> > +   (fepriv->max_drift == 0)) {
> > +
> > +   
> > dvb_frontend_swzigzag_update_delay(fepriv, s & DVBFE_HAS_LOCK);
> > +   return 0;
> > +   }
> > +   }
> > +   }
> > }
> > 
> > The 'if (fe->legacy)' branch looks broken:
> > fe->ops.get_frontend_algo is most likely zero, so
> > dvb_frontend_swzigzag_update_delay will not be called for old drivers.
> > 
> 
> This one's fixed although i see no usage of FE_CAN_RECOVER which is used in 
> the 
> tree currently, 

Re: [linux-dvb] CAM inserted/used reduces signal and SNR ?

[Oliver Endriss]

Luc Brosens wrote:
> Hi,
> 
> side note :
> the problems in my previous post "KNC1 TV-Station S, revision 0x1894, doesn't 
> tune", were related to the PCI-slots of the motherboard I used
> rebuilt the machine around a new motherboard, both KNC1's are now recognized 
> and able to tune
> lesson learnt : check the hardware before complaining about the software ...

Hm.

> why does inserting and accessing a CAM reduce the signal and SNR levels ? 
> (even if no descrambling is needed, as for BBC World)
> how can this be solved ?
> anyone out there having the same problems ?

I guess that the CAM increases the noise on the power supply planes of
the card. This might affect the tuner. ;-(

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Kernel module crash (divide error)

[Oliver Endriss]

Rutger ter Borg wrote:
> 
> Dear Linux DVB developers,
> 
> I've been trying to get DVB-C working on my system, meanwhile with multiple 
> DVB-C cards (KNC1 and Technotrend budget cards), with their CI counterparts, 
> and Alphacrypt CAM, so far unfortunately without success. In my 
> trial-and-error path I've encountered a possible bug in the linuxtv 
> dvb-drivers. Apparently, it's possible to get accepted by the kernel a symbol 
> rate of zero, causing a divide by zero error. 
> 
> This is valid for (Debian) kernels 2.6.18-4, 2.6.22-3, and 2.6.23-1. 
> 
> $ dvbstream -f 38800 -s 0 -o > test.mpg

This bug has already been fixed in the HG repository some time ago.
The fix will be included in 2.6.24.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Review] Multiproto tree

[Oliver Endriss]

Manu Abraham wrote:
> Oliver Endriss wrote:
> > ...
> > For now I ignored all differences, except for:
> > - frontend.h
> > - dvb_frontend.[ch]
> > - budget-ci.c
> > - budget-av.c
> > 
> > 
> > API extensions (frontend.h)
> > ---
> > looks fine
> > 
> > 
> > Card drivers (budget-ci, budget-av)
> > ---
> > I didn't check the details, but the extensions look ok.
> > You might consider whether parts of the stb0899/stb6100 stuff could be
> > factored out into a header file. See bsru6.h for an example.
> > It would reduce the file size, and tables etc could be reused.
> 
> The tables in some cases can't be reused, but the functions can be, due to 
> the initial cut and paste (tables), both set of tables have some amount of 
> common factor, But still in the end there will be a large common factor 
> altogether.
> 
> Ok, It does make sense to move it out to a common header.

If there are only minor differences, some settings could be moved to the
xxx_config struct. A different approach might use #ifdef blocks within
the header file. One could easily select a configuration by doing

#define xxx_CONFIG_A
#include "xxx.h"

> > dvb-core: dvb_frontend.c
> > 
> > fe->legacy is turned on/off by various ioctls:
> > - FE_SET_FRONTEND, FE_GET_FRONTEND -> 1
> > - DVBFE_SET_PARAMS -> 0/1
> > - DVBFE_GET_PARAMS, DVBFE_GET_DELSYS, DVBFE_GET_INFO -> 0
> > 
> > fe->legacy controls how the frontend thread works.
> > 
> > Since the frontend device can be accessed by multiple readers,
> > fe->legacy might be toggled in funny ways.
> > This might confuse the fe thread or dvb_frontend_add_event. ;-(
> > 
> > Imho ioctls should not set fe->legacy. All parameter conversions should
> > be done within the ioctl. For example:
> > - new driver: FE_SET_FRONTEND converts parms to new driver API
> > - old driver: DVBFE_SET_PARAMS converts parms to old driver API
> > 
> > Then the fe thread can simply use the old driver interface
> > (fe->legacy==1) or the new one (fe->legacy==0).
> 
> What's your thought, if i just checked for the new callbacks and handled the
> legacy "switch", ie: the check occuring in the init, so on an fe_open() the
> legacy switch will be set, depending upon the driver. That way things would 
> be set just before the thread is started and still be independent of any 
> ioctl 
> handling, thereby avoiding the flip-flop case with an ioctl.
> 
> What do you think ?

Doing this in dvb_register_frontend() seems to be the perfect place,
because all callbacks have been set, and fe device/thread do not exist
yet.

> > The error msg should display the offending parameter:
> > Instead of
> > +   printk("%s: Unsupported FEC\n", __func__);
> > you might use
> > +   printk(KERN_ERR "%s: Unsupported FEC %x\n", __func__, 
> > new_fec);
> > (same way for other conversion routines)
> 
> 
> Ok, fine. Better in fact.
>  
>  
> > +   /* Legacy   */
> > +   if (fe->legacy) {
> > +   if (fe->ops.set_frontend)
> > +   fe->ops.set_frontend(fe, &fepriv->parameters);
> > +   } else {
> > +// if ((dvbfe_sanity_check(fe) == 0)) {
> > +   /* Superseding  */
> > +   if (fe->ops.set_params)
> > +   fe->ops.set_params(fe, &fepriv->fe_params);
> > +// } else
> > +// return -EINVAL;
> > +   }
> > 
> > Sanity checks should be done in FE_SET_FRONTEND/DVBFE_SET_PARAMS ioctls.
> > (See HG master where I added this some time ago.)
> > Otherwise the application would not see an error status.
> 
> True, didn't think about returning the error back to the app. Will fix.
>  
> >/* don't actually do anything if we're in the LOSTLOCK state,
> > -* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0 */
> > -   if ((fepriv->state & FESTATE_LOSTLOCK) &&
> > -   (fe->ops.info.caps & FE_CAN_RECOVER) && (fepriv->max_drift == 
> > 0)) {
> > -   dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
> > -   return;
> > +* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0
> > +*/
> > +   /* Legacy   */
> > +   if (fe->

Re: [linux-dvb] Problems with Terratec Cinergy 1200 DVB-T (tda10046_attach())

[Oliver Endriss]

Oliver Haag wrote:
> Hello,
> 
> thanks for your answer.
> I haven't mixed them up, so this shouldn't be the problem.
> One time I compiled the kernel with the modules without adding any 
> modules from v4l-dvb - not working. Next time I unloaded all modules 
> >from the kernel and loaded the ones from v4l-dvb, same thing. I've also 
> tried compiling the kernel without any dvb-modules and adding the ones 
> >from v4l-dvb to keep it really clean and as expected - not working ;)
> 
> Do you have any other idea what's going wrong here?

Iirc there is a problem with older kernels and the symbol_request stuff.

You could try to disable
  [ ]   Load and attach frontend modules as needed
and recompile the driver. Then you must load all frontend drivers
referenced by the driver, not only the one which your card needs.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] KNC1 TV-Station S, revision 0x1894, doesn't tune

[Oliver Endriss]

Luc Brosens wrote:
> hello,
> 
> I've just put two of these card in my machine, and seem to run into the tuner 
> issue described at
> http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_1200_DVB-S_budget/Typhoon/KNC1_DVB-S_budget
> 
> has anybody gotten these cards to work ?
> any pointers on how to get tuning to work ?
> I'm new to dvb-driver development, suggestions on how to get started are 
> welcome too
> 
> below are lspci output, dmesg output and scan output :
> 
> DMESG
> saa7146: register extension 'budget_av'.
> PCI: Setting latency timer of device :00:10.1 to 64
> ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
> ACPI: PCI Interrupt :04:08.0[A] -> Link [APC1] -> GSI 16 (level, low) -> 
> IRQ 16
> saa7146: found saa7146 @ mem c20010606000 (revision 1, irq 16) 
> (0x1894,0x0016).
> saa7146 (0): dma buffer size 192512
> DVB: registering new adapter (KNC TV STAR DVB-S)
> adapter failed MAC signature check
> encoded MAC from EEPROM was 
> ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
> KNC1-0: MAC addr = 00:09:d6:65:9d:14
> DVB: registering frontend 0 (ST STV0299 DVB-S)...
> budget-av: ci interface initialised.

The initialisation of the first card looks ok.

> ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
> ACPI: PCI Interrupt :04:09.0[A] -> Link [APC2] -> GSI 17 (level, low) -> 
> IRQ 17
> saa7146: found saa7146 @ mem c2001061c000 (revision 1, irq 17) 
> (0x1894,0x0016).
> saa7146 (1): dma buffer size 192512
> DVB: registering new adapter (KNC TV STAR DVB-S)
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> Couldn't read from EEPROM: not there?
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> saa7146 (1) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
> KNC1-1: Could not read MAC from KNC1 card
> DVB: registering frontend 1 (ST STV0299 DVB-S)...
> budget-av: ci interface initialised.
> budget-av: cam inserted B
> saa7146: register extension 'dvb'.
> dvb_ca adaptor 1: PC card did not respond  :(
> 
> not all of these messages seem positive, should I worry ?

Yes. The second card does not work properly (I2C bus errors).

> SCAN
> silverstar:/home/myth # scan -vvv -a 1 /usr/share/dvb/dvb-s/Astra-19.2E
> scanning /usr/share/dvb/dvb-s/Astra-19.2E
> using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
> initial transponder 12551500 V 2200 5
> >>> >>> tune to: 12551:v:0:22000
> DiSEqC: switch pos 0, 13V, hiband (index 2)
> diseqc_send_msg:56: DiSEqC: e0 10 38 f1 00 00
> DVB-S IF freq is 1951500
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x03
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x03
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> WARNING: >>> tuning failed!!!
> >>> >>> tune to: 12551:v:0:22000 (tuning failed)
> DiSEqC: switch pos 0, 13V, hiband (index 2)
> diseqc_send_msg:56: DiSEqC: e0 10 38 f1 00 00
> DVB-S IF freq is 1951500
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x01
> >>> >>> tuning status == 0x01
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> >>> >>> tuning status == 0x02
> WARNING: >>> tuning failed!!!
> ERROR: initial tuning failed
> dumping lists (0 services)
> Done.

scan works with the first card ('-a 0'), correct?

> the signal from the satellite is fine, have been using a settop box for 
> several months
> a Skystar 2 card in the same machine scanned successfully and gave access to 
> the FTA channels
> 
> I'm using OpenSUSE 10.3, kernel version 2.6.22.12, dvb archive 816f256c2973 
> (downloaded it yesterday)

Swap the cards.
- If the errors moves to saa7146(0), the card might be broken.
- If the errors still come from saa7146(1), try a different PCI slot.
  (I2C errors might be caused by noise on power supply lines.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Problems with Terratec Cinergy 1200 DVB-T (tda10046_attach())

[Oliver Endriss]

Oliver Haag wrote:
> Hi,
> 
> I've bought the Terratec Cinergy 1200 DVB-T and have problems to get it 
> running.
> 
> I'm using Kubuntu Gutsy (amd64) with the 2.6.23.1 vanilla kernel (The 
> official kernel in the repos is very very buggy, so I don't want to try 
> it out there). Tried adding the modules in menuconfig and building them 
> as described here 
> http://www.linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers 
> too. I always get the same error in dmesg:
> 
> saa7146: register extension 'budget_av'.
> ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 18
> ACPI: PCI Interrupt :01:00.0[A] -> Link [LNKA] -> GSI 18 (level, 
> low) -> IRQ
>  18
> saa7146: found saa7146 @ mem c2aaec00 (revision 1, irq 18) 
> (0x153b,0x115
> 7).
> saa7146 (0): dma buffer size 192512
> DVB: registering new adapter (Terratec Cinergy 1200 DVB-T)
> adapter failed MAC signature check
> encoded MAC from EEPROM was 
> ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:f
> f:ff:ff
> bttv: driver version 0.9.17 loaded
> bttv: using 8 buffers with 2080k (520 pages) each for capture
> nvidia: module license 'NVIDIA' taints kernel.
> KNC1-0: MAC addr = 00:0a:ac:01:e7:02
> DVB: Unable to find symbol tda10046_attach()

This is the problem. See below.

> budget-av: A frontend driver was not found for device 1131/7146 
> subsystem 153b/1157
> budget-av: ci interface initialised.
> 
> It looks like the tda1004x-module is missing, but it isn't. It's also 
> loaded:
> Module  Size  Used by
> tda1004x   16900  0
> lp 11912  0
> budget_av  21120  0
> saa7146_vv 46912  1 budget_av
> videobuf_dma_sg13444  2 bttv,saa7146_vv
> videobuf_core  17028  3 bttv,saa7146_vv,videobuf_dma_sg
> budget_core11524  1 budget_av
> dvb_core   76116  2 budget_av,budget_core
> videodev   27456  2 bttv,saa7146_vv
> v4l2_common19968  4 bttv,compat_ioctl32,saa7146_vv,videodev
> v4l1_compat13316  3 bttv,saa7146_vv,videodev
> saa714617480  3 budget_av,saa7146_vv,budget_core
> ttpci_eeprom4352  1 budget_core
> 
> The frontend device-node is missing, everything else is there:
> $ ls /dev/dvb/adapter0/
> ca0  demux0  dvr0  net0
> 
> Also installed WinXP to try it out there and it's working fine, so it's 
> no hardware-problem.
> 
> 
> Is this a bug (probably only on amd64 kernels) or am I just too stupid 
> and did forget something?

Please make sure that you do not mix modules from the kernel with
modules from the v4l tree. This may cause all kind of problems.

First unload all modules, then insmod tda1004x and the other modules
from the v4l directory.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

[linux-dvb] [Review] Multiproto tree (was: Re: Future of Multiproto)

[Oliver Endriss]

Hi,

now we had bad weather, and I had some time to review the code. ;-)


General note

Obviously, the multiproto tree has not been updated from master for a
very long time. When merging care must be taken that no regressions flow
back to the main development tree.

For now I ignored all differences, except for:
- frontend.h
- dvb_frontend.[ch]
- budget-ci.c
- budget-av.c


API extensions (frontend.h)
---
looks fine


Card drivers (budget-ci, budget-av)
---
I didn't check the details, but the extensions look ok.
You might consider whether parts of the stb0899/stb6100 stuff could be
factored out into a header file. See bsru6.h for an example.
It would reduce the file size, and tables etc could be reused.


dvb-core: dvb_frontend.c

fe->legacy is turned on/off by various ioctls:
- FE_SET_FRONTEND, FE_GET_FRONTEND -> 1
- DVBFE_SET_PARAMS -> 0/1
- DVBFE_GET_PARAMS, DVBFE_GET_DELSYS, DVBFE_GET_INFO -> 0

fe->legacy controls how the frontend thread works.

Since the frontend device can be accessed by multiple readers,
fe->legacy might be toggled in funny ways.
This might confuse the fe thread or dvb_frontend_add_event. ;-(

Imho ioctls should not set fe->legacy. All parameter conversions should
be done within the ioctl. For example:
- new driver: FE_SET_FRONTEND converts parms to new driver API
- old driver: DVBFE_SET_PARAMS converts parms to old driver API

Then the fe thread can simply use the old driver interface
(fe->legacy==1) or the new one (fe->legacy==0).


The error msg should display the offending parameter:
Instead of
+   printk("%s: Unsupported FEC\n", __func__);
you might use
+   printk(KERN_ERR "%s: Unsupported FEC %x\n", __func__, new_fec);
(same way for other conversion routines)


+   /* Legacy   */
+   if (fe->legacy) {
+   if (fe->ops.set_frontend)
+   fe->ops.set_frontend(fe, &fepriv->parameters);
+   } else {
+// if ((dvbfe_sanity_check(fe) == 0)) {
+   /* Superseding  */
+   if (fe->ops.set_params)
+   fe->ops.set_params(fe, &fepriv->fe_params);
+// } else
+// return -EINVAL;
+   }

Sanity checks should be done in FE_SET_FRONTEND/DVBFE_SET_PARAMS ioctls.
(See HG master where I added this some time ago.)
Otherwise the application would not see an error status.


   /* don't actually do anything if we're in the LOSTLOCK state,
-* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0 */
-   if ((fepriv->state & FESTATE_LOSTLOCK) &&
-   (fe->ops.info.caps & FE_CAN_RECOVER) && (fepriv->max_drift == 0)) {
-   dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
-   return;
+* the frontend is set to FE_CAN_RECOVER, and the max_drift is 0
+*/
+   /* Legacy   */
+   if (fe->legacy) {
+   if ((fepriv->state & FESTATE_LOSTLOCK) && (fepriv->max_drift == 
0)) {
+   if (fe->ops.get_frontend_algo)
+   if (fe->ops.get_frontend_algo(fe) == 
DVBFE_ALGO_RECOVERY)
+   
dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
+
+   return 0;
+   }
+   } else {
+   if (fepriv->state & FESTATE_LOSTLOCK) {
+   if (fe->ops.get_frontend_algo) {
+   if ((fe->ops.get_frontend_algo(fe) == 
DVBFE_ALGO_RECOVERY) &&
+   (fepriv->max_drift == 0)) {
+
+   
dvb_frontend_swzigzag_update_delay(fepriv, s & DVBFE_HAS_LOCK);
+   return 0;
+   }
+   }
+   }
}

The 'if (fe->legacy)' branch looks broken:
fe->ops.get_frontend_algo is most likely zero, so
dvb_frontend_swzigzag_update_delay will not be called for old drivers.


Finally, I did a quick test with this tree, and it worked. ;-)
- dvb-ttpci driver with DVB-S Rev 1.3 (ves1x93)
- budget driver with DVB-S Nova Rev 1.0 (stv0299)
- VDR (using old API)


CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] TT Cynergy 1200 DVB-C Device 1176

[Oliver Endriss]

Thomas Kaiser wrote:
> Hi
> 
> I read this thread 
> http://www.linuxtv.org/pipermail/linux-dvb/2007-February/015663.html but I 
> can 
> not figure out if this card is now supported by linux-dvb?

Should be supported by the budget-av driver.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] stv0297: improvement for qam256 modulated channels

[Oliver Endriss]

[EMAIL PROTECTED] wrote:
> 2007/10/28, e9hack <[EMAIL PROTECTED]>:
> >
> > I've seen two different values for the carrier offset on Windows XP for a
> > TT-C2300. Registers 20/21h
> > are programmed with 3c0a or 3ba4 (carrier offset 6763 or 6718). The value
> > depends on the driver
> > revision. On a TT-C1500, this value is 4000 (carrier offset 7209). It may
> > be possible, that the
> > value is calculated from some other values. I know, that the patch has no
> > effect for some testers.
> > This is the first report with a failure. So it isn't possible to add the
> > patch.
> >
> > In my case, I've some channels in the UHF range with a poor signal
> > strength. Without the patch, I
> > got ber ~3500h and unc >10h. With the patch, I get ber ~b00h and unc 0.
> 
> Sorry, 'carrier offset' should be 'initial demodulation frequency'.

What shall we do with this patch?
I think we cannot apply it right now.

@e9hack:
Could it be that the windows driver tries different settings,
and uses the one with the lowest BER?
(Some kind of zig-zag scan for this parameter.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] tda10021: The value of signal strength depends on the configuration of the agc polarity.

[Oliver Endriss]

Oliver Endriss wrote:
> e9hack wrote:
> > Hi,
> > 
> > the attached patch fixes the increasing of the signal strength value 
> > (higher value = higher signal
> > strength).
> 
> If nobody objects I'll commit this patch.

Committed to HG. Thanks.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] stv0297: The value of the signal strength depends on the configuration of the agc polarity.

[Oliver Endriss]

e9hack wrote:
> Hi,
> 
> the attached patch fixes the increasing of the signal strength value (higher 
> value = higher signal
> strength) and scales the value to the range of 0... The charcteristic 
> itself is wrong. To get
> proper values on a TT-C2300 in the range of 40..60% real signal strength, the 
> values from the patch
> should be divide by two. The attached patch doesn't fix the characteristic.

Committed to HG. Thanks.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] ves1820: increase acquisition range for clock recovery

[Oliver Endriss]

Oliver Endriss wrote:
> @all users of ves1820-based DVB-C cards (FF ttpci, budget),
> 
> please test whether the attached patch has any adverse effects.
> (Tests @vdr-portal did not show any problems yet.)
> 
> It changes the acquisition range for clock recovery from 120 ppm to
> 240ppm. Apparently, some cable providers in Germany are playing with
> their parameters, and the capture range of the ves1820 is too small
> to acquire a lock with the current setting... ;-(
> 
> If nobody complains I will commit this patch next weekend.

Committed to HG.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] tda10021: The ber counting must be reinitialized after reading of the values

[Oliver Endriss]

e9hack wrote:
> Hi,
> 
> the attached patch fixes the not working ber counting of the tda10021 
> frontend.
> 
> - Hartmut

Committed to HG. Thanks.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] saa7146: 'wait_for_debi_done' fixes

[Oliver Endriss]

Oliver Endriss wrote:
> @all users of saa7146-based cards
> 
> (drivers: dvb-ttpci, budget, budget-ci, budget-av)
> 
> Please test whether the attached patch has any negative effects.
> 
> Two fixes for the 'saa7146_wait_for_debi_done' code:
> (a) Timeout did not work when the routine was called with interrupts
> disabled.
> (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
> Seems to be very important on fast machines!
> 
> Based on a patch posted by [EMAIL PROTECTED]
> 
> If nobody complains I will commit this patch next week.

Patch has been committed with slight modifications.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


___
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

[Oliver Endriss]

Mauro Carvalho Chehab wrote:
> 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);
> > }

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

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

It's ok. Currently we don't support those PAL standards in the firmware.

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

Will do so.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] stv0297: improvement for qam256 modulated channels

[Oliver Endriss]

Hi,

Guy Martin wrote:
> On Sat, 27 Oct 2007 08:17:14 +0200
> Oliver Endriss <[EMAIL PROTECTED]> wrote:
> > e9hack wrote:
> > > I did eavesdrop the i2c-bus on the TT-C2300 on windows. The
> > > initialization of the stv0297 is a little bit different. If I
> > > change the value for the initial demodulation frequency, the ber
> > > value is reduced to a fourths.
> > 
> > @all:
> > please test with QAM256 channels and report any problems.
> > 
> > If nobody objects I'll commit this patch.
> 
> This breaks my cablestar. After applying the patch, I cannot lock any
> QAM256 channel.

Thanks for reporting!

Apparently we cannot use 6718 for all cards.
So the patch must be modified...

@TT/Hauppauge DVB-C 2300 users:
Are there any problems with this patch?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] stv0297: improvement for qam256 modulated channels

[Oliver Endriss]

e9hack wrote:
> Hi,
> 
> I did eavesdrop the i2c-bus on the TT-C2300 on windows. The initialization of 
> the stv0297 is a
> little bit different. If I change the value for the initial demodulation 
> frequency, the ber value is
> reduced to a fourths.

@all:
please test with QAM256 channels and report any problems.

If nobody objects I'll commit this patch.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] tda10021: The ber counting must be reinitialized after reading of the values

[Oliver Endriss]

e9hack wrote:
> Hi,
> 
> the attached patch fixes the not working ber counting of the tda10021 
> frontend.

If nobody objects I'll commit this patch.

Thanks
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] tda10021: The value of signal strength depends on the configuration of the agc polarity.

[Oliver Endriss]

e9hack wrote:
> Hi,
> 
> the attached patch fixes the increasing of the signal strength value (higher 
> value = higher signal
> strength).

If nobody objects I'll commit this patch.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] stv0297: The value of the signal strength depends on the configuration of the agc polarity.

[Oliver Endriss]

e9hack wrote:
> Hi,
> 
> the attached patch fixes the increasing of the signal strength value (higher 
> value = higher signal
> strength) and scales the value to the range of 0... The charcteristic 
> itself is wrong. To get
> proper values on a TT-C2300 in the range of 40..60% real signal strength, the 
> values from the patch
> should be divide by two. The attached patch doesn't fix the characteristic.

Does this mean that you have a very high (80-100%) STR with this patch?

Imho we may apply some heuristic to get sane values.

We have 0 <= tmp <= 0x1ff. What about
*strength = (tmp/2) * (tmp/2)"
?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

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

[Oliver Endriss]

Hi,

Marco Schlüßler sent me 2 patches which remove the V4L1 dependencies
from these drivers. Works fine here.

Please test. If nobody complains the patches will be applied.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/

- remove wrong include 

Signed-off-by: Marco Schluessler <[EMAIL PROTECTED]>

diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/include/media/saa7146_vv.h v4l-dvb-7a6fab6d00a0/linux/include/media/saa7146_vv.h
--- v4l-dvb-7a6fab6d00a0_orig/linux/include/media/saa7146_vv.h	2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/include/media/saa7146_vv.h	2007-10-15 21:24:31.0 +0200
@@ -1,7 +1,6 @@
 #ifndef __SAA7146_VV__
 #define __SAA7146_VV__
 
-#include 
 #include 
 #include 
 #include - remove v4l1 code

Signed-off-by: Marco Schluessler <[EMAIL PROTECTED]>

diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/Kconfig v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/Kconfig
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/Kconfig	2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/Kconfig	2007-10-15 21:34:51.0 +0200
@@ -1,6 +1,6 @@
 config DVB_AV7110
 	tristate "AV7110 cards"
-	depends on DVB_CORE && PCI && I2C && VIDEO_V4L1
+	depends on DVB_CORE && PCI && I2C
 	select FW_LOADER if !DVB_AV7110_FIRMWARE
 	select VIDEO_SAA7146_VV
 	select DVB_VES1820 if !DVB_FE_CUSTOMISE
@@ -59,7 +59,7 @@
 
 config DVB_BUDGET
 	tristate "Budget cards"
-	depends on DVB_CORE && PCI && I2C && VIDEO_V4L1
+	depends on DVB_CORE && PCI && I2C
 	select VIDEO_SAA7146
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
 	select DVB_VES1X93 if !DVB_FE_CUSTOMISE
@@ -84,7 +84,7 @@
 
 config DVB_BUDGET_CI
 	tristate "Budget cards with onboard CI connector"
-	depends on DVB_CORE && PCI && I2C && VIDEO_V4L1
+	depends on DVB_CORE && PCI && I2C
 	select VIDEO_SAA7146
 	select DVB_STV0297 if !DVB_FE_CUSTOMISE
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
@@ -106,7 +106,7 @@
 
 config DVB_BUDGET_AV
 	tristate "Budget cards with analog video inputs"
-	depends on DVB_CORE && PCI && I2C && VIDEO_V4L1
+	depends on DVB_CORE && PCI && I2C
 	select VIDEO_SAA7146_VV
 	select DVB_PLL if !DVB_FE_CUSTOMISE
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
@@ -127,7 +127,7 @@
 
 config DVB_BUDGET_PATCH
 	tristate "AV7110 cards with Budget Patch"
-	depends on DVB_CORE && DVB_BUDGET && VIDEO_V4L1
+	depends on DVB_CORE && DVB_BUDGET
 	select DVB_AV7110
 	select DVB_STV0299 if !DVB_FE_CUSTOMISE
 	select DVB_VES1X93 if !DVB_FE_CUSTOMISE
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.c v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.c
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.c	2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.c	2007-10-15 21:32:02.0 +0200
@@ -2595,7 +2595,7 @@
 	mutex_init(&av7110->osd_mutex);
 
 	/* TV standard */
-	av7110->vidmode = tv_standard == 1 ? VIDEO_MODE_NTSC : VIDEO_MODE_PAL;
+	av7110->vidmode = tv_standard == 1 ? AV7110_VIDEO_MODE_NTSC : AV7110_VIDEO_MODE_PAL;
 
 	/* ARM "watchdog" */
 	init_waitqueue_head(&av7110->arm_wait);
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.h v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.h
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110.h	2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110.h	2007-10-15 21:32:30.0 +0200
@@ -50,6 +50,11 @@
 
 enum {AV_PES_STREAM, PS_STREAM, TS_STREAM, PES_STREAM};
 
+enum av7110_video_mode {
+	AV7110_VIDEO_MODE_PAL 	= 0,
+	AV7110_VIDEO_MODE_NTSC	= 1
+};
+
 struct av7110_p2t {
 	u8		  pes[TS_SIZE];
 	u8		  counter;
@@ -182,7 +187,7 @@
 
 	ca_slot_info_t		ci_slot[2];
 
-	int			vidmode;
+	enum av7110_video_mode	vidmode;
 	struct dmxdev		dmxdev;
 	struct dvb_demux	demux;
 
diff -bur v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110_av.c v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110_av.c
--- v4l-dvb-7a6fab6d00a0_orig/linux/drivers/media/dvb/ttpci/av7110_av.c	2007-10-15 21:24:20.0 +0200
+++ v4l-dvb-7a6fab6d00a0/linux/drivers/media/dvb/ttpci/av7110_av.c	2007-10-15 21:32:44.0 +0200
@@ -329,7 +329,7 @@
 	return 0;
 }
 
-int av7110_set_vidmode(struct av7110 *av7110, int mode)
+int av7110_set_vidmode(struct av7110 *av7110, enum av7110_video_mode mode)
 {
 	int ret;
 	dprintk(2, "av7110:%p, \n", av7110);
@@ -348,11 +348,11 @@
 }
 
 
-static int sw2mode[16] = {
-	VIDEO_MODE_PAL, VIDEO_MODE_NTSC, VIDEO_MODE_NTSC, VIDEO_MODE_PAL,
-	VIDEO_MODE_NTSC, VIDEO_MODE_NTSC, VIDEO_MODE_PAL, VIDEO_MODE_NTSC,
-	VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL,
-	VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL, VIDEO_MODE_PAL,
+static enum av7110_video_mode sw2mode[16] = {
+	AV7110_

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

[Oliver Endriss]

Soeren Sonnenburg wrote:
> 
> On Wed, 2007-10-17 at 02:34 +0200, Oliver Endriss wrote:
> > Soeren Sonnenburg wrote:
> > > On Sun, 2007-10-14 at 19:47 +0200, Oliver Endriss wrote:
> > > > Soeren Sonnenburg wrote:
> > > > > On Fri, 2007-10-12 at 02:24 +0200, Oliver Endriss wrote:
> > > > > > Soeren Sonnenburg wrote:
> > > > > > [...]
> > > Well :-) If the tt-1500 turns out to work OK I can just once give
> > the
> > > asus + your isolated patch a last chance before trashing it...
> > 
> > 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).

Thanks for the clarification.

> > (My patch is pointless if you do not run a saa7146-based card.)
> 
> Well but I don't have problems with the saa7146 except for the random
> saa7146_i2c_writeout: timed out waiting for end of xfer which however do
> not seem to cause any harm...

Hm - could you please test whether the patch decreases the number of
saa7146_i2c_writeout messages?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

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

[Oliver Endriss]

Hi,

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

CU
Oliver

--  Forwarded Message  --

Subject: [linux-dvb] [PATCH] Spezial Lifeview DVB-S Card without eeprom
Date: Sunday 14 October 2007 22:12
From: Martin Dauskardt <[EMAIL PROTECTED]>
To: linux-dvb@linuxtv.org

The patch has already been posted in May by Michael Möhle without getting 
attention: http://linuxtv.org/pipermail/linux-dvb/2007-May/018007.html

Several users in the german vdrportal forum use this card, therefore the patch 
is included in my LinVDR kernel package since months.  
To patch should really be included into the hg.

I attach a diff against hg from today. It is still the same patch originally 
written by Ralph Metzler.

Greets,
Martin Dauskardt


---

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/

diff -ur v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-cards.c v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-cards.c
--- v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-cards.c	2007-10-11 14:09:06.0 +0200
+++ v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-cards.c	2007-10-14 17:48:49.0 +0200
@@ -3591,6 +3591,26 @@
 			.tv = 1,
 		}},
 	},
+	[SAA7134_BOARD_LIFEVIEW_DVBS] = {
+		/* LifeView FlyDVB-s */
+		/* Ralph Metzler <[EMAIL PROTECTED]> */
+		.name   = "LifeView FlyDVB-S",
+		.audio_clock= 0x0020,
+		.tuner_type = TUNER_ABSENT,
+		.radio_type = UNSET,
+		.tuner_addr	= ADDR_UNSET,
+		.radio_addr	= ADDR_UNSET,
+		.mpeg   = SAA7134_MPEG_DVB,
+		.inputs = {{
+			.name = name_comp1,	/* Composite input */
+			.vmux = 3,
+			.amux = LINE1,
+		},{
+			.name = name_svideo,	/* S-Video signal on S-Video input */
+			.vmux = 8,
+			.amux = LINE1,
+		}},
+	},	
 };
 
 const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
Nur in v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134: saa7134-cards.c.orig.
diff -ur v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-dvb.c v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-dvb.c
--- v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134-dvb.c	2007-10-11 14:09:06.0 +0200
+++ v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134-dvb.c	2007-10-14 17:48:49.0 +0200
@@ -43,6 +43,8 @@
 #include "tda826x.h"
 #include "tda827x.h"
 #include "isl6421.h"
+#include "tua6100.h"
+#include "stv0299.h"
 
 MODULE_AUTHOR("Gerd Knorr <[EMAIL PROTECTED]> [SuSE Labs]");
 MODULE_LICENSE("GPL");
@@ -839,6 +841,130 @@
 	.demod_address= 0x0a,
 };
 
+/* -- */
+
+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;
+
+	if (params->u.qpsk.symbol_rate < 400)
+		buf[3] |= 1;
+
+	if (params->frequency < 125)
+		buf[3] |= 0;
+	else if (params->frequency < 155)
+		buf[3] |= 0x40;
+	else if (params->frequency < 205)
+		buf[3] |= 0x80;
+	else if (params->frequency < 215)
+		buf[3] |= 0xC0;
+
+	if (fe->ops.i2c_gate_ctrl)
+		fe->ops.i2c_gate_ctrl(fe, 1);
+	if (i2c_transfer(&dev->i2c_adap, &msg, 1) != 1)
+		return -EIO;
+	return 0;
+}
+
+static int lifeview_set_symbol_rate(struct dvb_frontend *fe, u32 srate, u32 ratio)
+{
+	u8 aclk = 0;
+	u8 bclk = 0;
+	u8 m1;
+
+	aclk = 0xb5;
+	if (srate < 200)
+		bclk = 0x86;
+	else if (srate < 500)
+		bclk = 0x89;
+	else if (srate < 1500)
+		bclk = 0x8f;
+	else if (srate < 4500)
+		bclk = 0x95;
+
+	m1 = 0x14;
+	if (srate < 400)
+		m1 = 0x10;
+
+	stv0299_writereg(fe, 0x13, aclk);
+	stv0299_writereg(fe, 0x14, bclk);
+	stv0299_writereg(fe, 0x1f, (ratio >> 16) & 0xff);
+	stv0299_writereg(fe, 0x20, (ratio >> 8) & 0xff);
+	stv0299_writereg(fe, 0x21, (ratio) & 0xf0);
+	stv0299_writereg(fe, 0x0f, 0x80 | m1);
+
+	return 0;
+}
+
+static u8 lifeview_inittab[] = {
+	0x01, 0x15,
+	0x02, 0x30,
+	0x03, 0x00,
+	0x04, 0x7d,		/* F22FR = 0x7d, F22 = f_VCO / 128 / 0x7d = 22 kHz */
+	0x05, 0x35,		/* I2CT = 0, SCLT = 1, SDAT = 1 */
+	0x06, 0x40,		/* DAC not used, set to high impendance mode */
+	0x07, 0x00,		/* DAC LSB */
+	0x08, 0x40,		/* DiSEqC off */
+	0x09, 0x00,		/* FIFO */
+	0x0c, 0x51,		/* OP1 ctl = Normal, OP1 val = 1 (LNB Power

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

[Oliver Endriss]

Soeren Sonnenburg wrote:
> On Sun, 2007-10-14 at 19:47 +0200, Oliver Endriss wrote:
> > Soeren Sonnenburg wrote:
> > > On Fri, 2007-10-12 at 02:24 +0200, Oliver Endriss wrote:
> > > > Soeren Sonnenburg wrote:
> > > > > I am unfortunately 100% sure that it is caused by the saa7146 driver, 
> > > > > as
> > > > > I have an uptime of over a week now that it is not loaded (but the 
> > > > > card
> > > > > is still in the slot, yeah and I did memory tests for 18 passes -
> > > > > nothing).
> > > > 
> > > > Could you please try the patch posted in
> > > > http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html
> > > > 
> > > > and report whether it fixes your problem?
> > > 
> > > Hmmhh, reading what it changes
> > > 
> > > "Two fixes for the 'saa7146_wait_for_debi_done' code:
> > > (a) Timeout did not work when the routine was called with interrupts
> > > disabled.
> > > (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
> > > Seems to be very important on fast machines!"
> > > 
> > > I am not sure why this could fix the problems I am seeing. I can give it
> > > a try if you are quite confident that it could help
> > 
> > High load on the PCI bus might trigger a bug somewhere else.
> > Btw, I'm not aware of any reports that the saa7146 driver caused memory
> > corruption or something like that.
> 
> Well it could be a bug in the asus p7131 firmware and the card just
> randomly doing weird things... and if this can be seen only after a few
> days of vdr/continuous use not many people may be affected and you may
> just not get reports.
> 
> > > , but I get 
> > > 
> > > - gcc compile failures
> > > - filesystem corruptions
> > > - database corruptions
> > 
> > Hm. Very often these symptoms are caused by broken hardware.
> 
> I know. But as this machine has uptimes of months without this card
> (even with several pci slots in use and worked for long long times with
> very different cards in these slots) and it does not work when I just
> use the card instead of a win-tv or so I am sure that it is the the asus
> card which is not working correctly.
> 
> Anyway I am now replacing that card with a tt-1500-t lets see whether
> strange things will happen or not.
> 
> > > when the card's driver is loaded and is in use for a few days (and then
> > > finally a hang/crash+reboot). I have the *feeling* that the situation
> > > improved slightly by improving reception via F-connectors, so I thing
> > > there is some kind of buffer overflow or so occurring...
> > > 
> > > Anyway thanks for your work, I will happily try it if you think it may
> > > fix this problem.
> > 
> > I would try. ;-)
> 
> Well :-) If the tt-1500 turns out to work OK I can just once give the
> asus + your isolated patch a last chance before trashing it...

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?

(My patch is pointless if you do not run a saa7146-based card.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Common interface on Technotrend S-1500 broken in v4l-dvb?

[Oliver Endriss]

P. van Gaans wrote:
> On 10/14/2007 07:54 PM, Oliver Endriss wrote:
> > Oliver Endriss wrote:
> >> P. van Gaans wrote:
> >>> On 10/14/2007 12:11 AM, Oliver Endriss wrote:
> >>>> P. van Gaans wrote:
> >>>>> Today I was testing some stuff and downloaded and installed the newest 
> >>>>> v4l-dvb from hg. After a while I figured out that FTA channels on my TT 
> >>>>> S-1500 still worked, but the CAM would not respond. I checked all 
> >>>>> connections, re-inserted the CAM, reboot the computer but nothing would 
> >>>>> help. My CI daughterboard version is 1.1 and I bought this S-1500 end 
> >>>>> of 
> >>>>> august 2007. I use Ubuntu 7.04 with kernel 2.6.20-16-generic.
> >>>>>
> >>>>> After installing a somewhat older version of v4l-dvb I luckily had left 
> >>>>> on my harddisk, the common interface directly came back to life.
> >>>> Could you please try to find out which changeset broke the code?
> >>>>
> >>>> If you have a current HG checkout, you can update the driver to a given
> >>>> version using 'hg update '.
> >>>>
> >>>>> Maybe I just did something wrong somewhere, but would it be possible 
> >>>>> some big change was made to the way the S-1500 handles the CI that 
> >>>>> could 
> >>>>> have broken it?
> >>>> It's probably a change in budget-ci.c or dvb_ca_en50221.c
> >>>>
> >>>> Just an educated guess:
> >>>> Did   http://linuxtv.org/hg/v4l-dvb/rev/b0a3a9b43d60
> >>>> break the code? -> 'hg update 6279'
> >>>>
> >>>> CU
> >>>> Oliver
> >>>>
> >>> 6279 does not compile.
> >>>
> >>> make -C /home/wn/v4l-dvb/v4l
> >>> make[1]: Entering directory `/home/wn/v4l-dvb/v4l'
> >>> perl scripts/make_config_compat.pl /lib/modules/2.6.20-16-generic/source
> >>> ./.myconfig ./config-compat.h
> >>> File not found:
> >>> /lib/modules/2.6.20-16-generic/source/include/linux/netdevice.h at
> >>> scripts/make_config_compat.pl line 15.
> >>> make[1]: *** [config-compat.h] Error 2
> >>> make[1]: Leaving directory `/home/wn/v4l-dvb/v4l'
> >>> make: *** [all] Error 2
> >>>
> >>> After trying a bit I figured out 6266 does compile. Everything between
> >>> 6279 and 6266 does not. I can tell you that with 6266, the common 
> >>> interface works, I hope that's enough info.
> >> Now I have a confirmation from Marco Schluessler that changeset
> >>   http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60
> >> broke CI support.
> >>
> >> For now simply revert this changeset.
> >> Save http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60 to a file.
> >> Then use 'patch -p1 -R < file' to revert the changeset.
> > 
> > Marco sent me the attached patch which should fix the problem.
> > Please test.
> > 
> > CU
> > Oliver
> > 
> > 
> > 
> > 
> > 
> > - "while (!ca->wakeup)" breaks the CAM initialisation
> > 
> > Signed-off-by: Marco Schluessler <[EMAIL PROTECTED]>
> > 
> > diff -bur 
> > v4l-dvb-ea93c93f1547_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c 
> > v4l-dvb-ea93c93f1547/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
> > --- 
> > v4l-dvb-ea93c93f1547_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c 
> > 2007-10-14 13:19:25.0 +0200
> > +++ v4l-dvb-ea93c93f1547/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c  
> > 2007-10-14 18:37:15.0 +0200
> > @@ -973,7 +973,7 @@
> > /* main loop */
> > while (!kthread_should_stop()) {
> > /* sleep for a bit */
> > -   while (!ca->wakeup) {
> > +   if (!ca->wakeup) {
> > set_current_state(TASK_INTERRUPTIBLE);
> > schedule_timeout(ca->delay);
> > if (kthread_should_stop())
> > 
> > 
> > 
> > 
> > ___
> > linux-dvb mailing list
> > linux-dvb@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 
> I wanted to test it but just downloaded the latest v4l-dvb and see the 
> patch is already applied. Common interface works with latest v4l-dvb 
> (oct 16 2007).

Correct, the patch has already been applied.

Thanks for testing!

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Technotrend DVB-T 1200 rev 1.2 does not tune/work

[Oliver Endriss]

Soeren Sonnenburg wrote:
> On Sun, 2007-10-14 at 18:53 +0200, Oliver Endriss wrote:
> > Soeren Sonnenburg wrote:
> > > On Sun, 2007-10-14 at 16:03 +0200, Oliver Endriss wrote:
> > > > Soeren Sonnenburg wrote:
> > > > > On Sat, 2007-10-13 at 23:52 +0200, Oliver Endriss wrote:
> > > > > > Soeren Sonnenburg wrote:
> > > > > > > Dear all,
> > > > > > > [...]
> > > > > > Did this card ever work before?
> > > > > 
> > > > > I just purchased it, so I cannot tell whether it ever worked with 
> > > > > linux.
> > > > > However the guy from whom I got the card claimed that it works w/
> > > > > windows.
> > > > 
> > > > Please try it with windows. Then we will know whether it is ok or not.
> > > 
> > > The problem is that I do not easily have access to a windows machine. Is
> > > there anything I can do to test whether it is OK without windows?
> > > 
> > > ...
> > >
> > > I mean the problem is, that the frontend registers and loads the sp8870
> > > firmware, but I have no idea whether that is the right one or not (it
> > > does not want the grundig frontend however)...
> > 
> > Afaik there are only those two frontends for DVB-T FF cards.
> 
> OK.
> 
> > > When I scan it does not find any channel and using a channel list
> > > obtained via a budget tt card, it still does not want to tune to any
> > > channel there...
> > > 
> > > Any ideas? I mean not that because the card is considered dvb-s some
> > > potentially wrong dvb-s settings are set somewhere?!
> > 
> > Afaics you did everything which could be done.
> > The frontend was detected. Basically the card should work.
> > (I assume that there are no tuning-related error messages in the log.)
> 
> no, nothing.
> 
> > Next you have to find out whether the card is broken or not.
> > >From your results I guess something is broken, but you can only be sure
> > if you test it with the windows driver. (There is a small chance that it
> > is a card variant which is not supported yet.)
> 
> OK, I convinced someone to try the card under windows and well scanning
> worked, for all the expected channels and we could tune... So the card
> works. And we used that old tt_Premium_217g.zip driver... so I guess it
> should work with linux too...
> 
> However also under windows it said dvb-s although we could load the
> driver.

Ok, the card works. There are two possibilities:
- The frontend driver is broken.
- The card is somehow different from those supported by the driver,
  and a special handling is required.

@all:
Can someone confirm that the current dvb-ttpci driver works for DVB-T
FF cards (ALPS TDLB7 tuner, sp8870-based)?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] [Patch] saa7146: 'wait_for_debi_done' fixes

[Oliver Endriss]

Tomi Orava wrote:
> 
> > Tomi Orava schrieb:
> >> I tried your patch and for me it resulted the following constant
> >> complaints:
> >>
> >> saa7146 (0): saa7146_wait_for_debi_done_sleep timed out while waiting
> >> for
> >> transfer completion
> >> saa7146 (0): saa7146_wait_for_debi_done_sleep timed out while waiting
> >> for
> >> transfer completion
> >> saa7146 (0): saa7146_wait_for_debi_done_sleep timed out while waiting
> >> for
> >> transfer completion
> >>
> >> The above complaint started as soon MythBackend started hopping from
> >> channel to channel and gathering EIT-information. These messages came
> >> every once couple of minutes until I stopped the test run.
> >
> > Oliver did changed two DEB_S() to printk. If you replace the DEB_S() with
> > printk (or enable debug
> > output) in saa7146_wait_for_debi_done() within a clean tree, probably you
> > will get the same messages.
> 
> You are correct. I do get the same message if I change the DEB_S to printk
> for a test run. Any ideas how to modify the system/settings not to error
> all the time
> (and I don't mean the actual error message) ? Somehow I think that this
> machine should finally be capable of handling all three DVB-C cards
> without hicups
> (AMD X2 5600, asus crosshair etc etc).

AFAICS the budget-av driver is triggering the log messages.
Is a CI connected to the Satelco EasyWatch DVB-C MK3?

If not I guess that the DEBI timeouts are normal because there is no
hardware connected to the debi bus. In this case I'd have to revert the
code to 'DEBI_S' because those timeouts are normal. ;-(

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Common interface on Technotrend S-1500 broken in v4l-dvb?

[Oliver Endriss]

Oliver Endriss wrote:
> P. van Gaans wrote:
> > On 10/14/2007 12:11 AM, Oliver Endriss wrote:
> > > P. van Gaans wrote:
> > >> Today I was testing some stuff and downloaded and installed the newest 
> > >> v4l-dvb from hg. After a while I figured out that FTA channels on my TT 
> > >> S-1500 still worked, but the CAM would not respond. I checked all 
> > >> connections, re-inserted the CAM, reboot the computer but nothing would 
> > >> help. My CI daughterboard version is 1.1 and I bought this S-1500 end of 
> > >> august 2007. I use Ubuntu 7.04 with kernel 2.6.20-16-generic.
> > >>
> > >> After installing a somewhat older version of v4l-dvb I luckily had left 
> > >> on my harddisk, the common interface directly came back to life.
> > > 
> > > Could you please try to find out which changeset broke the code?
> > > 
> > > If you have a current HG checkout, you can update the driver to a given
> > > version using 'hg update '.
> > > 
> > >> Maybe I just did something wrong somewhere, but would it be possible 
> > >> some big change was made to the way the S-1500 handles the CI that could 
> > >> have broken it?
> > > 
> > > It's probably a change in budget-ci.c or dvb_ca_en50221.c
> > > 
> > > Just an educated guess:
> > > Did   http://linuxtv.org/hg/v4l-dvb/rev/b0a3a9b43d60
> > > break the code? -> 'hg update 6279'
> > > 
> > > CU
> > > Oliver
> > > 
> > 
> > 6279 does not compile.
> > 
> > make -C /home/wn/v4l-dvb/v4l
> > make[1]: Entering directory `/home/wn/v4l-dvb/v4l'
> > perl scripts/make_config_compat.pl /lib/modules/2.6.20-16-generic/source
> > ./.myconfig ./config-compat.h
> > File not found:
> > /lib/modules/2.6.20-16-generic/source/include/linux/netdevice.h at
> > scripts/make_config_compat.pl line 15.
> > make[1]: *** [config-compat.h] Error 2
> > make[1]: Leaving directory `/home/wn/v4l-dvb/v4l'
> > make: *** [all] Error 2
> > 
> > After trying a bit I figured out 6266 does compile. Everything between
> > 6279 and 6266 does not. I can tell you that with 6266, the common 
> > interface works, I hope that's enough info.
> 
> Now I have a confirmation from Marco Schluessler that changeset
>   http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60
> broke CI support.
> 
> For now simply revert this changeset.
> Save http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60 to a file.
> Then use 'patch -p1 -R < file' to revert the changeset.

Marco sent me the attached patch which should fix the problem.
Please test.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/

- "while (!ca->wakeup)" breaks the CAM initialisation

Signed-off-by: Marco Schluessler <[EMAIL PROTECTED]>

diff -bur v4l-dvb-ea93c93f1547_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c v4l-dvb-ea93c93f1547/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
--- v4l-dvb-ea93c93f1547_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	2007-10-14 13:19:25.0 +0200
+++ v4l-dvb-ea93c93f1547/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	2007-10-14 18:37:15.0 +0200
@@ -973,7 +973,7 @@
 	/* main loop */
 	while (!kthread_should_stop()) {
 		/* sleep for a bit */
-		while (!ca->wakeup) {
+		if (!ca->wakeup) {
 			set_current_state(TASK_INTERRUPTIBLE);
 			schedule_timeout(ca->delay);
 			if (kthread_should_stop())
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Future of Multiproto

[Oliver Endriss]

Manu Abraham wrote:
> Oliver Endriss wrote:
> > @all,
> > I suggest the following:
> > 
> > 1a Review the API extensions (dvb_frontend.h).
> > 1b Commit them.
> > 
> > 2a Review dvb_core modifications.
> > 2b Commit them.
> > 
> > 3 Commit drivers when they are ready for inclusion.
> >
> 
> Will appreciate if you will do a review on this tree.
> 
> http://jusst.de/hg/multiproto/
> 
> The tree is not very clean though, with regards to CodingStyle etc. 
> If it looks fine, i will do the cleanups.

I'll try to find some time this week.

CU
Oliver


-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


___
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?)

[Oliver Endriss]

Soeren Sonnenburg wrote:
> On Fri, 2007-10-12 at 02:24 +0200, Oliver Endriss wrote:
> > Soeren Sonnenburg wrote:
> > > I am unfortunately 100% sure that it is caused by the saa7146 driver, as
> > > I have an uptime of over a week now that it is not loaded (but the card
> > > is still in the slot, yeah and I did memory tests for 18 passes -
> > > nothing).
> > 
> > Could you please try the patch posted in
> > http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html
> > 
> > and report whether it fixes your problem?
> 
> Hmmhh, reading what it changes
> 
> "Two fixes for the 'saa7146_wait_for_debi_done' code:
> (a) Timeout did not work when the routine was called with interrupts
> disabled.
> (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
> Seems to be very important on fast machines!"
> 
> I am not sure why this could fix the problems I am seeing. I can give it
> a try if you are quite confident that it could help

High load on the PCI bus might trigger a bug somewhere else.
Btw, I'm not aware of any reports that the saa7146 driver caused memory
corruption or something like that.

> , but I get 
> 
> - gcc compile failures
> - filesystem corruptions
> - database corruptions

Hm. Very often these symptoms are caused by broken hardware.

> when the card's driver is loaded and is in use for a few days (and then
> finally a hang/crash+reboot). I have the *feeling* that the situation
> improved slightly by improving reception via F-connectors, so I thing
> there is some kind of buffer overflow or so occurring...
> 
> Anyway thanks for your work, I will happily try it if you think it may
> fix this problem.

I would try. ;-)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Technotrend DVB-T 1200 rev 1.2 does not tune/work

[Oliver Endriss]

Soeren Sonnenburg wrote:
> On Sun, 2007-10-14 at 16:03 +0200, Oliver Endriss wrote:
> > Soeren Sonnenburg wrote:
> > > On Sat, 2007-10-13 at 23:52 +0200, Oliver Endriss wrote:
> > > > Soeren Sonnenburg wrote:
> > > > > Dear all,
> > > > > [...]
> > > > Did this card ever work before?
> > > 
> > > I just purchased it, so I cannot tell whether it ever worked with linux.
> > > However the guy from whom I got the card claimed that it works w/
> > > windows.
> > 
> > Please try it with windows. Then we will know whether it is ok or not.
> 
> The problem is that I do not easily have access to a windows machine. Is
> there anything I can do to test whether it is OK without windows?
> 
> ...
>
> I mean the problem is, that the frontend registers and loads the sp8870
> firmware, but I have no idea whether that is the right one or not (it
> does not want the grundig frontend however)...

Afaik there are only those two frontends for DVB-T FF cards.

> When I scan it does not find any channel and using a channel list
> obtained via a budget tt card, it still does not want to tune to any
> channel there...
> 
> Any ideas? I mean not that because the card is considered dvb-s some
> potentially wrong dvb-s settings are set somewhere?!

Afaics you did everything which could be done.
The frontend was detected. Basically the card should work.
(I assume that there are no tuning-related error messages in the log.)

Next you have to find out whether the card is broken or not.
>From your results I guess something is broken, but you can only be sure
if you test it with the windows driver. (There is a small chance that it
is a card variant which is not supported yet.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Common interface on Technotrend S-1500 broken in v4l-dvb?

[Oliver Endriss]

P. van Gaans wrote:
> On 10/14/2007 12:11 AM, Oliver Endriss wrote:
> > P. van Gaans wrote:
> >> Today I was testing some stuff and downloaded and installed the newest 
> >> v4l-dvb from hg. After a while I figured out that FTA channels on my TT 
> >> S-1500 still worked, but the CAM would not respond. I checked all 
> >> connections, re-inserted the CAM, reboot the computer but nothing would 
> >> help. My CI daughterboard version is 1.1 and I bought this S-1500 end of 
> >> august 2007. I use Ubuntu 7.04 with kernel 2.6.20-16-generic.
> >>
> >> After installing a somewhat older version of v4l-dvb I luckily had left 
> >> on my harddisk, the common interface directly came back to life.
> > 
> > Could you please try to find out which changeset broke the code?
> > 
> > If you have a current HG checkout, you can update the driver to a given
> > version using 'hg update '.
> > 
> >> Maybe I just did something wrong somewhere, but would it be possible 
> >> some big change was made to the way the S-1500 handles the CI that could 
> >> have broken it?
> > 
> > It's probably a change in budget-ci.c or dvb_ca_en50221.c
> > 
> > Just an educated guess:
> > Did   http://linuxtv.org/hg/v4l-dvb/rev/b0a3a9b43d60
> > break the code? -> 'hg update 6279'
> > 
> > CU
> > Oliver
> > 
> 
> 6279 does not compile.
> 
> make -C /home/wn/v4l-dvb/v4l
> make[1]: Entering directory `/home/wn/v4l-dvb/v4l'
> perl scripts/make_config_compat.pl /lib/modules/2.6.20-16-generic/source
> ./.myconfig ./config-compat.h
> File not found:
> /lib/modules/2.6.20-16-generic/source/include/linux/netdevice.h at
> scripts/make_config_compat.pl line 15.
> make[1]: *** [config-compat.h] Error 2
> make[1]: Leaving directory `/home/wn/v4l-dvb/v4l'
> make: *** [all] Error 2
> 
> After trying a bit I figured out 6266 does compile. Everything between
> 6279 and 6266 does not. I can tell you that with 6266, the common 
> interface works, I hope that's enough info.

Now I have a confirmation from Marco Schluessler that changeset
  http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60
broke CI support.

For now simply revert this changeset.
Save http://linuxtv.org/hg/v4l-dvb/raw-rev/b0a3a9b43d60 to a file.
Then use 'patch -p1 -R < file' to revert the changeset.

@Mauro,
Has this changeset ever been tested?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] TT-2300 with IR on CI - not work??

[Oliver Endriss]

Simon Baxter wrote:
> >> It always registers, no matter whether there is an ir receiver or not.
> >
> > oh, ok!
> >
> >>> ...and I've added the little jumper on the CI - but it won't work.
> >>>
> >>> I do a 'tail -f /dev/input/event3' and get nothing when pointing the 
> >>> remote
> >>> at it.
> >>
> >> This will only work if you have loaded a keymap.
> >
> > This isn't something I've done before - always used serial homebrew and 
> > LIRC
> 
> OK - works.  Thanks.
> 
> Some buttons dont work - will work on this 

If you use the remote plugin, let the plugin load its built-in keymap.
Then you don't have to bother about keymaps.
For details have a look into the plugin docs.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Technotrend DVB-T 1200 rev 1.2 does not tune/work

[Oliver Endriss]

Soeren Sonnenburg wrote:
> On Sat, 2007-10-13 at 23:52 +0200, Oliver Endriss wrote:
> > Soeren Sonnenburg wrote:
> > > Dear all,
> > > 
> > > I am having problems with a full featured TT-1200 dvb-t (sometimes also
> > > called technotrend dvb-t premium) card. 
> > > 
> > > It does not find the frontend and if I manually fiddle with the code (I
> > > simply had to remove the break in line 2176 of av7110.c in hg to allow
> > 
> > There is no 'break' on line 2176, should be 2167. (?)
> 
> yes, sorry.
> 
> > > fallthrough) to make it load the Spase SP8870 DVB-T it successfully
> > > registers this frontend and loads the sp8870 firmware but then it still
> > > refuses to tune to any channel...
> > 
> > Did this card ever work before?
> 
> I just purchased it, so I cannot tell whether it ever worked with linux.
> However the guy from whom I got the card claimed that it works w/
> windows.

Please try it with windows. Then we will know whether it is ok or not.

> > > As the card is listed as supported I am a bit confused what is going on
> > > - any ideas? 
> > > 
> > > Soeren
> > > 
> > > Details follow:
> > > 
> > > kernel is 2.6.23.1
> > > 
> > > #lspci
> > > 00:0b.0 0480: 1131:7146 (rev 01)
> > > Subsystem: 13c2:
> > 
> > This sub-system id is normally used by DVB-S cards.
> > Apparently there is one more exception. :-(
> 
> Yes... looks like it is yet another extremely old prototypical variant
> of this card.

I'll add this variant to the driver if (and only if) the card works.

> > > # dmesg
> > >  
> > > dvb-ttpci: info @ card 2: firm f0240009, rtsl b0250018, vid 71010068, app 
> > > 80f12623
> > > dvb-ttpci: firmware @ card 2 supports CI link layer interface
> > > dvb-ttpci: Crystal audio DAC @ card 2 detected
> > > saa7146_vv: saa7146 (2): registered device video1 [v4l2]
> > > saa7146_vv: saa7146 (2): registered device vbi1 [v4l2]
> > > ves1820: ves1820_readreg(): readreg error (reg == 0x1a,ret == -121)
> > > DVB: registering frontend 2 (Spase SP8870 DVB-T)...
> > > input: DVB on-card IR receiver as 
> > > /devices/pci:00/:00:0b.0/input/input9
> > > dvb-ttpci: found av7110-1.
> > > 
> > > hires photo taken of the card or further info on request...
> > 
> > Is this your card?
> > http://vdr-wiki.de/wiki/index.php/DVB-T_full-featured-Karten
> 
> yes, except that the stickers are different, the one on the metal box
> says TDLB7X257A 991006 ALPS and instead of the bar code I have
> TT-DVB-1.2 Ve0034/00
> 
> > Please note that this card is not able to tune to VHF channels!
> 
> Yes, but VHF is only 30 MHz to 300 MHz and according to 
> http://www.telesat-info.de/sat/dvbt/dvbthome.html
> this affects only channel 5 & 7 (FAB/arte).
> 
> So it should not be a problem to tune to 'Das Erste' or so

True.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Future of Multiproto

[Oliver Endriss]

Marcel Siegert wrote:
> can everybody _please_ stop this unnessessary discussion?

Full ack! I'm really tired reading these garbage threads.

@all,
I suggest the following:

1a Review the API extensions (dvb_frontend.h).
1b Commit them.

2a Review dvb_core modifications.
2b Commit them.

3 Commit drivers when they are ready for inclusion.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Common interface on Technotrend S-1500 broken in v4l-dvb?

[Oliver Endriss]

P. van Gaans wrote:
> Today I was testing some stuff and downloaded and installed the newest 
> v4l-dvb from hg. After a while I figured out that FTA channels on my TT 
> S-1500 still worked, but the CAM would not respond. I checked all 
> connections, re-inserted the CAM, reboot the computer but nothing would 
> help. My CI daughterboard version is 1.1 and I bought this S-1500 end of 
> august 2007. I use Ubuntu 7.04 with kernel 2.6.20-16-generic.
> 
> After installing a somewhat older version of v4l-dvb I luckily had left 
> on my harddisk, the common interface directly came back to life.

Could you please try to find out which changeset broke the code?

If you have a current HG checkout, you can update the driver to a given
version using 'hg update '.

> Maybe I just did something wrong somewhere, but would it be possible 
> some big change was made to the way the S-1500 handles the CI that could 
> have broken it?

It's probably a change in budget-ci.c or dvb_ca_en50221.c

Just an educated guess:
Did   http://linuxtv.org/hg/v4l-dvb/rev/b0a3a9b43d60
break the code? -> 'hg update 6279'

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] TT-2300 with IR on CI - not work??

[Oliver Endriss]

Simon Baxter wrote:
> Hi
> 
> I have a new TT-2300 DVB-C FF card with the associated CI module with 
> in-built IR receiver.
> 
> The IR seems to register fine:
> dmesg:
> input: DVB on-card IR receiver as /class/input/input3

It always registers, no matter whether there is an ir receiver or not.

> ...and I've added the little jumper on the CI - but it won't work.
> 
> I do a 'tail -f /dev/input/event3' and get nothing when pointing the remote 
> at it.

This will only work if you have loaded a keymap.

> Similarly get nothing with VDR and the vdr-remote plugin. 
> 
> Any ideas??? 

Is the IR receiver connected to the card or to the CI?

>From remote plugin FAQ:
| 2.2.1 The remote control does not work, if a CI is connected
|   --
| Whenever a CI is connected, the on-board connector will be disabled!
|
| On some CIs there is a jumper to select whether the receiver of the CI
| or the receiver of the FF-card should be used. RTFM.
|
| If not, use the integrated receiver of the CI,
| or connect the receiver to the ir connector of the CI.

Another solution posted by [EMAIL PROTECTED]:
http://www.vdr-portal.de/board/thread.php?postid=652902#post652902
(Remove the 0 Ohm resistor.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Technotrend DVB-T 1200 rev 1.2 does not tune/work

[Oliver Endriss]

Soeren Sonnenburg wrote:
> Dear all,
> 
> I am having problems with a full featured TT-1200 dvb-t (sometimes also
> called technotrend dvb-t premium) card. 
> 
> It does not find the frontend and if I manually fiddle with the code (I
> simply had to remove the break in line 2176 of av7110.c in hg to allow

There is no 'break' on line 2176, should be 2167. (?)

> fallthrough) to make it load the Spase SP8870 DVB-T it successfully
> registers this frontend and loads the sp8870 firmware but then it still
> refuses to tune to any channel...

Did this card ever work before?

> As the card is listed as supported I am a bit confused what is going on
> - any ideas? 
> 
> Soeren
> 
> Details follow:
> 
> kernel is 2.6.23.1
> 
> #lspci
> 00:0b.0 0480: 1131:7146 (rev 01)
> Subsystem: 13c2:

This sub-system id is normally used by DVB-S cards.
Apparently there is one more exception. :-(


> # dmesg
>  
> dvb-ttpci: info @ card 2: firm f0240009, rtsl b0250018, vid 71010068, app 
> 80f12623
> dvb-ttpci: firmware @ card 2 supports CI link layer interface
> dvb-ttpci: Crystal audio DAC @ card 2 detected
> saa7146_vv: saa7146 (2): registered device video1 [v4l2]
> saa7146_vv: saa7146 (2): registered device vbi1 [v4l2]
> ves1820: ves1820_readreg(): readreg error (reg == 0x1a,ret == -121)
> DVB: registering frontend 2 (Spase SP8870 DVB-T)...
> input: DVB on-card IR receiver as 
> /devices/pci:00/:00:0b.0/input/input9
> dvb-ttpci: found av7110-1.
> 
> hires photo taken of the card or further info on request...

Is this your card?
http://vdr-wiki.de/wiki/index.php/DVB-T_full-featured-Karten

Please note that this card is not able to tune to VHF channels!

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


___
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?)

[Oliver Endriss]

Soeren Sonnenburg wrote:
> I am unfortunately 100% sure that it is caused by the saa7146 driver, as
> I have an uptime of over a week now that it is not loaded (but the card
> is still in the slot, yeah and I did memory tests for 18 passes -
> nothing).

Could you please try the patch posted in
http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html

and report whether it fixes your problem?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Re : Re : Re : [Pat ch] saa7146: 'wait_for_debi_done' fixes

[Oliver Endriss]

manu wrote:
> On 10/11/2007 06:41:14 PM, Oliver Endriss wrote:
> > manu wrote:
> > > On 10/10/2007 01:02:46 PM, Oliver Endriss wrote:
> > > > manu wrote:
> > > > > On 10/09/2007 06:15:14 PM, Oliver Endriss wrote:
> > > > > > @all users of saa7146-based cards
> > > > > >
> > > > > > (drivers: dvb-ttpci, budget, budget-ci, budget-av)
> > > > > >
> > > > > > Please test whether the attached patch has any negative
> > effects.
> > > > > >
> > > > > > Two fixes for the 'saa7146_wait_for_debi_done' code:
> > > > > > (a) Timeout did not work when the routine was called with
> > > > interrupts
> > > > > > disabled.
> > > > > > (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
> > > > > > Seems to be very important on fast machines!
> > > > > >
> > > > > > Based on a patch posted by [EMAIL PROTECTED]
> > > > > >
> > > > > > If nobody complains I will commit this patch next week.
> > > > >
> > > > > Well sorry it seems to create an oops on my box. Just to make
> > sure
> > > > > though: it is the first time I compile and load modules from
> > > > mercurial
> > > > > and so could it just be a compatibility problem with my
> > 2.6.20-16
> > > > > Ubuntu Feisty kernel?
> > > >
> > > > Please make sure that you do not mix v4l/dvb modules from the
> > original
> > > > kernel and the HG driver, or you will see all kinds of crashes.
> > > >
> > > > First try the HG driver without my patch. If it works, apply the
> > patch
> > > > and try again.
> > > >
> > >
> > > OK now everything looks identical to the bug I described in a
> > previous
> > > post: this time CAM is OK looking at the logs (though gnutv -cammenu
> > 
> > > seems unresponsive whereas it used to work before, did something
> > > change, should I recompile it?), but dmesg says no driver found for
> > the
> > > frontend...
> > 
> > You do not have to recompile the application.
> > 
> > Just to be sure:
> > There is no difference whether you apply the patch or not.
> > Correct?
> 
> Well at first I thought that no, but it seems that the frontend is  
> found more easily with this patch, whereas it sometimes fails to be  
> loaded with the clean tree. See below.

That's fine. ;-)

> > Are you referring to the thread 'TT S-1500 CI not finding frontend
> > driver'?
> 
> Yes
> 
> > Did the card ever work reliably in this machine?
> > Type of machine? SMP system?
> 
> Via KM400, yes I know, AMD athlon (single core cpu).
> Yes beautifully, but at some point I got a weird error: the cam stopped  
> working (I got a dvb error in dmesg) and I had either to reboot or just  
> eject/reinsert I don't remember now. Since then it has been on and off.  
> And now I get "CAM did not respond" in the logs, even thoughI get the  
> full cam signature in the logs: so my guess is that the CI interface  
> works as it is able to retrieve the module name/signature, but the CAM  
> itself is damaged.
> This leads to my next question: is it possible that the bad CAM induces  
> i2c errors/timeouts leading to the frontend not being found? And in  
> this respect your patch seems to be helpful, as the frontend is, AFAICT  
> always found now.

Hard to tell. The patch reduces I/O load during some kinds of debi
transfers, and the CAM is connected to the debi interface...

> > Did the problem appear after updating the driver?
> 
> Nope
> 
> > I2C bus problems might be caused by a broken power supply or
> > mainboard.
> > You might also try a different pci slot.
> 
> Well the power supply of the beast is certailny not very good, but now  
> I think that th CAM is faulty.

CAM problems are sometimes caused by a broken cable between CI and DVB
card.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Re : Re : [Patch] saa714 6: 'wait_for_debi_done' fixes

[Oliver Endriss]

manu wrote:
> On 10/10/2007 01:02:46 PM, Oliver Endriss wrote:
> > manu wrote:
> > > On 10/09/2007 06:15:14 PM, Oliver Endriss wrote:
> > > > @all users of saa7146-based cards
> > > >
> > > > (drivers: dvb-ttpci, budget, budget-ci, budget-av)
> > > >
> > > > Please test whether the attached patch has any negative effects.
> > > >
> > > > Two fixes for the 'saa7146_wait_for_debi_done' code:
> > > > (a) Timeout did not work when the routine was called with
> > interrupts
> > > > disabled.
> > > > (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
> > > > Seems to be very important on fast machines!
> > > >
> > > > Based on a patch posted by [EMAIL PROTECTED]
> > > >
> > > > If nobody complains I will commit this patch next week.
> > >
> > > Well sorry it seems to create an oops on my box. Just to make sure
> > > though: it is the first time I compile and load modules from
> > mercurial
> > > and so could it just be a compatibility problem with my 2.6.20-16
> > > Ubuntu Feisty kernel?
> > 
> > Please make sure that you do not mix v4l/dvb modules from the original
> > kernel and the HG driver, or you will see all kinds of crashes.
> > 
> > First try the HG driver without my patch. If it works, apply the patch
> > and try again.
> > 
> 
> OK now everything looks identical to the bug I described in a previous  
> post: this time CAM is OK looking at the logs (though gnutv -cammenu  
> seems unresponsive whereas it used to work before, did something  
> change, should I recompile it?), but dmesg says no driver found for the  
> frontend...

You do not have to recompile the application.

Just to be sure:
There is no difference whether you apply the patch or not.
Correct?

Are you referring to the thread 'TT S-1500 CI not finding frontend
driver'?

Did the card ever work reliably in this machine?
Type of machine? SMP system?

Did the problem appear after updating the driver?

I2C bus problems might be caused by a broken power supply or mainboard.
You might also try a different pci slot.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] Re : [Patch] saa7146: 'wa it_for_debi_done' fixes

[Oliver Endriss]

manu wrote:
> On 10/09/2007 06:15:14 PM, Oliver Endriss wrote:
> > @all users of saa7146-based cards
> > 
> > (drivers: dvb-ttpci, budget, budget-ci, budget-av)
> > 
> > Please test whether the attached patch has any negative effects.
> > 
> > Two fixes for the 'saa7146_wait_for_debi_done' code:
> > (a) Timeout did not work when the routine was called with interrupts
> > disabled.
> > (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
> > Seems to be very important on fast machines!
> > 
> > Based on a patch posted by [EMAIL PROTECTED]
> > 
> > If nobody complains I will commit this patch next week.
> 
> Well sorry it seems to create an oops on my box. Just to make sure  
> though: it is the first time I compile and load modules from mercurial  
> and so could it just be a compatibility problem with my 2.6.20-16  
> Ubuntu Feisty kernel?

Please make sure that you do not mix v4l/dvb modules from the original
kernel and the HG driver, or you will see all kinds of crashes.

First try the HG driver without my patch. If it works, apply the patch
and try again.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [linux-dvb] budget-av/CI-interface with SMP

[Oliver Endriss]

Julian Scheel wrote:
> Am Freitag 17 August 2007 04:04 schrieb Oliver Endriss:
> > Same problem as before: Must not sleep within spinlock-ed code.
> >
> > > > If I disable nobusyloop the errors are gone. I will check if the
> > > > CI-module keeps working properly.
> > >
> > > If I disable nobusyloop the system becomes unresponsive after a while
> > > without CAM plugged.
> >
> > Does the machine freeze completely? No error messages on the console?
> 
> It only gets very slow then.
> 
> > Does it work with CAM plugged, or does it freeze, too?
> 
> With CAM plugged it was fine, I think.
> 
> > Please post the patch you are currently using.
> 
> Attached is the patch I use, against Manus latest multiproto tree.
> Should apply with some offset to the official tree, too.

Could you please try the patch posted in
http://linuxtv.org/pipermail/linux-dvb/2007-October/021042.html

Afaics it might fix the underlying problem.

> Sorry for the delay, hadn't had much time last weeks.

Same problem here. ;-(

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

[linux-dvb] [Patch] saa7146: 'wait_for_debi_done' fixes

[Oliver Endriss]

@all users of saa7146-based cards

(drivers: dvb-ttpci, budget, budget-ci, budget-av)

Please test whether the attached patch has any negative effects.

Two fixes for the 'saa7146_wait_for_debi_done' code:
(a) Timeout did not work when the routine was called with interrupts
disabled.
(b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
Seems to be very important on fast machines!

Based on a patch posted by [EMAIL PROTECTED]

If nobody complains I will commit this patch next week.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/

diff -r 54b01562b12d linux/drivers/media/common/saa7146_core.c
--- a/linux/drivers/media/common/saa7146_core.c	Tue Oct 09 22:58:39 2007 +0200
+++ b/linux/drivers/media/common/saa7146_core.c	Tue Oct 09 23:54:20 2007 +0200
@@ -59,41 +59,85 @@ void saa7146_setgpio(struct saa7146_dev 
 }
 
 /* This DEBI code is based on the saa7146 Stradis driver by Nathan Laredo */
-int saa7146_wait_for_debi_done(struct saa7146_dev *dev, int nobusyloop)
-{
-	unsigned long start;
+static inline int saa7146_wait_for_debi_done_sleep(struct saa7146_dev *dev,
+unsigned long us1, unsigned long us2)
+{
+	unsigned long timeout;
 	int err;
 
 	/* wait for registers to be programmed */
-	start = jiffies;
+	timeout = jiffies + usecs_to_jiffies(us1);
 	while (1) {
-		err = time_after(jiffies, start + HZ/20);
+		err = time_after(jiffies, timeout);
 		if (saa7146_read(dev, MC2) & 2)
 			break;
 		if (err) {
-			DEB_S(("timed out while waiting for registers getting programmed\n"));
+			printk(KERN_ERR "%s: %s timed out while waiting for registers getting programmed\n",
+	dev->name, __FUNCTION__);
 			return -ETIMEDOUT;
 		}
-		if (nobusyloop)
-			msleep(1);
+		msleep(1);
 	}
 
 	/* wait for transfer to complete */
-	start = jiffies;
+	timeout = jiffies + usecs_to_jiffies(us2);
 	while (1) {
-		err = time_after(jiffies, start + HZ/4);
+		err = time_after(jiffies, timeout);
 		if (!(saa7146_read(dev, PSR) & SPCI_DEBI_S))
 			break;
 		saa7146_read(dev, MC2);
 		if (err) {
-			DEB_S(("timed out while waiting for transfer completion\n"));
+			printk(KERN_ERR "%s: %s timed out while waiting for transfer completion\n",
+	dev->name, __FUNCTION__);
 			return -ETIMEDOUT;
 		}
-		if (nobusyloop)
-			msleep(1);
+		msleep(1);
 	}
 
 	return 0;
+}
+
+static inline int saa7146_wait_for_debi_done_busyloop(struct saa7146_dev *dev,
+unsigned long us1, unsigned long us2)
+{
+	unsigned long loops;
+
+	/* wait for registers to be programmed */
+	loops = us1;
+	while (1) {
+		if (saa7146_read(dev, MC2) & 2)
+			break;
+		if (!loops--) {
+			printk(KERN_ERR "%s: %s timed out while waiting for registers getting programmed\n",
+	dev->name, __FUNCTION__);
+			return -ETIMEDOUT;
+		}
+		udelay(1);
+	}
+
+	/* wait for transfer to complete */
+	loops = us2 / 5;
+	while (1) {
+		if (!(saa7146_read(dev, PSR) & SPCI_DEBI_S))
+			break;
+		saa7146_read(dev, MC2);
+		if (!loops--) {
+			printk(KERN_ERR "%s: %s timed out while waiting for transfer completion\n",
+	dev->name, __FUNCTION__);
+			return -ETIMEDOUT;
+		}
+		udelay(5);
+	}
+
+	return 0;
+}
+
+int saa7146_wait_for_debi_done(struct saa7146_dev *dev, int nobusyloop)
+{
+	if (nobusyloop)
+		return saa7146_wait_for_debi_done_sleep(dev, 5, 25);
+	else
+		return saa7146_wait_for_debi_done_busyloop(dev, 5, 25);
 }
 
 /
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] [Patch] ves1820: increase acquisition range for clock recovery

[Oliver Endriss]

@all users of ves1820-based DVB-C cards (FF ttpci, budget),

please test whether the attached patch has any adverse effects.
(Tests @vdr-portal did not show any problems yet.)

It changes the acquisition range for clock recovery from 120 ppm to
240ppm. Apparently, some cable providers in Germany are playing with
their parameters, and the capture range of the ves1820 is too small
to acquire a lock with the current setting... ;-(

If nobody complains I will commit this patch next weekend.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/

diff -r 21dd007fdc59 linux/drivers/media/dvb/frontends/ves1820.c
--- a/linux/drivers/media/dvb/frontends/ves1820.c	Thu Oct 04 22:36:22 2007 +0200
+++ b/linux/drivers/media/dvb/frontends/ves1820.c	Sat Oct 06 16:55:35 2007 +0200
@@ -47,7 +47,7 @@ static int verbose;
 static int verbose;
 
 static u8 ves1820_inittab[] = {
-	0x69, 0x6A, 0x93, 0x12, 0x12, 0x46, 0x26, 0x1A,
+	0x69, 0x6A, 0x93, 0x1A, 0x12, 0x46, 0x26, 0x1A,
 	0x43, 0x6A, 0xAA, 0xAA, 0x1E, 0x85, 0x43, 0x20,
 	0xE0, 0x00, 0xA1, 0x00, 0x00, 0x00, 0x00, 0x00,
 	0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
___
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

[Oliver Endriss]

Trent Piepho wrote:
> On Thu, 6 Sep 2007, hermann pitton wrote:
> > Am Mittwoch, den 05.09.2007, 13:29 +0200 schrieb Paolo Dell'Aquila:
> > > Than  I've done some test with Mythtv and auto-scanning
> > > for channels... and now...
> > >
> > > ...now I'm having the following (BIG) problem:
> > > dvb-t doesn't work anymore (also in kaffeiene or tzap).
> > >
> > > dmesg has the following error:
> > > DVB: frontend 0 frequency 2147483647 out of range (5100..85800)
> >
> > That sounds really mad, especially as you are in freq. limits of the
> > tda8275 and not of the tda8275a, which for sure you have.
> 
> 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.

> But, 2147483647 is not a valid DVB-T frequency.  It looks like some random
> number.

Ack, this frequency is bogus. The application must be fixed.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore

[Oliver Endriss]

Johannes Stezenbach wrote:
> On Sun, Aug 19, 2007, Oliver Endriss wrote:
> > 
> > Questions:
> > - Why should dvb_shutdown_timeout==0 disable sleep mode?
> 
> The use case was to watch video without any software running.
> Just program the hardware once and let it do it's job. Some
> people want that although I don't think it's really useful.
> (Works for FF cards only, of course.)
> 
> > - Does it make any sense to have LNB power 'on' and the frontend in
> >   sleep mode? 
> 
> No.
> 
> > Imho these should be controlled by dvb_powerdown_on_sleep alone,
> > for example:
> 
> Sounds good to me.

Ok.

Default value for dvb_shutdown_timeout set to 0:
http://linuxtv.org/hg/v4l-dvb/rev/56556c094e04

dvb_powerdown_on_sleep controls fe sleep _and_ LNB power:
http://linuxtv.org/hg/v4l-dvb/rev/9b00ad43d7f3

ts_bus_ctrl fixed:
http://linuxtv.org/hg/v4l-dvb/rev/e09c063c28dd

Afaics fe locking can be done using ts_bus_ctrl now
(iff dvb_shutdown_timeout == 0).

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



___
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

[Oliver Endriss]

Michael Krufky wrote:
> For the past few months, I've been working on refactoring the analog 
tuner.ko module, such that all hardware-specific code can be separated 
into dvb_frontend style tuner modules.
> 
> This allows for a single module to be used by both the v4l2 tuner 
interface via the tuner.ko i2c_client driver, and directly by the dvb 
subsystem's tuning system.
> 
> This refactoring process has zero impact to the way that v4l and dvb 
functions.
> 
> I have completed phase one of the refactoring process, and now it is 
ready for testing and review.
> 
> http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1
> 
> A brief description of the individual changesets follows:
> 
> - tuner: kill i2c_client interface to tuner sub-drivers
> 
> This changeset removes the i2c_client interface between tuner.ko and 
the tuner sub-drivers.
> 
> The i2c_client interface to tuner.ko, itself, remains the same as it 
has been -- this is only an internal change that affects the 
interaction between tuner.ko and the hardware-specific code.
> 
> Some helper functions and macros were added in this changeset, in 
order to ease the conversion process, without causing headaches or 
breakage. (see tuner-i2c.c)  We can remove these extra structs and 
helper functions after the refactoring process is complete.
> 
> - hybrid tuner refactoring core changes, phase 1
> 
> This changeset contains the more interesting work, where tuner-core is 
altered to support attachment of dvb_frontend style tuner modules.  An 
additional method "set_analog_params" was added to struct 
dvb_tuner_ops, so as to avoid altering the DVB subsystem userspace API 
headers.  This change does not create any dependency of the DVB 
subsystem on V4L, nor does it create any dependency of the V4L 
subsystem on DVB.
> 
> - tda8290: convert from tuner sub-driver into dvb_frontend module
> - mt20xx: convert from tuner sub-driver into dvb_frontend module
> - tea5761: convert from tuner sub-driver into dvb_frontend module
> - tea5767: convert from tuner sub-driver into dvb_frontend module
> - tuner-simple: convert from tuner sub-driver into dvb_frontend module
> 
> These changesets handle the conversions of the individual tuner 
sub-drivers into dvb_frontend style tuner modules.
> 
> - tuner: alter Makefile to produce separate modules
> 
> This changeset makes the changes to the build system, required for 
building the tuner sub-drivers as separate modules, and the ability to 
deselect undesired tuner sub-drivers via Kconfig.
> 
> --
> 
> What comes next?
> 
> After phase 1 of hybrid tuner refactoring is merged into the master 
branch, there is no change to the behavior of the drivers, apart from 
the fact that users will now have the ability to deselect undesired 
tuner sub-drivers via Kconfig.
> 
> I have the following changes planned for hybrid tuner refactoring, 
phases 2, 3 and 4:
> 
> - analog if demodulator refactoring
> 
> In this step, an internal api for analog IF demods will be created, 
allowing us to refactor the tda9887 module, and also to handle tda8290 
separately from the tda8275 and tda8275a tuners.
> 
> - tda8290 refactoring
> 
> In addition to the analog if demodulator refactoring, duplicated code 
for the tda8275 and tda8275a tuners between tda8290.ko and tda827x.ko 
shall be consolidated.  In addition, support for the tda8295 and 
tda18271 devices will be added.
> 
> - tuner-simple refactoring
> 
> Tuner-simple will be cleaned up to take on more of an object-oriented 
approach, and duplicated code for certain tuners present in both 
tuner-simple and dvb-pll shall be consolidated.
> 
> - miscellaneous work and additional cleanups
> 
> mt20xx shall be cleaned up to properly handle tuning requests from the 
DVB subsystem, rather that going through tuner.ko -- this is a very 
small change, but I decided to wait on this until after phase 1 is 
merged into master.
> 
> Support for new hybrid tuner hardware will now be _much_ easier to 
develop and add into the v4l-dvb codebase.
> 
> --
> 
> I'd like to thank all of the people that have looked this over thus 
far, whom have given suggestions on how I can make this better and 
easier to review.
> 
> If there are any other questions, comments or concerns, I would love 
to hear them.  Please don't be shy -- feel free to let me know if you 
like or dislike this approach.  I'd like to have this merged as soon as 
possible, so that I may continue to work on the items mentioned about 
in the "What comes next?" section.
> 
> Now, it's time to go out and party!  I will be able to respond to any 
comments tomorrow afternoon.

While I currently don't ha

Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer

[Oliver Endriss]

Soeren Sonnenburg wrote:
> On Sun, 2007-08-19 at 01:05 +0200, Oliver Endriss wrote:
> > Soeren Sonnenburg wrote:
> > > On Tue, 2007-07-31 at 14:37 +0200, Oliver Endriss wrote:
> > > > Stone wrote:
> > > > > On 7/17/07, Oliver Endriss <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Oliver Endriss wrote:
> > > > > > > Imho the interrupt processing was broken:
> > > > > > > - The first I2C interrupt should be used to wake-up the task.
> > > > > > >   It does not matter that it takes some time until ERR in IIC_STA
> > > > > > >   will be updated. We don't need it.
> > > > > > > - Interrupts must be acknowledged at the end of the ISR.
> > > > > > >
> > > > > > > @all
> > > > > > > Please test the attached patch.
> > > > > > > There shouldn't be any unexpected I2C interrupts anymore.
> [...]
> > > I was now using this patch for 1-2 weeks. This setup has a FF-dvb-c and
> > > a budget dvb-t card and after the patch there were no more timeout
> > > messages. However since I added the asus p7131 I am seeing this message
> > > regularly again (44 times in the last 5 days).
> > > 
> > > Thanks for investigating on this!!
> > > Soeren
> > 
> > Just to be sure:
> > You are using exactly the same setup, except for the new asus p7131?
> 
> yes, same setup + additional asus p7131.
> 
> > Strange. Maybe a power supply problem. Could you try another power
> > supply for your machine?
> 
> This is a brand new power supply already (because I thought at some
> point the usb disconnects were caused by a flaky power supply). However
> following Hermanns suggestion I permuted the cards in the slots. One day
> of up-time so far without seeing this message...

There have been reports that some mainboard layouts have problems to
supply enoungh power on the PCI bus...

> I will report back when the messages re-appear...

Thanks.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] only one read access to cx88-devices possible

[Oliver Endriss]

Fabian Förg wrote:
> Hello,
> 
> I realized that only one read access is possible to devices that use the 
> cx88 driver.
> In my case it is a Hauppauge WinTV Nova-S-Plus DVB-S card.
> You can reproduce it with the following test:
> Launch femon concurrently two or more times. Only one femon is able to 
> read from the card.
> Oliver Endriss confirmed that bug after looking in cx88-dvb.c.
> Usually, only one write access but an arbitrary amount of read accesses 
> should be allowed.

Basically it's a bug in dvb_frontend.
ts_bus_ctrl() should only be called by
- the first open
- the last release
call.

Please try the attached patch.

@all:
Ok?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/

diff -r abb4c177bf6c linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c	Wed Aug 22 00:46:48 2007 +0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c	Thu Aug 23 01:13:49 2007 +0200
@@ -1061,18 +1061,15 @@ static int dvb_frontend_open(struct inod
 
 	dprintk ("%s\n", __FUNCTION__);
 
+	if (dvbdev->users == -1 && fe->ops.ts_bus_ctrl) {
+		if ((ret = fe->ops.ts_bus_ctrl(fe, 1)) < 0)
+			return ret;
+	}
+
 	if ((ret = dvb_generic_open (inode, file)) < 0)
-		return ret;
-
-	if (fe->ops.ts_bus_ctrl) {
-		if ((ret = fe->ops.ts_bus_ctrl (fe, 1)) < 0) {
-			dvb_generic_release (inode, file);
-			return ret;
-		}
-	}
+		goto err1;
 
 	if ((file->f_flags & O_ACCMODE) != O_RDONLY) {
-
 		/* normal tune mode when opened R/W */
 		fepriv->tune_mode_flags &= ~FE_TUNE_MODE_ONESHOT;
 		fepriv->tone = -1;
@@ -1080,13 +1077,20 @@ static int dvb_frontend_open(struct inod
 
 		ret = dvb_frontend_start (fe);
 		if (ret)
-			dvb_generic_release (inode, file);
+			goto err2;
 
 		/*  empty event queue */
 		fepriv->events.eventr = fepriv->events.eventw = 0;
 	}
 
 	return ret;
+
+err2:
+	dvb_generic_release(inode, file);
+err1:
+	if (dvbdev->users == -1 && fe->ops.ts_bus_ctrl)
+		fe->ops.ts_bus_ctrl(fe, 0);
+	return ret;
 }
 
 static int dvb_frontend_release(struct inode *inode, struct file *file)
@@ -1101,16 +1105,18 @@ static int dvb_frontend_release(struct i
 	if ((file->f_flags & O_ACCMODE) != O_RDONLY)
 		fepriv->release_jiffies = jiffies;
 
-	if (fe->ops.ts_bus_ctrl)
-		fe->ops.ts_bus_ctrl (fe, 0);
-
 	ret = dvb_generic_release (inode, file);
 
-	if (dvbdev->users==-1 && fepriv->exit==1) {
-		fops_put(file->f_op);
-		file->f_op = NULL;
-		wake_up(&dvbdev->wait_queue);
-	}
+	if (dvbdev->users == -1) {
+		if (fepriv->exit == 1) {
+			fops_put(file->f_op);
+			file->f_op = NULL;
+			wake_up(&dvbdev->wait_queue);
+		}
+		if (fe->ops.ts_bus_ctrl)
+			fe->ops.ts_bus_ctrl(fe, 0);
+	}
+
 	return ret;
 }
 
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore

[Oliver Endriss]

Manu Abraham wrote:
> Oliver Endriss wrote:
> 
> > Does anyone know, why dvb_shutdown_timeout was introduced initially?
> 
> It was originally introduced looong time back by Obi. Some operations
> still incomplete on close() was the reason stated, IIRC. It had
> something to do with the FF cards ?, dunno.

Hm, for FF cards there is another voodoo parameter in dvb-ttpci:
'pids_off:clear video/audio/PCR PID filters when demux is closed'
Default is 0 which means don't close. ;-(

For FF cards there is one useful(?) application:
If someone does not want to keep szap running after tuning,
he might want to set dvb_shutdown_timeout=0.

This will both
- terminate the fe thread, and
- disable frontend powerdown.

> 
> > I don't have a problem if it will be removed, but I suspect there was a
> > reason for it. Anyway, we should set the default to 0.
> > 
> 
> I think a lot of people have been using it as set to 0. Ah, well that
> includes myself.

Afaics there are several features mixed-up with this parameter:

if (dvb_shutdown_timeout) {
if (dvb_powerdown_on_sleep)
if (fe->ops.set_voltage)
fe->ops.set_voltage(fe, SEC_VOLTAGE_OFF);
if (fe->ops.tuner_ops.sleep) {
fe->ops.tuner_ops.sleep(fe);
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
}
if (fe->ops.sleep)
fe->ops.sleep(fe);
}

Questions:
- Why should dvb_shutdown_timeout==0 disable sleep mode?
- Does it make any sense to have LNB power 'on' and the frontend in
  sleep mode? 

Imho these should be controlled by dvb_powerdown_on_sleep alone,
for example:

if (dvb_powerdown_on_sleep) {
if (fe->ops.set_voltage)
fe->ops.set_voltage(fe, SEC_VOLTAGE_OFF);
if (fe->ops.tuner_ops.sleep) {
fe->ops.tuner_ops.sleep(fe);
if (fe->ops.i2c_gate_ctrl)
fe->ops.i2c_gate_ctrl(fe, 0);
}
if (fe->ops.sleep)
fe->ops.sleep(fe);
}


CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] System load raises when budget_av is loaded

[Oliver Endriss]

e9hack wrote:
> Oliver Endriss schrieb:
> >> It seems, the delay of 100usec is too short. During booting of the ARM,
> >> DEBI_E is set for ca. 360usec after some debi commands. I've changed the
> >> delay to 500usec. The load average is dropped from 0.65 to 0.0 with
> >> budget_av and dvb_ttpci loaded and vdr isn't running.
> > 
> > With this patch I get random error messages from av7110_debiread|write:
> > 
> > | Aug 19 01:26:05 orion kernel: av7110_debiread: wait_for_debi_done #1 
> > failed
> > | Aug 19 01:26:05 orion kernel: av7110_debiwrite: wait_for_debi_done failed
> > 
> 
> I saw the same messages, if I used a too short delay (100usec). For testing, 
> I printed out the time,
> while the DEBI_E was active.
> 
> Startup of the TT-C2300:
> Aug 19 08:53:38 darkstar kernel: Linux video capture interface: v2.00
> Aug 19 08:53:38 darkstar kernel: saa7146: register extension 'dvb'.
> Aug 19 08:53:38 darkstar kernel: ACPI: PCI Interrupt :04:06.0[A] -> Link 
> [LNKA] -> GSI 17
> (level, low) -> IRQ 22
> Aug 19 08:53:38 darkstar kernel: saa7146: found saa7146 @ mem fab6ec00 
> (revision 1, irq 22)
> (0x13c2,0x000a).
> Aug 19 08:53:38 darkstar kernel: DVB: registering new adapter 
> (Technotrend/Hauppauge WinTV Nexus-CA
> rev1.X)
> Aug 19 08:53:38 darkstar kernel: adapter has MAC addr = ??:??:??:??:??:??
> Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 30usec
> Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 360usec
> Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 360usec
> Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 360usec
> Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 360usec
> Aug 19 08:53:38 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 360usec
> Aug 19 08:53:38 very-new-darkstar kernel:
> 
> 
> vdr is running:
> Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was 
> active for 38(253)msec
> Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was 
> active for 38(253)msec
> Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 20usec
> Aug 19 08:59:33 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was 
> active for 38(253)msec
> Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was 
> active for 38(253)msec
> Aug 19 08:59:34 darkstar kernel: (tda10021.c:305) ckoff=26, sroffset=672, 
> sr=690
> Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 30usec
> Aug 19 08:59:34 darkstar kernel: (tda10021.c:305) ckoff=0, sroffset=0, 
> sr=6900672
> Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was 
> active for 38(253)msec
> Aug 19 08:59:34 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was 
> active for 38(253)msec
> Aug 19 08:59:35 darkstar kernel: (saa7146_core.c:132) saa7146 (1): SEBI_E was 
> active for 38(253)msec
> Aug 19 08:59:35 darkstar kernel: (saa7146_core.c:136) saa7146 (0): SEBI_E was 
> active for 110usec
> 
> The longest time from the TT-C2300 was 370us. The Cinergy does always timeout 
> with a debi error.
> I've used the attached patch.

For full-featured cards it may take some time until the debi transfer
has completed, because those cards use debi dma.

I wonder
- why the error bit gets set at all, and.
- whether the debi status bits are updated before the transfer has
  been completed/stopped.

I'll try to look into this next week.

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore

[Oliver Endriss]

Steven Toth wrote:
> Trent Piepho wrote:
> > On Fri, 17 Aug 2007, Markus Rechberger wrote:
> >   
>  as I wrote earlier the thread can be idle/closed even before the node
>  gets closed (you can test that with kaffeine, and you can test the
>  other case with the scan utility)
>  
> >>> How can this happen? Afaics the fe thread may continue to exist after
> >>> the device node was closed, but not vice-versa.
> >>>   
> >
> > Yes, how can that happen?  What will make the dvb frontend thread exit 
> > before
> > the device is closed?
> >   
> 
> I don't know. I should probably spend sometime reminding myself of the 
> purpose of the thread.

It cannot happen, unless someone kills the thread...

> > Maybe it would be a good idea to do what Andreas suggested and have the
> > frontend release function block until the frontend thread has exited.  
> > AFAIK,
> > the thread hanging around after the device is closed does nothing but cause
> > problems.  It's a very common FAQ, "Q:  Why does it mythtv not work if I
> > change from a digital channel to an analog one?  A:  You need to set
> > dvb_shutdown_timeout to 0." What's the purpose of dvb_shutdown_timeout > 0?

Does anyone know, why dvb_shutdown_timeout was introduced initially?

I don't have a problem if it will be removed, but I suspect there was a
reason for it. Anyway, we should set the default to 0.

> We should be clear that the ts_bus_ctrl isn't design to lock or version 
> count in any way. The purpose of the callback is to allow the bridge to 
> determine whether the it has sufficient hardware resources to allow the 
> ops open to complete (assuming that the callers wants data). The best 
> example of this todate has been the HVR1300 sub-drivers in which a V4L 
> and DVB ops structures both need to access frontends on the single PCI bus.

Ok, then it is probably used the wrong way in dvb_frontend.c.
It should only be called for
- the first open of the fe device and
- the last close of the fe device (or maybe when the frontend thread
  exits, whichever comes later).

For multiple tuners ts_bus_ctrl is responsible to do the right thing.

> Having a DVB application interfere with the V4L application's use of the 
> bus isn't acceptable.
> 
> Personally,  I think ts_bus_ctrl needs to be replaced with a single 
> resource allocation/deallocation mechanism that extends beyond simple 
> bus negotiation into tuners, demods, encoders and other devices.
> 
> >>> ts_bus_ctrl does a kind of reference counting.
> >>>
> >>> For readers:
> >>> - fe->ops.ts_bus_ctrl(fe,1) is called during open
> >>> - fe->ops.ts_bus_ctrl(fe,0) is called during close
> >>>
> >>> For the one and only writer:
> >>> - fe->ops.ts_bus_ctrl(fe,1) is called during open
> >>> - fe->ops.ts_bus_ctrl(fe,0) is called when the thread exits,
> >>>   usually after close
> >>>   
> >
> > So, how do you tell if the ts bus is already locked?
> >
> >   
> 
> Until now it's never been a requirement.

Simply try to lock it. If it fails, you know that it is taken. ;-)

> >> I didn't want to write it but this is also what I would do, and I
> >> would also include the other dvb device nodes.. it doesn't make sense
> >> to keep them open as non functional dummies, or even allow people to
> >> open these nodes if the dvb mode is locked.
> >> 
> >
> > What about a device with two frontends?  Maybe the DVB-T/Analog frontend is
> > locked by the V4L device, but you can still use a DVB-S frontend with dvb.  
> > In
> > that case the demux could still be opened and used.
> >
> >   
> The HVR1300 (and HVR3000 / 4000) prohibit this by using ts_bus_ctrl, 
> these are good examples.

Btw, someone reported at vdr-portal, that cx88_dvb does not allow the
frontend to be opened more than once anymore. Seems to be caused by
calling the ts_bus_ctrl hook in dvb_frontend.

Note that it should always be possible to open the fe for additional
readers. femon can be run concurrently, for example.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

[linux-dvb] [Patches] dvb_ca_en50221: fix use count, error code

[Oliver Endriss]

Hi,

Marco Schluessler sent me patches which fix two bugs in dvb_ca_en50221:
- decrement module use count on error
- return correct error code value

If no one objects I'll commit them.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/

- return correct error code value

Signed-off-by: Marco Schluessler <[EMAIL PROTECTED]>

diff -bur v4l-dvb-96c5b8101ea3_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c v4l-dvb-96c5b8101ea3/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
--- v4l-dvb-96c5b8101ea3_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	2007-08-17 21:05:15.0 +0200
+++ v4l-dvb-96c5b8101ea3/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	2007-08-18 00:34:14.0 +0200
@@ -1570,7 +1570,7 @@
 {
 	struct dvb_device *dvbdev = file->private_data;
 	struct dvb_ca_private *ca = dvbdev->priv;
-	int err = 0;
+	int err;
 
 	dprintk("%s\n", __FUNCTION__);
 
@@ -1582,7 +1582,7 @@
 
 	module_put(ca->pub->owner);
 
-	return 0;
+	return err;
 }
 
 
- decrement module use count on error

Signed-off-by: Marco Schluessler <[EMAIL PROTECTED]>

diff -bur v4l-dvb-96c5b8101ea3_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c v4l-dvb-96c5b8101ea3/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
--- v4l-dvb-96c5b8101ea3_orig/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	2007-08-17 21:05:15.0 +0200
+++ v4l-dvb-96c5b8101ea3/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	2007-08-18 00:16:24.0 +0200
@@ -1536,8 +1536,10 @@
 		return -EIO;
 
 	err = dvb_generic_open(inode, file);
-	if (err < 0)
+	if (err < 0) {
+		module_put(ca->pub->owner);
 		return err;
+	}
 
 	for (i = 0; i < ca->slot_count; i++) {
 ___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] System load raises when budget_av is loaded

[Oliver Endriss]

[EMAIL PROTECTED] wrote:
> 2007/8/18, e9hack <[EMAIL PROTECTED]>:
> >
> > I've modified saa7146_wait_for_debi_done() a little bit. The function
> > returns earlier from the
> > second loop, if nobusyloop was 0 and if SPCI_DEBI_E was set after 100usec.
> > I've used udelay() and an
> > additional counter. My TT-C2300 has reported an ARM boot error. The
> > unmodified driver wasn't able to
> > restart the ARM. I must do a power off to recover the TT-C2300. I will do
> > more test on this issue,
> > but currently I do some tests on a TT-C1500. Too many challenges are not
> > so good at the same time.
 
> It seems, the delay of 100usec is too short. During booting of the ARM,
> DEBI_E is set for ca. 360usec after some debi commands. I've changed the
> delay to 500usec. The load average is dropped from 0.65 to 0.0 with
> budget_av and dvb_ttpci loaded and vdr isn't running.

With this patch I get random error messages from av7110_debiread|write:

| Aug 19 01:26:05 orion kernel: av7110_debiread: wait_for_debi_done #1 failed
| Aug 19 01:26:05 orion kernel: av7110_debiwrite: wait_for_debi_done failed

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer

[Oliver Endriss]

Soeren Sonnenburg wrote:
> On Tue, 2007-07-31 at 14:37 +0200, Oliver Endriss wrote:
> > Stone wrote:
> > > On 7/17/07, Oliver Endriss <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Oliver Endriss wrote:
> > > > > Imho the interrupt processing was broken:
> > > > > - The first I2C interrupt should be used to wake-up the task.
> > > > >   It does not matter that it takes some time until ERR in IIC_STA
> > > > >   will be updated. We don't need it.
> > > > > - Interrupts must be acknowledged at the end of the ISR.
> > > > >
> > > > > @all
> > > > > Please test the attached patch.
> > > > > There shouldn't be any unexpected I2C interrupts anymore.
> > > >
> > > > Attached is an updated patch which does extended status checking.
> > > 
> > > 
> > > Did this patch solve everyone's problems?  Is is checked in now?
> > 
> > There was little feedback, so it's not in the repository yet.
> > 
> > I would really appreciate if more people would test this patch,
> > no matter whether they have a problem with the current driver
> > or not. It would reduce the risk to introduce a bug.
> 
> I was now using this patch for 1-2 weeks. This setup has a FF-dvb-c and
> a budget dvb-t card and after the patch there were no more timeout
> messages. However since I added the asus p7131 I am seeing this message
> regularly again (44 times in the last 5 days).
> 
> Thanks for investigating on this!!
> Soeren

Just to be sure:
You are using exactly the same setup, except for the new asus p7131?

Strange. Maybe a power supply problem. Could you try another power
supply for your machine?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer

[Oliver Endriss]

André Weidemann wrote:
> Oliver Endriss wrote:
> 
> Hi Oliver,
> 
> > Please try the current HG driver. (Important because timeouts are now
> > logged in poll mode, too.)
> 
> I downloaded the refactoring driver from the bz2-link on this page:
> http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring and compiled them.
> 
> > If it still happens, please replace SAA7146_USE_I2C_IRQ by
> > SAA7146_I2C_SHORT_DELAY in av7110.c. Does it help?
> 
> With the new driver I still got the error message :-(. But it looks 
> slightly different than before: "saa7146 (1) saa7146_i2c_writeout [irq]:
> timed out waiting for end of xfer".

Yes, I slightly modified the messages.

> I presume the (1) is the second registered frontend.

Correct.

> Well this is my budget-ci card and not the FF-Card...
> 
> So I thought I might as well try your advice for the FF card for the 
> budget card and changed the flag in budget-ci.c to SAA7146_I2C_SHORT_DELAY.
> Now the error message that shows is: "saa7146_i2c_writeout [poll]: timed 
> out waiting for end of xfer"

Thanks. It shows that disabling IRQ mode does not solve the problem.

Note that older drivers did not log this message in POLL mode, but the
underlying problem was always was there.

> Until now I thought that the motherboard change had caused this problem, 
> but at the same I have replace the S1400 with an S1500 with a CI 
> connected to it.
> I now have an Asus M2NPV-VM(NVidia GeForce 6150 + nForce 430) with an 
> Athlon64 3200+ and 512MB DDR2 RAM(667).
> I am running Debian Etch x86_64 with kernel 2.6.20+refactoring driver.
> Maybe some of the above might give you a clue on what could be the cause 
> of the problem.
> 
> Thank you for looking into the problem.

Unfortunately, I have no idea why the I2C transfer hangs sometimes.
Is there any pattern? Does it happen rarely or does the message flood
your logs?

If it does not happen too often, it should not be a big problem, because
the I2C transfer will be retried...

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] New Revision of KNC1 DVB-S Plus 1894:0015

[Oliver Endriss]

Johannes Deisenhofer wrote:
> Oliver Endriss wrote:
> > Johannes Deisenhofer wrote:
> >> Hi,
> >>
> >> I have a bunch of KNC1 DVB-S Plus Cards, with Subsystem ID 1894:0015.
> >> There are 'Plus' cards, with Phillips SD1878 Tuner and Analog Inputs.
> >> (Picture at http://www.vdr-wiki.de/wiki/index.php/Bild:Knc1splusx4.jpg)
> > 
> > Is 'KNC1 DVB-S plus X4' the correct name of this card?
> > According to your patch the name is 'SUBID_DVBS_TV_STAR_PLUS'.
> > 
> 
> Hm, difficult to tell. It's called "TV Station Plus" on the box, but is 
> different from the old 'TV Station Plus'. 'X4' is written on the board 
> (see photo).
> The windows driver's .ini-File calls it 'DVBS+ X4'
> Technically, it's more in line with the "TV Star" cards (same tuner).
> But I'll gladly leave the taxonomic decisions to the maintainer.

Then let's call this baby 'TV Station Plus X4'. ;-)

> >> Besides the analog input, these seem to be identical to the "TV Star"
> >> Cards from KNC1. Adding the PCI Ids is easy, but:
> >>
> >> Can anybody advise me how I can find out if my card needs to be added to
> >> this list of IDs? It's a plus card, after all. Do I need to test with a 
> >> CA adapter?
> > 
> > Would be nice (if you have a CI/CAM).
> >
> 
> I could probably find one, if there's a chance it has something to do 
> with it.
> 
> > 
> > Simply try whether it works without setting GPIO3.
> > If not, try with GPIO3 set to high.
> > 
> 
> Been there, done that. Works both ways.

Iirc GPIO3 has something to do with the initialisation of the CI/CAM.
So it would be nice if you could verify that.
If it works both ways, we should not touch GPIO3.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] System load raises when budget_av is loaded

[Oliver Endriss]

e9hack wrote:
> Oliver Endriss schrieb:
> > Jukka Pirinen wrote:
> >> As workaround I commented out initialisation of CI interface, that's not
> >> a problem because I don't have CI.
> >>
> >> diff budget-av.c.orig budget-av.c
> >> 1175c1175
> >> <ciintf_init(budget_av);
> >> ---
> >>>//ciintf_init(budget_av);
> > 
> > Could you please try to find out, why the CI thread is causing high
> > load? You might start checking the values of ca->delay and ca->wakeup
> > before wait_event_interruptible_timeout().
> > 
> > Sorry, I can't do this. I don't have budget-av hardware.
> 
> It may be a problem of saa7146_wait_for_debi_done(). Without a CI/CAM, every 
> debi read/write request
> ends with an error. In this case, SPCI_DEBI_S will never go low.

Yep, this might be a problem. But it is surprising that this issue
was never detected before.

If DEBI_S ever goes high, it will never be reset.
Afaics there is no direct way to reset this bit.
(A new debi command should reset it, though.)

> Most of the debi requests are done with an spinlock held.

None of the debiread/write accesses in budget-av uses locks,
which is probably a bug. See the other thread.

> Saa7146_wait_for_debi_done() polls for 250msec the PSR. Possible, this is the 
> reason for the high load. Usually, saa7146_wait_for_debi_done() can bail out 
> earlier,
> if SPCI_DEBI_E is set.

Some debiread/write calls in budget-av use busy-waiting.
For testing it might be worth to set the last parameter of the
debiread/write calls to 1 (nobusyloop).

> saa7146_wait_for_debi_done() is also used by the TT-FF cards. During the 
> booting of the ARM, 
> this cards need the timeout/wait after a debi error.

Could you please explain why the FF card needs this timeout?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



___
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

[Oliver Endriss]

Trent Piepho wrote:
> On Fri, 17 Aug 2007, Oliver Endriss wrote:
> > Markus Rechberger wrote:
> > > 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]>
> >
> > Are you talking about this tiny patch?
> >
> > struct dvb_net *dvbnet = dvbdev->priv;
> >
> > -   if (!dvbdev)
> > -   return -ENODEV;
> >
> > If yes,
> > Acked-by: Oliver Endriss <[EMAIL PROTECTED]>
> >
> > Btw, why is this patch important? Basically it doesn't change anything.
> 
> It checks if dvbdev is NULL after dvbdev already been used.  Coverity spots
> this as a programming mistake (which it is), and Adrian Bunk posts patches
> to fix it.

Sure, but the patch does exactly the same.
It's just hidden behind a function call...

@Mauro:
This patch simply replaces a code block by a function call.
The function does exactly the same as the code block did.
It's safe to apply this patch.

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore

[Oliver Endriss]

Markus Rechberger wrote:
> On 8/17/07, Oliver Endriss <[EMAIL PROTECTED]> wrote:
> > Markus Rechberger wrote:
> > > On 8/17/07, Oliver Endriss <[EMAIL PROTECTED]> wrote:
> > > > Steven Toth wrote:
> > > > > The ts_bus_ctrl function pointer / callback is already in the
> > mainline,
> > > > > check dvb_frontend.c for more details. You shouldn't need a patch from
> > me.
> > > >
> > > > ACK, should be enough to do this kind of locking.
> > > >
> > > > Furthermore, with this callback, the dvb_frontend_active() routine from
> > > > '[linux-dvb] [PATCH] function for checking if the dvb framework is idle'
> > > > is not required at all. The callback is aware whether the frontend is
> > > > running or not...
> > > >
> > > As far as I've seen the callback will be called as soon as the device
> > > gets closed, even though the thread might still be spinning in the
> > > background and the subsystem might still access DVB components, this
> > > is why dvb_frontend_active is  still needed.
> > > Closing the devicenode and that callback doesn't mean that the device is
> > idle.
> >
> > Ok, this should be fixed. What about this patch:
> >
> > diff -r dd58780b6fb4 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> > --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   Thu Aug 09 
> > 16:30:39
> > 2007 +0200
> > +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   Fri Aug 17 
> > 20:07:28
> > 2007 +0200
> > @@ -596,6 +596,10 @@ restart:
> > mb();
> >
> > dvb_frontend_wakeup(fe);
> > +
> > +   if (fe->ops.ts_bus_ctrl)
> > +   fe->ops.ts_bus_ctrl (fe, 0);
> > +
> > return 0;
> >  }
> 
> as I wrote earlier the thread can be idle/closed even before the node
> gets closed (you can test that with kaffeine, and you can test the
> other case with the scan utility)

How can this happen? Afaics the fe thread may continue to exist after
the device node was closed, but not vice-versa.

> 
> >
> > @@ -1101,9 +1105,10 @@ static int dvb_frontend_release(struct i
> >
> > if ((file->f_flags & O_ACCMODE) != O_RDONLY)
> > fepriv->release_jiffies = jiffies;
> > -
> > -   if (fe->ops.ts_bus_ctrl)
> > -   fe->ops.ts_bus_ctrl (fe, 0);
> > +   else {
> > +   if (fe->ops.ts_bus_ctrl)
> > +   fe->ops.ts_bus_ctrl (fe, 0);
> > +   }
> >
> 
> can you explain this? to me it doesn't look right. Before it always
> called ts_bus_ctrl and afterwards it has a dependency to the access
> mode bits?

ts_bus_ctrl does a kind of reference counting.

For readers:
- fe->ops.ts_bus_ctrl(fe,1) is called during open
- fe->ops.ts_bus_ctrl(fe,0) is called during close

For the one and only writer:
- fe->ops.ts_bus_ctrl(fe,1) is called during open
- fe->ops.ts_bus_ctrl(fe,0) is called when the thread exits,
  usually after close

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore

[Oliver Endriss]

Markus Rechberger wrote:
> On 8/17/07, Oliver Endriss <[EMAIL PROTECTED]> wrote:
> > Steven Toth wrote:
> > > The ts_bus_ctrl function pointer / callback is already in the mainline,
> > > check dvb_frontend.c for more details. You shouldn't need a patch from me.
> >
> > ACK, should be enough to do this kind of locking.
> >
> > Furthermore, with this callback, the dvb_frontend_active() routine from
> > '[linux-dvb] [PATCH] function for checking if the dvb framework is idle'
> > is not required at all. The callback is aware whether the frontend is
> > running or not...
> >
> As far as I've seen the callback will be called as soon as the device
> gets closed, even though the thread might still be spinning in the
> background and the subsystem might still access DVB components, this
> is why dvb_frontend_active is  still needed.
> Closing the devicenode and that callback doesn't mean that the device is idle.

Ok, this should be fixed. What about this patch:

diff -r dd58780b6fb4 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   Thu Aug 09 16:30:39 
2007 +0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c   Fri Aug 17 20:07:28 
2007 +0200
@@ -596,6 +596,10 @@ restart:
mb();
 
dvb_frontend_wakeup(fe);
+
+   if (fe->ops.ts_bus_ctrl)
+   fe->ops.ts_bus_ctrl (fe, 0);
+
return 0;
 }
 
@@ -1101,9 +1105,10 @@ static int dvb_frontend_release(struct i
 
if ((file->f_flags & O_ACCMODE) != O_RDONLY)
fepriv->release_jiffies = jiffies;
-
-   if (fe->ops.ts_bus_ctrl)
-   fe->ops.ts_bus_ctrl (fe, 0);
+   else {
+   if (fe->ops.ts_bus_ctrl)
+   fe->ops.ts_bus_ctrl (fe, 0);
+   }
 
ret = dvb_generic_release (inode, file);
 

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



___
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

[Oliver Endriss]

Markus Rechberger wrote:
> 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]>

Are you talking about this tiny patch?

--- a/linux/drivers/media/dvb/dvb-core/dvb_net.cFri Jun 08 08:58:41 
2007 -0300
+++ b/linux/drivers/media/dvb/dvb-core/dvb_net.cFri Jun 15 15:34:08 
2007 -0700
 -1502,18 +1502,9  static int dvb_net_close(struct 
inode *i
struct dvb_device *dvbdev = file->private_data;
struct dvb_net *dvbnet = dvbdev->priv;

-   if (!dvbdev)
-   return -ENODEV;
-
-   if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
-   dvbdev->readers++;
-   } else {
-   dvbdev->writers++;
-   }
-
-   dvbdev->users++;
-
-   if(dvbdev->users == 1 && dvbnet->exit==1) {
+   dvb_generic_release(inode, file);
+
+   if(dvbdev->users == 1 && dvbnet->exit == 1) {
fops_put(file->f_op);
    file->f_op = NULL;
wake_up(&dvbdev->wait_queue);

If yes,
Acked-by: Oliver Endriss <[EMAIL PROTECTED]>

Btw, why is this patch important? Basically it doesn't change anything.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore

[Oliver Endriss]

Steven Toth wrote:
> Steven Toth wrote:
> > Markus Rechberger wrote:
> >   
> >> On 8/9/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> >>   
> >> 
> >>> Markus Rechberger wrote:
> >>> 
> >>>   
>  On 8/9/07, Steven Toth <[EMAIL PROTECTED]> wrote:
> 
>    
>  
> > Markus Rechberger wrote:
> >
> > 
> >   
> >> Following patch adds a rather primitive way to temporary lock dvb
> >> devicenodes, this can be useful for hybrid devices which use the
> >> video4linux framework for the analogue TV part and the dvb framework 
> >> for
> >> digital TV if only one mode can be accessed at a time.
> >>
> >> Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
> >>
> >>
> >>
> >>   
> >> 
> > Call me dumb but I don't understand how this patch helps v4l devices. :)
> >
> > Allocation/management of a single card resource doesn't belong inside
> > the dvb framework, these answers need to come from the bridge-frameworks
> > (via callbacks from dvb-core or the analog equivalent) who are better
> > placed to make the decision about hybrid tuners, bus capacity or
> > allocation, in use devices.
> >
> > As a working example, I added similar support in my older HVR3000 tree
> > where two frontends share a single transport bus. The code is old but it
> > demonstrates a solution, much the my earlier patches for shared
> > DVB/Blackbird boards also.
> >
> > I understand how this patch helps the current dvb tree, it stops
> > multiple people opening a device but that's it. ... Or, maybe I've just
> > missed to point.
> >
> >
> > 
> >   
>  Hi Steve,
> 
>  the bridge framework triggers locking these filehandles.
> 
>    
>  
> >>> http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/c0817d73a2a9/linux/drivers/media/video/em28xx/em28xx-video.c
> >>> 
> >>>   
>  line 434
>  this locks the dvb nodes if someone tries to open the v4l devicenode,
>  it first checks if there's still something active at the DVB side.
> 
> 
>    
>  
> >>> http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/f9f3e6bdd6fc/linux/drivers/media/video/em28xx/em2880-dvb.c
> >>> 
> >>>   
>  Line 471 - 484 if this would go into the dvb core we'd have a callback
>  for locking the device nodes.
> 
> 
>    
>  
> >>> Your comment about lines 471-484 make sense, but that code is not
> >>> referenced via a callback (that I can see in the DVB patch) ... which is
> >>> what I expected to see.
> >>>
> >>> To do this cleanly in the dvb-core (or any v4l-core) I suggest requires
> >>> callbacks into the bridge-frameworks and I didn't see those callbacks
> >>> clearly defined in either your original patch, or your follow up
> >>> patches. I was pretty sure I did something similar for the
> >>> DVB/MpegEncoder shared bus support.
> >>>
> >>> Have you seen this? http://linuxtv.org/hg/~stoth/hvr3000/rev/4b846f1d939b
> >>>
> >>> Or more importantly this:
> >>> http://linuxtv.org/hg/~stoth/hvr3000/rev/a619436699cc
> >>>
> >>> Can we just re-use that?
> >>>
> >>> 
> >>>   
> >> Since I don't see any move forward from anyone again, can you extract
> >> that locking callback and submit it independently? I can work around
> >> the issue that the dvb core still tries to access DVB components after
> >> a device has been closed, although you might have to verify that issue
> >> within your drivers too.
> >>
> >>   
> >> 
> > Sure, I'll prepare a patch later this evening.
> >
> >   
> The ts_bus_ctrl function pointer / callback is already in the mainline, 
> check dvb_frontend.c for more details. You shouldn't need a patch from me.

ACK, should be enough to do this kind of locking.

Furthermore, with this callback, the dvb_frontend_active() routine from
'[linux-dvb] [PATCH] function for checking if the dvb framework is idle'
is not required at all. The callback is aware whether the frontend is
running or not...

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] New Revision of KNC1 DVB-S Plus 1894:0015

[Oliver Endriss]

Johannes Deisenhofer wrote:
> Hi,
> 
> I have a bunch of KNC1 DVB-S Plus Cards, with Subsystem ID 1894:0015.
> There are 'Plus' cards, with Phillips SD1878 Tuner and Analog Inputs.
> (Picture at http://www.vdr-wiki.de/wiki/index.php/Bild:Knc1splusx4.jpg)

Is 'KNC1 DVB-S plus X4' the correct name of this card?
According to your patch the name is 'SUBID_DVBS_TV_STAR_PLUS'.

> Besides the analog input, these seem to be identical to the "TV Star"
> Cards from KNC1. Adding the PCI Ids is easy, but:
> 
> Can anybody advise me how I can find out if my card needs to be added to
> this list of IDs? It's a plus card, after all. Do I need to test with a 
> CA adapter?

Would be nice (if you have a CI/CAM).

> What's different if I set / don't set the GPIO-Pin? 
>
>  From budget-av.c, line 928:
> 
>  /* additional setup necessary for the PLUS cards */
>  switch (saa->pci->subsystem_device) {
>  case SUBID_DVBS_KNC1_PLUS:
>  case SUBID_DVBC_KNC1_PLUS:
>  case SUBID_DVBT_KNC1_PLUS:
>  case SUBID_DVBS_TV_STAR_PLUS:
>  case SUBID_DVBC_EASYWATCH:
>  case SUBID_DVBC_KNC1_PLUS_MK3:
>  saa7146_setgpio(saa, 3, SAA7146_GPIO_OUTHI);
>  break;
>  }

Simply try whether it works without setting GPIO3.
If not, try with GPIO3 set to high.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] System load raises when budget_av is loaded

[Oliver Endriss]

Jukka Pirinen wrote:
> As workaround I commented out initialisation of CI interface, that's not
> a problem because I don't have CI.
> 
> diff budget-av.c.orig budget-av.c
> 1175c1175
>  ---
> >//ciintf_init(budget_av);

Could you please try to find out, why the CI thread is causing high
load? You might start checking the values of ca->delay and ca->wakeup
before wait_event_interruptible_timeout().

Sorry, I can't do this. I don't have budget-av hardware.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] budget-av/CI-interface with SMP

[Oliver Endriss]

Julian Scheel wrote:
> Am Donnerstag 16 August 2007 13:12 schrieb Julian Scheel:
> > Am Donnerstag 09 August 2007 20:34 schrieb Oliver Endriss:
> > > Well, that's not surprising.
> > > If you set uselocks=1, ttpci_budget_debiread/write must not sleep,
> > > i.e. you have to set nobusyloop=0. Does it work now?
> > >
> > > Nevertheless I don't like busy looping with interrupts disabled.
> > > AFAICS the budget_debi routines are never called from interrupt context,
> > > so it should be sufficient to use spin_[un]lock_bh() instead of
> > > spin_[un]lock_irq_save(). Could you please try this?
> >
> > When I switch from irq-lock to bh-lock while keeping uselocks = 1, the
> > error changes:
> >
> > BUG: scheduling while atomic: kdvb-ca-0:0/0x0101/28258
> >  [] __sched_text_start+0x56/0x7a4
> >  [] lock_timer_base+0x15/0x2f
> >  [] __mod_timer+0x94/0x9e
> >  [] schedule_timeout+0x70/0x8d
> >  [] __sched_text_start+0x719/0x7a4
> >  [] process_timeout+0x0/0x5
> >  [] msleep+0xd/0x12
> >  [] saa7146_wait_for_debi_done+0xda/0xec [saa7146]
> >  [] ttpci_budget_debiread+0x44/0xce [budget_core]
> >  [] ciintf_poll_slot_status+0x99/0x146 [budget_av]
> >  [] dvb_ca_en50221_check_camstatus+0x37/0xae [dvb_core]
> >  [] dvb_ca_en50221_thread+0x1c7/0xb24 [dvb_core]
> >  [] autoremove_wake_function+0x0/0x35
> >  [] do_notify_parent+0x155/0x160
> >  [] deactivate_task+0x19/0x23
> >  [] __fput+0x112/0x13c
> >  [] put_files_struct+0x64/0xa7
> >  [] do_exit+0x6a9/0x6ad
> >  [] do_page_fault+0x277/0x525
> >  [] kprobe_flush_task+0x4b/0x80
> >  [] schedule_tail+0x4f/0x87
> >  [] ret_from_fork+0x6/0x1c
> >  [] dvb_ca_en50221_thread+0x0/0xb24 [dvb_core]
> >  [] kernel_thread_helper+0x7/0x10
> >  ===

Same problem as before: Must not sleep within spinlock-ed code.

> > If I disable nobusyloop the errors are gone. I will check if the CI-module
> > keeps working properly.
> 
> If I disable nobusyloop the system becomes unresponsive after a while without 
> CAM plugged.

Does the machine freeze completely? No error messages on the console?

Does it work with CAM plugged, or does it freeze, too?

Please post the patch you are currently using.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] Suspend/Resume support for budget-av

[Oliver Endriss]

Marko Ristola wrote:
> I did for the Mantis branch a working solution for mem and disk cases.
> I haven't tested standby yet, but I think that it should be easy to
> extend if it doesn't work yet.
>
> I used linux/Documentation/power/*.txt while 
> trying to understand how to implement suspend/resume.
> 
> On my opinion, the easiest way to make standby+mem+disk work, is to 
> implement suspend() so, that you
> assume that you might lose the power if the source transition is D0.
> If the source transition state is another one, you just turn some power 
> off, but don't touch
> the saved state that resume() needs.
> (My implementation doesn't handle source transition at all now, because 
> of my limited time.)
> 
> Then you must implement resume() so, that it assumes, that you are 
> recovering from a power loss.
> You might try to optimize resume() by checking from the device or from 
> some previous kernel state,
> whether the device has actually lost it's power or not.
> 
> My Mantis suspend/resume altered too many files, and thus it isn't final 
> yet,
> but it is a working although not perfect version.
> 
> In Linux code, there is a more simple PCI suspend/resume implementation 
> in linux/drivers/pci/pci-driver.c.
> 
> pci_device_suspend(): this does a very simple and basic PCI suspend 
> operation.
> pci_default_resume(): this does a very simple and basic PCI resume 
> operation.
> So I will try to learn from them some day to lessen changes in mantis_pci.c.
> 
> My personal idea for the responsibilities is that:
> pci_save_state() and pci_restore_state() and other function calls found 
> in pci-driver.c
> will handle saving and restoring PCI state, although I absolute must 
> copy them into mantis_pci.c.
> Then on resume, I have to restore non-pci states, I mean those that 
> aren't restored by
> pci_restore_state(), pci_set_master() and such. In Mantis there is 
> according to Manu at least
> tuner power setting and retuning. I don't know the working and optimally 
> small solution yet that
> Manu requires: there is still testing to be done for me in Mantis.
> 
> With a very small understanding, I have been able to implement a working 
> patch though.
> 
> So I'd suggest for you to check out drivers/pci/pci-driver.c first to 
> implement similar PCI
> functionality into budget-av. That might fix S2MEM and S2DISK. Or then 
> there is still something
> more that has to be done.
> 
> With my implementation I can use Kaffeine so, that after S2DISK, 
> Kaffeine will continue showing
> the channel that it showed before. Kaffeine doesn't have to retune or 
> restart DMA transfer.
> So only some frames were lost.
> Kaffeine didn't work properly with USB based sound output, and thus I needed
> motherboard internal sound output for the tests.

Thanks for your response.

Meanwhile I had a look at Documentation/power and did more tests.

For a proper suspend/restore implementation there is much more to be
done. The state of the saa7146 must be saved/restored, which requires
more than a few hours of work (and testing!). I put it on my todo list.

Is there any way to find out the power state the system tries to enter
(standby/mem/disk)?

For now, I could add support for standby mode and deny any attempt to
enter mem or disk supend mode. Better than nothing...

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer

[Oliver Endriss]

André Weidemann wrote:
> Oliver Endriss wrote:
> > Sigmund Augdal wrote:
> >> On Tuesday 17 July 2007 07:45, Oliver Endriss wrote:
> >>> Oliver Endriss wrote:
> >>>> Imho the interrupt processing was broken:
> >>>> - The first I2C interrupt should be used to wake-up the task.
> >>>>   It does not matter that it takes some time until ERR in IIC_STA
> >>>>   will be updated. We don't need it.
> >>>> - Interrupts must be acknowledged at the end of the ISR.
> >>>>
> >>>> @all
> >>>> Please test the attached patch.
> >>>> There shouldn't be any unexpected I2C interrupts anymore.
> >>> Attached is an updated patch which does extended status checking.
> >> I've tried this patch on a box running 2.6.20 now for about a day and has 
> >> not 
> >> yet seen any i2c timeouts with it. I have tried to stress the i2c bus a 
> >> bit 
> >> by starting and stopping capture, retuning and browsing the MMI menus of 
> >> the 
> >> CAM quite a lot. I did however not see any pattern in when the i2c 
> >> timeouts 
> >> happened before applying the patch, so I can't possitivly confirm they are 
> >> all gone.
> > 
> > Ok, patch committed with minor modifications.
> 
> Hi Oliver,
> I just had time to read the mailing list after several weeks and 
> stumbled accross this thread.
> 
> I have this error: "saa7146_i2c_writeout: timed out waiting for end of 
> xfer".
> This error occurs with and without the patch, but only on my modded FF 
> Card(TT1500 DVB-S) with 4MB. Any other card works flawlessly in the same 
> comp and the very same PCI slot. I have two other TT1600 DVB-s which are 
> not modded and working just fine.
> 
> Could the problems be caused by the 4MB-Mod?

No, the 4MB-Mod has nothing to do with the saa7146.

It is not clear what causes these timeouts. Meanwhile I think that
these timeouts are not related to interrupt mode at all.

Please try the current HG driver. (Important because timeouts are now
logged in poll mode, too.)

If it still happens, please replace SAA7146_USE_I2C_IRQ by
SAA7146_I2C_SHORT_DELAY in av7110.c. Does it help?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] Suspend/Resume support for budget-av

[Oliver Endriss]

Julian Scheel wrote:
> Oliver Endriss schrieb:
> > Julian Scheel wrote:
> >   
> >> Attached is a patch with adds full support for suspend/resume in 
> >> budget-av. 
> >> Actually only the CI interface needs to be reinitialised as all the tuner 
> >> stuff gets reinitialised at the next tuning-process anyway.
> >> So this patch should be ready to go pretty straightforward into head.
> >> 
> >
> > Please post the sub-system ids of the cards you tested and which power
> > states you tested.
> >   
> Going to look up the IDs later, when I have access to my dev-system.
> But it should be all current KNC DVB-C and DVB-S cards.
> >> diff -r c45e373bbca3 linux/drivers/media/common/saa7146_core.c
> >> --- a/linux/drivers/media/common/saa7146_core.c Sat Jul 28 00:06:44 2007 
> >> -0300
> >> +++ b/linux/drivers/media/common/saa7146_core.c Tue Aug 07 23:22:54 2007 
> >> +0200
> >> @@ -515,6 +515,28 @@ static void saa7146_remove_one(struct pc
> >> saa7146_num--;
> >>  }
> >>
> >> +static int saa7146_suspend(struct pci_dev *pdev)
> >> +{
> >> +   struct saa7146_dev* dev = pci_get_drvdata(pdev);
> >> +   DEB_EE(("dev:%p\n",dev));
> >> +   int err;
> >> +
> >> +   err = dev->ext->suspend(dev);
> >> 
> >   ^
> > Causes an oops if the card driver did not set the suspend hook.
> >
> > Fix:
> > int err = -EBUSY;
> > if (dev->ext->suspend)
> > err = dev->ext->suspend(dev);
> >   
> Agreed (c:
> >> +
> >> +   return err;
> >> +}
> >> +
> >> +static int saa7146_resume(struct pci_dev *pdev)
> >> +{
> >> +   struct saa7146_dev* dev = pci_get_drvdata(pdev);
> >> +   DEB_EE(("dev:%p\n",dev));
> >> +   int err;
> >> +
> >> +   err = dev->ext->resume(dev);
> >> 
> >
> > ditto
> >
> > IMO this patch can only work with S1 state. Higher states turn off PCI
> > power and require re-initialization of saa7146, demod, tuner etc.
> > See other drivers which fully implement suspend/resume.
> >   
> Works perfectly fine with S3-state for me. Actually S3 always worked 
> fine, only ci interface did not work anymore after S3, that is fixed 
> with this patch.

Hm, I did some tests with budget.c:
- "echo standby > /sys/power/state" works
- "echo mem > /sys/power/state" does not work!
- "echo disk > /sys/power/state" does not work!

It works if the PCI bus stays 'on', i.e. the card is not powered-off.
So there is much more to be done if we want to support power states
properly.

Btw, could you test if the CI works without reinitialisation if you
apply the attached patch? I can't test it. Without this patch the kernel
thread will die and the CI does not work anymore...

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/

diff -r 600876f4508f linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	Thu Aug 09 07:41:16 2007 +0200
+++ b/linux/drivers/media/dvb/dvb-core/dvb_ca_en50221.c	Sun Aug 12 14:39:07 2007 +0200
@@ -38,8 +38,15 @@
 #include 
 #include 
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
+#include 
+#else
+#include 
+#endif
+
 #include "dvb_ca_en50221.h"
 #include "dvb_ringbuffer.h"
+#include "compat.h"
 
 static int dvb_ca_en50221_debug;
 
@@ -1002,6 +1009,8 @@ static int dvb_ca_en50221_thread(void *d
 	/* choose the correct initial delay */
 	dvb_ca_en50221_thread_update_delay(ca);
 
+	set_freezable();
+
 	/* main loop */
 	while (!ca->exit) {
 		/* sleep for a bit */
@@ -1009,6 +1018,8 @@ static int dvb_ca_en50221_thread(void *d
 			flags = wait_event_interruptible_timeout(ca->thread_queue,
  dvb_ca_en50221_thread_should_wakeup(ca),
  ca->delay);
+			if (try_to_freeze())
+continue;
 			if ((flags == -ERESTARTSYS) || ca->exit) {
 /* got signal or quitting */
 break;
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] budget-av/CI-interface with SMP

[Oliver Endriss]

Julian Scheel wrote:
> Oliver Endriss schrieb:
> > Julian Scheel wrote:
> >   
> >> Attached is a patch which fixes an issue which I see with budget-av based 
> >> cards using libdvben50221 based programs.
> >> After some time (sometimes just a few minutes, sometimes hours) the stack 
> >> breaks with error -2 or -3 and won't recover until the modules are 
> >> reloaded.
> >> 
> >
> > Please post the error log.
> >
> >   
> >> This does not happen anymore with this patch, but if no CI-interface is 
> >> connected this patch floads the syslog with weird error-messages of which 
> >> I 
> >> have no idea why they are shown.
> >> 
> >
> > Please post a log of these error messages.
> >
> > Thanks,
> >
> > Oliver
> >
> >   
> Sure, this is the error that loops all over:
> BUG: scheduling while atomic: kdvb-ca-0:0/0x0001/3030
>  [] __sched_text_start+0x56/0x7a4
>  [] lock_timer_base+0x15/0x2f
>  [] __mod_timer+0x94/0x9e
>  [] schedule_timeout+0x70/0x8d
>  [] __sched_text_start+0x719/0x7a4
>  [] process_timeout+0x0/0x5
>  [] msleep+0xd/0x12
>  [] saa7146_wait_for_debi_done+0xda/0xec [saa7146]
>  [] ttpci_budget_debiread+0x47/0xd6 [budget_core]
>  [] ciintf_poll_slot_status+0x99/0x146 [budget_av]
>  [] dvb_ca_en50221_check_camstatus+0x37/0xae [dvb_core]
>  [] dvb_ca_en50221_thread+0x1c7/0xb24 [dvb_core]
>  [] autoremove_wake_function+0x0/0x35
>  [] do_exit+0x6a9/0x6ad
>  [] do_page_fault+0x277/0x525
>  [] kprobe_flush_task+0x4b/0x80
>  [] schedule_tail+0x4f/0x87
>  [] ret_from_fork+0x6/0x1c
>  [] dvb_ca_en50221_thread+0x0/0xb24 [dvb_core]
>  [] kernel_thread_helper+0x7/0x10
>  ===

Well, that's not surprising.
If you set uselocks=1, ttpci_budget_debiread/write must not sleep,
i.e. you have to set nobusyloop=0. Does it work now?

Nevertheless I don't like busy looping with interrupts disabled.
AFAICS the budget_debi routines are never called from interrupt context,
so it should be sufficient to use spin_[un]lock_bh() instead of
spin_[un]lock_irq_save(). Could you please try this?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer

[Oliver Endriss]

Sigmund Augdal wrote:
> On Tuesday 17 July 2007 07:45, Oliver Endriss wrote:
> > Oliver Endriss wrote:
> > > Imho the interrupt processing was broken:
> > > - The first I2C interrupt should be used to wake-up the task.
> > >   It does not matter that it takes some time until ERR in IIC_STA
> > >   will be updated. We don't need it.
> > > - Interrupts must be acknowledged at the end of the ISR.
> > >
> > > @all
> > > Please test the attached patch.
> > > There shouldn't be any unexpected I2C interrupts anymore.
> >
> > Attached is an updated patch which does extended status checking.
> I've tried this patch on a box running 2.6.20 now for about a day and has not 
> yet seen any i2c timeouts with it. I have tried to stress the i2c bus a bit 
> by starting and stopping capture, retuning and browsing the MMI menus of the 
> CAM quite a lot. I did however not see any pattern in when the i2c timeouts 
> happened before applying the patch, so I can't possitivly confirm they are 
> all gone.

Ok, patch committed with minor modifications.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Oliver Endriss]

Michael Krufky wrote:
> Oliver Endriss wrote:
> 
> >Manu Abraham wrote:
> >  
> >
> >>On 8/6/07, Michael Krufky <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Now I'm beginning to have doubts about Oliver's original patch:
> >>>
> >>>dvb_frontend: Range check of frequency and symbol rate
> >>>http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
> >>>
> >>>Should we be checking fe->ops.tuner_ops.info.frequency_min|max , instead of
> >>>fe->ops.info.frequency_min|max ???
> >>>  
> >>>
> >>Ideally, what's provided by the demod and not the tuner max/min. The
> >>tuners max/min should be checked by the demod on setting params.
> >>
> >>The upper/lower limits in the demodulator drivers, came from the
> >>concept of a frontend as a whole. Independant bounds do not make sense
> >>(except internally -- It is the demod driver that which sets
> >>parameters for the tuner. The external world doesn't need to know
> >>what's the limit of the tuner, but only of the frontend as a whole).
> >>
> >>Ideally, the demodulator should just demodulate only. There are some
> >>cases, there are some cases which are not.
> >>
> >>
> >
> >Ok, I'm trying to put all pieces together:
> >There might be cases where demod and tuner have different limits.
> >
> >So FE_GET_INFO and dvb_frontend_check_parameters() should use the
> >'smallest common bandwidth':
> >
> >freq_min = max(fe->ops.info.frequency_min, 
> >fe->ops.tuner_ops.info.frequency_min);
> >
> >if (fe->ops.info.frequency_max == 0)
> > freq_max = fe->ops.tuner_ops.info.frequency_max;
> >else if (fe->ops.tuner_ops.info.frequency_max == 0)
> > freq_max = fe->ops.info.frequency_max;
> >else
> > freq_max = min(fe->ops.info.frequency_max, 
> > fe->ops.tuner_ops.info.frequency_max);
> >
> >if (freq_min == 0 || freq_max == 0)
> > printk(KERN_WARNING "frequency limits undefined - please fix the 
> > driver\n");
> >
> >Conclusions:
> >- A tuner-only driver must set fe->ops.tuner_ops.info.
> >- Monolithic drivers must set fe->ops.tuner_ops.info or fe->ops.info
> >  (or both).
> >  
> >
> I apologize for my delayed response -- I had to leave town unexpectedly.

No problem.

> The above is OK with me.  As I understand it, we cannot remove 
> fe->ops.info.frequency_max|min because it is part of the userspace API.  
> I wasn't thinking about that fact when I wrote my last email in this 
> thread.  We should keep this in mind, for whenever the time comes that 
> we do have to break API compat.

Basically, the internal data structures don't have to be the same as the
external API data structures. The GET_INFO ioctl might collect its data
from anywhere...

I think we should postpone cleaning-up the frontend data until
multiproto has been merged. It will add more compatibility stuff,
so it might be worth cleaning up these things afterwards.

For now I have committed Hartmut's patch and the fix above.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] budget-av/CI-interface with SMP

[Oliver Endriss]

Julian Scheel wrote:
> Attached is a patch which fixes an issue which I see with budget-av based 
> cards using libdvben50221 based programs.
> After some time (sometimes just a few minutes, sometimes hours) the stack 
> breaks with error -2 or -3 and won't recover until the modules are reloaded.

Please post the error log.

> This does not happen anymore with this patch, but if no CI-interface is 
> connected this patch floads the syslog with weird error-messages of which I 
> have no idea why they are shown.

Please post a log of these error messages.

Thanks,

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] Suspend/Resume support for budget-av

[Oliver Endriss]

Julian Scheel wrote:
> Attached is a patch with adds full support for suspend/resume in budget-av. 
> Actually only the CI interface needs to be reinitialised as all the tuner 
> stuff gets reinitialised at the next tuning-process anyway.
> So this patch should be ready to go pretty straightforward into head.

Please post the sub-system ids of the cards you tested and which power
states you tested.

> diff -r c45e373bbca3 linux/drivers/media/common/saa7146_core.c
> --- a/linux/drivers/media/common/saa7146_core.c Sat Jul 28 00:06:44 2007 -0300
> +++ b/linux/drivers/media/common/saa7146_core.c Tue Aug 07 23:22:54 2007 +0200
> @@ -515,6 +515,28 @@ static void saa7146_remove_one(struct pc
> saa7146_num--;
>  }
>
> +static int saa7146_suspend(struct pci_dev *pdev)
> +{
> +   struct saa7146_dev* dev = pci_get_drvdata(pdev);
> +   DEB_EE(("dev:%p\n",dev));
> +   int err;
> +
> +   err = dev->ext->suspend(dev);
  ^
Causes an oops if the card driver did not set the suspend hook.

Fix:
int err = -EBUSY;
if (dev->ext->suspend)
err = dev->ext->suspend(dev);

> +
> +   return err;
> +}
> +
> +static int saa7146_resume(struct pci_dev *pdev)
> +{
> +   struct saa7146_dev* dev = pci_get_drvdata(pdev);
> +   DEB_EE(("dev:%p\n",dev));
> +   int err;
> +
> +   err = dev->ext->resume(dev);

ditto

IMO this patch can only work with S1 state. Higher states turn off PCI
power and require re-initialization of saa7146, demod, tuner etc.
See other drivers which fully implement suspend/resume.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Oliver Endriss]

Manu Abraham wrote:
> On 8/6/07, Michael Krufky <[EMAIL PROTECTED]> wrote:
> >
> > Now I'm beginning to have doubts about Oliver's original patch:
> >
> > dvb_frontend: Range check of frequency and symbol rate
> > http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
> >
> > Should we be checking fe->ops.tuner_ops.info.frequency_min|max , instead of
> > fe->ops.info.frequency_min|max ???
> 
> 
> Ideally, what's provided by the demod and not the tuner max/min. The
> tuners max/min should be checked by the demod on setting params.
> 
> The upper/lower limits in the demodulator drivers, came from the
> concept of a frontend as a whole. Independant bounds do not make sense
> (except internally -- It is the demod driver that which sets
> parameters for the tuner. The external world doesn't need to know
> what's the limit of the tuner, but only of the frontend as a whole).
> 
> Ideally, the demodulator should just demodulate only. There are some
> cases, there are some cases which are not.

Ok, I'm trying to put all pieces together:
There might be cases where demod and tuner have different limits.

So FE_GET_INFO and dvb_frontend_check_parameters() should use the
'smallest common bandwidth':

freq_min = max(fe->ops.info.frequency_min, 
fe->ops.tuner_ops.info.frequency_min);

if (fe->ops.info.frequency_max == 0)
freq_max = fe->ops.tuner_ops.info.frequency_max;
else if (fe->ops.tuner_ops.info.frequency_max == 0)
freq_max = fe->ops.info.frequency_max;
else
freq_max = min(fe->ops.info.frequency_max, 
fe->ops.tuner_ops.info.frequency_max);

if (freq_min == 0 || freq_max == 0)
printk(KERN_WARNING "frequency limits undefined - please fix the 
driver\n");

Conclusions:
- A tuner-only driver must set fe->ops.tuner_ops.info.
- Monolithic drivers must set fe->ops.tuner_ops.info or fe->ops.info
  (or both).

Ok?

CU
Oliver


-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Oliver Endriss]

e9hack wrote:
> Currently, I'm missing something in the tuner modules (and I didn't ask for 
> it). It isn't possible
> to wait for getting the pll lock. The tuning function of the TT-C2300 does 
> wait. It isn't possible
> to switch the time constant of the loop filter after getting the lock. 
> Usually, it is recommended
> for any pll chips.

Have a look how I implemented that in the tda10086 driver (search for
'has_lock').

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Oliver Endriss]

Michael Krufky wrote:
> Oliver Endriss wrote:
> > Michael Krufky wrote:
> >> Trent Piepho wrote:
> >>> On Mon, 6 Aug 2007, e9hack wrote:
> >>>> Michael Krufky schrieb:
> >>>>> Now I'm beginning to have doubts about Oliver's original patch:
> >>>>>
> >>>>> dvb_frontend: Range check of frequency and symbol rate
> >>>>> http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
> >>>>>
> >>>>> Should we be checking fe->ops.tuner_ops.info.frequency_min|max , 
> >>>>> instead of
> >>>>> fe->ops.info.frequency_min|max ???
> >>>>>
> >>>> I didn't see the ranges from the tuner, because the dvb-c drivers don't 
> >>>> use the pll framework. They
> >>>> have very simple tuning functions only. We should use both values. One 
> >>>> part may be more restrictive
> >>>> than the other one.
> >>> Most demodulators don't have frequency ranges.  They just take whatever 
> >>> the
> >>> tuner gives them at a fixed intermediate frequency.  It's really the tuner
> >>> that has the frequency range.
> > 
> > Agreed.
> > 
> >>> I think it would make more sense for the demodulator drivers to fill
> >>> fe->ops.info.frequency_min|max using 
> >>> fe->ops.tuner_ops.info.frequency_min|max.
> >>> A frontend driver that doesn't use a separate tuner driver (like DST) 
> >>> would
> >>> set the fe->ops.info.frequency_min|max directly.
> > 
> > Afaics the demod driver cannot fill fe->ops.info.frequency_min|max using
> > fe->ops.tuner_ops.info.frequency_min|max, because the tuner driver will
> > be attached _after_ the demod driver (see budget-av.c for example).
> > 
> >> The way I see it, the demod driver that doesn't have a separate tuner 
> >> driver
> >> should just go ahead and fill ops.tuner_ops.info.frequency_min|max , 
> >> because
> >> otherwise those fields will be there anyway, just remaining empty.  Those
> >> structures are not pointers, and we should always be able to rely on their 
> >> presence.
> >>
> >> There is no need for BOTH ops.info.frequency_min|max AND
> >> ops.tuner_ops.info.frequency_min|max
> > 
> > The following drivers set ops.tuner_ops.info.frequency_min|max:
> > dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100.
> > 
> > All other drivers use ops.info.frequency_min|max.
> > 
> > What about this:
> > dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if
> > non-zero. Otherwise it would continue to use ops.info.frequency_min|max.
> 
> That's fine with me... except I just don't see why we shouldn't just have the
> demod drivers that have the integrated tuning functionality just fill
> tuner_ops.info.frequency_max|min anyway.  The point is, the structures will be
> present regardless of whether any tuner_ops are actually filled.  This is an
> opportunity to remove the frequency_min|max from the demod ops.info structure,
> as we all agree that it is inappropriate there anyhow.  If we do this, then we
> will have a standard across the board.

That's fine if we agree that we have to touch most frontend drivers.

If we choose to do that, we should remove ops.info.frequency_min|max,
i.e. remove 'struct dvb_frontend_info' from 'struct frontend_ops' and
add something like 'struct dvb_demod_info' instead.

We must not modify 'struct dvb_frontend_info' because it is an API data
structure.

Afaics 'frequency_stepsize' can be substituted by 'frequency_step',
but what should we do with 'frequency_tolerance'?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Oliver Endriss]

Michael Krufky wrote:
> Trent Piepho wrote:
> > On Mon, 6 Aug 2007, e9hack wrote:
> >> Michael Krufky schrieb:
> >>> Now I'm beginning to have doubts about Oliver's original patch:
> >>>
> >>> dvb_frontend: Range check of frequency and symbol rate
> >>> http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
> >>>
> >>> Should we be checking fe->ops.tuner_ops.info.frequency_min|max , instead 
> >>> of
> >>> fe->ops.info.frequency_min|max ???
> >>>
> >> I didn't see the ranges from the tuner, because the dvb-c drivers don't 
> >> use the pll framework. They
> >> have very simple tuning functions only. We should use both values. One 
> >> part may be more restrictive
> >> than the other one.
> > 
> > Most demodulators don't have frequency ranges.  They just take whatever the
> > tuner gives them at a fixed intermediate frequency.  It's really the tuner
> > that has the frequency range.

Agreed.

> > I think it would make more sense for the demodulator drivers to fill
> > fe->ops.info.frequency_min|max using 
> > fe->ops.tuner_ops.info.frequency_min|max.
> > A frontend driver that doesn't use a separate tuner driver (like DST) would
> > set the fe->ops.info.frequency_min|max directly.

Afaics the demod driver cannot fill fe->ops.info.frequency_min|max using
fe->ops.tuner_ops.info.frequency_min|max, because the tuner driver will
be attached _after_ the demod driver (see budget-av.c for example).

> The way I see it, the demod driver that doesn't have a separate tuner driver
> should just go ahead and fill ops.tuner_ops.info.frequency_min|max , because
> otherwise those fields will be there anyway, just remaining empty.  Those
> structures are not pointers, and we should always be able to rely on their 
> presence.
>
> There is no need for BOTH ops.info.frequency_min|max AND
> ops.tuner_ops.info.frequency_min|max

The following drivers set ops.tuner_ops.info.frequency_min|max:
dvb-pll, mt2060, qt1010, tda826x, tda827x, tua6100.

All other drivers use ops.info.frequency_min|max.

What about this:
dvb_frontend.c shall use ops.tuner_ops.info.frequency_min|max if
non-zero. Otherwise it would continue to use ops.info.frequency_min|max.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Oliver Endriss]

Michael Krufky wrote:
> Oliver Endriss wrote:
> > Michael Krufky wrote:
> >   
> >> e9hack wrote:
> >> 
> >>> Hi,
> >>>
> >>> the min frequencies of the DVB-C frontends are wrong. In Europe, the 
> >>> center frequency of the lowest
> >>> channel is 50.5MHz and not 51MHz. All known cards with the 
> >>> stv0297/tda0002x/ves1820 frontend are
> >>> able to tune to this frequency. I've changed the range to the lowest 
> >>> channel - 1/2 bandwidth and the
> >>> highest channel + 1/2 bandwidth. For the design of the dvb driver, the 
> >>> frequency ranges must be part
> >>> of the tuner and not of the frontend itself. The same frontend may be 
> >>> used for different tuners. The
> >>> attached patch does only fix the ranges and not the design.
> >>>   
> >> Now I'm beginning to have doubts about Oliver's original patch:
> >>
> >> dvb_frontend: Range check of frequency and symbol rate
> >> http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
> >>
> >> Should we be checking fe->ops.tuner_ops.info.frequency_min|max , instead of
> >> fe->ops.info.frequency_min|max ???
> >> 
> >
> > Hm, I was not aware that there is another info.frequency_min|max
> > in tuner_ops. :-(
> >
> > Do we need both of them?
> I think it's most appropriate to keep tuner_ops.info.frequency_min|max ,
> since it is the tuner that we're talking about.  If the demodulator
> itself does not have such limitations, then we should not have such a
> field in the demod ops.info section.
> 
> I believe that this is leftover from before Andrew's original dvb tuner
> refactoring.

It is an API issue: FE_GET_INFO returns fe->ops.info, so we cannot
easily drop this field.

What about modifying dvb_pll_attach to override fe->ops.info.frequency?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends

[Oliver Endriss]

Michael Krufky wrote:
> e9hack wrote:
> > Hi,
> > 
> > the min frequencies of the DVB-C frontends are wrong. In Europe, the center 
> > frequency of the lowest
> > channel is 50.5MHz and not 51MHz. All known cards with the 
> > stv0297/tda0002x/ves1820 frontend are
> > able to tune to this frequency. I've changed the range to the lowest 
> > channel - 1/2 bandwidth and the
> > highest channel + 1/2 bandwidth. For the design of the dvb driver, the 
> > frequency ranges must be part
> > of the tuner and not of the frontend itself. The same frontend may be used 
> > for different tuners. The
> > attached patch does only fix the ranges and not the design.
> 
> Now I'm beginning to have doubts about Oliver's original patch:
> 
> dvb_frontend: Range check of frequency and symbol rate
> http://linuxtv.org/hg/v4l-dvb/rev/8186a34dd0a6
> 
> Should we be checking fe->ops.tuner_ops.info.frequency_min|max , instead of
> fe->ops.info.frequency_min|max ???

Hm, I was not aware that there is another info.frequency_min|max
in tuner_ops. :-(

Do we need both of them?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] DVB-S2 support

[Oliver Endriss]

Steven Toth wrote:
> ... But were a way off, perhaps months from seeing multiproto accept in 
> v4l-dvb hg.

Why? I think it's time to get multiproto into the main tree.

We should review the API and dvb core changes asap.

For me the API looks fine except for the modified FE_GET_EVENT ioctl,
which is not backward compatible. When this issue has been fixed. there
are no major problems afaics.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] frequency out of range - Problems

[Oliver Endriss]

Michael Krufky wrote:
> Manu Abraham wrote:
> > On 8/6/07, Lars Buerding <[EMAIL PROTECTED]> wrote:
> >> Hello Manu,
> >>
>  I am getting these messages using the latest available tip-version
>  (v4l-dvb-5bb1af77fdc5).
> 
>  --
>  Aug  6 07:07:17 gwmuc kernel: DVB: frontend 0 frequency 151 out of
>  range (95..140)
>  Aug  6 07:08:05 gwmuc kernel: DVB: frontend 0 frequency 1958000 out of
>  range (95..140)
>  --
> 
> >>> In frontends/tda8083.c
> >>>
> >>> Look for this:
> >>>   446 .frequency_min  = 95, /* FIXME: 
> >>> guessed! */
> >>>   447 .frequency_max  = 140,/* FIXME: 
> >>> guessed! */
> >>>
> >>> change to line: #447 to
> >>>
> >>> .frequency_max = 215,
> >>>
> >>> This should fix your problem.
> >>>
> >>> Manu
> >>>
> >> I did that and it looks good - at least I can switch to the channels
> >> again and can grab a picture inside vdradmin, I am a bit too far away
> >> from my VDR currently :)
> > 
> > N' joy :)
> 
> Manu,
> 
> Do you have a spec for that demod?  If so, would you kindly update the driver 
> so
> that users don't have to worry about this issue?

According to the crippled datasheet, a symbol rate from 12..30 MSym/s
should be correct for the TDA8083.

The Grundig 29504-451 tuner uses the TDA8060 down-converter, which has a
frequency range from 920..2200MHz.

So the attached patch should fix the range issues. Ok?

CU
Oliver

- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/

diff -r 8f9147c3bacd linux/drivers/media/dvb/frontends/tda8083.c
--- a/linux/drivers/media/dvb/frontends/tda8083.c	Wed Aug 01 12:14:44 2007 -0300
+++ b/linux/drivers/media/dvb/frontends/tda8083.c	Mon Aug 06 18:06:09 2007 +0200
@@ -443,12 +443,12 @@ static struct dvb_frontend_ops tda8083_o
 	.info = {
 		.name			= "Philips TDA8083 DVB-S",
 		.type			= FE_QPSK,
-		.frequency_min		= 95, /* FIXME: guessed! */
-		.frequency_max		= 140,/* FIXME: guessed! */
+		.frequency_min		= 92, /* TDA8060 */
+		.frequency_max		= 220,/* TDA8060 */
 		.frequency_stepsize	= 125,   /* kHz for QPSK frontends */
 	/*  .frequency_tolerance	= ???,*/
-		.symbol_rate_min	= 100,   /* FIXME: guessed! */
-		.symbol_rate_max	= 4500,  /* FIXME: guessed! */
+		.symbol_rate_min	= 1200,
+		.symbol_rate_max	= 3000,
 	/*  .symbol_rate_tolerance	= ???,*/
 		.caps = FE_CAN_INVERSION_AUTO |
 			FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Problems with SMP (i.e. dualcore) system: dvb-ttpci: warning: timeout waiting in LoadBitmap

[Oliver Endriss]

Sven Mueller wrote:
> Oliver Endriss wrote on 01/08/2007 00:27:
> > Sven Mueller wrote:
> >> Hi.
> >>
> >> I don't know which hardware interrupts those are mapped from/to and
> >> currently don't know how to find out.
> >>
> >> If you need any further data to give a helpful answer, don't hesitate to
> >> ask.
> > 
> > Which firmware are you using?
> 
> Most recent AFAICT (261f).

Nope, the most recent firmware is
http://linuxtv.org/downloads/firmware/dvb-ttpci-01.fw-2622

or the latest experimental firmware
http://www.suse.de/~werner/test_av-f12623.tar.bz2

> > A log showing driver startup might be useful.
> 
> Do you mean this?
> 
> dvb-ttpci: gpioirq unknown type=0 len=0
> dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068,
> app 8000261f
> dvb-ttpci: firmware @ card 1 supports CI link layer interface
> dvb-ttpci: Crystal audio DAC @ card 1 detected
> dvb-ttpci: found av7110-0.
> 
> > Does OSD work fine before the error occurres?
> 
> Yes
> 
> > Does the VDR recover if you wait some time (1 or 2 minutes) before you
> > press the next key?
> 
> Sometimes (if I interpret things correctly though, this is due to an
> internal watchdog in VDR triggering a restart, which now, on my system,
> includes module unload/reload due to my problems).

With recent firmware VDR should recover _without_ emergency exit.

> > You might also try whether this driver improves things:
> > http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring/
> 
> Will take a look into that later once I find some time.
> 
> One think fixed the problem for me, for now though:
> noapic nolapic
> on the kernel commandline (grub).

Are you sure that this did not disable SMP?

> However the system runs stable in every other aspect, so it seems to me
> that enabling apic/lapic does something which the dvb_ttpci driver
> doesn't handle properly on SMP systems.

There is no special handling for SMP or non-SMP systems.
Of course there might be a bug which will only show up with SMP. :-(

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [RFC PATCH] Choose dvb adapter number with a driver specific module option

[Oliver Endriss]

Janne Grunau wrote:
> Hi,
> 
> Dynamic loading of modules by udev on startup (aka coldplugging) doesn't
> result in deterministic dvb adapter numbers.
> 
> V4L drivers have the {radio|vbi|video}_nr module options to allocate
> static minor numbers per driver.
> Attached patch adds a similiar mechanism to the dvb subsystem. To avoid
> problems with device unplugging and repluging each driver holds
> a DVB_MAX_ADAPTER long array of the preffered order of adapter numbers.
> options dvb-usb-dib0700 adapter_nr=7,6,5,4,3,2,1,0 would result in a
> reversed allocation of adapter numbers.
> With adapter_nr=2,5 it tries first to get adapter number 2 and 5. If both
> are already in use it will allocate the lowest free adapter number.
> 
> Besides following changes in dvb-core and dvb-usb core the patch adds to
> all drivers 
> ...

While I don't care much whether there is an option for this in the
driver, I'd like to point out that this is the wrong approach (imho).

Citing Greg Kroah-Hartman (udev-113/docs/udev_vs_devfs):
|...
|2) udev does not care about the major/minor number schemes.  If the
|   kernel tomorrow switches to randomly assign major and minor numbers
|   to different devices, it would work just fine (this is exactly
|   what I am proposing to do in 2.7...)
|3) This is the main reason udev is around.  It provides the ability
|   to name devices in a persistent manner.  More on that below.
|...

According to this, adding such an option is a step into the wrong
direction. The right way is to fix the udev scripts...

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] Re : Professional trolls

[Oliver Endriss]

manu wrote:
> Well for reading this list out of curiosity for a while (also I have a  
> TT S-1500 CI that I plan to use soon ;-) I for sure am surprised by the  
> amount of "noise" surrounding actual coding discussion. I have  
> participated in another free software project and things were much  
> smoother.
> I understand that some people will just not get along, but things sound  
> really nasty sometimes here.

Don't worry, this happens from time to time. It is a problem in the good
old USENET, and there is the same problem in the Internet.
Apparently we have to live with it.

If you are really interested, look at the mailing list archives and you
will see, when this started and who is responsible...

Simply blacklist the offending mail addresses, and they will never
bother you again. ;-)

Meanwhile I have blacklisted 3 or 4 list users.
And an ex-maintainer will enter my killfile soon, if he will not stop
abusing this mailing list for his propaganda.

This list was created for technical discussions and user support,
not for frustrated egoists!

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] CAM problem with Cinergy/KNCONE DVB-C card

[Oliver Endriss]

e9hack wrote:
> Hi,
> 
> some people do report, that the CAM on a Cinergy/KNCONE DVB-C card doesn't 
> work. They get the
> following log entries (repeated many times):
> 
> budget-av: cam inserted A
> budget-av: cam inserted B
> dvb_ca adapter 1: DVB CAM detected and initialised successfully
> budget-av: cam ejected 3
> ...
> 
> It seems, that is never possible to read a control value of 0xff from address 
> 0 or 1 of the CAM. The
> attached patch may fix this problem. I didn't test this patch by myself, 
> because I don't need a CAM.
> 
> If someone uses a Cinergy/KNCONE DVB-C/T/S card with a CAM, please test this 
> patch.

| ... ((result == 0xff) && ((address & 3) < 2)) ...

What does result 0xff mean?
Btw, there is no such check in the budget-ci driver.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer

[Oliver Endriss]

Stone wrote:
> >
> >
> > > Did this patch solve everyone's problems?  Is is checked in now?
> >
> > There was little feedback, so it's not in the repository yet.
> >
> > I would really appreciate if more people would test this patch,
> > no matter whether they have a problem with the current driver
> > or not. It would reduce the risk to introduce a bug.
> 
> I did not have any problems before this patch was introduced, but I have
> been using this patch since it was posted without any problems.  These
> changes seem fine to me.

Thank you for the feedback.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] Problems with SMP (i.e. dualcore) system: dvb-ttpci: warning: timeout waiting in LoadBitmap

[Oliver Endriss]

Sven Mueller wrote:
> Hi.
> 
> I'm running my vdr on an up-to-date (with respects to BIOS) ASUS
> mainboard P5VD2-X with an Intel Pentium DualCore E2160 (a 65Watts
> dualcore at 1800MHz). Kernel version is 2.6.18-4 (from Debian/ctvdr6).
> The system has two IDE disks (with DMA enabled of course) and both a
> budget (Nova-S) and a full featured (Nexus-S, rev. 1.5 IIRC) DVB-S PCI card.
> 
> If I boot 2.6.18-4-486 (which is a non-SMP kernel so only one core is
> used), my vdr works perfectly nice. However, when I boot 2.6.18-4-686 or
> any other SMP kernel (self-built or not, with Debian/ctvdr patches or a
> stock kernel up to version 2.6.22, I tried everything apart from diving
> into the code myself), I get the error message quoted in the subject
> line (in syslog):
> 
> kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
> 
> And vdr seems to retry loading the Bitmap (as further messages of the
> kind appear until I kill vdr and remove+reload the DVB kernel modules).
> The error isn't 100% reproducible but usually occures when I try to open
> vdr's on-screen menu. Once the first message of that kind occures, vdr
> isn't responsible to keyboard/LIRC inputs anymore.
> 
> Any ideas how to fix this problem? I would really love to be able to use
> both cores of my CPU and still have a working vdr.
> 
> "lspci -v" output for the DVB-S cards:
> 
> 04:04.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
> Subsystem: Technotrend Systemtechnik GmbH
>Siemens/Technotrend/Hauppauge DVB card
>rev1.3 or rev1.5
> Flags: bus master, medium devsel, latency 32, IRQ 50
> Memory at dfeff000 (32-bit, non-prefetchable) [size=512]
> 
> 04:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
> Subsystem: Technotrend Systemtechnik GmbH
>Technotrend-Budget/Hauppauge WinTV-NOVA-S DVB card
> Flags: bus master, medium devsel, latency 32, IRQ 233
> Memory at dfefe000 (32-bit, non-prefetchable) [size=512]
> 
> "/proc/interrupts|grep -E 'dvb|saa'" says:
>  50: 1288508186   IO-APIC-level  saa7146 (1)
> 233:   42658103   IO-APIC-level  saa7146 (0)
> 
> 
> I don't know which hardware interrupts those are mapped from/to and
> currently don't know how to find out.
> 
> If you need any further data to give a helpful answer, don't hesitate to
> ask.

Which firmware are you using?
A log showing driver startup might be useful.

Does OSD work fine before the error occurres?

Does the VDR recover if you wait some time (1 or 2 minutes) before you
press the next key?

You might also try whether this driver improves things:
http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring/

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] saa7146_i2c_writeout: timed out waiting for end of xfer

[Oliver Endriss]

Stone wrote:
> On 7/17/07, Oliver Endriss <[EMAIL PROTECTED]> wrote:
> >
> > Oliver Endriss wrote:
> > > Imho the interrupt processing was broken:
> > > - The first I2C interrupt should be used to wake-up the task.
> > >   It does not matter that it takes some time until ERR in IIC_STA
> > >   will be updated. We don't need it.
> > > - Interrupts must be acknowledged at the end of the ISR.
> > >
> > > @all
> > > Please test the attached patch.
> > > There shouldn't be any unexpected I2C interrupts anymore.
> >
> > Attached is an updated patch which does extended status checking.
> 
> 
> Did this patch solve everyone's problems?  Is is checked in now?

There was little feedback, so it's not in the repository yet.

I would really appreciate if more people would test this patch,
no matter whether they have a problem with the current driver
or not. It would reduce the risk to introduce a bug.

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] [PATCH] femon: added option for the count of printed lines

[Oliver Endriss]

Hermann Gausterer wrote:
> hi
> 
> i changed femon to accept an option for the number of printed
> lines; there is also a script attached which uses this to 
> convenient print out the status of all dvb cards in a system! :-)
> i think, this script should be added to dvb-apps.
> 
> patch is again
> http://www.linuxtv.org/downloads/linuxtv-dvb-1.1.1.tar.bz2
> 
> please reply in case of problems accepting the patch!

linuxtv-dvb-1.1.1.tar.bz2 is _very_ old.
Please use femon from the dvb-apps HG repository.

| usage: femon [options]
| -h: human readable output
| -a number : use given adapter (default 0)
| -f number : use given frontend (default 0)
| -c number : samples to take (default 0 = infinite)

There is already a -c option...

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [linux-dvb] Hauppauge WinTV Nova-S-Plus - multiple read accesses impossible

[Oliver Endriss]

Fabian Förg wrote:
> Fabian Förg wrote:
> > Hello,
> >
> > in newer kernel releases multiple read accesses on the Hauppauge WinTV 
> > Nova-S-Plus are impossible.
> > Thus, the command line femon is for example unable to open the DVB 
> > device when VDR is running:
> >
> > $ fuser -v /dev/dvb/adapter0/frontend0
> >
> >USERPID ACCESS COMMAND
> > /dev/dvb/adapter0/frontend0:
> >myuser 5073 F vdr
> >
> > $ femon
> > using '/dev/dvb/adapter0/frontend0'
> > opening frontend failed: Device or resource busy
> >
> > I encounterd this issue with kernel 2.6.22.1 and the current Ubuntu 
> > feisty kernel (2.6.20.x).
> > Older kernels allowed multiple accesses. However, I can't test which 
> > ones, because I replaced
> > my system board some time ago, and older kernels don't contain the 
> > necessary drivers for the board.
> >
> > Greets,
> > Fabian
> >   
> Today I tested it with the newest v4l-sources - also no multiple read 
> accesses possible.
> Any suggestions?

Hm, I tested budget and dvb-ttpci drivers from HG with kernel 2.6.22.
Works without any problems here.

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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