[PATCH] tm6000-dvb: Fix module unload.

[Julian Scheel]

dvb_unregister_frontend has to be called before detach. Otherwise the
unregister call will segfault. This made tm6000-dvb module unload unusable.

Signed-off-by: Julian Scheel 
---
 drivers/media/usb/tm6000/tm6000-dvb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/tm6000/tm6000-dvb.c 
b/drivers/media/usb/tm6000/tm6000-dvb.c
index e1f3f66..9fc1e94 100644
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -360,8 +360,8 @@ dvb_dmx_err:
dvb_dmx_release(&dvb->demux);
 frontend_err:
if (dvb->frontend) {
-   dvb_frontend_detach(dvb->frontend);
dvb_unregister_frontend(dvb->frontend);
+   dvb_frontend_detach(dvb->frontend);
}
 adapter_err:
dvb_unregister_adapter(&dvb->adapter);
@@ -384,8 +384,8 @@ static void unregister_dvb(struct tm6000_core *dev)
 
 /* mutex_lock(&tm6000_driver.open_close_mutex); */
if (dvb->frontend) {
-   dvb_frontend_detach(dvb->frontend);
dvb_unregister_frontend(dvb->frontend);
+   dvb_frontend_detach(dvb->frontend);
}
 
dvb_dmxdev_release(&dvb->dmxdev);
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tm6000: Add parameter to keep urb bufs allocated.

[Julian Scheel]

Hi Ezequiel,

Am Donnerstag, den 04.10.2012, 14:35 -0300 schrieb Ezequiel Garcia:
> Nice work! Just one pico-tiny nitpick:

Should I update the patch to reflect this? Or is it ok if the maintainer
integrated your proposal when comitting it?

> On Thu, Oct 4, 2012 at 11:04 AM, Julian Scheel  wrote:
> > On systems where it cannot be assured that enough continous memory is 
> > available
> > all the time it can be very useful to only allocate the memory once when it 
> > is
> > needed the first time. Afterwards the initially allocated memory will be
> > reused, so it is ensured that the memory will stay available until the 
> > driver
> > is unloaded.
> >
> > Signed-off-by: Julian Scheel 
> > ---
> >  drivers/media/video/tm6000/tm6000-video.c | 111 
> > +-
> >  drivers/media/video/tm6000/tm6000.h   |   5 ++
> >  2 files changed, 97 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/media/video/tm6000/tm6000-video.c 
> > b/drivers/media/video/tm6000/tm6000-video.c
> > index 03de3d8..1b8db35 100644
> > --- a/drivers/media/video/tm6000/tm6000-video.c
> > +++ b/drivers/media/video/tm6000/tm6000-video.c
> > @@ -49,12 +49,15 @@
> >  #define TM6000_MIN_BUF 4
> >  #define TM6000_DEF_BUF 8
> >
> > +#define TM6000_NUM_URB_BUF 8
> > +
> >  #define TM6000_MAX_ISO_PACKETS 46  /* Max number of ISO packets */
> >
> >  /* Declare static vars that will be used as parameters */
> >  static unsigned int vid_limit = 16;/* Video memory limit, in Mb */
> >  static int video_nr = -1;  /* /dev/videoN, -1 for autodetect */
> >  static int radio_nr = -1;  /* /dev/radioN, -1 for autodetect */
> > +static int keep_urb = 0;   /* keep urb buffers allocated */
> >
> 
> There's no need to initialize this one to zero.
> 
> >  /* Debug level */
> >  int tm6000_debug;
> > @@ -570,6 +573,70 @@ static void tm6000_irq_callback(struct urb *urb)
> >  }
> >
> >  /*
> > + * Allocate URB buffers
> > + */
> > +static int tm6000_alloc_urb_buffers(struct tm6000_core *dev)
> > +{
> > +   int num_bufs = TM6000_NUM_URB_BUF;
> > +   int i;
> > +
> > +   if (dev->urb_buffer != NULL)
> > +   return 0;
> > +
> > +   dev->urb_buffer = kmalloc(sizeof(void *)*num_bufs, GFP_KERNEL);
> > +   if (!dev->urb_buffer) {
> > +   tm6000_err("cannot allocate memory for urb buffers\n");
> > +   return -ENOMEM;
> > +   }
> > +
> > +   dev->urb_dma = kmalloc(sizeof(dma_addr_t *)*num_bufs, GFP_KERNEL);
> > +   if (!dev->urb_dma) {
> > +   tm6000_err("cannot allocate memory for urb dma pointers\n");
> > +   return -ENOMEM;
> > +   }
> > +
> > +   for (i = 0; i < num_bufs; i++) {
> > +   dev->urb_buffer[i] = usb_alloc_coherent(dev->udev, 
> > dev->urb_size,
> > +   GFP_KERNEL, &dev->urb_dma[i]);
> > +   if (!dev->urb_buffer[i]) {
> > +   tm6000_err("unable to allocate %i bytes for 
> > transfer"
> > +   " buffer %i\n", dev->urb_size, i);
> > +   return -ENOMEM;
> > +   }
> > +   memset(dev->urb_buffer[i], 0, dev->urb_size);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +/*
> > + * Free URB buffers
> > + */
> > +static int tm6000_free_urb_buffers(struct tm6000_core *dev)
> > +{
> > +   int i;
> > +
> > +   if (dev->urb_buffer == NULL)
> > +   return 0;
> > +
> > +   for (i = 0; i < TM6000_NUM_URB_BUF; i++) {
> > +   if (dev->urb_buffer[i]) {
> > +   usb_free_coherent(dev->udev,
> > +   dev->urb_size,
> > +   dev->urb_buffer[i],
> > +   dev->urb_dma[i]);
> > +   dev->urb_buffer[i] = NULL;
> > +   }
> > +   }
> > +   kfree (dev->urb_buffer);
> > +   kfree (dev->urb_dma);
> > +   dev->urb_buffer = NULL;
> > +   dev->urb_dma = NULL;
> > +
> > +   return 0;
> > +}
> > +
> > +/*
> >   * Stop and Deallocate URBs
>

[PATCH] tm6000: Add parameter to keep urb bufs allocated.

[Julian Scheel]

On systems where it cannot be assured that enough continous memory is available
all the time it can be very useful to only allocate the memory once when it is
needed the first time. Afterwards the initially allocated memory will be
reused, so it is ensured that the memory will stay available until the driver
is unloaded.

Signed-off-by: Julian Scheel 
---
 drivers/media/video/tm6000/tm6000-video.c | 111 +-
 drivers/media/video/tm6000/tm6000.h   |   5 ++
 2 files changed, 97 insertions(+), 19 deletions(-)

diff --git a/drivers/media/video/tm6000/tm6000-video.c 
b/drivers/media/video/tm6000/tm6000-video.c
index 03de3d8..1b8db35 100644
--- a/drivers/media/video/tm6000/tm6000-video.c
+++ b/drivers/media/video/tm6000/tm6000-video.c
@@ -49,12 +49,15 @@
 #define TM6000_MIN_BUF 4
 #define TM6000_DEF_BUF 8
 
+#define TM6000_NUM_URB_BUF 8
+
 #define TM6000_MAX_ISO_PACKETS 46  /* Max number of ISO packets */
 
 /* Declare static vars that will be used as parameters */
 static unsigned int vid_limit = 16;/* Video memory limit, in Mb */
 static int video_nr = -1;  /* /dev/videoN, -1 for autodetect */
 static int radio_nr = -1;  /* /dev/radioN, -1 for autodetect */
+static int keep_urb = 0;   /* keep urb buffers allocated */
 
 /* Debug level */
 int tm6000_debug;
@@ -570,6 +573,70 @@ static void tm6000_irq_callback(struct urb *urb)
 }
 
 /*
+ * Allocate URB buffers
+ */
+static int tm6000_alloc_urb_buffers(struct tm6000_core *dev)
+{
+   int num_bufs = TM6000_NUM_URB_BUF;
+   int i;
+
+   if (dev->urb_buffer != NULL)
+   return 0;
+
+   dev->urb_buffer = kmalloc(sizeof(void *)*num_bufs, GFP_KERNEL);
+   if (!dev->urb_buffer) {
+   tm6000_err("cannot allocate memory for urb buffers\n");
+   return -ENOMEM;
+   }
+
+   dev->urb_dma = kmalloc(sizeof(dma_addr_t *)*num_bufs, GFP_KERNEL);
+   if (!dev->urb_dma) {
+   tm6000_err("cannot allocate memory for urb dma pointers\n");
+   return -ENOMEM;
+   }
+
+   for (i = 0; i < num_bufs; i++) {
+   dev->urb_buffer[i] = usb_alloc_coherent(dev->udev, 
dev->urb_size,
+   GFP_KERNEL, &dev->urb_dma[i]);
+   if (!dev->urb_buffer[i]) {
+   tm6000_err("unable to allocate %i bytes for transfer"
+   " buffer %i\n", dev->urb_size, i);
+   return -ENOMEM;
+   }
+   memset(dev->urb_buffer[i], 0, dev->urb_size);
+   }
+
+   return 0;
+}
+
+/*
+ * Free URB buffers
+ */
+static int tm6000_free_urb_buffers(struct tm6000_core *dev)
+{
+   int i;
+
+   if (dev->urb_buffer == NULL)
+   return 0;
+
+   for (i = 0; i < TM6000_NUM_URB_BUF; i++) {
+   if (dev->urb_buffer[i]) {
+   usb_free_coherent(dev->udev,
+   dev->urb_size,
+   dev->urb_buffer[i],
+   dev->urb_dma[i]);
+   dev->urb_buffer[i] = NULL;
+   }
+   }
+   kfree (dev->urb_buffer);
+   kfree (dev->urb_dma);
+   dev->urb_buffer = NULL;
+   dev->urb_dma = NULL;
+
+   return 0;
+}
+
+/*
  * Stop and Deallocate URBs
  */
 static void tm6000_uninit_isoc(struct tm6000_core *dev)
@@ -585,18 +652,15 @@ static void tm6000_uninit_isoc(struct tm6000_core *dev)
if (urb) {
usb_kill_urb(urb);
usb_unlink_urb(urb);
-   if (dev->isoc_ctl.transfer_buffer[i]) {
-   usb_free_coherent(dev->udev,
-   urb->transfer_buffer_length,
-   
dev->isoc_ctl.transfer_buffer[i],
-   urb->transfer_dma);
-   }
usb_free_urb(urb);
dev->isoc_ctl.urb[i] = NULL;
}
dev->isoc_ctl.transfer_buffer[i] = NULL;
}
 
+   if (!keep_urb)
+   tm6000_free_urb_buffers(dev);
+
kfree(dev->isoc_ctl.urb);
kfree(dev->isoc_ctl.transfer_buffer);
 
@@ -606,12 +670,12 @@ static void tm6000_uninit_isoc(struct tm6000_core *dev)
 }
 
 /*
- * Allocate URBs and start IRQ
+ * Assign URBs and start IRQ
  */
 static int tm6000_prepare_isoc(struct tm6000_core *dev)
 {
struct tm6000_dmaqueue *dma_q = &dev->vidq;
-   int i, j, sb_size, pipe, size, max_packets, num_bufs = 8;
+   int i, j, sb_size, pipe, size, max_packets, num_bufs = 
TM6000_NUM_URB_BUF;
struct urb *urb;
 
/* De-allocates all 

[PATCH] Add support for new revision of KNC 1 DVB-C cards. Using tda10024 instead of tda10023, which is compatible to tda10023 driver.

[Julian Scheel]

Signed-off-by: Julian Scheel 
---
 drivers/media/dvb/ttpci/budget-av.c   |4 
 drivers/media/dvb/ttpci/budget-core.c |2 ++
 drivers/media/dvb/ttpci/budget.h  |1 +
 3 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/ttpci/budget-av.c 
b/drivers/media/dvb/ttpci/budget-av.c
index e957d76..5b28bc6 100644
--- a/drivers/media/dvb/ttpci/budget-av.c
+++ b/drivers/media/dvb/ttpci/budget-av.c
@@ -1197,6 +1197,7 @@ static u8 read_pwm(struct budget_av *budget_av)
 #define SUBID_DVBC_KNC10x0020
 #define SUBID_DVBC_KNC1_PLUS   0x0021
 #define SUBID_DVBC_KNC1_MK30x0022
+#define SUBID_DVBC_KNC1_TDA10024   0x0028
 #define SUBID_DVBC_KNC1_PLUS_MK3   0x0023
 #define SUBID_DVBC_CINERGY1200 0x1156
 #define SUBID_DVBC_CINERGY1200_MK3 0x1176
@@ -1316,6 +1317,7 @@ static void frontend_init(struct budget_av *budget_av)
case SUBID_DVBC_EASYWATCH_MK3:
case SUBID_DVBC_CINERGY1200_MK3:
case SUBID_DVBC_KNC1_MK3:
+   case SUBID_DVBC_KNC1_TDA10024:
case SUBID_DVBC_KNC1_PLUS_MK3:
budget_av->reinitialise_demod = 1;
budget_av->budget.dev->i2c_bitrate = 
SAA7146_I2C_BUS_BIT_RATE_240;
@@ -1558,6 +1560,7 @@ MAKE_BUDGET_INFO(knc1sp, "KNC1 DVB-S Plus", 
BUDGET_KNC1SP);
 MAKE_BUDGET_INFO(knc1spx4, "KNC1 DVB-S Plus X4", BUDGET_KNC1SP);
 MAKE_BUDGET_INFO(knc1cp, "KNC1 DVB-C Plus", BUDGET_KNC1CP);
 MAKE_BUDGET_INFO(knc1cmk3, "KNC1 DVB-C MK3", BUDGET_KNC1C_MK3);
+MAKE_BUDGET_INFO(knc1ctda10024, "KNC1 DVB-C TDA10024", BUDGET_KNC1C_TDA10024);
 MAKE_BUDGET_INFO(knc1cpmk3, "KNC1 DVB-C Plus MK3", BUDGET_KNC1CP_MK3);
 MAKE_BUDGET_INFO(knc1tp, "KNC1 DVB-T Plus", BUDGET_KNC1TP);
 MAKE_BUDGET_INFO(cin1200s, "TerraTec Cinergy 1200 DVB-S", BUDGET_CIN1200S);
@@ -1587,6 +1590,7 @@ static struct pci_device_id pci_tbl[] = {
MAKE_EXTENSION_PCI(knc1c, 0x1894, 0x0020),
MAKE_EXTENSION_PCI(knc1cp, 0x1894, 0x0021),
MAKE_EXTENSION_PCI(knc1cmk3, 0x1894, 0x0022),
+   MAKE_EXTENSION_PCI(knc1ctda10024, 0x1894, 0x0028),
MAKE_EXTENSION_PCI(knc1cpmk3, 0x1894, 0x0023),
MAKE_EXTENSION_PCI(knc1t, 0x1894, 0x0030),
MAKE_EXTENSION_PCI(knc1tp, 0x1894, 0x0031),
diff --git a/drivers/media/dvb/ttpci/budget-core.c 
b/drivers/media/dvb/ttpci/budget-core.c
index 37666d4..37d02fe 100644
--- a/drivers/media/dvb/ttpci/budget-core.c
+++ b/drivers/media/dvb/ttpci/budget-core.c
@@ -110,6 +110,7 @@ static int start_ts_capture(struct budget *budget)
break;
case BUDGET_CIN1200C_MK3:
case BUDGET_KNC1C_MK3:
+   case BUDGET_KNC1C_TDA10024:
case BUDGET_KNC1CP_MK3:
if (budget->video_port == BUDGET_VIDEO_PORTA) {
saa7146_write(dev, DD1_INIT, 0x06000200);
@@ -434,6 +435,7 @@ int ttpci_budget_init(struct budget *budget, struct 
saa7146_dev *dev,
case BUDGET_KNC1CP:
case BUDGET_CIN1200C:
case BUDGET_KNC1C_MK3:
+   case BUDGET_KNC1C_TDA10024:
case BUDGET_KNC1CP_MK3:
case BUDGET_CIN1200C_MK3:
budget->buffer_width = TS_WIDTH_DVBC;
diff --git a/drivers/media/dvb/ttpci/budget.h b/drivers/media/dvb/ttpci/budget.h
index 3ad0c67..3d8a806 100644
--- a/drivers/media/dvb/ttpci/budget.h
+++ b/drivers/media/dvb/ttpci/budget.h
@@ -104,6 +104,7 @@ static struct saa7146_pci_extension_data x_var = { \
 #define BUDGET_KNC1C_MK3  16
 #define BUDGET_KNC1CP_MK3 17
 #define BUDGET_KNC1S2  18
+#define BUDGET_KNC1C_TDA10024 19
 
 #define BUDGET_VIDEO_PORTA 0
 #define BUDGET_VIDEO_PORTB 1
-- 
1.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: S2-3200 switching-timeouts on 2.6.38

[Julian Scheel]

Am 24.03.2011 19:32, schrieb Steffen Barszus:

It has been done some work (and effort), to prove its having positive
effect. you should allways
have more then 1000 stations at any time on that SAT, if you see that maximum
number of stations is somewhere at 1600. everything around 400 is
broken hardware or driver.


Agreed, but this is why I asked about the difference between the channel 
search with stb6100 patch only and both patches applied.

Nobody says that 400 channels are expected behaviour.
But the difference of less than 20 channels between both patches could 
easily be caused by temporal availability of services. This is all I 
said and all I suggested to proof.


Even a simple diff of both searches would be helpful. Just to check 
which channels are missing.


I am not in the position to accept or reject this driver, just wanted to 
be helpful in finding out if it's really needed.



Please dont consider his post as single experience of a single user. The general
perception was more like "Wow i can finally use that card and don't
throw it away."
  from 10+ Users which i know of. So no matter if its considered done
right or not.
The tuning patch is out of question of improving the usability of the
affected cards.

The request has been, to prove that the changes at the stb6100 is not
enough to actually
fix the problem. This prove has been done now . The changes on the
stb6100 is not enough,
the changes at the stb0899 still has quite positive effect.

So taking into account that the patch improves situation and doesn't
have negative side
effects for others, it might be wise to consider inclusion of the
patch, even if it might not
be the perfect solution from technical/theoretical perspective.

I dont want to complain until the patch is in, its just: We have a
problem, we have a solution.
Lets use it and make this hardware useful for the people and lets do
it right when time permits.

There is still a handful of other patches for the same hardware
floating around to improve other parts of that driver.

I mean this hardware is known to work "less then perfect" since years, really.

So please do something about it. Accept the helping hands.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: S2-3200 switching-timeouts on 2.6.38

[Julian Scheel]

Hi,

Am 23.03.2011 19:19, schrieb H. Ellenberger:

@Manu: Your argumentation is inconsistent and lacks any proof.

Running a full scan of Astra 19.2 E with Kaffeine together with cards model
Skystar HD and Twinhan/Azurewave VP-1041 results in a channel list of approx
400 stations only. When I apply my patch then almost all stations are found:

patch in tuner: 400 stations found, not usable,


With KNC TV-Station DVB-S2 (which is stb0899 as well) I can't confirm 
this issue. Channel search finds > 1000 channels at any time.



patch in tuner + demod: 1127 stations found, better but less than without
tuner patch.
patch in demod only: 1145 stations found, slightly more than with tuner patch.


Have you done both searches at (almost) same time? On astra network 
there are quite some channels, which are only available and announced at 
certain time, which can make a noticable difference in the amount of 
channels found.


-Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Am 01.02.2011 14:22, schrieb Mauro Carvalho Chehab:

Em 08-01-2011 13:40, Julian Scheel escreveu:

Am 06.01.2011 23:31, schrieb Julian Scheel:

Attached is the diff I currently use.


Some more process. Attached is a new patch, which allows me to capture video 
and audio from a PAL tuner. Imho the video has wrong colours though (using 
PAL-B). Maybe someone would want to test that patch and give some feedback?

Ok some hours of debugging later, I figured out that only encoder 1 was not 
working properly. This was due to a wrong addressing when sending the dif setup 
commands. The attached new patch fixes this.


Is this patch already working properly?

If so, please:
1) Check its codingstyle with ./scripts/checkpatch.pl
(there are some issues there, like commenting with //)
2) Remove the dead code;
3) Provide a patch description and your Signed-off-by:



For my purpose it works well, but actually I guess some more 
modifications would be needed for other PAL regions. Actually Steven 
wanted to take a look at this patch and merge it. What do you think, Steven?



saa7164-card-pal.diff


Nur in linux-2.6.37/drivers/media/video/saa7164/: modules.order.
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru 
linux-2.6.37.a/drivers/media/video/saa7164//saa7164-api.c 
linux-2.6.37/drivers/media/video/saa7164//saa7164-api.c
--- linux-2.6.37.a/drivers/media/video/saa7164//saa7164-api.c   2011-01-05 
01:50:19.0 +0100
+++ linux-2.6.37/drivers/media/video/saa7164//saa7164-api.c 2011-01-08 
16:10:32.0 +0100
@@ -548,7 +548,7 @@
tvaudio.std = TU_STANDARD_NTSC_M;
tvaudio.country = 1;
} else {
-   tvaudio.std = TU_STANDARD_PAL_I;
+   tvaudio.std = 0x04; //TU_STANDARD_PAL_I;

Probably, you need to add a define for 0x04 and use its symbol here.

As I have no specification for the card/firmware it's a bit hard to 
insert a define here, as I can not say for sure for which standards it 
would properly work. Again this is something Steven would have to take a 
look at, I think.



tvaudio.country = 44;
}

@@ -608,7 +608,7 @@
dprintk(DBGLVL_API, "%s(nr=%d type=%d val=%x)\n", __func__,
port->nr, port->type, val);

-   if (port->nr == 0)
+   if (port->nr<  3) //== 0)
mas = 0xd0;
else
mas = 0xe0;
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru 
linux-2.6.37.a/drivers/media/video/saa7164//saa7164-cards.c 
linux-2.6.37/drivers/media/video/saa7164//saa7164-cards.c
--- linux-2.6.37.a/drivers/media/video/saa7164//saa7164-cards.c 2011-01-05 
01:50:19.0 +0100
+++ linux-2.6.37/drivers/media/video/saa7164//saa7164-cards.c   2011-01-06 
16:16:56.0 +0100
@@ -203,6 +203,66 @@
.i2c_reg_len= REGLEN_8bit,
} },
},
+   [SAA7164_BOARD_HAUPPAUGE_HVR2200_4] = {
+   .name   = "Hauppauge WinTV-HVR2200",
+   .porta  = SAA7164_MPEG_DVB,
+   .portb  = SAA7164_MPEG_DVB,
+.portc  = SAA7164_MPEG_ENCODER,
+.portd  = SAA7164_MPEG_ENCODER,
+.porte  = SAA7164_MPEG_VBI,
+.portf  = SAA7164_MPEG_VBI,
+   .chiprev= SAA7164_CHIP_REV3,
+   .unit   = {{
+   .id = 0x1d,
+   .type   = SAA7164_UNIT_EEPROM,
+   .name   = "4K EEPROM",
+   .i2c_bus_nr = SAA7164_I2C_BUS_0,
+   .i2c_bus_addr   = 0xa0>>  1,
+   .i2c_reg_len= REGLEN_8bit,
+   }, {
+   .id = 0x04,
+   .type   = SAA7164_UNIT_TUNER,
+   .name   = "TDA18271-1",
+   .i2c_bus_nr = SAA7164_I2C_BUS_1,
+   .i2c_bus_addr   = 0xc0>>  1,
+   .i2c_reg_len= REGLEN_8bit,
+   }, {
+   .id = 0x05,
+   .type   = SAA7164_UNIT_ANALOG_DEMODULATOR,
+   .name   = "TDA8290-1",
+   .i2c_bus_nr = SAA7164_I2C_BUS_1,
+   .i2c_bus_addr   = 0x84>>  1,
+   .i2c_reg_len= REGLEN_8bit,
+   }, {
+   .id = 0x1b,
+   .type   = SAA7164_UNIT_TUNER,
+   .name   = "TDA18271-2",
+   .i2c_bus_nr = SAA7164_I2C_BUS_2,
+   .i2c_bus_addr   = 0xc0>>  1,
+

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Am 06.01.2011 23:31, schrieb Julian Scheel:



Attached is the diff I currently use.

Some more process. Attached is a new patch, which allows me to capture 
video and audio from a PAL tuner. Imho the video has wrong colours 
though (using PAL-B). Maybe someone would want to test that patch and 
give some feedback?
Ok some hours of debugging later, I figured out that only encoder 1 was 
not working properly. This was due to a wrong addressing when sending 
the dif setup commands. The attached new patch fixes this.


Nur in linux-2.6.37/drivers/media/video/saa7164/: modules.order.
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru linux-2.6.37.a/drivers/media/video/saa7164//saa7164-api.c linux-2.6.37/drivers/media/video/saa7164//saa7164-api.c
--- linux-2.6.37.a/drivers/media/video/saa7164//saa7164-api.c	2011-01-05 01:50:19.0 +0100
+++ linux-2.6.37/drivers/media/video/saa7164//saa7164-api.c	2011-01-08 16:10:32.0 +0100
@@ -548,7 +548,7 @@
 		tvaudio.std = TU_STANDARD_NTSC_M;
 		tvaudio.country = 1;
 	} else {
-		tvaudio.std = TU_STANDARD_PAL_I;
+		tvaudio.std = 0x04; //TU_STANDARD_PAL_I;
 		tvaudio.country = 44;
 	}
 
@@ -608,7 +608,7 @@
 	dprintk(DBGLVL_API, "%s(nr=%d type=%d val=%x)\n", __func__,
 		port->nr, port->type, val);
 
-	if (port->nr == 0)
+	if (port->nr < 3) //== 0)
 		mas = 0xd0;
 	else
 		mas = 0xe0;
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru linux-2.6.37.a/drivers/media/video/saa7164//saa7164-cards.c linux-2.6.37/drivers/media/video/saa7164//saa7164-cards.c
--- linux-2.6.37.a/drivers/media/video/saa7164//saa7164-cards.c	2011-01-05 01:50:19.0 +0100
+++ linux-2.6.37/drivers/media/video/saa7164//saa7164-cards.c	2011-01-06 16:16:56.0 +0100
@@ -203,6 +203,66 @@
 			.i2c_reg_len	= REGLEN_8bit,
 		} },
 	},
+	[SAA7164_BOARD_HAUPPAUGE_HVR2200_4] = {
+		.name		= "Hauppauge WinTV-HVR2200",
+		.porta		= SAA7164_MPEG_DVB,
+		.portb		= SAA7164_MPEG_DVB,
+.portc  = SAA7164_MPEG_ENCODER,
+.portd  = SAA7164_MPEG_ENCODER,
+.porte  = SAA7164_MPEG_VBI,
+.portf  = SAA7164_MPEG_VBI,
+		.chiprev	= SAA7164_CHIP_REV3,
+		.unit		= {{
+			.id		= 0x1d,
+			.type		= SAA7164_UNIT_EEPROM,
+			.name		= "4K EEPROM",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_0,
+			.i2c_bus_addr	= 0xa0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x04,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x05,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1b,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1c,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1e,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x10 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1f,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x12 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		} },
+	},
 	[SAA7164_BOARD_HAUPPAUGE_HVR2250] = {
 		.name		= "Hauppauge WinTV-HVR2250",
 		.porta		= SAA7164_MPEG_DVB,
@@ -426,6 +486,10 @@
 		.subvendor = 0x0070,
 		.subdevice = 0x8851,
 		.card  = SAA7164_BOARD_HAUPPAUGE_HVR2250_2,
+	}, {
+		.subvendor = 0x0070,
+		.subdevice = 0x8940,
+		.card  = SAA7164_BOARD_HAUPPAUGE_HVR2200_4,
 	},
 };
 const unsigned int saa7164_idcount = ARRAY_SIZE(saa7164_subids);
@@ -469,6 +533,7 @@
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_3:
@@ -549,6 +614,7 @@
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_3:
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru linux-2.6.37.a/drivers/media/video/saa7164//saa7164-dvb.c linux-2.6.37/drivers/media/vide

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Attached is the diff I currently use.

Some more process. Attached is a new patch, which allows me to capture 
video and audio from a PAL tuner. Imho the video has wrong colours 
though (using PAL-B). Maybe someone would want to test that patch and 
give some feedback?


Regards,
Julian

Nur in linux-2.6.37/drivers/media/video/saa7164/: modules.order.
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-api.c linux-2.6.37/drivers/media/video/saa7164//saa7164-api.c
--- linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-api.c	2010-12-29 02:05:48.0 +0100
+++ linux-2.6.37/drivers/media/video/saa7164//saa7164-api.c	2011-01-06 23:22:17.0 +0100
@@ -548,7 +548,7 @@
 		tvaudio.std = TU_STANDARD_NTSC_M;
 		tvaudio.country = 1;
 	} else {
-		tvaudio.std = TU_STANDARD_PAL_I;
+		tvaudio.std = 0x04; //TU_STANDARD_PAL_I;
 		tvaudio.country = 44;
 	}
 
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-cards.c linux-2.6.37/drivers/media/video/saa7164//saa7164-cards.c
--- linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-cards.c	2010-12-29 02:05:48.0 +0100
+++ linux-2.6.37/drivers/media/video/saa7164//saa7164-cards.c	2011-01-06 16:16:56.0 +0100
@@ -203,6 +203,66 @@
 			.i2c_reg_len	= REGLEN_8bit,
 		} },
 	},
+	[SAA7164_BOARD_HAUPPAUGE_HVR2200_4] = {
+		.name		= "Hauppauge WinTV-HVR2200",
+		.porta		= SAA7164_MPEG_DVB,
+		.portb		= SAA7164_MPEG_DVB,
+.portc  = SAA7164_MPEG_ENCODER,
+.portd  = SAA7164_MPEG_ENCODER,
+.porte  = SAA7164_MPEG_VBI,
+.portf  = SAA7164_MPEG_VBI,
+		.chiprev	= SAA7164_CHIP_REV3,
+		.unit		= {{
+			.id		= 0x1d,
+			.type		= SAA7164_UNIT_EEPROM,
+			.name		= "4K EEPROM",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_0,
+			.i2c_bus_addr	= 0xa0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x04,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x05,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1b,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1c,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1e,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x10 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1f,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x12 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		} },
+	},
 	[SAA7164_BOARD_HAUPPAUGE_HVR2250] = {
 		.name		= "Hauppauge WinTV-HVR2250",
 		.porta		= SAA7164_MPEG_DVB,
@@ -426,6 +486,10 @@
 		.subvendor = 0x0070,
 		.subdevice = 0x8851,
 		.card  = SAA7164_BOARD_HAUPPAUGE_HVR2250_2,
+	}, {
+		.subvendor = 0x0070,
+		.subdevice = 0x8940,
+		.card  = SAA7164_BOARD_HAUPPAUGE_HVR2200_4,
 	},
 };
 const unsigned int saa7164_idcount = ARRAY_SIZE(saa7164_subids);
@@ -469,6 +533,7 @@
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_3:
@@ -549,6 +614,7 @@
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_3:
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-dvb.c linux-2.6.37/drivers/media/video/saa7164//saa7164-dvb.c
--- linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-dvb.c	2010-12-29 02:05:48.0 +0100
+++ linux-2.6.37/drivers/media/video/saa7164//saa7164-dvb.c	2011-01-06 16:16:56.0 +0100
@@ -475,6 +475,7 @@
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 		i2c_bus = &dev->i2c_bus[port->nr + 1];
 		switch (port->nr) {
 		case 0:
diff -x '*.o' -x '*.ko' -x '*.cmd' -x '*.mod.*' -ru linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-encoder.c linux-2.6.37/drivers/media/video/saa7164//saa7164-encoder.c
--- linux-2.6.37-rc8.a/driv

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Am 15.12.2010 08:04, schrieb Julian Scheel:

Am 14.12.2010 um 20:51 schrieb Steven Toth:


On 12/14/10 12:23 PM, Julian Scheel wrote:

Is there any reason, why the additional card-information found here:
http://www.kernellabs.com/hg/~stoth/saa7164-dev/
is not yet in the kernel tree?

On my todo list.

Ok, fine.


I validate each board before I add its profile to the core tree. If certain
boards are missing then its because that board is considered experimental or is
pending testing and merge.

PAL encoder support is broken in the current tree and it currently getting my
love and attention. Point me at the specific boards you think are missing and
I'll also add these to my todo list, they'll likely get merged at the same time.

Actually this is the board I am testing with:
http://www.kernellabs.com/hg/~stoth/saa7164-dev/rev/cf2d7530d676

Should it work with your testing tree or is the encoder part broken there as 
well?
I was able to get the encoder working now. The diff I referenced did not 
contain the encoder port settings. I added them manually and now get 
/dev/video0,1 and /dev/vbi0,1. A simple cat /dev/video0 > test.mpg 
reveals that the encoder seems to be running - it shows a nice 
mpeg-encoded bluescreen.
Anyway running scantv did not show any results although I have a proper 
input signal connected. I guess there is something broken still? Any ideas?
Also it seems so far only NTSC is supported. dmesg shows that the 
firmware is capable of PAL - just the question is what needs to be 
changed in the drivers to switch between the modes?


Attached is the diff I currently use.

-Julian

diff -ru -x '*.o*' -x '*.ko*' -x '*.cmd' -x '*.orig' linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-cards.c linux-2.6.37-rc8/drivers/media/video/saa7164//saa7164-cards.c
--- linux-2.6.37-rc8.a/drivers/media/video/saa7164//saa7164-cards.c	2010-12-29 02:05:48.0 +0100
+++ linux-2.6.37-rc8/drivers/media/video/saa7164//saa7164-cards.c	2011-01-04 02:26:56.0 +0100
@@ -203,6 +203,66 @@
 			.i2c_reg_len	= REGLEN_8bit,
 		} },
 	},
+	[SAA7164_BOARD_HAUPPAUGE_HVR2200_4] = {
+		.name		= "Hauppauge WinTV-HVR2200",
+		.porta		= SAA7164_MPEG_DVB,
+		.portb		= SAA7164_MPEG_DVB,
+.portc  = SAA7164_MPEG_ENCODER,
+.portd  = SAA7164_MPEG_ENCODER,
+.porte  = SAA7164_MPEG_VBI,
+.portf  = SAA7164_MPEG_VBI,
+		.chiprev	= SAA7164_CHIP_REV3,
+		.unit		= {{
+			.id		= 0x1d,
+			.type		= SAA7164_UNIT_EEPROM,
+			.name		= "4K EEPROM",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_0,
+			.i2c_bus_addr	= 0xa0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x04,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x05,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1b,
+			.type		= SAA7164_UNIT_TUNER,
+			.name		= "TDA18271-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0xc0 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1c,
+			.type		= SAA7164_UNIT_ANALOG_DEMODULATOR,
+			.name		= "TDA8290-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x84 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1e,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-1",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_1,
+			.i2c_bus_addr	= 0x10 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		}, {
+			.id		= 0x1f,
+			.type		= SAA7164_UNIT_DIGITAL_DEMODULATOR,
+			.name		= "TDA10048-2",
+			.i2c_bus_nr	= SAA7164_I2C_BUS_2,
+			.i2c_bus_addr	= 0x12 >> 1,
+			.i2c_reg_len	= REGLEN_8bit,
+		} },
+	},
 	[SAA7164_BOARD_HAUPPAUGE_HVR2250] = {
 		.name		= "Hauppauge WinTV-HVR2250",
 		.porta		= SAA7164_MPEG_DVB,
@@ -426,6 +486,10 @@
 		.subvendor = 0x0070,
 		.subdevice = 0x8851,
 		.card  = SAA7164_BOARD_HAUPPAUGE_HVR2250_2,
+	}, {
+		.subvendor = 0x0070,
+		.subdevice = 0x8940,
+		.card  = SAA7164_BOARD_HAUPPAUGE_HVR2200_4,
 	},
 };
 const unsigned int saa7164_idcount = ARRAY_SIZE(saa7164_subids);
@@ -469,6 +533,7 @@
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250_3:
@@ -549,6 +614,7 @@
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_2:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2200_3:
+	case SAA7164_BOARD_HAUPPAUGE_HVR2200_4:
 	case SAA7164_BOARD_HAUPPAUGE_HVR2250:
 	case SAA7164_BOARD_HAUP

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Hi Steve,

Am 14.12.2010 20:51, schrieb Steven Toth:

On 12/14/10 12:23 PM, Julian Scheel wrote:

Is there any reason, why the additional card-information found here:
http://www.kernellabs.com/hg/~stoth/saa7164-dev/
is not yet in the kernel tree?

PAL encoder support is broken in the current tree and it currently getting my
love and attention. Point me at the specific boards you think are missing and
I'll also add these to my todo list, they'll likely get merged at the same time


Any progress on this? If you need any assistance please let me know.

Regards,
Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Am 14.12.2010 um 20:51 schrieb Steven Toth:

> On 12/14/10 12:23 PM, Julian Scheel wrote:
>> Is there any reason, why the additional card-information found here:
>> http://www.kernellabs.com/hg/~stoth/saa7164-dev/
>> is not yet in the kernel tree?
> 
> On my todo list.

Ok, fine.

> I validate each board before I add its profile to the core tree. If certain
> boards are missing then its because that board is considered experimental or 
> is
> pending testing and merge.
> 
> PAL encoder support is broken in the current tree and it currently getting my
> love and attention. Point me at the specific boards you think are missing and
> I'll also add these to my todo list, they'll likely get merged at the same 
> time.

Actually this is the board I am testing with:
http://www.kernellabs.com/hg/~stoth/saa7164-dev/rev/cf2d7530d676

Should it work with your testing tree or is the encoder part broken there as 
well?

Julian--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Am 14.12.2010 18:23, schrieb Julian Scheel:

Am 07.12.2010 14:01, schrieb Andy Walls:

It appears to be in the media_tree.git repository on the
staging/for_v2.6.37-rc1 branch:

http://git.linuxtv.org/media_tree.git?a=tree;f=drivers/media/video/saa7164;h=0acaa4ada45ae6881bfbb19447ae9db43f06ef9b;hb=staging/for_v2.6.37-rc1 



saa7164-cards.c appears to have analog entries added for HVR-2200's and
saa7164-encoder.c has a number of V4L ioctl()'s for MPEG streams.

Is there any reason, why the additional card-information found here:
http://www.kernellabs.com/hg/~stoth/saa7164-dev/
is not yet in the kernel tree?


Actually after manually adding this changeset into linux-26.37-rc5 tree 
the card is detected and dmesg says:


[3.653289] saa7164 driver loaded
[3.653340] saa7164 :02:00.0: PCI INT A -> GSI 16 (level, low) -> 
IRQ 16
[3.654909] CORE saa7164[0]: subsystem: 0070:8940, board: Hauppauge 
WinTV-HVR2200 [card=9,autodetected]
[3.654914] saa7164[0]/0: found at :02:00.0, rev: 129, irq: 16, 
latency: 0, mmio: 0xfb00

[3.654919] saa7164 :02:00.0: setting latency timer to 64
[3.813647] saa7164_downloadfirmware() no first image
[3.814781] saa7164_downloadfirmware() Waiting for firmware upload 
(NXP7164-2010-03-10.1.fw)

[3.839841] saa7164_downloadfirmware() firmware read 4019072 bytes.
[3.839843] saa7164_downloadfirmware() firmware loaded.
[3.839844] Firmware file header part 1:
[3.839846]  .FirmwareSize = 0x0
[3.839847]  .BSLSize = 0x0
[3.839848]  .Reserved = 0x3d538
[3.839849]  .Version = 0x3
[3.839850] saa7164_downloadfirmware() SecBootLoader.FileSize = 4019072
[3.839856] saa7164_downloadfirmware() FirmwareSize = 0x1fd6
[3.839857] saa7164_downloadfirmware() BSLSize = 0x0
[3.839858] saa7164_downloadfirmware() Reserved = 0x0
[3.839860] saa7164_downloadfirmware() Version = 0x1661c00
[   10.693325] saa7164_downloadimage() Image downloaded, booting...
[   10.797316] saa7164_downloadimage() Image booted successfully.
[   10.797332] starting firmware download(2)
[   13.425188] saa7164_downloadimage() Image downloaded, booting...
[   15.089109] saa7164_downloadimage() Image booted successfully.
[   15.089128] firmware download complete.
[   15.129700] tveeprom 1-: Hauppauge model 89619, rev D3F2, serial# 
7259796

[   15.129703] tveeprom 1-: MAC address is 00:0d:fe:6e:c6:94
[   15.129704] tveeprom 1-: tuner model is NXP 18271C2_716x (idx 
152, type 4)
[   15.129707] tveeprom 1-: TV standards PAL(B/G) NTSC(M) PAL(I) 
SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)

[   15.129709] tveeprom 1-: audio processor is SAA7164 (idx 43)
[   15.129710] tveeprom 1-: decoder processor is SAA7164 (idx 40)
[   15.129711] tveeprom 1-: has radio
[   15.129712] saa7164[0]: Hauppauge eeprom: model=89619
[   15.189491] tda18271 2-0060: creating new instance
[   15.194156] TDA18271HD/C2 detected @ 2-0060
[   15.446842] DVB: registering new adapter (saa7164)
[   15.446845] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN 
DVB-T)...

[   15.477568] tda18271 3-0060: creating new instance
[   15.482514] TDA18271HD/C2 detected @ 3-0060
[   15.733973] tda18271: performing RF tracking filter calibration
[   18.082962] tda18271: RF tracking filter calibration complete
[   18.083552] DVB: registering new adapter (saa7164)
[   18.083554] DVB: registering adapter 1 frontend 0 (NXP TDA10048HN 
DVB-T)...


dvb-devices are registered, but no video-devices. Any thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Hauppauge HVR-2200 analog

[Julian Scheel]

Am 07.12.2010 14:01, schrieb Andy Walls:

On Tue, 2010-12-07 at 12:04 +0100, Julian Scheel wrote:

Hi,

is there any progress on adding analog support to the HVR-2200?
It seems support for the used chipsets in general is already in the kernel?

It appears to be in the media_tree.git repository on the
staging/for_v2.6.37-rc1 branch:

http://git.linuxtv.org/media_tree.git?a=tree;f=drivers/media/video/saa7164;h=0acaa4ada45ae6881bfbb19447ae9db43f06ef9b;hb=staging/for_v2.6.37-rc1

saa7164-cards.c appears to have analog entries added for HVR-2200's and
saa7164-encoder.c has a number of V4L ioctl()'s for MPEG streams.

Is there any reason, why the additional card-information found here:
http://www.kernellabs.com/hg/~stoth/saa7164-dev/
is not yet in the kernel tree?

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hauppauge HVR-2200 analog

[Julian Scheel]

Hi,

is there any progress on adding analog support to the HVR-2200?
It seems support for the used chipsets in general is already in the kernel?

Regards,
Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Announcing v4l-utils-0.7.90 (which includes libv4l-0.7.90)

[Julian Scheel]

Hi,

Am Montag, 1. März 2010 10:26:47 schrieb Hans de Goede:
> >>> I'm happy to announce the first (test / beta) release of v4l-utils,
> >>> v4l-utils is the combination of various v4l and dvb utilities which
> >>> used to be part of the v4l-dvb mercurial kernel tree and libv4l.
>
> Reading some more about dvb-apps, I have to side with the people
> who are voting for keeping dvb-apps separate. I do wonder
> if those people and you and Mauro are talking about the same dvb-apps,
> or if this is just a misunderstanding.
> 
> The dvp-apps I'm talking about now, and of which I'm not in favor of
> merging them with v4l-utils are the ones, which can be downloaded
> here:
> http://linuxtv.org/downloads/
> http://linuxtv.org/hg/dvb-apps
> 
> Although I must agree with the people who are in favor of
> integrating this into v4l-utils, that this needs much more active
> maintainership wrt to making regular tarbal releases for distro's
> to consume.
> 
> Still I believe this should stay as a separate project, because
> so far it clearly was, and I see no huge advantages in integrating it.
> 
> Signs that this clearly is a separate stand alone project:
> 
> 1) It has done several tarbal releases (these are ancient guys,
> this needs to be fixed).
> 
> 2) It has its own VCS
> 
> 3) It is packaged up by various distros:
> 
> http://packages.debian.org/sid/video/dvb-apps
> http://packages.ubuntu.com/source/dapper/linuxtv-dvb-apps
> http://cvs.fedoraproject.org/viewvc/rpms/dvb-apps/
> http://rpm.pbone.net/index.php3?stat=3&search=dvb-apps&srodzaj=3
> http://gentoo-portage.com/media-tv/linuxtv-dvb-apps
> http://aur.archlinux.org/packages.php?ID=2034
> http://www.slax.org/modules.php?action=detail&id=3143
> https://dev.openwrt.org/ticket/2804
> 
> 4) It is referenced as a standalone project by 3th parties:
> http://www.mythtv.org/wiki/Dvb-apps
> 
> 
> So given the stand alone nature, and that it is already widely packaged
> as a standalone project by distro's. For now I'm against ingrating this
> into v4l-utils.
> 
> And the most important argument for me being against this, is that one
> of the 2 active contributors (judging from the hg tree), Manu Abraham,
> is very much against integration. And the people who are in favor
> (Hans Verkuil and Mauro) don't seem to have done any commits to the
> tree in question, for at least the last 2 years.
> 
> So unless we can get some buy in for integrating this in to
> v4l-utils from active dvb-apps contributors I'm opposed to the integration.

I agree with you that dvb-apps should stay a seperate project as there are 
now. I don't see any reason for integrating them into one project with v4l-
utils. There are no developers actively working on both projects. This would 
lead to problematic release preparation for sure. Especially when keeping in 
mind that Mauro and Manu are not exactly happy with working together, so I 
really think it would be much easier to keep it seperated.
Also I don't think that all users who use dvb-apps would need to have all the 
v4l-utils and vice versa.
So please keep it seperate.
 
> With this all said, I must say: Manu please do a tarbal release real real
> soon, and make a habit out of doing so regularly!

This is of course right and should be done soon. I think this wasn't done for 
a long time due to the incompleteness of v5 API support. But afaik Manu is 
currently working on it, so it shouldn't take too long anymore.

Regards,
Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New DVB-Statistics API

[Julian Scheel]

Am 09.12.09 14:02, schrieb Mauro Carvalho Chehab:

Manu Abraham wrote:
   

On Wed, Dec 9, 2009 at 3:43 AM, Mauro Carvalho Chehab
  wrote:
 
   

Even with STB, let's assume a very slow cpu that runs at 100 Megabytes/second. 
So, the clock
speed is 10 nanoseconds. Assuming that this CPU doesn't have a good pipeline, 
being
capable of handling only one instruction per second, you'll have one 
instruction at executed
at each 10 nanoseconds (as a reference, a Pentium 1, running at 133 Mbps is 
faster than this).
   

Incorrect.
A CPU doesn't execute instruction per clock cycle. Clock cycles
required to execute an instruction do vary from 2 cycles 12 cycles
varying from CPU to CPU.
 

See the description of an old Pentium MMX processor (the sucessor of i586, 
running up to 200 MHz):
http://www.intel.com/design/archives/processors/mmx/docs/243185.htm

Thanks to superscalar architecture, it runs 2 instructions per clock cycle 
(IPC).

Newer processors can run more instructions per clock cycle. For example, any 
Pentium-4 processor,
can do 3 IPC:
http://www.intel.com/support/processors/pentium4/sb/CS-017371.htm
   


I don't think you can just take the average IPC rates into account for 
this. When doing a syscall the processors TLB cache will be cleared, 
which will force the CPU to go to the whole instruction pipeline before 
the first syscall instruction is actually executed. This will introduce 
a delay for each syscall you make. I'm not exactly sure about the length 
of the delay, but I think it should be something like 2 clock cycles.

So, even on such bad hardware that is at least 20x slower than a netbook 
running at 1Gbps,
what determines the delay is the amount of I/O you're doing, and not the number 
of extra
code.
   


The I/O overhead required to read 4 registers from hardware is the
same whether you use the ioctl approach or s2api.
 

It seems you got my point. What will determinate the delay is the number of 
I/O's, and not the
amount of instructions.
   
The number of hardware I/Os is constant for both cases, so we do not 
need to discuss them as pro/con for any of the proposals.

Eventually, as you have pointed out yourself, The data struct will be
in the cache all the time for the ioctl approach. The only new
addition to the existing API in the ioctl case is a CALL instruction
as compared to the numerous instructions in comparison to that you
have pointed out as with the s2api approach.
 

True, but, as shown, the additional delay introduced by the code is less than 
0.01%, even on
a processor that has half of the speed of a 12-year old very slow CPU (a 
Pentium MMX @ 100 MHz
is capable of 2 IPC. My calculus assumed 1 IPC).

So, what will affect the delay is the number of I/O you need to do.

To get all data that the ioctl approach struct has, the delay for S2API will be 
equal.
To get less data, S2API will have a small delay.
   
Imho the S2API would be slower when reading all data the ioctl fetches, 
due to the way the instructions would be handled.


Correct me, if I'm wrong with any of this.

Cheers,
Julian

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New DVB(!!)-Statistics API

[Julian Scheel]

Am 08.12.09 10:16, schrieb Julian Scheel:

Hello together,

after the last thread which asked about signal statistics details 
degenerated into a discussion about the technical possibilites for 
implementing an entirely new API, which lead to nothing so far, I 
wanted to open a new thread to bring this forward. Maybe some more 
people can give their votes for the different options


Actually Manu did propose a new API for fetching enhanced statistics. 
It uses new IOCTL to directly fetch the statistical data in one go 
from the frontend. This propose was so far rejected by Mauro who wants 
to use the S2API get/set calls instead.


Now to give everyone a quick overview about the advantages and 
disadvantages of both approaches I will try to summarize it up:


1st approach: Introduce new IOCTL

Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
 1. all values are fetched in one go (as long as possible) from the 
frontend, so that they can be treated as one united and be valued in 
conjunction
 2. the requested values arrive the caller in an almost constant 
timeframe, as the ioctl is directly executed by the driver
- It does not interfere with the existing statistics API, which has to 
be kept alive as it is in use for a long time already. (unifying it's 
data is not the approach of this new API)


Cons:
- Forces the application developers to interact with two APIs. The 
S2API for tuning on the one hand and the Statistics API for reading 
signal values on the other hand.


2nd approach: Set up S2API calls for reading statistics

Pros:
- Continous unification of the linuxtv API, allowing all calls to be 
made through one API. -> easy for application developers


Cons:
- Due to the key/value pairs used for S2API getters the statistical 
values can't be read as a unique block, so we loose the guarantee, 
that all of the values can be treatend as one unit expressing the 
signals state at a concrete time.
- Due to the general architecture of the S2API the delay between 
requesting and receiving the actual data could become too big to allow 
realtime interpretation of the data (as it is needed for applications 
like satellite finders, etc.)


I hope that this summary is technically correct in all points, if not 
I'd be thankful for objective corrections. I am not going to 
articulate my personal opinion in this mail, but I will do it in 
another mail in reply to this one, so that this mail can be seen as a 
neutral summary of the current situation.


So now it's everyones turn to think about the options and give an 
opinion. In the end I am quite sure that all of us would have great 
benefits of an improved statistics API.


Cheers,
Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


The above mail of course has nothing to do with USB-Statistics. I must 
have been slightly confused when typing the message title! Sorry for that!

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

New USB-Statistics API

[Julian Scheel]

Hello together,

after the last thread which asked about signal statistics details 
degenerated into a discussion about the technical possibilites for 
implementing an entirely new API, which lead to nothing so far, I wanted 
to open a new thread to bring this forward. Maybe some more people can 
give their votes for the different options


Actually Manu did propose a new API for fetching enhanced statistics. It 
uses new IOCTL to directly fetch the statistical data in one go from the 
frontend. This propose was so far rejected by Mauro who wants to use the 
S2API get/set calls instead.


Now to give everyone a quick overview about the advantages and 
disadvantages of both approaches I will try to summarize it up:


1st approach: Introduce new IOCTL

Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
 1. all values are fetched in one go (as long as possible) from the 
frontend, so that they can be treated as one united and be valued in 
conjunction
 2. the requested values arrive the caller in an almost constant 
timeframe, as the ioctl is directly executed by the driver
- It does not interfere with the existing statistics API, which has to 
be kept alive as it is in use for a long time already. (unifying it's 
data is not the approach of this new API)


Cons:
- Forces the application developers to interact with two APIs. The S2API 
for tuning on the one hand and the Statistics API for reading signal 
values on the other hand.


2nd approach: Set up S2API calls for reading statistics

Pros:
- Continous unification of the linuxtv API, allowing all calls to be 
made through one API. -> easy for application developers


Cons:
- Due to the key/value pairs used for S2API getters the statistical 
values can't be read as a unique block, so we loose the guarantee, that 
all of the values can be treatend as one unit expressing the signals 
state at a concrete time.
- Due to the general architecture of the S2API the delay between 
requesting and receiving the actual data could become too big to allow 
realtime interpretation of the data (as it is needed for applications 
like satellite finders, etc.)


I hope that this summary is technically correct in all points, if not 
I'd be thankful for objective corrections. I am not going to articulate 
my personal opinion in this mail, but I will do it in another mail in 
reply to this one, so that this mail can be seen as a neutral summary of 
the current situation.


So now it's everyones turn to think about the options and give an 
opinion. In the end I am quite sure that all of us would have great 
benefits of an improved statistics API.


Cheers,
Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Details about DVB frontend API

[Julian Scheel]

Manu Abraham schrieb

Not only is it time critical, but it should also be "atomic", ie it
should be all in one go, ie one single snapshot of an event, not
events bunched together serially. Things wont seem that "atomic" on a
system with a large load. Latency will have a significant effect on
the statistics (values) read back, since it is again disjoint events.
  

Right, the values should be treatened as a unique unit...

Time stamping would be helpful, prior to any processing by the library
such that the time overhead for the calculations is offset, but that
can be really useful within the same library alone. I can't imagine
how time stamping can be helpful to result a low latency.
  


No, timestamping would of course not be helpful for reducing the 
latency, it would just allow to correctly interpret values if they are 
delayed. So that you won't assume the values you receive can be taken as 
proven for the current moment.



If you don't have a low latency, Consider this (even when you are able
to ignore the statistics for any general processing, on the thought
that "i can always live with those errors and i always had"):

The error fedback into the loop for a sat positioner/rotor. The final
calculated position will never be the actual position that you wanted
the antenna to be at a certain location. The problem would be made
worser by the different rotor speeds as well, to add to the nightmare.

With the V5 operation, you bunch operations together in a serial
manner, it is atomic to the sense that it happens or doesn't happen,
but it is not atomic to the sense of any particular time frame. You
just keep your fingers crossed that the CPU executes the event in the
shortest frame. This won't hold good in all cases when there is a high
latency on the system when there is a significant load.

eg: You can imagine an IPTV headend streaming data, with a small CPU
with multiple tuners and trying to compensate the offset that's
introduced.

Still worser situation: imagine a gyro stabilized setup, where the
base itself is not that stationary.
  


Ok, thanks for the details about how V5 API deals with this. Indeed this 
is a major issue one has to think of when talking about signal statistics.



Some other points to be considered:
* As of now, the get/set interface is not used for any signal statistics

* Even if one prefers to normalize all parameters into one single
standard, even then you wouldn't land with a get/set interface.

* The generic get/set interface is good when you have an unknown set
of parameters, such that one can keep adding in parameters.  Eg: most
people favoured this approach when we had a larger set of modulations/
error correction and other parameters.

For the case what we have currently, we do not have such a varied set
of parameters to consider.


Right, the situation about the parameters which will be requested in 
terms of signal statistics should not change for future frontend types, 
so it really should be a save approach to have a static API here. I have 
not yet done a very detailed look into your proposed patch, but I will 
do so tomorrow.

I really would like to see a reliable statistics API in v4l-dvb soon.

Regards,
Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Details about DVB frontend API

[Julian Scheel]

Am Freitag, 20. November 2009 10:29:34 schrieb Manu Abraham:
> Let me explain a bit. The current issue that persists as Devin explained in
> another email explains things to a certain extend, but still i think it
> might be better to detail further.
> 
> Generally a request can be classified to 3 basic types.
> 
> 1. Request to acquire, retrieve acquisition details
> 2. Get information (device state, device info)
> 3. Get information (channel statistics)
> 
> 
> The first one for example is a request to say tune to a channel, get tuned
> channel details, or even other frontend specific commands such as SEC
> operations. These operations are not very critical with regards on a time
> scale, just that things could be shifted all along on the time scale, the
> worser the implementation, the larger the time "taken to carry around a
> larger set of information to handle the operation". Currently, the V3.x and
> the V5 implementation handles this. The V3 implementation is small and
>  fast, while the V5 implementation is "sluggish".
> 
> 
> The second one gets basic device information. The V3 implementation handled
> this to a certain extend, but the V5 implementation hardly handles this and
> the implementation is rather crude rather than being "sophisticated".
> 
> 
> The third aspect which is basically needed in most cases for debugging the
> channel properties. If all things were ideal, one wouldn't need to know the
> details on what's going on inside. So being in the far from ideal thing,
>  the requisite to know what happens internally is very much a need in all
>  cases. Another point to be noted is that this category of information is
>  very much critical on a timescale as these parameters are valid for a very
>  certain instances of time only. The more this information gets out of
>  sync, the more these values are meaningless. Also another point to be
>  noted is that all these values when read back together at the very same
>  instance only does make sense. It is indeed very hard to achieve this very
>  short timespan between each of the values being monitored. The larger the
>  bandwidth associated, the larger the error introduced in the readback of
>  the values within the same timeframe in between the reads. So the
>  timeframe has to be the very least possible in between this operation to
>  the device driver internals too..
> 
> 
> Although, i have pointed out with this patch what happens at the driver
> level and at the userspace level, There needs additions to the libdvb parts
> to handle whatever conversions from format x to y. This needs to be handled
> since it might not be very easy to be handled consistsently by all
> applications. So in this concept, the application can choose the format
> conversion from the library as well, such that the application can provide
> the statistics in either the the driver native format, or a unified format
> (conversion done by the library) if the user prefers it.
> 
> > We are already redefining some existing ioctls there, so it would be
> > clearer for the userspace developers what would be the new way to
> > retrieve frontend stats, as we can simply say that DVBS2API features
> > superseeds the equivalent DVB v3 ioctls.
> 
> As i have noted above, the statistics related calls have a meaning, if and
> only if it is hanled very fast and properly with no caching. Having a
> genarlized datastructure to handle this event, breaks up the whole meaning
> of having this call itself in this position.
> 
> What an API generally does is to make things generalized. When one makes
> things "the most generalized way" an overhead is also associated with it in
> terms of performance. If things were possible, i would directly read from
> memory from an application from the hardware itself for processing data in
> such a scenario, rather than to make things very generalized. This is an
> area where concepts like data caching can be ruled out completely. We are
> already at a disadvantage with the kernel driver doing a copy_to_user
> itself. Ideally, a memory mapped to userspace would have been the ideal
> thing over here.
> 
> It is just the question of having yet another set of statistics calls that
> handles the information properly or not.

Hi Manu,

thanks for the detailed explanation of your point. Actually I am not 
completely familiar with how the S2API calls are handled internally. Still are 
there any proven measurements about the timeframe the calls are being executed 
within? - I absolutely see that reading signal statistics is a time critical 
process, at least it is important to be able to assign the data to a specific 
moment so it can be interpreted in conjunction with the data which is being 
received in that moment.
If this would be the only point where the delay is important one might be able 
to overcome this by adding timestamps into the retrieved data, although I am 
not sure if this would be feasible at all. Anyway having a very good and low-
delay 

Re: Ubuntu karmic, 2.6.31-14 + KNC1 DVB-S2 = GPF

[Julian Scheel]

> It would appear that since I've upgraded to Ubuntu Karmic and the
> 2.6.31-14 kernel, my KNC1 DVB-S2 now enjoys a GPF when I use scan-s2.
> 
> Has anyone else come across this issue with a KNC1 card? Any suggestions
> what I can do to trace the issue?

Which gcc version are you using?
If you run a gcc 4.4 could you try to compile the v4l-dvb tree with a gcc-4.3 
and see if it helps?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Mystique SaTiX DVB-S2 [KNC ONE] - Kernel panic

[Julian Scheel]

Am Montag, 28. September 2009 18:59:19 schrieb Folnin Vi:
> I am having problems with Mystique SaTiX DVB-S2 card.
> 
> Using the latest drivers from linuxtv.org.
> 
> Every time I use the card kernel panic occurs.
> For example when trying to scan transponder.
> 
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
> in: fb40d12f

Have you gained any progress with this problem? - Actually I think this only 
happens when the v4l-dvb is compiled with gcc 4.4 - using gcc 4.3 works around 
it. Can you confirm this?
Besides I am quite clueless what's causing this issue so far.

-Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: stb0899 i2c communication broken after suspend

[Julian Scheel]

Am Freitag, 31. Juli 2009 18:44:13 schrieb Julian Scheel:
> I made an interesting observation with the stb0899 drivers. If the
> system was in suspend to ram state (no matter if dvb modules were
> unloaded before or not) the i2c communication of stb0899 driver and
> chipset seems to be somewhat broken. Tuning to dvb-s channels still
> works as expected, but tuning to dvb-s2 channels is completely broken.
> The system log shows this error on the first tuning approach:
> stb0899_write_s2reg ERR (1), Device=[0xf3fc], Base Address=[0x0460],
> Offset=[0xf34c], Data=[0x], status=-121

I actually played around a bit more and figured out, that after a reload of 
the i2c_core module the s2 channels start working again after suspend. But as 
this module is needed by many others (like nvidia, so X server has to be 
stopped to unload it), it can't be simply reloaded.
Now the question is whether the issue is in i2c_core itself or in the way that 
stb0899-drivers use i2c_core. Especially I am wondering why only the s2 
channels fail, isn't for the dvb-s2 channels i2c communication used as well?

-Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix lowband tuning with tda8261

[Julian Scheel]

Alex Deucher schrieb:

On Fri, Jul 31, 2009 at 12:40 PM, Julian Scheel wrote:
  

Attached is a patch which fixes tuning to low frequency channels with
stb0899+tda8261 cards like the KNC TV-Station DVB-S2.
The cause of the issue was a broken if construct, which should have been an
if/else if, so that the setting for the lowest matching frequency is
applied.

Without this patch for example tuning to "arte" on Astra 19.2, 10744MHz
SR22000 failed most times and when it failed the communication between
driver and tda8261 was completely broken.
This problem disappears with the attached patch.




Please replay with your Signed Off By.

Alex

  

diff -r 6477aa1782d5 linux/drivers/media/dvb/frontends/tda8261.c
--- a/linux/drivers/media/dvb/frontends/tda8261.c   Tue Jul 21 09:17:24
2009 -0300
+++ b/linux/drivers/media/dvb/frontends/tda8261.c   Fri Jul 31 18:36:07
2009 +0200
@@ -136,9 +136,9 @@

   if (frequency < 145)
   buf[3] = 0x00;
-   if (frequency < 200)
+   else if (frequency < 200)
   buf[3] = 0x40;
-   if (frequency < 215)
+   else if (frequency < 215)
   buf[3] = 0x80;

   /* Set params */


    

Signed-off-by: Julian Scheel 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Fix lowband tuning with tda8261

[Julian Scheel]

Attached is a patch which fixes tuning to low frequency channels with 
stb0899+tda8261 cards like the KNC TV-Station DVB-S2.
The cause of the issue was a broken if construct, which should have been 
an if/else if, so that the setting for the lowest matching frequency is 
applied.


Without this patch for example tuning to "arte" on Astra 19.2, 10744MHz 
SR22000 failed most times and when it failed the communication between 
driver and tda8261 was completely broken.

This problem disappears with the attached patch.
diff -r 6477aa1782d5 linux/drivers/media/dvb/frontends/tda8261.c
--- a/linux/drivers/media/dvb/frontends/tda8261.c   Tue Jul 21 09:17:24 
2009 -0300
+++ b/linux/drivers/media/dvb/frontends/tda8261.c   Fri Jul 31 18:36:07 
2009 +0200
@@ -136,9 +136,9 @@
 
if (frequency < 145)
buf[3] = 0x00;
-   if (frequency < 200)
+   else if (frequency < 200)
buf[3] = 0x40;
-   if (frequency < 215)
+   else if (frequency < 215)
buf[3] = 0x80;
 
/* Set params */

stb0899 i2c communication broken after suspend

[Julian Scheel]

I made an interesting observation with the stb0899 drivers. If the 
system was in suspend to ram state (no matter if dvb modules were 
unloaded before or not) the i2c communication of stb0899 driver and 
chipset seems to be somewhat broken. Tuning to dvb-s channels still 
works as expected, but tuning to dvb-s2 channels is completely broken.

The system log shows this error on the first tuning approach:
stb0899_write_s2reg ERR (1), Device=[0xf3fc], Base Address=[0x0460], 
Offset=[0xf34c], Data=[0x], status=-121


Has anyone seen a similar behaviour or has any ideas?
This happens on latest v4l-dvb head and kernel 2.6.29

-Julian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html