Re: [PATCH] AVerTV MCE 116 Plus radio

[Aleksandr V. Piskunov]

On Wed, Feb 03, 2010 at 07:33:20PM -0500, Andy Walls wrote:
 On Tue, 2010-02-02 at 13:29 -0200, Mauro Carvalho Chehab wrote:
  Hi Andy,
  
  This patch has never been applied or nacked. From your last comment, it
  seems that you're waiting for Aleksandr Signed-of-by:.
  
  If this is still the case, I suggest you to wait for a couple days. If he 
  doesn't
  send it, it is safe to add it without his SOB, since it is really a trivial 
  change.
 
 I'd like to look at this one once more.  The extra 50 ms and another
 reset may be avoidable.
 
 cx25840-core.c:set_input() gets called for s_frequency so I'd like not
 to add 50 ms if not needed.

This patch is ugly, thats why no SOB was provided by me :)
Delaying every frequency change by 50 ms is no-go.

One possible solution is to mess with audio controller registers only when its 
really
required: when standard has to be changed, when TV-Radio switch occurs, etc.

I have a patch that does something like this, will mail when get to PC with 
that card
and retest it.

As far as I remember there was another codepath that 100% triggers tinny audio, 
perhaps
it was a change of sampling rate.

 
 Regards,
 Andy
 
  Cheers,
  Mauro.
  
  Andy Walls wrote:
   On Sun, 2009-10-11 at 04:01 +0300, Aleksandr V. Piskunov wrote:
   On Tue, Oct 06, 2009 at 11:11:59AM +0300, Aleksandr V. Piskunov wrote:
   On Tue, Oct 06, 2009 at 11:04:06AM +0300, Aleksandr V. Piskunov wrote:
   Added FM radio support to Avermedia AVerTV MCE 116 Plus card
  
   What leaves me puzzled, radio only works ok with ivtv newi2c=1
  
   With default newi2c audio is tinny, metallic, with some strange static.
   Similar problem with pvr-150 was reported years ago, guess issue is 
   still
   unresolved, perhaps something with cx25840..
   This particular tinny audio problem is definitely I2C speed related, 
   to be
   more precise, audio only goes bad if i2c-algo-bit is being run with 
   udelay
   less than 15, i.e. i2c bus frequency is higher than 30 KHz.
  
   So with default udelay=10 or udelay=5 (optimal for IR reciever on that 
   board)
   radio goes bad. Running with newi2c=1 is ok, but again it isn't optimal 
   for IR
   reciever on AVerTV M116.
  
   I2C reads/writes to cx25840 themself are ok, verified using register 
   readback
   after each write/write4. Problem seems to be that with cx25840 register 
   writes
   coming too fast on higher i2c bus speed, switching register 0x808 _from_ 
   TV standard autodetection mode (0xff) _to_ FM radio mode (0xf9) leaves 
   chip 
   audio detection routine in inconsistent state.
  
   The only solution I found is to do standard routine (assert_reset + 
   write +
   deassert_reset) followed by 50ms delay and another reset.
  
   Following patch works_for_me, can be improved to only delay/doublereset 
   when
   really needed, etc. Andy, could you comment/review?
   
   Aleksandr,
   
   Could you provide your Signed-off-by for this patch?  I'm going to
   commit it as is.
   
   Thanks,
   Andy
   
   diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c 
   b/linux/drivers/media/video/cx25840/cx25840-core.c
   --- a/linux/drivers/media/video/cx25840/cx25840-core.c
   +++ b/linux/drivers/media/video/cx25840/cx25840-core.c
   @@ -626,7 +642,13 @@
if (state-radio) {
cx25840_write(client, 0x808, 0xf9);
cx25840_write(client, 0x80b, 0x00);
   -}
   +/* Double reset cx2384x after setting FM radio mode, 
   helps to
   +   avoid tinny audio when ivtv I2C bus is being run on
   +   frequency higher than 30 KHz */
   +cx25840_and_or(client, 0x810, ~0x01, 0);
   +msleep(50);
   +cx25840_and_or(client, 0x810, ~0x01, 1);
   +}   
else if (std  V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
   that causes audio to drop out. For these models the
  
   --
   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
  
  
 
--
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: cx18: Need information on SECAM-D/K problem with PVR-2100

[Aleksandr V. Piskunov]

On Mon, Jan 04, 2010 at 02:40:47PM +0300, Sergey Bolshakov wrote:
  Andy == Andy Walls awa...@radix.net writes:
 
   Sergey,
   On IRC you mentioned a problem of improper detection of SECAM-D/K with
   the Leadtek PVR2100 (XC2028 and CX23418) from an RF source.
 
 It was some misunderstanding, i suppose, i do not have problems with
 secam, i had improper detection of sound standard (and silence as
 result) on pal channels. Later i've found, that fully-specified std
 (pal-d instead of just pal) helps, so i can live with that.
 

Thats a general problem of any card with XC2028 silicon tuner, user
(tv app) has to specify a precise substandard (audio carrier frequency)
for sound to work.

PAL-BG users (western europe, etc) won't notice it, since in case of 
generic PAL standard set, xceive tuner defaults to BG substandard firmware.

In other cases, you either have to specify correct standard (DK, etc) or
try to specify PAL-I, which seems to work for BG, DK and I carriers.
At least it works for me :)

See http://osdir.com/ml/linux-media/2009-09/msg00997.html for more details.
--
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: Status of CX25821 PCI-E capture driver

[Aleksandr V. Piskunov]

On Fri, Oct 16, 2009 at 10:25:53AM -0400, Steven Toth wrote:
 On Fri, Oct 16, 2009 at 8:46 AM, Donald Bailey don...@apple2pl.us wrote:
  I recently picked up a 16 port DVR card from China which uses two CX25821
  chips.  I compiled the staging driver for it and was able to load it
  successfully with kernel 2.6.32-rc2.  But I can't find any /dev devices to
  get at the inputs.  I created a character device with a major/minor of 81/0
  but am unable to open it.
 
 We're planning to do some work inside KernelLabs on that particular
 driver. We have access to hardware and are looking to stabilize and
 improve the overall quality of the driver to a commercial production
 grade. I don't have any timescales as this is currently and unfunded
 project but you're not alone, the driver does need some major
 improvements.

Mmm, any links to a reasonably priced CX25821 capture cards?
--
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] AVerTV MCE 116 Plus radio

[Aleksandr V. Piskunov]

On Tue, Oct 06, 2009 at 11:11:59AM +0300, Aleksandr V. Piskunov wrote:
 On Tue, Oct 06, 2009 at 11:04:06AM +0300, Aleksandr V. Piskunov wrote:
  Added FM radio support to Avermedia AVerTV MCE 116 Plus card
  
 
 What leaves me puzzled, radio only works ok with ivtv newi2c=1
 
 With default newi2c audio is tinny, metallic, with some strange static.
 Similar problem with pvr-150 was reported years ago, guess issue is still
 unresolved, perhaps something with cx25840..

This particular tinny audio problem is definitely I2C speed related, to be
more precise, audio only goes bad if i2c-algo-bit is being run with udelay
less than 15, i.e. i2c bus frequency is higher than 30 KHz.

So with default udelay=10 or udelay=5 (optimal for IR reciever on that board)
radio goes bad. Running with newi2c=1 is ok, but again it isn't optimal for IR
reciever on AVerTV M116.

I2C reads/writes to cx25840 themself are ok, verified using register readback
after each write/write4. Problem seems to be that with cx25840 register writes
coming too fast on higher i2c bus speed, switching register 0x808 _from_ 
TV standard autodetection mode (0xff) _to_ FM radio mode (0xf9) leaves chip 
audio detection routine in inconsistent state.

The only solution I found is to do standard routine (assert_reset + write +
deassert_reset) followed by 50ms delay and another reset.

Following patch works_for_me, can be improved to only delay/doublereset when
really needed, etc. Andy, could you comment/review?

diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c 
b/linux/drivers/media/video/cx25840/cx25840-core.c
--- a/linux/drivers/media/video/cx25840/cx25840-core.c
+++ b/linux/drivers/media/video/cx25840/cx25840-core.c
@@ -626,7 +642,13 @@
if (state-radio) {
cx25840_write(client, 0x808, 0xf9);
cx25840_write(client, 0x80b, 0x00);
-   }
+   /* Double reset cx2384x after setting FM radio mode, helps to
+  avoid tinny audio when ivtv I2C bus is being run on
+  frequency higher than 30 KHz */
+   cx25840_and_or(client, 0x810, ~0x01, 0);
+   msleep(50);
+   cx25840_and_or(client, 0x810, ~0x01, 1);
+   }   
else if (std  V4L2_STD_525_60) {
/* Certain Hauppauge PVR150 models have a hardware bug
   that causes audio to drop out. For these models the

--
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] AVerTV MCE 116 Plus radio

[Aleksandr V. Piskunov]

Added FM radio support to Avermedia AVerTV MCE 116 Plus card

Signed-off-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com

diff --git a/linux/drivers/media/video/ivtv/ivtv-cards.c 
b/linux/drivers/media/video/ivtv/ivtv-cards.c
--- a/linux/drivers/media/video/ivtv/ivtv-cards.c
+++ b/linux/drivers/media/video/ivtv/ivtv-cards.c
@@ -965,6 +965,7 @@
{ IVTV_CARD_INPUT_AUD_TUNER,  CX25840_AUDIO5   },
{ IVTV_CARD_INPUT_LINE_IN1,   CX25840_AUDIO_SERIAL, 1 },
},
+   .radio_input = { IVTV_CARD_INPUT_AUD_TUNER,  CX25840_AUDIO5 },
/* enable line-in */
.gpio_init = { .direction = 0xe000, .initial_value = 0x4000 },
.xceive_pin = 10,
--
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] AVerTV MCE 116 Plus radio

[Aleksandr V. Piskunov]

On Tue, Oct 06, 2009 at 11:04:06AM +0300, Aleksandr V. Piskunov wrote:
 Added FM radio support to Avermedia AVerTV MCE 116 Plus card
 

What leaves me puzzled, radio only works ok with ivtv newi2c=1

With default newi2c audio is tinny, metallic, with some strange static.
Similar problem with pvr-150 was reported years ago, guess issue is still
unresolved, perhaps something with cx25840..
--
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: [REVIEW] ivtv, ir-kbd-i2c: Explicit IR support for the AVerTV M116 for newer kernels

[Aleksandr V. Piskunov]

  Basicly during the I2C operation that reads scancode, controller seems
  to stop processing input from IR sensor, resulting a loss of keypress.
  
  So the solution(?) I found was to decrease the udelay in
  ivtv_i2c_algo_template from 10 to 5. Guess it just doubles the frequency
  of ivtv i2c bus or something like that. Problem went away, IR controller
  is now working as expected.
 
 That's a long standing error in the ivtv driver.  It ran the I2C bus at
 1/(2*10 usec) = 50 kHz instead of the standard 100 kHz.
 
 Technically any I2C device should be able to handle clock rates down to
 about DC IIRC; so there must be a bug in the IR microcontroller
 implementation.
 
 Also the CX23416 errantly marks its PCI register space as cacheable
 which is probably wrong (see lspci output).  This may also be
 interfering with proper I2C operation with i2c_algo_bit depedning on the
 PCI bridges in your system.
 
  
  So question is:
  1) Is it ok to decrease udelay for this board?
 
 Sure, I think.  It would actually run the ivtv I2C bus at the nominal
 clock rate specified by the I2C specification.
 
 I never had any reason to change it, as I feared causing regressions in
 many well tested boards.
 
 
  2) If yes, how to do it right?
 
 Try:
 
 # modprobe ivtv newi2c=1
 
 to see if that works first. 
 

udelay=10, newi2c=0  = BAD
udelay=10, newi2c=1  = BAD
udelay=5,  newi2c=0  = OK
udelay=5,  newi2c=1  = BAD


newi2c=1 also throws some log messages, not sure if its ok or not.

Oct  5 11:41:16 moon kernel: [45430.916449] ivtv: Start initialization, version 
1.4.1
Oct  5 11:41:16 moon kernel: [45430.916618] ivtv0: Initializing card 0
Oct  5 11:41:16 moon kernel: [45430.916628] ivtv0: Autodetected AVerTV MCE 116 
Plus card (cx23416 based)
Oct  5 11:41:16 moon kernel: [45430.918887] ivtv :03:06.0: PCI INT A - GSI 
20 (level, low) - IRQ 20
Oct  5 11:41:16 moon kernel: [45430.919229] ivtv0:  i2c: i2c init
Oct  5 11:41:16 moon kernel: [45430.919234] ivtv0:  i2c: setting scl and sda to 
1
Oct  5 11:41:16 moon kernel: [45430.937745] cx25840 0-0044: cx25843-23 found @ 
0x88 (ivtv i2c driver #0)
Oct  5 11:41:16 moon kernel: [45430.949145] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.951628] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.954191] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.956724] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.959211] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.961749] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.964236] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.966722] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.966786] ivtv0:  i2c: i2c write to 43 failed
Oct  5 11:41:16 moon kernel: [45430.971106] tuner 0-0061: chip found @ 0xc2 
(ivtv i2c driver #0)
Oct  5 11:41:16 moon kernel: [45430.974404] wm8739 0-001a: chip found @ 0x34 
(ivtv i2c driver #0)
Oct  5 11:41:16 moon kernel: [45430.986328] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.988871] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.991355] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.993904] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.996427] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45430.998938] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.001477] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.003968] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.004053] ivtv0:  i2c: i2c write to 18 failed
Oct  5 11:41:16 moon kernel: [45431.011333] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.013883] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.016418] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.018911] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.021463] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.023937] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.026478] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.028998] ivtv0:  i2c: Slave did not ack
Oct  5 11:41:16 moon kernel: [45431.029063] ivtv0:  i2c: i2c write to 71 failed
Oct  5 11:41:16 moon kernel: [45431.031468] ivtv0:  i2c: Slave did not ack


--
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: [REVIEW] ivtv, ir-kbd-i2c: Explicit IR support for the AVerTV M116 for newer kernels

[Aleksandr V. Piskunov]

On Mon, Oct 05, 2009 at 11:04:02AM +0200, Jean Delvare wrote:
 On Mon, 5 Oct 2009 11:50:31 +0300, Aleksandr V. Piskunov wrote:
   Try:
   
   # modprobe ivtv newi2c=1
   
   to see if that works first. 
   
  
  udelay=10, newi2c=0  = BAD
  udelay=10, newi2c=1  = BAD
  udelay=5,  newi2c=0  = OK
  udelay=5,  newi2c=1  = BAD
 
 The udelay value is only used by i2c-algo-bit, not newi2c, so the last
 test was not needed.
 

Yup, also tried udelay=4, IR controller handles it without problems,
though cx25840 and xc2028 doesn't seem to like the 125 KHz frequency,
refusing to communicate. xc2028 even stopped responding, requiring a cold
reboot.

So for M116 board, the most stable combination seems to be 100 KHz i2c bus
and 150ms polling delay (up from 100 default). With this combination
I can quickly press 1234567890 on remote and driver gets the combination
without any losses.
--
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: [REVIEW] ivtv, ir-kbd-i2c: Explicit IR support for the AVerTV M116 for newer kernels

[Aleksandr V. Piskunov]

On Sat, Oct 03, 2009 at 11:44:20AM -0400, Andy Walls wrote:
 Aleksandr and Jean,
 
 Zdrastvoitye  Bonjour,
 
 To support the AVerMedia M166's IR microcontroller in ivtv and
 ir-kbd-i2c with the new i2c binding model, I have added 3 changesets in
 
   http://linuxtv.org/hg/~awalls/ivtv
 

Now the last step to the decent support of M116 remote.

I spent hours banging my head against the wall, controller just doesn't
give a stable keypresses, skips a lot of them. Increasing polling interval
from default 100 ms to 400-500 ms helps a bit, but it only masks the
problem. Decreasing polling interval below 50ms makes it skip virtually
90% of keypresses.

Basicly during the I2C operation that reads scancode, controller seems
to stop processing input from IR sensor, resulting a loss of keypress.

So the solution(?) I found was to decrease the udelay in
ivtv_i2c_algo_template from 10 to 5. Guess it just doubles the frequency
of ivtv i2c bus or something like that. Problem went away, IR controller
is now working as expected.

So question is:
1) Is it ok to decrease udelay for this board?
2) If yes, how to do it right?
--
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: [REVIEW] ivtv, ir-kbd-i2c: Explicit IR support for the AVerTV M116 for newer kernels

[Aleksandr V. Piskunov]

On Sun, Oct 04, 2009 at 04:41:01PM -0400, Andy Walls wrote:
 On Sun, 2009-10-04 at 12:26 +0300, Aleksandr V. Piskunov wrote:
  On Sun, Oct 04, 2009 at 10:44:52AM +0200, Jean Delvare wrote:
   On Sun, 4 Oct 2009 11:31:39 +0300, Aleksandr V. Piskunov wrote:
Tested on 2.6.30.8, one of Ubuntu mainline kernel builds.

ivtv-i2c part works, ivtv_i2c_new_ir() gets called, according to 
/sys/bus/i2c
device @ 0x40 gets a name ir_rx_em78p153s_ave.

Now according to my (very) limited understanding of new binding model, 
ir-kbd-i2c
should attach to this device by its name. Somehow it doesn't, 
ir-kbd-i2c gets loaded
silently without doing anything.
   
   Change the device name to a shorter string (e.g. ir_rx_em78p153s).
   You're hitting the i2c client name length limit. More details about
   this in the details reply I'm writing right now.
  
  Thanks, it works now. ir-kbd-i2c picks up the short name, input device is 
  created, remote
  works.
  
  Another place where truncation occurs is name field in 
  em78p153s_aver_ir_init_data 
  (ivtv-CX23416 EM78P153S AVerMedia). Actual input device ends up with a 
  name
  i2c IR (ivtv-CX23416 EM78P153S , limited by char name[32] in IR_i2c 
  struct.
 
 I'm naive here.  What applications actually show this string or use it?
 For what purposes do applications use it?

Mmm, from the top of my head
1) evtest, using it to test remotes and other input devices.
2) gnome-device-manager, displays a tree of hardware devices with details

I hope when the time comes for a media controller stuff, applications will be 
able to link
all the related hardware, including boards IR device and show this information 
to end-user.
There it becomes a little bit more important to have a readable and meaningful 
name.

  IMHO actual name of resulting input device should be readable by end-user. 
  Perhaps it should
  include the short name of the card itself, or model/color of remote control 
  itself if several
  revisions exist, etc.
 
 The em28xx driver uses things like:
 
   i2c IR (EM28XX Terratec)
   i2c IR (EM28XX Pinnacle PCTV)
 
 The saa7134 driver uses thing like:
   
   Pinnacle PCTV
   Purple TV
   MSI t...@nywhere Plus
   HVR 1110
   BeholdTV
 
 The cx18 driver (i.e. me) uses:
 
   CX23418 Z8F0811 Hauppauge
 
 
 I appear to be user-unfriendly. ;)  I guess I like knowing what devices
 are precisely involved, as it helps me when I need to troubleshoot.  I
 agree that it doesn't help the normal user in day to day operations.
 
 I will change the names to something more card specific.  It could end
 up slightly misleading in the long run.  A single card entry in
 ivtv-cards.c can describe multiple card variants, but gives all those
 variants the same name whether or not the consumer retail names are
 the same.
 
 
 Regards,
 Andy
 
 
--
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: [REVIEW] ivtv, ir-kbd-i2c: Explicit IR support for the AVerTV M116 for newer kernels

[Aleksandr V. Piskunov]

On Sat, Oct 03, 2009 at 11:44:20AM -0400, Andy Walls wrote:
 Aleksandr and Jean,
 
 Zdrastvoitye  Bonjour,
 
 To support the AVerMedia M166's IR microcontroller in ivtv and
 ir-kbd-i2c with the new i2c binding model, I have added 3 changesets in
 
   http://linuxtv.org/hg/~awalls/ivtv
 
 01/03: ivtv: Defer legacy I2C IR probing until after setup of known I2C 
 devices
 http://linuxtv.org/hg/~awalls/ivtv?cmd=changeset;node=3d243437f046
 
 02/03: ivtv: Add explicit IR controller initialization for the AVerTV M116
 http://linuxtv.org/hg/~awalls/ivtv?cmd=changeset;node=0127ed2ea55b
 
 03/03: ir-kbd-i2c: Add support for the AVerTV M116 with the new binding model
 http://linuxtv.org/hg/~awalls/ivtv?cmd=changeset;node=c10e0d5d895c
 
 
 I cannot really test them as I still am using an older kernel.  Could
 you please review, and test them if possible?
 

Thank you, Andy! Much more elegant solution than simply pounding 0x40 on every 
ivtv
board.

Tested on 2.6.30.8, one of Ubuntu mainline kernel builds.

ivtv-i2c part works, ivtv_i2c_new_ir() gets called, according to /sys/bus/i2c
device @ 0x40 gets a name ir_rx_em78p153s_ave.

Now according to my (very) limited understanding of new binding model, 
ir-kbd-i2c
should attach to this device by its name. Somehow it doesn't, ir-kbd-i2c gets 
loaded
silently without doing anything.
--
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: [REVIEW] ivtv, ir-kbd-i2c: Explicit IR support for the AVerTV M116 for newer kernels

[Aleksandr V. Piskunov]

On Sun, Oct 04, 2009 at 10:44:52AM +0200, Jean Delvare wrote:
 On Sun, 4 Oct 2009 11:31:39 +0300, Aleksandr V. Piskunov wrote:
  Tested on 2.6.30.8, one of Ubuntu mainline kernel builds.
  
  ivtv-i2c part works, ivtv_i2c_new_ir() gets called, according to 
  /sys/bus/i2c
  device @ 0x40 gets a name ir_rx_em78p153s_ave.
  
  Now according to my (very) limited understanding of new binding model, 
  ir-kbd-i2c
  should attach to this device by its name. Somehow it doesn't, ir-kbd-i2c 
  gets loaded
  silently without doing anything.
 
 Change the device name to a shorter string (e.g. ir_rx_em78p153s).
 You're hitting the i2c client name length limit. More details about
 this in the details reply I'm writing right now.

Thanks, it works now. ir-kbd-i2c picks up the short name, input device is 
created, remote
works.

Another place where truncation occurs is name field in 
em78p153s_aver_ir_init_data 
(ivtv-CX23416 EM78P153S AVerMedia). Actual input device ends up with a name
i2c IR (ivtv-CX23416 EM78P153S , limited by char name[32] in IR_i2c struct.

IMHO actual name of resulting input device should be readable by end-user. 
Perhaps it should
include the short name of the card itself, or model/color of remote control 
itself if several
revisions exist, etc.
--
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: [REVIEW] ivtv, ir-kbd-i2c: Explicit IR support for the AVerTV M116 for newer kernels

[Aleksandr V. Piskunov]

 Patch #3.
 
  --- a/linux/drivers/media/video/ir-kbd-i2c.cSat Oct 03 11:23:00 
  2009 -0400
  +++ b/linux/drivers/media/video/ir-kbd-i2c.cSat Oct 03 11:27:19 
  2009 -0400
  @@ -730,6 +730,7 @@
  { ir_video, 0 },
  /* IR device specific entries should be added here */
  { ir_rx_z8f0811_haup, 0 },
  +   { ir_rx_em78p153s_aver, 0 },
  { }
   };
   
 
 I think we need to discuss this. I don't really see the point of adding
 new entries if the ir-kbd-i2c driver doesn't do anything about it. This
 makes device probing slower with no benefit. As long as you pass device
 information with all the details, the ir-kbd-i2c driver won't care
 about the device name.
 
 So the question is, where are we going with the ir-kbd-i2c driver? Are
 we happy with the current model where bridge drivers pass IR device
 information? Or do we want to move to a model where they just pass a
 device name and ir-kbd-i2c maps names to device information? In the
 latter case, it makes sense to have many i2c_device_id entries in
 ir-kbd-i2c, but in the former case it doesn't.
 
 I guess the answer depends in part on how common IR devices and remote
 controls are across adapters. If the same IR device is used on many
 adapters then it makes some sense to move the definitions into
 ir-kbd-i2c. But if devices are heavily adapter-dependent, and moving
 the definitions into ir-kbd-i2c doesn't allow for any code refactoring,
 then I don't quite see the point.

I believe when it comes to TV cards, IR RX devices and remotes are mostly
vendor-dependent thing, hardware design is usually reused in different
products of same vendor.

Did some research into Avermedia IR stuff while trying to get my M116 working.

For example during last ~10 years Avermedia had 6(?) remote unit models,
covering entire range of its TV cards (models FP/KH, HR/KJ, HV, JX, KS, KV).
Model name is clearly printed on the remote near the vendor label. There is
no clear connection or logic in how remotes are assigned to product. Analog
USB Volar AX stick has a bulky JX remote, while the more advanced hybrid
Volar HX variant of same stick has a smaller/cheaper HR/KJ remote.

How IR RX part is handled also seems to be device specific, but generally
there are several designs being repeated on different models.

Like the above mentioned 8-bit controller design, it either Elan EM78P153S
or Sonix SN8P2501A on I2C bus, or perhaps other compatible 8-bit controller:
* AVerTV Cardbus Plus (Cardbus, saa713x, SN8P2501A)
  http://www.ixbt.com/monitor/images/aver-cardbus-plus/inside-front.jpg
* AVerTV USB2.0 Plus (USB, tvp5150, SN8P2501A) (not supported?)
  http://www.ixbt.com/monitor/images/aver-usb20-plus/inside-front.jpg
* AVerTV MCE 116 Plus (PCI, ivtv, EM78P153S or SN8P2501A)
  http://www.ixbt.com/monitor/images/aver-m116-plus/aver-m116-plus-front.jpg
* AVerTV Studio 709 (PCI, saa713x, EM78P153S)
  http://www.ixbt.com/monitor/images/aver-709/aver-709-front.jpg

So different buses, different bridge drivers, same IR RX controller design.
--
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: AVerTV MCE 116 Plus remote

[Aleksandr V. Piskunov]

On Sat, Oct 03, 2009 at 09:19:07AM -0400, Andy Walls wrote:
 On Sat, 2009-10-03 at 00:49 +0300, Aleksandr V. Piskunov wrote:
  Preliminary version of patch adding support for AVerTV MCE 116 Plus remote.
  This board has an IR sensor is connected to EM78P153S, general purpose 8-bit
  microcontroller with a 1024 × 13 bits of OTP-ROM. According to i2cdetect, 
  it is
  sitting on address 0x40.
  
  Patch allows ir-kbd-i2c to probe cx2341x boards for this address. Manually
  loading ir-kbd-i2c now detects remote, every key is working as expected.
  
  As I understand, current I2C/probing code is being redesigned/refactored. 
  Sheer
  amount of #ifdefs for every second kernel version is making my eyes bleed, 
  so
  please somebody involved check if patch is ok. 
 
 
 Aleksandr,
 
 
  Should I also add the 0x40 address to addr_list[] in ivtv-i2c.c? How to 
  point
  ivtv to this remote and autoload ir-kbd-i2c?
 
 No.
 
 
 At first glance, this patch doesn't look safe for all ivtv boards so:
 
   Naked-by: Andy Walls awa...@radix.net
 
 
 In ivtv-i2c.c I see:
 
   #define IVTV_MSP3400_I2C_ADDR   0x40
 
 It is probably not good to assume that only an IR microcontroller could
 be at I2C address 0x40 for a CX2341x adapter.
 

Yea, that did confuse me too yesterday, saw it while searching sources for 0x40.
Thanks for pointing out the problem! Besides after some testing I don't really 
like
the way that IR controller behaves, doesn't always catch keypresses, repeats
chaotically and sends wrong keygroup codes from time to time. Basically in 
order to
get a more or less stable keypress, one has to doubleclick the button on 
remote,
strange..

 I will work up an ivtv specific change similar to what I did in
 cx18-cards.c and cx18-i2c.c for IR on the HVR-1600 for bringing up the
 IR for the M116 cards alone.
 
 What kernel version do you use?
 

2.8.28, can easily switch to any later for testing.
--
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

AVerTV MCE 116 Plus remote

[Aleksandr V. Piskunov]

Preliminary version of patch adding support for AVerTV MCE 116 Plus remote.
This board has an IR sensor is connected to EM78P153S, general purpose 8-bit
microcontroller with a 1024 × 13 bits of OTP-ROM. According to i2cdetect, it is
sitting on address 0x40.

Patch allows ir-kbd-i2c to probe cx2341x boards for this address. Manually
loading ir-kbd-i2c now detects remote, every key is working as expected.

As I understand, current I2C/probing code is being redesigned/refactored. Sheer
amount of #ifdefs for every second kernel version is making my eyes bleed, so
please somebody involved check if patch is ok. 

Should I also add the 0x40 address to addr_list[] in ivtv-i2c.c? How to point
ivtv to this remote and autoload ir-kbd-i2c?

diff --git a/linux/drivers/media/video/ir-kbd-i2c.c 
b/linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.c
+++ b/linux/drivers/media/video/ir-kbd-i2c.c
@@ -461,7 +461,7 @@
}
break;
case 0x40:
-   name= AVerMedia Cardbus remote;
+   name= AVerMedia RM-FP/RM-KH remote;
ir-get_key = get_key_avermedia_cardbus;
ir_type = IR_TYPE_OTHER;
ir_codes= ir_codes_avermedia_cardbus_table;
@@ -706,8 +706,12 @@
ir_attach(adap, msg.addr, 0, 0);
}
 
-   /* Special case for AVerMedia Cardbus remote */
-   if (adap-id == I2C_HW_SAA7134) {
+   /* Special case for AVerMedia remotes:
+  * AVerTV Hybrid+FM Cardbus
+  * AVerTV MCE 116 Plus
+  * probably others with RM-FP, RM-KH remotes and microcontroller
+chip @ 0x40 */
+   if ((adap-id == I2C_HW_SAA7134) || (adap-id == I2C_HW_B_CX2341X)) {
unsigned char subaddr, data;
struct i2c_msg msg[] = { { .addr = 0x40, .flags = 0,
   .buf = subaddr, .len = 1},
--
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] cx25840 6.5MHz carrier detection fixes

[Aleksandr V. Piskunov]

On Sat, Sep 26, 2009 at 04:12:59PM -0400, Andy Walls wrote:
 On Sat, 2009-09-26 at 00:16 +0300, Aleksandr V. Piskunov wrote:
  cx25840:
  Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
  Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
  system DK and L.
  
  Signed-off-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com
 
 Aleksandr,
 
 I would like a little more time to look at your patch.

PAL part of the patch shouldn't affect any users IMHO, its the SECAM
part where we got SECAM-L users in France and SECAM-DK in Russia.

 
 However, in the mean time, could you test the DK vs. L autodetection,
 without your patch, using the cx25840 firmware in
 
 http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20070217.tar.gz
 
 ?
 
 The MD5 sum of that firmware is:
 
 $ md5sum /lib/firmware/v4l-cx25840.fw 
 99836e41ccb28c7b373e87686f93712a  /lib/firmware/v4l-cx25840.fw
 
 The cx25840 firmware in
 
 http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20080701.tar.gz
 http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware.tar.gz
 
 is probably wrong to use for the CX2584[0123] chips as it it actually
 CX23148 A/V core firmware - very similar but not the same.
 

Tested following versions of v4l-cx25840.fw, no patch:

99836e41ccb28c7b373e87686f93712a
b3704908fd058485f3ef136941b2e513
647d818c6fc82f385ebfbbd4fb2def6d (comes as makoaudc.rom with win driver)

Same issue with all 3 versions of firmware tested, cold shutdown between
every test.
Quick description: PAL-DK source from cable, strong and clear signal.
On channel switch there are 3 typical outcomes
a) ~50% - DK audio system detected
b) ~40 - controller fails to detect standard, muted, may detect
   something later
c) ~10% - AM-L audio detected, playing some bogus static, may detect DK
   later

Of course there is a possibility that CX25843 doesn't like something
in IF that comes from xc2028 tuner, but as I said, signal ir very good
and picture/audio on every of 50+ channels is crisp and clear.
--
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: xc2028 sound carrier detection

[Aleksandr V. Piskunov]

On Wed, Sep 23, 2009 at 05:27:56PM -0400, Devin Heitmueller wrote:
 On Wed, Sep 23, 2009 at 3:28 PM, Aleksandr V. Piskunov
 aleksandr.v.pisku...@gmail.com wrote:
  Mmm, tested that tuner under windows, it autodetects all 3 sound carrier 
  sub-
  standards instantly: PAL-BG, PAL-DK, PAL-I.
 
  In order to test, I connected ancient Panasonic VCR that has a built-in 
  tuner
  and can output video to RF-OUT on fixed frequency using PAL standard. Sound
  carrier frequency can be choosen using hardware switch BG, DK or I.
 
  So under windows: tuner produces clear audio in BG, DK and I, hardware 
  switch
  can be toggled on fly, audio never stops, only a few miliseconds of static 
  on
  switch.
 
  Under linux: audio only works if driver is set to use specific audio carrier
  sub-standard AND same is selected on PVR. (not to mention extremely 
  unreliable
  PAL-DK detection by cx25843, only works 50% of times, but thats another 
  issue)
 
  Either a more generic firmware exists can be uploaded on xc2028.. or several
  can be uploaded at once. Any xc2028 gurus out there?
 
 It's possible that perhaps the Windows driver is relying on the
 cx25843 standard detection and then using that to load the appropriate
 firmware on the 3028.
 
 I can confirm though Mauro's assertion that the 3028 does use
 different firmware depending on the selected audio standard.  You
 might want to try to get a capture of the device under Windows and see
 what firmware gets loaded.

Ok, done a little research, here are results:

1) Best suitable xc2028 firmware for PAL audio is the one that gets chosen 
for PAL-I, to be more precise its
Firmware 69, type: SCODE FW  MONO HAS IF (0x60008000), IF = 6.00 MHz
With this firmware loaded, tuner seems to pass everything from +5.5 MHz to
+6.5Mhz straight to cx25843, resulting automatic detection of BG, I and DK 
audio.
Instant detection on source change, instant playback, same as under windows.
Would be great if more people would try v4l2-ctl -s pal-i and give feedback,
especially for stereo sources.

2) Extremely unreliable detection of DK was caused by cx25843 trying to guess
if 6.5MHz carrier is system DK or system L, special register was set to 
autodetection
which failed half of the times. Will send a patch in a separate mail.
--
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] cx25840 6.5MHz carrier detection fixes

[Aleksandr V. Piskunov]

cx25840:
Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
system DK and L.

Signed-off-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com

diff --git a/linux/drivers/media/video/cx25840/cx25840-core.c 
b/linux/drivers/media/video/cx25840/cx25840-core.c
--- a/linux/drivers/media/video/cx25840/cx25840-core.c
+++ b/linux/drivers/media/video/cx25840/cx25840-core.c
@@ -647,13 +647,30 @@
}
cx25840_write(client, 0x80b, 0x00);
} else if (std  V4L2_STD_PAL) {
-   /* Follow tuner change procedure for PAL */
+   /* Autodetect audio standard and audio system */
cx25840_write(client, 0x808, 0xff);
-   cx25840_write(client, 0x80b, 0x10);
+   /* Since system PAL-L is pretty much non-existant and
+  not used by any public broadcast network, force
+  6.5 MHz carrier to be interpreted as System DK,
+  this avoids DK audio detection instability */
+   cx25840_write(client, 0x80b, 0x00);
} else if (std  V4L2_STD_SECAM) {
-   /* Select autodetect for SECAM */
+   /* Autodetect audio standard and audio system */
cx25840_write(client, 0x808, 0xff);
-   cx25840_write(client, 0x80b, 0x10);
+   /* If only one of SECAM-DK / SECAM-L is required, then force
+  6.5MHz carrier, else autodetect it */
+   if ((std  V4L2_STD_SECAM_DK) 
+   !(std  (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
+   /* 6.5 MHz carrier to be interpreted as System DK */
+   cx25840_write(client, 0x80b, 0x00);
+   } else if (!(std  V4L2_STD_SECAM_DK) 
+  (std  (V4L2_STD_SECAM_L | V4L2_STD_SECAM_LC))) {
+   /* 6.5 MHz carrier to be interpreted as System L */
+   cx25840_write(client, 0x80b, 0x08);
+   } else {
+   /* 6.5 MHz carrier to be autodetected */
+   cx25840_write(client, 0x80b, 0x10);
+   }
}

cx25840_and_or(client, 0x810, ~0x01, 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: xc2028 sound carrier detection

[Aleksandr V. Piskunov]

On Mon, Sep 21, 2009 at 09:52:38PM -0300, Mauro Carvalho Chehab wrote:
 Em Tue, 22 Sep 2009 01:37:51 +0300
 Aleksandr V. Piskunov aleksandr.v.pisku...@gmail.com escreveu:
 
  Is xc2028 tuner able to autodetect/handle different sound carrier standards
  without being spoon-fed precise input system information using module param
  or ioctl?
  
  Got an ivtv board here (AverTV MCE 116) with xc2028 and cx25843.
  
  When I specify a generic standard using 'v4l2-ctl -s pal', xc2028 loads
  firmware specific to PAL-BG, so if there is an PAL-DK or PAL-I signal on RF
  input... nice picture but no sound. Setting a more precise standard like
  'v4l2-ctl -s pal-dk' fixes the issue, but other PAL-BG or PAL-I channels
  loose sound.
  
  Bttv board with a tin-can tuner sitting on the same RF source autodetects
  PAL-BG, PAL-DK and PAL-I without any manual intervention.
  
  So any voodoo tricks to get the autodetection running?
 
 No, sorry. It requires specific and different firmwares based on your video
 standard. I suspect that it is due to some firmware limiting size, since newer
 products from Xceive, like xc5000 don't have such troubles, but this is just 
 my
 guess.

Mmm, tested that tuner under windows, it autodetects all 3 sound carrier sub-
standards instantly: PAL-BG, PAL-DK, PAL-I.

In order to test, I connected ancient Panasonic VCR that has a built-in tuner
and can output video to RF-OUT on fixed frequency using PAL standard. Sound
carrier frequency can be choosen using hardware switch BG, DK or I.

So under windows: tuner produces clear audio in BG, DK and I, hardware switch
can be toggled on fly, audio never stops, only a few miliseconds of static on
switch.

Under linux: audio only works if driver is set to use specific audio carrier
sub-standard AND same is selected on PVR. (not to mention extremely unreliable
PAL-DK detection by cx25843, only works 50% of times, but thats another issue)

Either a more generic firmware exists can be uploaded on xc2028.. or several
can be uploaded at once. Any xc2028 gurus out there?
--
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: [PULL] http://linuxtv.org/hg/~anttip/af9015/

[Aleksandr V. Piskunov]

On Tue, Sep 22, 2009 at 03:34:11AM +0300, Antti Palosaari wrote:
 Hei Mauro,

 Please pull from http://linuxtv.org/hg/~anttip/af9015/
 for the following:

 af9015: add USB ID for KWorld PlusTV DVB-T PCI Pro Card (DVB-T PC160-T)
 af9015: fix few typos
 af9015: add LeadTek Y04G0051 remote buttons
 af9015: add MSI DIGIVOX mini III remote
 af9015: enable remote polling when eeprom contains 0x04

Thank you Antti, MSI DIGIVOX mini III remote is now being detected and working
as expected.

Tested-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com
--
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: MSI Digivox mini III Remote Control

[Aleksandr V. Piskunov]

Well, it seems there is a patch for Digivox mini III remote control at
http://linuxtv.org/hg/~anttip/af9015-digivox3_remote/, perhaps Antti
can tell you more about it.

I got this tuner, and no, IR receiver doesn't work for me, it doesn't
even work in WinXP with bundled drivers and software, tested with
USB snoop, no reaction to keypresses. Maybe a hardware defect at
receiver part, maybe something is missing in a firmware, no idea.

So check it on some Windows system first, then try patch..


On Sun, Sep 20, 2009 at 08:26:26PM +0200, Roman wrote:
 hi,
 
 after my previous failure with the hvr-900h and another Digivox micro hd, i 
 am 
 finally able to watch dvb-tv with the Digivox mini III.
 Has anyone gotten the IR working? The wiki-entry says it is not supported 
 yet on the other hand MSI provides linux-drivers that don't seem to work 
 on recent kernels...
 
 greetings,
 Roman
 -- 
 Leave no stone unturned.
   -- Euripides
 --
 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: MSI Digivox mini III Remote Control

[Aleksandr V. Piskunov]

Just grab that patch and apply it to the current vl4-dvb, no need to mess
with old repository.
http://linuxtv.org/hg/~anttip/af9015-digivox3_remote/raw-rev/914ded6d921d

Now if the current tree doesn't compile, thats another issue, probably
something with kernel headers, etc.

Actually thats interesting, I will test it on 64-bit Windows 7 when I get
home, will RMA that stick if remote doesn't work.

As for channel switching, it's most likely a tv viewing software issue, 
buffering or something like that. For me this tuner locks to transponder
in aprox. 1 second.

On Mon, Sep 21, 2009 at 12:53:49PM +0200, Roman wrote:
 Hi,
 
 thx for the tip, i jusst tested it on Windows 7 and i was amazed
 Not only the remote worked perfectly out of the box, also the software used 
 (some media-center from ArcSoft), worked flawless. (I last used a Hauppauge 
 TV-Card about 2 years ago on windows).
 One thing to note is the channel switching was a LOT faster (max. 1sec.) than 
 on linux (sometimes  5sec.).
 
 Anyway, the remote works on windows, no i am trying to compile the mentioned 
 repository, but it seems to fail compiling.
 I already sent a mail to the msi-support...
 
 #--
 make[2]: Entering directory `/home/strowi/src/zen-sources'
   CC [M]  /home/strowi/src/af9015-digivox3_remote/v4l/au0828-cards.o
 In file included from /home/strowi/src/af9015-digivox3_remote/v4l/dmxdev.h:33,
  from /home/strowi/src/af9015-digivox3_remote/v4l/au0828.h:29,
  
 from /home/strowi/src/af9015-digivox3_remote/v4l/au0828-cards.c:22:
 /home/strowi/src/af9015-digivox3_remote/v4l/compat.h:385: error: redefinition 
 of 'usb_endpoint_type'
 include/linux/usb/ch9.h:377: error: previous definition of 
 'usb_endpoint_type' 
 was here
 make[3]: *** [/home/strowi/src/af9015-digivox3_remote/v4l/au0828-cards.o] 
 Error 1
 #--
 
 Am Monday 21 September 2009 10:19:33 schrieb Aleksandr V. Piskunov:
  Well, it seems there is a patch for Digivox mini III remote control at
  http://linuxtv.org/hg/~anttip/af9015-digivox3_remote/, perhaps Antti
  can tell you more about it.
 
  I got this tuner, and no, IR receiver doesn't work for me, it doesn't
  even work in WinXP with bundled drivers and software, tested with
  USB snoop, no reaction to keypresses. Maybe a hardware defect at
  receiver part, maybe something is missing in a firmware, no idea.
 
  So check it on some Windows system first, then try patch..
 
 
 greetings,
 Roman
 -- 
 Iron Law of Distribution:
   Them that has, gets.
 --
 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: MSI Digivox mini III Remote Control

[Aleksandr V. Piskunov]

On Mon, Sep 21, 2009 at 04:31:19PM +0200, Roman wrote:
 Hi Antti,
 
 Am Monday 21 September 2009 16:19:37 schrieb Antti Palosaari:
   Here is the output of dmesg after reloading the module:
   #--
   af9015_usb_probe: interface:0
   af9015_read_config: IR mode:4
 
  IR mode 4 disables it. I have strong feeling it should mean polling...
  Could you change af9015.c around line 720:
  from: if (val == AF9015_IR_MODE_DISABLED || val == 0x04) {
  to: if (val == AF9015_IR_MODE_DISABLED) {
 
  and test again.
  Antti
 
 Ahh progress... ;)
 I did as you suggested, now dmesg shows the IR-device:
 #--
 Sep 21 16:25:50 Seth input: IR-receiver inside an USB DVB receiver 
 as /devices/pci:00/:00:1d.7/usb1/1-1/input/input7
 Sep 21 16:25:50 Seth dvb-usb: schedule remote query interval to 150 msecs
 #--
 
 And syslog shows requests like the following:
 #--
 Sep 21 16:26:33 Seth af9015_rc_query: 07 00 27 00 00 00 00 00
 #--
 
 If it is ok, i will mail the output to you (and not spam the ml), later this 
 day or tomorrow morning, as i have to leave for the university now...
 

Oh, tested under Windows, hardware is fine afterall.

Applied patch, removed check for val 0x04, now driver gets the scancodes!

So here we are, high-res picture of remote added to wiki at
http://www.linuxtv.org/wiki/index.php/MSI_DIGIVOX_mini_III

32 keys, left-to-right, top-to-bottom:

Sep 21 21:15:30 moon kernel: [ 5216.332334] af9015_rc_query: 07 00 13 00 00 00 
00 00
Sep 21 21:15:32 moon kernel: [ 5218.308390] af9015_rc_query: 07 00 3b 00 00 00 
00 00
Sep 21 21:15:33 moon kernel: [ 5219.524395] af9015_rc_query: 07 00 3e 00 00 00 
00 00
Sep 21 21:15:36 moon kernel: [ 5221.956404] af9015_rc_query: 07 00 0b 00 00 00 
00 00
Sep 21 21:15:39 moon kernel: [ 5225.452309] af9015_rc_query: 07 00 1e 00 00 00 
00 00
Sep 21 21:15:41 moon kernel: [ 5227.428367] af9015_rc_query: 07 00 1f 00 00 00 
00 00
Sep 21 21:15:42 moon kernel: [ 5228.644871] af9015_rc_query: 07 00 20 00 00 00 
00 00
Sep 21 21:15:44 moon kernel: [ 5230.164338] af9015_rc_query: 07 00 52 00 00 00 
00 00
Sep 21 21:15:46 moon kernel: [ 5232.292388] af9015_rc_query: 07 00 21 00 00 00 
00 00
Sep 21 21:15:47 moon kernel: [ 5233.508393] af9015_rc_query: 07 00 22 00 00 00 
00 00
Sep 21 21:15:48 moon kernel: [ 5234.572411] af9015_rc_query: 07 00 23 00 00 00 
00 00
Sep 21 21:15:50 moon kernel: [ 5236.244373] af9015_rc_query: 07 00 51 00 00 00 
00 00
Sep 21 21:15:52 moon kernel: [ 5238.524400] af9015_rc_query: 07 00 24 00 00 00 
00 00
Sep 21 21:15:53 moon kernel: [ 5239.588419] af9015_rc_query: 07 00 25 00 00 00 
00 00
Sep 21 21:15:54 moon kernel: [ 5240.500328] af9015_rc_query: 07 00 26 00 00 00 
00 00
Sep 21 21:15:55 moon kernel: [ 5241.564350] af9015_rc_query: 07 00 50 00 00 00 
00 00
Sep 21 21:15:57 moon kernel: [ 5243.084450] af9015_rc_query: 07 00 05 00 00 00 
00 00
Sep 21 21:15:58 moon kernel: [ 5244.604424] af9015_rc_query: 07 00 27 00 00 00 
00 00
Sep 21 21:15:59 moon kernel: [ 5245.516335] af9015_rc_query: 07 00 08 00 00 00 
00 00
Sep 21 21:16:01 moon kernel: [ 5247.188419] af9015_rc_query: 07 00 4f 00 00 00 
00 00
Sep 21 21:16:03 moon kernel: [ 5249.012366] af9015_rc_query: 07 00 3f 00 00 00 
00 00
Sep 21 21:16:04 moon kernel: [ 5250.532340] af9015_rc_query: 07 00 16 00 00 00 
00 00
Sep 21 21:16:05 moon kernel: [ 5251.448378] af9015_rc_query: 07 00 2a 00 00 00 
00 00
Sep 21 21:16:06 moon kernel: [ 5252.664872] af9015_rc_query: 07 00 3c 00 00 00 
00 00
Sep 21 21:16:09 moon kernel: [ 5254.944405] af9015_rc_query: 07 00 18 00 00 00 
00 00
Sep 21 21:16:10 moon kernel: [ 5256.616366] af9015_rc_query: 07 00 07 00 00 00 
00 00
Sep 21 21:16:11 moon kernel: [ 5257.680885] af9015_rc_query: 07 00 0f 00 00 00 
00 00
Sep 21 21:16:13 moon kernel: [ 5258.896393] af9015_rc_query: 07 00 15 00 00 00 
00 00
Sep 21 21:16:14 moon kernel: [ 5260.720336] af9015_rc_query: 07 00 36 00 00 00 
00 00
Sep 21 21:16:16 moon kernel: [ 5261.784858] af9015_rc_query: 07 00 37 00 00 00 
00 00
Sep 21 21:16:17 moon kernel: [ 5262.848378] af9015_rc_query: 07 00 2d 00 00 00 
00 00
Sep 21 21:16:17 moon kernel: [ 5263.608427] af9015_rc_query: 07 00 2e 00 00 00 
00 00
--
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

xc2028 sound carrier detection

[Aleksandr V. Piskunov]

Is xc2028 tuner able to autodetect/handle different sound carrier standards
without being spoon-fed precise input system information using module param
or ioctl?

Got an ivtv board here (AverTV MCE 116) with xc2028 and cx25843.

When I specify a generic standard using 'v4l2-ctl -s pal', xc2028 loads
firmware specific to PAL-BG, so if there is an PAL-DK or PAL-I signal on RF
input... nice picture but no sound. Setting a more precise standard like
'v4l2-ctl -s pal-dk' fixes the issue, but other PAL-BG or PAL-I channels
loose sound.

Bttv board with a tin-can tuner sitting on the same RF source autodetects
PAL-BG, PAL-DK and PAL-I without any manual intervention.

So any voodoo tricks to get the autodetection running?
--
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: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Fri, Sep 11, 2009 at 05:38:08PM +0300, Antti Palosaari wrote:
 On 09/10/2009 10:39 PM, Aleksandr V. Piskunov wrote:
 On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote:
 On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote:
 Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
 Now powertop shows only about 220 wakeups on my computer for the both
 sticks.
 Please test and tell what powertop says:
 http://linuxtv.org/hg/~anttip/urb_size/

 I wonder if we can decide what URB size DVB USB drivers should follow
 and even add new module param for overriding driver default.

 Thanks, Antti!

 Tested your branch on affected system.

 Load definitely went down, from ~7000 wakeups to ~250 for each tuner
 according to powertop.
 Both tuners still working ok if not used simultaneously or if used the
 same time on different USB controllers.

 Bad news are that original problem still persists: putting both tuners
 on same USB controller and zapping simultaneously corrupts stream.
 Interesting observation: no matter in what sequence tuners are connected
 (i.e. become adapter0 or adapter1), af9015 stream always gets heavily
 distorted, visually mplayer picture becomes like 80% corrupted with
 random color blocks and pixels, sound becomes a mess. At the same time
 ce6230 gets slight corruption, a few discolored blocks at the time and
 sound hickups.

 Anyway, will try to do a few more tests:
 1) Two usb flash drives on same controller calculating md5sum of
 big .iso file, to check if it is/isn't dvb-usb problem.
 2) Will see if same issue persists on another PC with same motherboard
 (slightly different revision) to rule out hardware issues. If I manage
 to wire antenna there, that is...

 Ok, two USB flash drives on same controller, no problem when bulk reading
 from both at the same time, no speed drops, no corruption.

 Now if I plug ce6230 tuner, zap to channel and then start reading from
 flash drive:
 * slightly corrupted TS stream
 * flash drive read getting starved on bandwidth, speed drops from 10 MB/s
to ~7 MB/s

 If I plug af9015 tuner, zap and read from flash
 * heavy corruption of TS stream
 * flash drive read speed drops from 10 MB/s to 2(!) MB/s

 Now I don't really know the USB protocol under-the-hood details, all the
 different types of bandwidth, reservation and so on. But shouldn't one
 480 Mbit/sec controller handle rather large number of digital tuners, each
 pushing 20-25 Mbit/sec max, even considering all the overhead?

 I have no any problems here, ce6230 and af9015 with dual tuners (3x  
 DVB-T 22Mbit/sec TS streams) running same time on same bus.

 One possibility is that there is RF-noise looping from device to device  
 disturbing USB transfer or RF-signal. I have seen such situation when I  
 connect multiple DVB-C devices to same antenna cable using cheap 
 splitter.

 Anyhow, I increased URB sizes to 65k. Now ce6230 gives 70 wakeups and  
 af9015 120 wakeups - due to remote polling. You can test if you wish,  
 but results are most likely same as earlier. I cannot do much more.
 http://linuxtv.org/hg/~anttip/urb_size/

Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs..
So using my fresh knowledge I went away and hacked ce6230 to use Isochronous
transfer endpoint instead of Bulk one. And it helped, tuner works, no
corruption with af9015 running on same controller at the same time.

Of course it isn't a fix per se, af9015 still corrupts if I start bulk
reading from a flash drive, etc. And there are no Isochronous endpoints on
af9015, so no alternative to bulk transfers :)

But at least I'm getting closer to pinpointing the real problem and so far
everything points to AMD SB700 chipset driver. Google says it has quite
some hardware bugs and several workarounds in linux drivers...

P.S. Rather unrelated question, what type of USB transfer is generally
preferred for USB media stream devices, BULK or ISOC? Antti, why did you
choose BULK for ce6230?
--
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: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote:
 On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyerclintonmeye...@gmail.com wrote:
  Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC 
  OTA TV.
 
  Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE
  3.5.10, kernel 2.6.27-1-mepis-smp
 
  All three machines now have wireless blocked, either do not connect or
  all packets dropped/blocked if a connection is made.
 
  Used the resources from LinuxTV (dot) org
 
  to get it working, they are referenced and posted as follows:
   linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware
 
   *** **
   Quote:
  In order to use the LinuxTV driver, you need to download and install
  the firmware for the xc5000.
 
  Quote:
  wget  ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip
  wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh
   sh extract (dot) sh
  cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware
  :Unquote
 
  Note: Though the usual directory location in which the firmware file
  is placed is /lib/firmware, this may differ in the case of some
  distros; consult your distro's documentation for the appropriate
  location.
 
  The firmware will be added lazily (on-demand) when you first use the driver.
  Drivers
 
  The xc5000 driver needed for this WinTV-HVR-950Q is already part of
  the latest Linux kernel (part of v4l-dvb drivers).
 
  Analog support was merged into the mainline v4l-dvb tree on March 18, 2009.
  :Unquote
   *** **  *** **
  So on Saturday I got this up and running... and Sunday morning
  recorded one show successfully that had set up on a timer.
 
  Then set up three consecutive shows for the afternoon.
  They were all part of a series on the same channel. Here are the results:
 
      * Show A, 2.5 hours long, 13.2gb file size, appears to be OK.
      * Show B, 2.0 hours long, 3.7gb file size, appears to be OK.
   * Show C, supposed to be 2.0 hours long, result was 2.7gb file
  size, about the first hour is missing.
 
  At about this point, I lost wireless internet connectivity on TV
  recording laptop. Machine sees the access point, but won't connect.
 
  Went to my main desktop where i had first worked with this Hauppauge
  WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost
  internet, even though it was right next to AP and got a very good
  signal.
 
  Thought it was maybe the AP, so switched it out for a working spare.
   Same results.
  Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD
  and an 8.06 Live USB stick and hit the road to go to a reliable high
  speed wifi spot.
  Same results... changins ISPs resulted in the same issues.
   Also same ting happened with the spare laptop, an IBM T43 Thinkpad I
  had also done the wget ... steventoth (dot)
  net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip
  firmware thing to.
 
  Was able to get one machine, while running a LIVE USB session, to
  connect, but zero packets received.. ALL were blocked. The connection
  information said ALL packets were dropped.
   None of the two other machines connected to wireless on a LiveCD or
  LiveUSB thing too
  Three machines. All different brands (HP, Dell, and IBM) with
  different wifi cards. All three see the access point ESSID, but none
  connect.
 
  This does not *feel* good. What got flashed? Can this be resolved?
 
  Came home. No difference. Grabbed a laptop that i had NOT done the
  firmware thing to and that is what I am using to write this. Hooked
  right up to the AP.
 
  Please help... that is too much hardware disabled for me to think calmly.
  I'd really like to make the USB tv tuner work... what a great way to
  PVR / DVR, but I need wireless.
 
  Can provide any details requested to drive this towards a fix!
 
  Thank you,
  Clinton
  --
  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
 
 
 Hello Clinton,
 
 That is indeed curious.  It's hard to imagine how there could be
 interference between the V4L subsystem and the wireless subsystem,
 short of hitting some sort of timing condition on crappy wireless
 drivers.
 
 Here are a few questions:
 
 1.  You specified you followed the instructions for the firmware, but
 are you running the current v4l-dvb code, or are you just using
 whatever came with your Debian kernel?  If you're actually using the
 1.1 Xceive firmware, I'm assuming you're still using the old code.
 
 2.  How reproducible is this?  Does it occur even if the device is
 connected but you do not attempt any capturing with the device?  Does
 it always drop out while capturing?
 
 3.  What type of wireless cards are you using?  Are they implemented
 over PCI, or USB?  If the wireless cards are USB based, perhaps there
 is some sort of USB 

Re: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
 Aleksandr V. Piskunov wrote:
 Here is a test case:
 Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners,

 Err, make it: dvb_usb_af9015 and dvb_usb_ce6230

 Those both uses currently too small bulk urbs, only 512 bytes. I have  
 asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one  
 have answered yet (search ml back week or two). I think will increase  
 those to the 8k to reduce load.


Nice, I'm ready to test if such change helps.

Does USB subsystem provide any way to monitor current raw USB data transfer 
rate?

--
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: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote:
 On 09/10/2009 04:47 PM, Antti Palosaari wrote:
 Aleksandr V. Piskunov wrote:
 On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
 Aleksandr V. Piskunov wrote:
 Here is a test case:
 Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015.
 Different tuners,
 Err, make it: dvb_usb_af9015 and dvb_usb_ce6230
 Those both uses currently too small bulk urbs, only 512 bytes. I have
 asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but
 no-one have answered yet (search ml back week or two). I think will
 increase those to the 8k to reduce load.


 Nice, I'm ready to test if such change helps.

 OK, I will make test version in couple of hours.

 Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
 Now powertop shows only about 220 wakeups on my computer for the both  
 sticks.
 Please test and tell what powertop says:
 http://linuxtv.org/hg/~anttip/urb_size/

 I wonder if we can decide what URB size DVB USB drivers should follow  
 and even add new module param for overriding driver default.

Thanks, Antti!

Tested your branch on affected system.

Load definitely went down, from ~7000 wakeups to ~250 for each tuner
according to powertop.
Both tuners still working ok if not used simultaneously or if used the
same time on different USB controllers.

Bad news are that original problem still persists: putting both tuners
on same USB controller and zapping simultaneously corrupts stream.
Interesting observation: no matter in what sequence tuners are connected
(i.e. become adapter0 or adapter1), af9015 stream always gets heavily
distorted, visually mplayer picture becomes like 80% corrupted with
random color blocks and pixels, sound becomes a mess. At the same time
ce6230 gets slight corruption, a few discolored blocks at the time and
sound hickups.

Anyway, will try to do a few more tests:
1) Two usb flash drives on same controller calculating md5sum of 
big .iso file, to check if it is/isn't dvb-usb problem.
2) Will see if same issue persists on another PC with same motherboard
(slightly different revision) to rule out hardware issues. If I manage
to wire antenna there, that is...
--
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: LinuxTV firmware blocks all wireless connections / traffic

[Aleksandr V. Piskunov]

On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote:
 On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote:
  On 09/10/2009 04:47 PM, Antti Palosaari wrote:
  Aleksandr V. Piskunov wrote:
  On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote:
  Aleksandr V. Piskunov wrote:
  Here is a test case:
  Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015.
  Different tuners,
  Err, make it: dvb_usb_af9015 and dvb_usb_ce6230
  Those both uses currently too small bulk urbs, only 512 bytes. I have
  asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but
  no-one have answered yet (search ml back week or two). I think will
  increase those to the 8k to reduce load.
 
 
  Nice, I'm ready to test if such change helps.
 
  OK, I will make test version in couple of hours.
 
  Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices.
  Now powertop shows only about 220 wakeups on my computer for the both  
  sticks.
  Please test and tell what powertop says:
  http://linuxtv.org/hg/~anttip/urb_size/
 
  I wonder if we can decide what URB size DVB USB drivers should follow  
  and even add new module param for overriding driver default.
 
 Thanks, Antti!
 
 Tested your branch on affected system.
 
 Load definitely went down, from ~7000 wakeups to ~250 for each tuner
 according to powertop.
 Both tuners still working ok if not used simultaneously or if used the
 same time on different USB controllers.
 
 Bad news are that original problem still persists: putting both tuners
 on same USB controller and zapping simultaneously corrupts stream.
 Interesting observation: no matter in what sequence tuners are connected
 (i.e. become adapter0 or adapter1), af9015 stream always gets heavily
 distorted, visually mplayer picture becomes like 80% corrupted with
 random color blocks and pixels, sound becomes a mess. At the same time
 ce6230 gets slight corruption, a few discolored blocks at the time and
 sound hickups.
 
 Anyway, will try to do a few more tests:
 1) Two usb flash drives on same controller calculating md5sum of 
 big .iso file, to check if it is/isn't dvb-usb problem.
 2) Will see if same issue persists on another PC with same motherboard
 (slightly different revision) to rule out hardware issues. If I manage
 to wire antenna there, that is...

Ok, two USB flash drives on same controller, no problem when bulk reading
from both at the same time, no speed drops, no corruption.

Now if I plug ce6230 tuner, zap to channel and then start reading from 
flash drive:
* slightly corrupted TS stream
* flash drive read getting starved on bandwidth, speed drops from 10 MB/s
  to ~7 MB/s

If I plug af9015 tuner, zap and read from flash
* heavy corruption of TS stream
* flash drive read speed drops from 10 MB/s to 2(!) MB/s

Now I don't really know the USB protocol under-the-hood details, all the
different types of bandwidth, reservation and so on. But shouldn't one
480 Mbit/sec controller handle rather large number of digital tuners, each
pushing 20-25 Mbit/sec max, even considering all the overhead?
--
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

correct implementation of FE_READ_UNCORRECTED_BLOCKS

[Aleksandr V. Piskunov]

DVB API documentation says:
This ioctl call returns the number of uncorrected blocks detected by the 
device driver during its lifetime Note that the counter will wrap to zero 
after its maximum count has been reached.
--
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: correct implementation of FE_READ_UNCORRECTED_BLOCKS

[Aleksandr V. Piskunov]

Oops, sent it way too fast. Anyway.

DVB API documentation says:
This ioctl call returns the number of uncorrected blocks detected by
the device driver during its lifetime Note that the counter will
wrap to zero after its maximum count has been reached.

Does it mean that correct implementation of frontend driver should
keep its own counter of UNC blocks and increment it every time hardware
reports such block?

From what I see, a lot of current frontend drivers simply dump a value
from some hardware register. For example zl10353 I got here reports 
some N unc blocks and then gets back to reporting zero.
--
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: correct implementation of FE_READ_UNCORRECTED_BLOCKS

[Aleksandr V. Piskunov]

On Sun, Aug 02, 2009 at 02:11:38PM -0400, Andy Walls wrote:
 On Sun, 2009-08-02 at 20:56 +0300, Aleksandr V. Piskunov wrote:
  Oops, sent it way too fast. Anyway.
  
  DVB API documentation says:
  This ioctl call returns the number of uncorrected blocks detected by
  the device driver during its lifetime Note that the counter will
  wrap to zero after its maximum count has been reached.
  
  Does it mean that correct implementation of frontend driver should
  keep its own counter of UNC blocks and increment it every time hardware
  reports such block?
 
 No, but a frontend driver may wish to keep a software counter that is
 wider than the hardware register counter, in case the hardware register
 rolls over too frequently.
 
 
  From what I see, a lot of current frontend drivers simply dump a value
  from some hardware register. For example zl10353 I got here reports 
  some N unc blocks and then gets back to reporting zero.
 
 To support the use case of multiple user apps trying to collect UNC
 block statistics, the driver should not zero out the UNC block counter
 when read.  If the hardware zeros it automatically, then one probably
 should maintain a software counter in the driver.
 

Here is a patch that makes zl10353 a bit more DVB API compliant:
FE_READ_UNCORRECTED_BLOCKS - keep a counter of UNC blocks
FE_GET_FRONTEND - return last set frequency instead of zero

Signed-off-by: Aleksandr V. Piskunov alexandr.v.pisku...@gmail.com


--- v4l-dvb/linux/drivers/media/dvb/frontends/zl10353.c.orig2009-08-02 
15:38:28.133464216 +0300
+++ v4l-dvb/linux/drivers/media/dvb/frontends/zl10353.c 2009-08-02 
16:03:00.305465369 +0300
@@ -39,6 +39,8 @@ struct zl10353_state {
struct zl10353_config config;
 
enum fe_bandwidth bandwidth;
+   u32 ucblocks;
+   u32 frequency;
 };
 
 static int debug;
@@ -204,6 +206,8 @@ static int zl10353_set_parameters(struct
u16 tps = 0;
struct dvb_ofdm_parameters *op = param-u.ofdm;
 
+   state-frequency = param-frequency;
+
zl10353_single_write(fe, RESET, 0x80);
udelay(200);
zl10353_single_write(fe, 0xEA, 0x01);
@@ -469,7 +473,7 @@ static int zl10353_get_parameters(struct
break;
}
 
-   param-frequency = 0;
+   param-frequency = state-frequency;
op-bandwidth = state-bandwidth;
param-inversion = INVERSION_AUTO;
 
@@ -549,9 +553,13 @@ static int zl10353_read_snr(struct dvb_f
 static int zl10353_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
 {
struct zl10353_state *state = fe-demodulator_priv;
+   u32 ubl = 0;
+
+   ubl = zl10353_read_register(state, RS_UBC_1)  8 |
+ zl10353_read_register(state, RS_UBC_0);
 
-   *ucblocks = zl10353_read_register(state, RS_UBC_1)  8 |
-   zl10353_read_register(state, RS_UBC_0);
+   state-ucblocks += ubl;
+   *ucblocks = state-ucblocks;
 
return 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