Re: [PATCH] soc-camera: ov772x: Add buswidth selection flags for platform

2010-01-05 Thread Guennadi Liakhovetski
Hello Morimoto-san

On Tue, 5 Jan 2010, Kuninori Morimoto wrote:

 This patch remove buswidth struct member and add new flags for 
 ov772x_camera_info.
 And it also modify ap325rxa/migor setup.c

Can you explain a bit why this patch is needed? Apart from a slight 
stylistic improvement and a saving of 4 bytes of platform data per camera 
instance? Is it going to be needed for some future changes?

 
 Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
 ---
  arch/sh/boards/mach-ap325rxa/setup.c |4 ++--
  arch/sh/boards/mach-migor/setup.c|2 +-
  drivers/media/video/ov772x.c |   28 
  include/media/ov772x.h   |7 ---
  4 files changed, 19 insertions(+), 22 deletions(-)
 
 diff --git a/arch/sh/boards/mach-ap325rxa/setup.c 
 b/arch/sh/boards/mach-ap325rxa/setup.c
 index 1f5fa5c..71f556f 100644
 --- a/arch/sh/boards/mach-ap325rxa/setup.c
 +++ b/arch/sh/boards/mach-ap325rxa/setup.c
 @@ -471,8 +471,8 @@ static struct i2c_board_info ap325rxa_i2c_camera[] = {
  };
  
  static struct ov772x_camera_info ov7725_info = {
 - .buswidth   = SOCAM_DATAWIDTH_8,
 - .flags  = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
 + .flags  = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP | \
 +   OV772X_FLAG_8BIT,
   .edgectrl   = OV772X_AUTO_EDGECTRL(0xf, 0),
  };
  
 diff --git a/arch/sh/boards/mach-migor/setup.c 
 b/arch/sh/boards/mach-migor/setup.c
 index 507c77b..9b4676f 100644
 --- a/arch/sh/boards/mach-migor/setup.c
 +++ b/arch/sh/boards/mach-migor/setup.c
 @@ -431,7 +431,7 @@ static struct i2c_board_info migor_i2c_camera[] = {
  };
  
  static struct ov772x_camera_info ov7725_info = {
 - .buswidth   = SOCAM_DATAWIDTH_8,
 + .flags  = OV772X_FLAG_8BIT,
  };
  
  static struct soc_camera_link ov7725_link = {
 diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
 index 3a45e94..12cb66f 100644
 --- a/drivers/media/video/ov772x.c
 +++ b/drivers/media/video/ov772x.c
 @@ -547,7 +547,6 @@ static const struct v4l2_queryctrl ov772x_controls[] = {
   },
  };
  
 -
  /*
   * general function
   */
 @@ -634,9 +633,18 @@ static unsigned long ov772x_query_bus_param(struct 
 soc_camera_device *icd)
   struct soc_camera_link *icl = to_soc_camera_link(icd);
   unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
   SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
 - SOCAM_DATA_ACTIVE_HIGH | priv-info-buswidth;
 + SOCAM_DATA_ACTIVE_HIGH;
 +
 + if (priv-info-flags  OV772X_FLAG_8BIT)
 + flags |= SOCAM_DATAWIDTH_8;
 +
 + if (priv-info-flags  OV772X_FLAG_10BIT)
 + flags |= SOCAM_DATAWIDTH_10;

At the moment ov7722's .set_bus_param() method does nothing and just 
returns success. To me this means, that it cannot dynamically switch 
between various bus configurations, also not using platform provided 
methods. Therefore the test, that the current driver version performs 
whether one and only one bus width flag is set in ov772x_video_probe() 
makes sense. With this patch you're removing that test below and now 
silently accepting any bus-width parameter configuration from the 
platform. Wouldn't a test like

if (!is_power_of_2(priv-info-flags  (OV772X_FLAG_8BIT | 
OV772X_FLAG_10BIT)))
return 0;

make sense here? Or even just modify your tests above to

switch (priv-info-flags  (OV772X_FLAG_8BIT | OV772X_FLAG_10BIT)) {
case OV772X_FLAG_8BIT:
flags |= SOCAM_DATAWIDTH_8;
break;
case OV772X_FLAG_10BIT:
flags |= SOCAM_DATAWIDTH_10;
break;
}

Adding a default: case just above the case OV772X_FLAG_10BIT: line 
would seem like a good idea to me too.

  
 - return soc_camera_apply_sensor_flags(icl, flags);
 + if (flags  SOCAM_DATAWIDTH_MASK)
 + return soc_camera_apply_sensor_flags(icl, flags);
 +
 + return 0;

Why do you need this fail path? If any flags are missing the soc-camera 
core will catch that anyway.

  }
  
  static int ov772x_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
 @@ -1040,15 +1048,6 @@ static int ov772x_video_probe(struct soc_camera_device 
 *icd,
   return -ENODEV;
  
   /*
 -  * ov772x only use 8 or 10 bit bus width
 -  */
 - if (SOCAM_DATAWIDTH_10 != priv-info-buswidth 
 - SOCAM_DATAWIDTH_8  != priv-info-buswidth) {
 - dev_err(client-dev, bus width error\n);
 - return -ENODEV;
 - }

This is the test, that you're removing, that I meant above.

 -
 - /*
* check and show product ID and manufacturer ID
*/
   pid = i2c_smbus_read_byte_data(client, PID);
 @@ -1130,7 +1129,6 @@ static int ov772x_probe(struct i2c_client *client,
   const struct i2c_device_id *did)
  {
   struct ov772x_priv*priv;
 - struct 

em28xx: New device request and tvp5150 distortion issues when capturing from vcr

2010-01-05 Thread Michael Rüttgers
Hello,

a year ago I bought a device named Hama Video Editor, which was not
(and is not yet) supported by the em28xx driver.
So I played around with the card parameter and got the device basically
working with card=38.
Basically working means, that I had a distortion when capturing old
VHS-Tapes from my old vcr.

The problem can be seen here:
http://www.michael-ruettgers.de/em28xx/test.avi

A few weeks ago I started tracking down the reason for this issue with
the help of Devin.
Wondering, that the device works perfectly in Windows, I compared the
i2c commands, that programmed the register of the tvp5150 in Windows.

Finally I got the device working properly, setting the TV/VCR option
in the register Operation Mode Controls Register at address 02h
manually to Automatic mode determined by the internal detection
circuit. (default):

000109:  OUT: 00 ms 107025 ms 40 02 00 00 b8 00 02 00   02 00

After programming this register, the distortion issue disappeared.

So my conclusion was, that the TV/VCR detection mode is forced to
TV-mode in the em28xx, which could have been verified by a look into the
debug output using the parameter reg_debug=1:

OUT: 40 02 00 00 b8 00 02 00  02 30

Bit 4, 5 are used for setting the TV/VCR mode:

Description in the Spec:
 TV/VCR mode
   00 = Automatic mode determined by the internal detection circuit.
(default)
   01 = Reserved
   10 = VCR (nonstandard video) mode
   11 = TV (standard video) mode
 With automatic detection enabled, unstable or nonstandard syncs on the
input video forces the detector into the VCR
 mode. This turns off the comb filters and turns on the chroma trap
filter.

Thus far the tvp5150 distortion issues when capturing from vcr.

---

The device not supported yet but mostly working with card=38 has the
following features:

1 Button
1 LED
1 S-VHS input
1 Composite video input (Chinch) 
1 Stereo audio input (2 x Chinch)

The inputs are matched correctly to the video sources in a viewer-app
(S-VHS - S-VHS, Composite - Composite1).


It's product name is Hama USB 2.0 Video Editor:
http://www.hama.de/portal/articleId*139673/action*2563


This board has no unique USB ID but could be detected by its i2c
devicelist hash 0x77800080:

 [  119.160182] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0,
class 0)
 [  119.160297] em28xx #0: chip ID is em2860
 [  119.283595] em28xx #0: board has no eeprom
 [  119.300289] em28xx #0: Identified as Unknown EM2750/28xx video
grabber (card=1)
 [  119.323789] em28xx #0: found i2c device @ 0xb8 [tvp5150a]
 [  119.332914] em28xx #0: Your board has no unique USB ID and thus
need a hint to be detected.
 [  119.332917] em28xx #0: You may try to use card=n insmod option to
workaround that.
 [  119.332919] em28xx #0: Please send an email with this log to: 
 [  119.332920] em28xx #0: V4L Mailing List
linux-media@vger.kernel.org
 [  119.332922] em28xx #0: Board eeprom hash is 0x
 [  119.332924] em28xx #0: Board i2c devicelist hash is 0x77800080

This board seem to be branded under another name in Austria:
http://lists-archives.org/video4linux/27246-empia-device-without-unique-usb-id-or-eeprom.html

On Mon, Apr 20, 2009 at 9:06 AM, Anthony Hogan anthony-...@xxx
wrote:
 Aldi (Supermarket chain) Fission (home brand) USB hi-speed dvd maker
 Aldi Product number/SKU: 6675
 Model Number: DK-8703
 Composite + SVHS video input
 Stereo line-level audio input
 Single button, single LED
 No FCC ID (intended for Australian/European market, only has CE and
Tick mark)

---

I would appreciate to see this device beeing detected and working
correctly for capturing even from a vcr with weak sync signals.

Thanks.

Regards,

Michael Rüttgers

--
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 10/10] media/dvb: add __init/__exit macros to drivers/media/dvb/bt8xx/bt878.c

2010-01-05 Thread Jean Delvare
On Tue, 22 Dec 2009 09:38:14 +0100, peterhu...@gmx.de wrote:
 From: Peter Huewe peterhu...@gmx.de
 
 Trivial patch which adds the __init/__exit macros to the module_init/
 module_exit functions of
 
 drivers/media/dvb/bt8xx/bt878.c
 
 Please have a look at the small patch and either pull it through
 your tree, or please ack' it so Jiri can pull it through the trivial
 tree.
 
 Patch against linux-next-tree, 22. Dez 08:38:18 CET 2009
 but also present in linus tree.
 
 Signed-off-by: Peter Huewe peterhu...@gmx.de

Acked-by: Jean Delvare kh...@linux-fr.org

 ---
  drivers/media/dvb/bt8xx/bt878.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/dvb/bt8xx/bt878.c b/drivers/media/dvb/bt8xx/bt878.c
 index a24c125..2a0886a 100644
 --- a/drivers/media/dvb/bt8xx/bt878.c
 +++ b/drivers/media/dvb/bt8xx/bt878.c
 @@ -582,7 +582,7 @@ static int bt878_pci_driver_registered;
  /* Module management functions */
  /***/
  
 -static int bt878_init_module(void)
 +static int __init bt878_init_module(void)
  {
   bt878_num = 0;
   bt878_pci_driver_registered = 0;
 @@ -600,7 +600,7 @@ static int bt878_init_module(void)
   return pci_register_driver(bt878_pci_driver);
  }
  
 -static void bt878_cleanup_module(void)
 +static void __exit bt878_cleanup_module(void)
  {
   if (bt878_pci_driver_registered) {
   bt878_pci_driver_registered = 0;


-- 
Jean Delvare
--
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 10/10] media/dvb: add __init/__exit macros to drivers/media/dvb/bt8xx/bt878.c

2010-01-05 Thread Jiri Kosina
On Tue, 5 Jan 2010, Jean Delvare wrote:

  Trivial patch which adds the __init/__exit macros to the module_init/
  module_exit functions of
  
  drivers/media/dvb/bt8xx/bt878.c
  
  Please have a look at the small patch and either pull it through
  your tree, or please ack' it so Jiri can pull it through the trivial
  tree.
  
  Patch against linux-next-tree, 22. Dez 08:38:18 CET 2009
  but also present in linus tree.
  
  Signed-off-by: Peter Huewe peterhu...@gmx.de
 
 Acked-by: Jean Delvare kh...@linux-fr.org

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
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

2010-01-05 Thread 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c

2010-01-05 Thread Alan Stern
On Mon, 4 Jan 2010, Sean wrote:

 Alan Stern wrote:
  Um, when you say it does the job, what do you mean?
 It traps the error and prevents the kernel from crashing.

As did some of the earlier patches, right?

  The job it was _intended_ to do was to prove that your problems are
  caused by hardware errors rather than software bugs.  If the patch
  causes the problems to stop, without printing any error messages in the
  log, then it does indeed prove this.  After all, the only places the
  patch changes any persistent values are after it prints an error 
  message.

 It did print out error messages:

 .ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 
 c677b900 
 ...ohci_hcd :00:0b.0: Circular hash: 36 c669f900 c677b900 
 c677b900   
 .ohci_hcd :00:0b.0: Circular hash: 32 c669f800 c677b800 
 c677b800 

Ooh, that's odd.  The Circular hash message occurs in the same spot 
as the Circular pointer #2a message in the previous patch -- and that 
message never got printed!

  I noticed that your CPU is a Cyrix.  Perhaps it is the culprit.  Have
  you tried running the program on a different computer?

 Yes, on other computers I don't get this error. Same os image. Though I 
 haven't found a computer with an ohci controller yet.

So that's not a real test, unfortunately.

Still, at this point I'm not sure it's worthwhile to pursue this any
farther.  I'm convinced it's a hardware problem.  Do you want to 
continue, or are you happy to switch computers and forget about it?

Alan Stern

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


Terratec Cinergy C PCI HD - different subsystems

2010-01-05 Thread Hemmelig Konto
Hi there

I'm the owner of two Terratec Cinergy C PCI HD cards.

I'm running on vanilla kernel 2.6.32.0 x64 and is using the s2-liblianin driver.

My problem is that the driver only see 1 of my 2 cards.
When I investigate the cards, I see that they have a different
subsystem identifiers : 153b:1178 which works, and 153b.01788 which
doesn't work. There are no visible difference between the card, as far
as I can see.

How do I get the driver to attach to both the cards so I can get
both adapter0 and adapter1 - today it is only adapter0 ?

Please help !!!

/Ole W

lspci -vnn output :

06:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd
Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01)
Subsystem: TERRATEC Electronic GmbH Device [153b:0178]
Flags: bus master, medium devsel, latency 64, IRQ 16
Memory at edfff000 (32-bit, prefetchable) [size=4K]
Kernel modules: mantis

06:01.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd
Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01)
Subsystem: TERRATEC Electronic GmbH Device [153b:1178]
Flags: bus master, medium devsel, latency 64, IRQ 17
Memory at fdffe000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

dmesg output :

Mantis :06:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
Mantis :06:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17
irq: 17, latency: 64
 memory: 0xfdffe000, mmio: 0xc9001178e000
found a VP-2040 PCI DVB-C device on (06:01.0),
Mantis Rev 1 [153b:1178], irq: 17, latency: 64
memory: 0xfdffe000, mmio: 0xc9001178e000
MAC Address=[00:08:ca:1e:88:83]
mantis_alloc_buffers (1): DMA=0x37c6 cpu=0x880037c6 size=65536
mantis_alloc_buffers (1): RISC=0x37c06000 cpu=0x880037c06000 size=1000
DVB: registering new adapter (Mantis dvb adapter)
input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input4
HDA Intel :01:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17
HDA Intel :01:00.1: setting latency timer to 64
mantis_frontend_init (1): Probing for CU1216 (DVB-C)
TDA10023: i2c-addr = 0x0c, id = 0x7d
mantis_frontend_init (1): found Philips CU1216 DVB-C frontend (TDA10023) @ 0x0c
mantis_frontend_init (1): Mantis DVB-C Philips CU1216 frontend attach success
DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
mantis_ca_init (1): Registering EN50221 device
mantis_ca_init (1): Registered EN50221 device
mantis_hif_init (1): Adapter(1) Initializing Mantis Host Interface
input: Mantis VP-2040 IR Receiver as /devices/virtual/input/input5
Mantis VP-2040 IR Receiver: unknown key for scancode 0x
Mantis VP-2040 IR Receiver: unknown key: key=0x00 down=1
Mantis VP-2040 IR Receiver: unknown key: key=0x00 down=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


[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

2010-01-05 Thread Jean-Francois Moine
Hi Mauro,

Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb

for the following 9 changesets:

01/09: gspca - vc032x: Fix bad probe of the sensor mi1320.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=89f9221d4555

02/09: gspca - vc032x: Add the H and V flip controls for sensor mi1320.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=17a73955b94a

03/09: gspca - vc032x: Change the sensor of 046d:0892 and 046d:0896.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=cbd0fdc04914

04/09: gspca - sonixj: Add more controls.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=dd4a73349d62

05/09: gspca - zc3xx: Fix the contrast control.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=b978912adcaa

06/09: gspca - zc3xx: Adjust the pas202b exchanges.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=aa0e795c6db3

07/09: gspca - main: Check the interface class at probe time.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5b914c313b68

08/09: gspca - some subdrivers: Make sd_desc const.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5e4054307384

09/09: gspca - all subdrivers: Make control descriptors constant.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=163a46b2f384


 benq.c|2 
 conex.c   |4 
 etoms.c   |4 
 gl860/gl860.c |   10 
 gspca.c   |8 
 mars.c|2 
 mr97310a.c|2 
 ov534.c   |4 
 pac207.c  |2 
 pac7302.c |4 
 pac7311.c |4 
 sn9c20x.c |2 
 sonixb.c  |2 
 sonixj.c  |  130 ++
 spca500.c |4 
 spca501.c |2 
 spca505.c |2 
 spca506.c |4 
 spca508.c |2 
 spca561.c |4 
 stk014.c  |2 
 stv0680.c |2 
 sunplus.c |2 
 t613.c|2 
 tv8532.c  |2 
 vc032x.c  |  716 +++---
 zc3xx.c   |  257 +---
 27 files changed, 864 insertions(+), 317 deletions(-)

Thanks and happy new year!

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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] drivers/media/video/cx23885/cx23885-dvb.c: use %pM to show MAC address

2010-01-05 Thread H Hartley Sweeten
Use the %pM kernel extension to display the MAC address.

Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Steven Toth st...@kernellabs.com
Cc: David S. Miller da...@davemloft.net

---

Repost due to merge issues.

diff --git a/drivers/media/video/cx23885/cx23885-dvb.c 
b/drivers/media/video/cx23885/cx23885-dvb.c
index e45d2df..f9243de 100644
--- a/drivers/media/video/cx23885/cx23885-dvb.c
+++ b/drivers/media/video/cx23885/cx23885-dvb.c
@@ -994,15 +994,8 @@ static int dvb_register(struct cx23885_tsport *port)
netup_get_card_info(dev-i2c_bus[0].i2c_adap, cinfo);
memcpy(port-frontends.adapter.proposed_mac,
cinfo.port[port-nr - 1].mac, 6);
-   printk(KERN_INFO NetUP Dual DVB-S2 CI card port%d MAC=
-   %02X:%02X:%02X:%02X:%02X:%02X\n,
-   port-nr,
-   port-frontends.adapter.proposed_mac[0],
-   port-frontends.adapter.proposed_mac[1],
-   port-frontends.adapter.proposed_mac[2],
-   port-frontends.adapter.proposed_mac[3],
-   port-frontends.adapter.proposed_mac[4],
-   port-frontends.adapter.proposed_mac[5]);
+   printk(KERN_INFO NetUP Dual DVB-S2 CI card port%d MAC=%pM\n,
+   port-nr, port-frontends.adapter.proposed_mac);
 
netup_ci_init(port);
break;
--
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] drivers/media/dvb/dvb-core/dvb_net.c: use %pM to show MAC address

2010-01-05 Thread H Hartley Sweeten
Use the %pM kernel extension to display the MAC address and mask.

The only difference in the output is that the output is shown in
the usual colon-separated hex notation.

Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: David S. Miller da...@davemloft.net

---

Repost due to merge issues.

diff --git a/drivers/media/dvb/dvb-core/dvb_net.c 
b/drivers/media/dvb/dvb-core/dvb_net.c
index 8b8558f..da6552d 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -949,11 +949,8 @@ static int dvb_net_filter_sec_set(struct net_device *dev,
(*secfilter)-filter_mask[10] = mac_mask[1];
(*secfilter)-filter_mask[11]=mac_mask[0];
 
-   dprintk(%s: filter mac=%02x %02x %02x %02x %02x %02x\n,
-  dev-name, mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
-   dprintk(%s: filter mask=%02x %02x %02x %02x %02x %02x\n,
-  dev-name, mac_mask[0], mac_mask[1], mac_mask[2],
-  mac_mask[3], mac_mask[4], mac_mask[5]);
+   dprintk(%s: filter mac=%pM\n, dev-name, mac);
+   dprintk(%s: filter mask=%pM\n, dev-name, mac_mask);
 
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


[PATCH] drivers/media/video/tveeprom.c: use %pM to show MAC address

2010-01-05 Thread H Hartley Sweeten
Use the %pM kernel extension to display the MAC address.

Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: David S. Miller da...@davemloft.net

---

Repost due to merge issues.

diff --git a/drivers/media/video/tveeprom.c b/drivers/media/video/tveeprom.c
index d533ea5..0a87749 100644
--- a/drivers/media/video/tveeprom.c
+++ b/drivers/media/video/tveeprom.c
@@ -680,10 +680,7 @@ void tveeprom_hauppauge_analog(struct i2c_client *c, 
struct tveeprom *tvee,
tveeprom_info(Hauppauge model %d, rev %s, serial# %d\n,
tvee-model, tvee-rev_str, tvee-serial_number);
if (tvee-has_MAC_address == 1)
-   tveeprom_info(MAC address is %02X-%02X-%02X-%02X-%02X-%02X\n,
-   tvee-MAC_address[0], tvee-MAC_address[1],
-   tvee-MAC_address[2], tvee-MAC_address[3],
-   tvee-MAC_address[4], tvee-MAC_address[5]);
+   tveeprom_info(MAC address is %pM\n, tvee-MAC_address);
tveeprom_info(tuner model is %s (idx %d, type %d)\n,
t_name1, tuner1, tvee-tuner_type);
tveeprom_info(TV standards%s%s%s%s%s%s%s%s (eeprom 0x%02x)\n,
--
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: PROBLEM: DVB-T scan not working after ioctl

2010-01-05 Thread Devin Heitmueller
On Tue, Jan 5, 2010 at 12:50 PM, Franz Fürbaß franz.fuerb...@chello.at wrote:
 Hello,

 [1] . Can't scan for DVB-T channels with Hauppauge HVR 4000 HD.

 [2] Got a scan problem with the Hauppauge HVR 4000 HD card.
 If I try to scan for channels with the DVB-T frontend
 (/dev/dvb/adapter0/frontend1)
 no lock is generated after this sequence:

 -open()
 -ioctl( fd, FE_GET_INFO, fe_info )
 -close()
 -open()
 -ioctl( fd, FE_GET_INFO, fe_info )

Could be some sort of timing bug where the frontend kernel thread is
suspending the device.  Just as a test, try putting an msleep(5000);
between the first close and the second open(), and see if the problem
still occurs.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK

2010-01-05 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Tue Jan  5 19:00:02 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13879:b6b82258cf5e
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.33-rc2-armv5: ERRORS
linux-2.6.32-armv5-davinci: OK
linux-2.6.33-rc2-armv5-davinci: ERRORS
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: OK
linux-2.6.33-rc2-armv5-ixp: ERRORS
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.33-rc2-armv5-omap2: ERRORS
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.11-i686: OK
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: OK
linux-2.6.31-i686: WARNINGS
linux-2.6.32-i686: WARNINGS
linux-2.6.33-rc2-i686: ERRORS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.33-rc2-m32r: ERRORS
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-mips: OK
linux-2.6.33-rc2-mips: ERRORS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.33-rc2-powerpc64: ERRORS
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-x86_64: WARNINGS
linux-2.6.33-rc2-x86_64: ERRORS
spec: OK
sparse (linux-2.6.32): ERRORS
sparse (linux-2.6.33-rc2): ERRORS
linux-2.6.16.61-i686: OK
linux-2.6.17.14-i686: OK
linux-2.6.18.8-i686: OK
linux-2.6.19.5-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.61-x86_64: OK
linux-2.6.17.14-x86_64: OK
linux-2.6.18.8-x86_64: OK
linux-2.6.19.5-x86_64: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.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


WinTV Radio rev-c121 remote support

2010-01-05 Thread Samuel Rakitničan
Hi,

I have an old bt878 based analog card. It's 'Hauppauge WinTV Radio' model 44914,
rev C121.

I'm trying to workout support for this shipped remote control. I have
tried to add
following lines to bttv-cards.c and bttv-input.c, but that gived
really bad results
(dmesg output is in attachment).


diff -r b6b82258cf5e linux/drivers/media/video/bt8xx/bttv-cards.c
--- a/linux/drivers/media/video/bt8xx/bttv-cards.c  Thu Dec 31 19:14:54 2009
-0200
+++ b/linux/drivers/media/video/bt8xx/bttv-cards.c  Tue Jan 05 13:25:09 2010
+0100
@@ -491,6 +491,7 @@
    .pll    = PLL_28,
    .tuner_type = UNSET,
    .tuner_addr = ADDR_UNSET,
+   .has_remote = 1,
    },
    [BTTV_BOARD_MIROPRO] = {
    .name   = MIRO PCTV pro,
diff -r b6b82258cf5e linux/drivers/media/video/bt8xx/bttv-input.c
--- a/linux/drivers/media/video/bt8xx/bttv-input.c  Thu Dec 31 19:14:54 2009
-0200
+++ b/linux/drivers/media/video/bt8xx/bttv-input.c  Tue Jan 05 13:25:09 2010
+0100
@@ -341,6 +341,12 @@
    ir-last_gpio    = ir_extract_bits(bttv_gpio_read(btv-c),
   ir-mask_keycode);
    break;
+   case BTTV_BOARD_HAUPPAUGE878:
+   ir_codes = ir_codes_pctv_sedna_table;
+   ir-mask_keycode = 0;
+   ir-mask_keyup   = 0;
+   //ir-polling  = 50;
+   break;
    }
    if (NULL == ir_codes) {
    dprintk(KERN_INFO Ooops: IR config error [card=%d]\n,
btv-c.type);



r...@crni:~/v4l-dvb# modprobe bttv
Segmentation fault
r...@crni:~/v4l-dvb#
Message from sysl...@crni at Tue Jan  5 13:03:08 2010 ...
crni kernel: Oops:  [#1] SMP

 [...]




So I guess that's not going to work. I have read in
wiki that Hauppauge cards needs ir-kbd-i2c, so I tried with that too, but
then similar error like previous happens when I try 'modprobe ir-kbd-i2c debug=1
hauppauge=1' as well as just 'modprobe ir-kbd-i2c'.

Can I have a little pointer what to do?

Regards,
Samuel
--
Card: http://linuxtv.org/wiki/index.php/File:Wintv-radio-C121.jpg
Remote: http://linuxtv.org/wiki/index.php/File:Wintv-radio-remote.jpg


ir-dmesg
Description: Binary data


Re: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c

2010-01-05 Thread Alan Stern
On Tue, 5 Jan 2010, Sean wrote:

 Thanks so much for your help Alan. I also think this is definitely a bug 
 in the hardware. Let's leave it at that, I'm happy.

Okay.  You should mark the Bugzilla report as REJECTED and close it 
out.

Alan Stern

--
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 - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver

2010-01-05 Thread Kevin Hilman
m-kariche...@ti.com writes:

 From: Muralidharan Karicheri m-kariche...@ti.com

 This combines the two patches sent earlier to change the clock configuration
 and converting ccdc drivers to platform drivers. This has updated comments
 against v2 of these patches. Two new clocks master and slave are defined 
 for ccdc driver
 as per comments from Kevin Hilman.

 This adds platform code for ccdc driver on DM355 and DM6446.

 Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
 Reviewed-by: Kevin Hilman khil...@deeprootsystems.com

 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
 Applies to linux-davinci tree
  arch/arm/mach-davinci/dm355.c  |   41 ---
  arch/arm/mach-davinci/dm644x.c |   20 ++-
  2 files changed, 48 insertions(+), 13 deletions(-)

 diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
 index 2244e8c..a9ea761 100644
 --- a/arch/arm/mach-davinci/dm355.c
 +++ b/arch/arm/mach-davinci/dm355.c
 @@ -378,6 +378,8 @@ static struct davinci_clk dm355_clks[] = {
   CLK(NULL, timer3, timer3_clk),
   CLK(NULL, rto, rto_clk),
   CLK(NULL, usb, usb_clk),
 + CLK(dm355_ccdc, master, vpss_master_clk),
 + CLK(dm355_ccdc, slave, vpss_slave_clk),

I still don't understand why you have to add new entries here and
can't simply rename the existing CLK nodes using vpss_*_clk.  

Same comment for dm644x.c changes.

Kevin

   CLK(NULL, NULL, NULL),
  };
  
 @@ -665,6 +667,17 @@ static struct platform_device dm355_asp1_device = {
   .resource   = dm355_asp1_resources,
  };
  
 +static void dm355_ccdc_setup_pinmux(void)
 +{
 + davinci_cfg_reg(DM355_VIN_PCLK);
 + davinci_cfg_reg(DM355_VIN_CAM_WEN);
 + davinci_cfg_reg(DM355_VIN_CAM_VD);
 + davinci_cfg_reg(DM355_VIN_CAM_HD);
 + davinci_cfg_reg(DM355_VIN_YIN_EN);
 + davinci_cfg_reg(DM355_VIN_CINL_EN);
 + davinci_cfg_reg(DM355_VIN_CINH_EN);
 +}
 +
  static struct resource dm355_vpss_resources[] = {
   {
   /* VPSS BL Base address */
 @@ -701,6 +714,10 @@ static struct resource vpfe_resources[] = {
   .end= IRQ_VDINT1,
   .flags  = IORESOURCE_IRQ,
   },
 +};
 +
 +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct resource dm355_ccdc_resource[] = {
   /* CCDC Base address */
   {
   .flags  = IORESOURCE_MEM,
 @@ -708,8 +725,18 @@ static struct resource vpfe_resources[] = {
   .end= 0x01c70600 + 0x1ff,
   },
  };
 +static struct platform_device dm355_ccdc_dev = {
 + .name   = dm355_ccdc,
 + .id = -1,
 + .num_resources  = ARRAY_SIZE(dm355_ccdc_resource),
 + .resource   = dm355_ccdc_resource,
 + .dev = {
 + .dma_mask   = vpfe_capture_dma_mask,
 + .coherent_dma_mask  = DMA_BIT_MASK(32),
 + .platform_data  = dm355_ccdc_setup_pinmux,
 + },
 +};
  
 -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
  static struct platform_device vpfe_capture_dev = {
   .name   = CAPTURE_DRV_NAME,
   .id = -1,
 @@ -860,17 +887,7 @@ static int __init dm355_init_devices(void)
   davinci_cfg_reg(DM355_INT_EDMA_CC);
   platform_device_register(dm355_edma_device);
   platform_device_register(dm355_vpss_device);
 - /*
 -  * setup Mux configuration for vpfe input and register
 -  * vpfe capture platform device
 -  */
 - davinci_cfg_reg(DM355_VIN_PCLK);
 - davinci_cfg_reg(DM355_VIN_CAM_WEN);
 - davinci_cfg_reg(DM355_VIN_CAM_VD);
 - davinci_cfg_reg(DM355_VIN_CAM_HD);
 - davinci_cfg_reg(DM355_VIN_YIN_EN);
 - davinci_cfg_reg(DM355_VIN_CINL_EN);
 - davinci_cfg_reg(DM355_VIN_CINH_EN);
 + platform_device_register(dm355_ccdc_dev);
   platform_device_register(vpfe_capture_dev);
  
   return 0;
 diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
 index e65e29e..e5f1ee9 100644
 --- a/arch/arm/mach-davinci/dm644x.c
 +++ b/arch/arm/mach-davinci/dm644x.c
 @@ -315,6 +315,8 @@ struct davinci_clk dm644x_clks[] = {
   CLK(NULL, timer0, timer0_clk),
   CLK(NULL, timer1, timer1_clk),
   CLK(watchdog, NULL, timer2_clk),
 + CLK(dm644x_ccdc, master, vpss_master_clk),
 + CLK(dm644x_ccdc, slave, vpss_slave_clk),
   CLK(NULL, NULL, NULL),
  };
  
 @@ -612,6 +614,11 @@ static struct resource vpfe_resources[] = {
   .end= IRQ_VDINT1,
   .flags  = IORESOURCE_IRQ,
   },
 +};
 +
 +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct resource dm644x_ccdc_resource[] = {
 + /* CCDC Base address */
   {
   .start  = 0x01c70400,
   .end= 0x01c70400 + 0xff,
 @@ -619,7 +626,17 @@ static struct resource vpfe_resources[] = {
   },
  };
  
 -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 

Re: uvcvideo Logitech patch

2010-01-05 Thread Laurent Pinchart
Hi Mitar,

On Tuesday 29 December 2009 17:51:14 Mitar wrote:
 Hi!
 
  Could be, but I'd like to know if increasing the control streaming
  timeout is required as well.
 
 I had some time now and have tested it and it is enough just to increase
 UVC_CTRL_STREAMING_TIMEOUT to 5000, I left UVC_CTRL_CONTROL_TIMEOUT at
 300. And everything seems to work.

Thanks. I'll increase the streaming timeout value to 5000.

-- 
Regards,

Laurent Pinchart
--
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: av7110 error reporting

2010-01-05 Thread Oliver Endriss
Hi,

Johan wrote:
 I need some guidance on error messages..
 
 The machine receives these messages in the systemlog (dmesg)
 
 [ 7673.168026] dvb-ttpci: StartHWFilter error  buf 0b07 0010 07e9 b96a  
 ret 0  handle 
 [ 7674.192025] dvb-ttpci: StartHWFilter error  buf 0b07 0010 07ee b96a  
 ret 0  handle 
 [ 7675.224025] dvb-ttpci: StartHWFilter error  buf 0b07 0010 07f3 b96a  
 ret 0  handle 
 [ 7676.248128] dvb-ttpci: StartHWFilter error  buf 0b07 0010 07f9 b96a  
 ret 0  handle 
 [ 7677.280026] dvb-ttpci: StartHWFilter error  buf 0b07 0010 07fd b96a  
 ret 0  handle 
 [ 7678.312025] dvb-ttpci: StartHWFilter error  buf 0b07 0010 0803 b96a  
 ret 0  handle 
 
 These start as soon as I view or record a channel, and obviously fills 
 up the log quickly.
 
 I believe the code that generates these messages is at the bottom of 
 this message (part of av7110.c). This code was introduced in 2005 to 
 improve error reporting.

True.

 Currently I run today's v4l-dvb (using a hg update), and kernel 
 2.6.31-16. (Ubuntu), however the issue occurred in older combinations as 
 well (over a year ago), so it is not introduced by the last kernels or 
 DVB driverset.

 The message seems to be triggered by the variable handle being larger 
 then 32. On my system it always reports .

Handle ==  means that the av7110 was not able to create a new filter
entry. This will happen if there are already 32 active filters.

Does it happen for all channels, or only for a specific one?
If the latter is true: Which channel is causing the problem?
Does it have a large number of audio pids?

 Am I looking at faulty hardware, or can I resolve this issue more 
 elegant than just disabling the fault report?
 (keep in mind that I do not have a programming/coding background)

You may disable the warning, but be warned that some parts of the data
will not be recorded due to missing filter entries...

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

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


[PULL] http://linuxtv.org/hg/~awalls/cx18-pvr2100

2010-01-05 Thread Andy Walls
Mauro,

Please pull from http://linuxtv.org/hg/~awalls/cx18-pvr2100

for the following 2 changesets:

01/02: cx18: Fix tuner reset pin in card entry for the Leadtek PVR2100
http://linuxtv.org/hg/~awalls/cx18-pvr2100?cmd=changeset;node=7cc248252f21

02/02: saa7127: Add support for generating SECAM output for the SAA712[89] chips
http://linuxtv.org/hg/~awalls/cx18-pvr2100?cmd=changeset;node=ad62ab7e4325


 cx18/cx18-cards.c |2 +-
 saa7127.c |   47 ---
 2 files changed, 41 insertions(+), 8 deletions(-)

Thanks,
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: PROBLEM: DVB-T scan not working after ioctl

2010-01-05 Thread Devin Heitmueller
On Tue, Jan 5, 2010 at 6:37 PM, Franz Fürbaß franz.fuerb...@chello.at wrote:
 Ok, seems to work. I put an usleep(500); between close and open.
 I will try to apply this to MythTV and w_scan as well.

You can certainly try that with w_scan and MythTV to see if it
improves your situation.  However, I want to be clear that I just
wanted you to do it for testing purposes to see if it helps, and it
likely suggests a bug in the kernel that will need to be fixed.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-05 Thread Robert Lowery
 On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
 On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
   Mauro,
  
   I've split the revert2.diff that I sent you previously to fix the
 tuning
   regression on my DViCO Dual Digital 4 (rev 1) into three separate
 patches
   that will hopefully allow you to review more easily.
  
   The first two patches revert their respective changesets and
nothing
 else,
   fixing the issue for me.
   12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
   11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
 6MHz
  
   The third patch does what I believe is the obvious equivalent fix
to
   e6a8672631a0 but without the cleanup that breaks tuning on my card.
  
   Please review and merge
  
   Signed-off-by: Robert Lowery rglow...@exemail.com.au
 
  Mauro,
 
  I'm yet to receive a response from you on this clear regression
 introduced
  in the 2.6.31 kernel.  You attention would be appreciated
 
  Thanks
 
  -Rob
 Robert,
 The changes in question (mostly authored by me) are based on
 documentation on what offsets are to be used with the firmware for
various DVB bandwidths and demodulators.  The change was tested by Terry
 on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
and
 some other cards I can't remember, using a DVB-T pattern generator for
7
 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
(Devin,
  Maybe you can double check on the offsets in tuner-xc2028.c with any
documentation you have available to you?)
 I haven't been following this thread really at all as the board in the
subject line was unfamiliar to me, so sorry for any late response or dumb
questions by me.
 May I ask:
 1. what are the exact problem frequencies?
 2. what is the data source from which you are getting the frequency
information?
 3. what does tuner-xc2028 debug logging show as the firmware loaded
when
 tune to one of the the problem frequencies?


 Robert,

 I just found that ACMA has a very nice compilation licensed DTV
 transmitters in Australia and their frequencies.  Have a look at the
Excel spreadsheet linked on this page:

   http://acma.gov.au/WEB/STANDARD/pc=PC_9150

 The DTV tab has a list of the Area, callsign, and DTV center freq. The
Glossary tab mentions that DTV broadcasters can have an offset of +/- 125
kHz from the DTV center freq.

 If you could verify that the frequencies you are using for the problem
stations match the list, that would help eliminate commanded tuning
frequency as source of the problem.

Andy, I don't think this issue is frequency, it is the removal of the
500kHz offset.

The channel with the biggest problem (most stuttering) is Channel 8 in
Melbourne, which looks correct at 191.625 MHz on the above site.

With debug enabled on the the current hg tip (stuttering case) we have
divisor= 00 00 2f 58 (freq=191.625)

With the patch reverted (working case)
divisor= 00 00 2f 38 (freq=191.625)

Have you reviewed my patch.  It leaves your original DTV6 fix in place,
but reverts the cleanup which broke the offset calculation for me.

-Rob


 Regards,
 Andy


 BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
 cxusb_dvico_xc3028_tuner_attach(), this declaration
 static struct xc2028_ctrl ctl = {
 .fname   = XC2028_DEFAULT_FIRMWARE,
 .max_len = 64,
 .demod   = XC3028_FE_ZARLINK456,
 };
 really should have .type = XC2028_AUTO or .type = XC2028_D2633, but
since XC2028_AUTO has a value of 0, it probably doesn't matter.
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

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