RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume Support

2009-12-21 Thread Karicheri, Muralidharan
Vaibhav,

Did you address my comments against this patch? What was
the resolution. I haven't seen any response from you. Please
forward me any response that you had sent.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, December 21, 2009 1:29 AM
To: Karicheri, Muralidharan; linux-media@vger.kernel.org
Cc: hverk...@xs4all.nl
Subject: RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume Support

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Friday, November 20, 2009 3:31 AM
 To: Hiremath, Vaibhav; linux-media@vger.kernel.org
 Cc: hverk...@xs4all.nl
 Subject: RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume
 Support

 Vaibhav,

 I have some comments. I have tested this patch for normal
 use case of tvp5146 capture on DM355. It looks ok. We
 don't have support for power management on DM355. So I couldn't
 test the suspend  resume operations.

[Hiremath, Vaibhav] Murali,

If you don't any further comments/analysis, this patch should go in. I will
resubmit the patch against the tip.

Thanks,
Vaibhav

 
  struct ccdc_hw_device {
 diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
 b/drivers/media/video/davinci/dm644x_ccdc.c
 index 5dff8d9..fdab823 100644
 --- a/drivers/media/video/davinci/dm644x_ccdc.c
 +++ b/drivers/media/video/davinci/dm644x_ccdc.c
 @@ -88,6 +88,10 @@ static void *__iomem ccdc_base_addr;
  static int ccdc_addr_size;
  static enum vpfe_hw_if_type ccdc_if_type;
 
 +#define CCDC_SZ_REGS   SZ_1K
 +
 +static u32 ccdc_ctx[CCDC_SZ_REGS / sizeof(u32)];

 The last register is at 0x94 on DM6446. So do we need 256
 entries when we have only 37 registers?

 +
  /* register access routines */
  static inline u32 regr(u32 offset)
  {
 @@ -834,6 +838,87 @@ static int ccdc_set_hw_if_params(struct
 vpfe_hw_if_param *params)
 return 0;
  }
 
 +static void ccdc_save_context(void)
 +{
 +   ccdc_ctx[CCDC_PCR] = regr(CCDC_PCR);


 For this and below, You are using every 4th location in the array
 for saving register values which is not necessary if you use
 something like.
 ccdc_ctx[CCDC_PCR  2] = regr(CCDC_PCR);
 ccdc_ctx[CCDC_SYN_MODE  2] = regr(CCDC_SYN_MODE);
 Any reason why you do this way?

 +   ccdc_ctx[CCDC_SYN_MODE] = regr(CCDC_SYN_MODE);
 +   ccdc_ctx[CCDC_HD_VD_WID] = regr(CCDC_HD_VD_WID);
 +   ccdc_ctx[CCDC_PIX_LINES] = regr(CCDC_PIX_LINES);
 +   ccdc_ctx[CCDC_HORZ_INFO] = regr(CCDC_HORZ_INFO);
 +   ccdc_ctx[CCDC_VERT_START] = regr(CCDC_VERT_START);
 +   ccdc_ctx[CCDC_VERT_LINES] = regr(CCDC_VERT_LINES);
 +   ccdc_ctx[CCDC_CULLING] = regr(CCDC_CULLING);
 +   ccdc_ctx[CCDC_HSIZE_OFF] = regr(CCDC_HSIZE_OFF);
 +   ccdc_ctx[CCDC_SDOFST] = regr(CCDC_SDOFST);
 +   ccdc_ctx[CCDC_SDR_ADDR] = regr(CCDC_SDR_ADDR);
 +   ccdc_ctx[CCDC_CLAMP] = regr(CCDC_CLAMP);
 +   ccdc_ctx[CCDC_DCSUB] = regr(CCDC_DCSUB);
 +   ccdc_ctx[CCDC_COLPTN] = regr(CCDC_COLPTN);
 +   ccdc_ctx[CCDC_BLKCMP] = regr(CCDC_BLKCMP);
 +   ccdc_ctx[CCDC_FPC] = regr(CCDC_FPC);
 +   ccdc_ctx[CCDC_FPC_ADDR] = regr(CCDC_FPC_ADDR);
 +   ccdc_ctx[CCDC_VDINT] = regr(CCDC_VDINT);
 +   ccdc_ctx[CCDC_ALAW] = regr(CCDC_ALAW);
 +   ccdc_ctx[CCDC_REC656IF] = regr(CCDC_REC656IF);
 +   ccdc_ctx[CCDC_CCDCFG] = regr(CCDC_CCDCFG);
 +   ccdc_ctx[CCDC_FMTCFG] = regr(CCDC_FMTCFG);
 +   ccdc_ctx[CCDC_FMT_HORZ] = regr(CCDC_FMT_HORZ);
 +   ccdc_ctx[CCDC_FMT_VERT] = regr(CCDC_FMT_VERT);
 +   ccdc_ctx[CCDC_FMT_ADDR0] = regr(CCDC_FMT_ADDR0);
 +   ccdc_ctx[CCDC_FMT_ADDR1] = regr(CCDC_FMT_ADDR1);
 +   ccdc_ctx[CCDC_FMT_ADDR2] = regr(CCDC_FMT_ADDR2);
 +   ccdc_ctx[CCDC_FMT_ADDR3] = regr(CCDC_FMT_ADDR3);
 +   ccdc_ctx[CCDC_FMT_ADDR4] = regr(CCDC_FMT_ADDR4);
 +   ccdc_ctx[CCDC_FMT_ADDR5] = regr(CCDC_FMT_ADDR5);
 +   ccdc_ctx[CCDC_FMT_ADDR6] = regr(CCDC_FMT_ADDR6);
 +   ccdc_ctx[CCDC_FMT_ADDR7] = regr(CCDC_FMT_ADDR7);
 +   ccdc_ctx[CCDC_PRGEVEN_0] = regr(CCDC_PRGEVEN_0);
 +   ccdc_ctx[CCDC_PRGEVEN_1] = regr(CCDC_PRGEVEN_1);
 +   ccdc_ctx[CCDC_PRGODD_0] = regr(CCDC_PRGODD_0);
 +   ccdc_ctx[CCDC_PRGODD_1] = regr(CCDC_PRGODD_1);
 +   ccdc_ctx[CCDC_VP_OUT] = regr(CCDC_VP_OUT);
 +}
 +
 +static void ccdc_restore_context(void)
 +{
 +   regw(ccdc_ctx[CCDC_SYN_MODE], CCDC_SYN_MODE);
 +   regw(ccdc_ctx[CCDC_HD_VD_WID], CCDC_HD_VD_WID);
 +   regw(ccdc_ctx[CCDC_PIX_LINES], CCDC_PIX_LINES);
 +   regw(ccdc_ctx[CCDC_HORZ_INFO], CCDC_HORZ_INFO);
 +   regw(ccdc_ctx[CCDC_VERT_START], CCDC_VERT_START);
 +   regw(ccdc_ctx[CCDC_VERT_LINES], CCDC_VERT_LINES);
 +   regw(ccdc_ctx[CCDC_CULLING], CCDC_CULLING);
 +   regw(ccdc_ctx[CCDC_HSIZE_OFF], CCDC_HSIZE_OFF);
 +   regw(ccdc_ctx[CCDC_SDOFST], CCDC_SDOFST);
 +   regw(ccdc_ctx[CCDC_SDR_ADDR], CCDC_SDR_ADDR);
 +   regw(ccdc_ctx[CCDC_CLAMP], CCDC_CLAMP);
 +   regw(ccdc_ctx[CCDC_DCSUB], CCDC_DCSUB);
 +   regw(ccdc_ctx[CCDC_COLPTN], CCDC_COLPTN);
 +   regw(ccdc_ctx[CCDC_BLKCMP], CCDC_BLKCMP);
 +   regw(ccdc_ctx[CCDC_FPC], CCDC_FPC);
 +   

Re: Pinnacle PCTV Hybrid (2) dvb woes

2009-12-21 Thread Devin Heitmueller
On Sun, Dec 20, 2009 at 6:40 PM, Pedro Ribeiro ped...@gmail.com wrote:
 Damn, I suspected that.

 Anyway, I'm having trouble viewing analog TV. I can scan and watch
 channels fine, but there is no audio, and I don't know how to
 configure it. If you could help me, I would really appreciate it

 Should I use the em28xx soundcard for output or my own internal soundcard?

 tvtime only uses ALSA, but my internal soundcard as OSS mixer
 emulation (the em28xx has not). However, I cannot control the volume
 in tvtime

 Alsa says that the em28xx soundcard has no mixer controls.

Hello Pedro,

Tvtime doesn't support reading on ALSA devices - this is an issue not
specific to the em28xx, but effects pretty much every modern tuner -
tvtime was written during a time when capture cards had a line out
cable that you would connect to speakers.  I've written about the
topic at length on the kernellabs.com blog if you want more info.

Note that the em28xx provides a PCM *input* device.  To get audio, you
will typically read on the em28xx PCM device and output to your sound
card.

To make it work in tvtime, run tvtime, open a separate window, and try
the following:

arecord -D hw:1,0 -c 2 -r 48000 -f S16_LE | aplay -

(assuming that the em28xx board is detected as 1,0 if you run arecord -l)

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: scan/scan-s2 doesn't tune, but dvbtune does?

2009-12-21 Thread BOUWSMA Barry
On Fri, 18 Dec 2009, Michael Akey wrote:

I can't get the scan/scan-s2 utilities to lock any transponders (DVB-S).
 My test satellite is AMC1 103W, the Pentagon Channel tp. This is
probably
some simple user error on my part, but I can't figure it out.  I have a
Corotor II with polarity changed via serial command to an external IRD.
 C/Ku is switched by 22KHz tone, voltage is always 18V.  Ku is with tone
off, C with tone on.  Speaking of which, is there a way to manually set
the
tone from the arguments on the scan utilities?

   I think
 it's a tone issue, but then again, why does attempting to scan something on
 both bands C and Ku (tone on, and tone off respectively) not work?  I figured
 if it's a tone issue that only one band would work.
 
 I tried setting the FEC and even the delivery system (S1 rather than S) and it
 makes no difference.  I could try the DVB-S2 NBC mux on that satellite too..
 but I'm not sure why that would make a difference.
 
 If you folks have any other ideas, let me know.  Thanks for your responses so
 far!

Hi Mike,

I overlooked your description of your Corotor and IRD earlier, and
now, with poor connectivity, I can't really look up the details 
and match them with my experiences.

I have a switch that is activated by the 22kHz signal and which
used to be used for old analogue setups to select between two
positions.  I'm not sure if there is a discrete component like
this in your setup, but if there is, is it possible for you to
bypass it and get directly to the C- or Ku-band LNB?  Or am I
failing to do research to show me this is not possible...

In any case, I'd do what I can to get directly to the LNB.  Also,
your mention of polarity switching is, well, alien to me.  I
suspect the card is expecting to use 13V or 18V to get vertical
or horizontal polarisation; for circular polarisation I wouldn't
know what handedness corresponds to what switching.

Anyway, the 18V you say is constant, would be supplied by the
horizontal polarisation.  If you're able to get that 22kHz switch
out of the way, and scan the Ku-band LNB directly, you ought to be
able to see the same results with giving the directly-used 
frequency values, or subtracting 1 000 000kHz to convert your
10750MHz to the 9750MHz expected by the low-band Universal LNB
local oscillator frequency -- the latter normally not generating
the 22kHz signal.

I don't know if this will help at all, or if it's possible, and I
apologise for my ignorance about your specific dish(es?).


barry bouwsma
--
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 3/4 v13] TVP7002 driver for DM365

2009-12-21 Thread Santiago Nunez-Corrales

Alexey,


Good catch. Thanks for reviewing the code. I will update and send the 
patch asap.



Regards,


Alexey Klimov wrote:

Hello,

On Fri, Dec 18, 2009 at 8:07 PM,  santiago.nu...@ridgerun.com wrote:
  

From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values. Testing shows that the device
needs not to be powered down and up for correct behaviour.
Improved readability. Uses helper function for preset information.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 drivers/media/video/tvp7002.c | 1189 +
 1 files changed, 1189 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/tvp7002.c

diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..058ffda
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1189 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tvp7002.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include tvp7002_reg.h
+
+MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
+MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
+MODULE_LICENSE(GPL);
+
+/* Module Name */
+#define TVP7002_MODULE_NAMEtvp7002
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Read write definition for registers */
+#define TVP7002_READ   0
+#define TVP7002_WRITE  1
+#define TVP7002_RESERVED   2
+
+/* Interlaced vs progressive mask and shift */
+#define TVP7002_IP_SHIFT   5
+#define TVP7002_INPR_MASK  (0x01  TVP7002_IP_SHIFT)
+
+/* Shift for CPL and LPF registers */
+#define TVP7002_CL_SHIFT   8
+#define TVP7002_CL_MASK0x0f
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-2));
+
+/* Structure for register values */
+struct i2c_reg_value {
+   u8 reg;
+   u8 value;
+   u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+   { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+   { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+   { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+   { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+   { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+   { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+   { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+   { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+   { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+   { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+   { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },

Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-21 Thread Takashi Iwai
At Sun, 13 Dec 2009 10:22:44 -0500,
Devin Heitmueller wrote:
 
 On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
  Hi Devin,
 
  It is better to submit the RFC patches to alsa ML for they to take a look.
 
  Cheers,
  Mauro
 
 Is there something specific you want the ALSA people to review?  There
 are no changes to the ALSA core and this is a pretty
 simple/straightforward PCM capture device modelled after the existing
 cx88/saa7134/em28xx-alsa drivers.  The driver is complete, tested by
 both KernelLabs and the customer.  As far as I know, we generally
 haven't bothered the ALSA people with devices in the /media tree in
 the past unless there was some specific issue.
 
 If there is something here out of the ordinary here that you felt
 the ALSA people would be able to offer some insight on, I would be
 more than happy to send it to them.

Just a very quick look through the files, here are some comments:

- snd_card_free() can't be called with NULL, but the error path in
  snd_cx18_init() may reach that (when snd_card_create() returns an
  error).

- Specifying both SNDRV_PCM_RATE_CONTINOUS and _KNOT to
  snd_pcm_hw_info.rates doesn't make sense.  In your case, if it's
  only 48kHz, SNDRV_PCM_RATE_48000 there instead.

- vfree() should be called in hw_free callback rather than close
  callback.  And, there are already global vmalloc-buffer helper
  functions in the latest ALSA tree for 2.6.34...

- It'd be nice if you give TLV information for the mixer dB mapping.
  

thanks,

Takashi
--
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://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-21 Thread Devin Heitmueller
On Mon, Dec 21, 2009 at 12:21 PM, Takashi Iwai ti...@suse.de wrote:
 Just a very quick look through the files, here are some comments:

 - snd_card_free() can't be called with NULL, but the error path in
  snd_cx18_init() may reach that (when snd_card_create() returns an
  error).

 - Specifying both SNDRV_PCM_RATE_CONTINOUS and _KNOT to
  snd_pcm_hw_info.rates doesn't make sense.  In your case, if it's
  only 48kHz, SNDRV_PCM_RATE_48000 there instead.

 - vfree() should be called in hw_free callback rather than close
  callback.  And, there are already global vmalloc-buffer helper
  functions in the latest ALSA tree for 2.6.34...

 - It'd be nice if you give TLV information for the mixer dB mapping.

Hello Takashi,

Thanks for taking the time to provide feedback.  I will make these
changes and add them to the tree.

Out of curiosity, is there any sort of tool/code which exercises the
driver to verify the advertised capabilities.  Part of the problem
here is that it is not really easy to find example applications which
use all the features, which I suspect is one of the big headaches that
the PulseAudio people are suffering from in that they are finding bugs
in ALSA drivers because they are the first ones to actually attempt to
use some of these capabilities.  For me the card works, but then
some user complains that their PulseAudio is broken because I didn't
setup the config structures properly or only half-implemented some
capability used by PulseAudio but not arecord/aplay.

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


[PATCH 3/4 v13 r1] TVP7002 driver for DM365

2009-12-21 Thread santiago . nunez
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values. Testing shows that the device
needs not to be powered down and up for correct behaviour.
Improved readability. Uses helper function for preset information.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 drivers/media/video/tvp7002.c | 1191 +
 1 files changed, 1191 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/tvp7002.c

diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..229fa1c
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1191 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tvp7002.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include tvp7002_reg.h
+
+MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
+MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
+MODULE_LICENSE(GPL);
+
+/* Module Name */
+#define TVP7002_MODULE_NAMEtvp7002
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Read write definition for registers */
+#define TVP7002_READ   0
+#define TVP7002_WRITE  1
+#define TVP7002_RESERVED   2
+
+/* Interlaced vs progressive mask and shift */
+#define TVP7002_IP_SHIFT   5
+#define TVP7002_INPR_MASK  (0x01  TVP7002_IP_SHIFT)
+
+/* Shift for CPL and LPF registers */
+#define TVP7002_CL_SHIFT   8
+#define TVP7002_CL_MASK0x0f
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-2));
+
+/* Structure for register values */
+struct i2c_reg_value {
+   u8 reg;
+   u8 value;
+   u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+   { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+   { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+   { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+   { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+   { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+   { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+   { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+   { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+   { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+   { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+   { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
+   { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_2, 0x00, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_3, 0x01, TVP7002_WRITE 

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

2009-12-21 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:Mon Dec 21 19:00:02 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13836:9defbd461e5f
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.32-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: ERRORS
linux-2.6.28-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30-i686: ERRORS
linux-2.6.31-i686: ERRORS
linux-2.6.32-i686: ERRORS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-mips: OK
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: WARNINGS
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
spec: OK
sparse (linux-2.6.32): ERRORS
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

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


Re: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?

2009-12-21 Thread Robert Longfield
Well it gets even better.
So on the weekend I was able to steal a few minutes to properly
trouble shoot the issue now that I know it was in the mythbuntu box.
As a long shot I pulled out the Promise Tech Ultra133 TX2 / ATA card I
am using for the backup drive. With this card removed the sync issue
went away, when I put the card back in the issue returned. Now this
card was in the slot right next to the PVR-150 card. I moved the
controller card as far away as I could get from the PVR-150 and the
sync issue was gone.

So it would appear that the Promise Tech card was causing some EM
interference with the PVR-150 card. I will keep an eye on this to make
sure that this was indeed the issue.

Does it seem reasonable that this card would kick out interference like this?

-Rob

On Fri, Dec 18, 2009 at 3:13 PM, Steven Toth st...@kernellabs.com wrote:
 So it looks like the problem is restricted to my mythbuntu box.

 Congrats, that's better news.

 --
 Steven Toth - 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: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?

2009-12-21 Thread Devin Heitmueller
On Mon, Dec 21, 2009 at 3:09 PM, Robert Longfield
robert.longfi...@gmail.com wrote:
 Well it gets even better.
 So on the weekend I was able to steal a few minutes to properly
 trouble shoot the issue now that I know it was in the mythbuntu box.
 As a long shot I pulled out the Promise Tech Ultra133 TX2 / ATA card I
 am using for the backup drive. With this card removed the sync issue
 went away, when I put the card back in the issue returned. Now this
 card was in the slot right next to the PVR-150 card. I moved the
 controller card as far away as I could get from the PVR-150 and the
 sync issue was gone.

 So it would appear that the Promise Tech card was causing some EM
 interference with the PVR-150 card. I will keep an eye on this to make
 sure that this was indeed the issue.

 Does it seem reasonable that this card would kick out interference like this?

Having worked at a lab that did EMI compliance testing, I can
definitely tell some stories of cases far stranger than that.  But
yeah, if the card works in a different slot, then it's unlikely any
sort of PCI bus congestion issue but rather an EMI problem.

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: How to make a Zaapa LR301AP DVB-T card work

2009-12-21 Thread hermann pitton

Am Sonntag, den 20.12.2009, 13:13 + schrieb Antonio Marcos López
Alonso: 
  
  please try with card=86.
  
  If everything is fine, we add it to auto detection.
  
  Cheers,
  Hermann
  
 
 Did it so and the card (TDA10046 chip ) is now detected by MythTV (have to 
 say 
 previous setup was not detected by Kaffeine because MythTV backend was 
 running). However scanning process did not find any channel and I'm sure 
 previous cards have worked doing so.
 
 New dmesg|grep saa output:
 *
 [8.840823] saa7130/34: v4l2 driver version 0.2.15 loaded
 [8.841237] saa7134 :00:0c.0: PCI INT A - Link[LNKB] - GSI 11 
 (level, 
 low) - IRQ 11
 [8.841244] saa7134[0]: found at :00:0c.0, rev: 1, irq: 11, latency: 
 64, mmio: 0xdc00
 [8.841251] saa7134[0]: subsystem: 4e42:0301, board: LifeView FlyDVB-T / 
 Genius VideoWonder DVB-T [card=86,insmod option]
 [8.841272] saa7134[0]: board init: gpio is 1
 [8.841369] input: saa7134 IR (LifeView FlyDVB-T / as 
 /devices/pci:00/:00:0c.0/input/input5
 [8.841411] IRQ 11/saa7134[0]: IRQF_DISABLED is not guaranteed on shared 
 IRQs
 [8.992137] saa7134[0]: i2c eeprom 00: 42 4e 01 03 54 20 1c 00 43 43 a9 1c 
 55 d2 b2 92
 [8.992147] saa7134[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff ff ff ff ff ff 
 ff ff ff ff
 [8.992155] saa7134[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 e2 
 ff ff ff ff
 [8.992163] saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992170] saa7134[0]: i2c eeprom 40: ff 1b 00 c0 ff 10 01 00 ff ff ff ff 
 ff ff ff ff
 [8.992177] saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992185] saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992192] saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992199] saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992207] saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992214] saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992221] saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992229] saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992236] saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992243] saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992250] saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff 
 ff ff ff ff
 [8.992393] saa7134[0]: registered device video0 [v4l2]
 [8.992418] saa7134[0]: registered device vbi0
 [9.533985] DVB: registering new adapter (saa7134[0])
 [   10.279639] saa7134 ALSA driver for DMA sound loaded
 [   10.279652] IRQ 11/saa7134[0]: IRQF_DISABLED is not guaranteed on shared 
 IRQs
 [   10.279679] saa7134[0]/alsa: saa7134[0] at 0xdc00 irq 11 registered as 
 card -1
 
 Cheers
 Antonio
 

Antonio,

the report for tda10046 firmware loading is missing. Was that OK?

LR301 is a LifeView design. It is very common to see multiple other
subvendors for their cards, but they keep the original subdevice ID.
In this case 0x0301. The subvendor 0x4e42 is usually Typhoon/Anubis and
they are distributing clones of almost all LifeView cards.

Gpio init is the same like on the other known LR301 cards and eeprom
differs only for a few bytes, but not for tuner type, tuner and demod
address.

http://ubuntuforums.org/archive/index.php/t-328140.html

Since this design with a saa7134 chip and tda8274 DVB-T only tuner is very old,
I don't expect an additional Low Noise Amplifier on it.

We can't detect such LNAs and on newer cards they can cause problems, if
not configured correctly and might cause scan to fail.

If you mean above other card types did previously work for your card,
use them and report.

Sorry, I don't have better ideas for your card so far.

Cheers,
Hermann





--
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: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?

2009-12-21 Thread Andy Walls
On Mon, 2009-12-21 at 15:09 -0500, Robert Longfield wrote:
 Well it gets even better.
 So on the weekend I was able to steal a few minutes to properly
 trouble shoot the issue now that I know it was in the mythbuntu box.
 As a long shot I pulled out the Promise Tech Ultra133 TX2 / ATA card I
 am using for the backup drive. With this card removed the sync issue
 went away, when I put the card back in the issue returned. Now this
 card was in the slot right next to the PVR-150 card. I moved the
 controller card as far away as I could get from the PVR-150 and the
 sync issue was gone.
 
 So it would appear that the Promise Tech card was causing some EM
 interference with the PVR-150 card. I will keep an eye on this to make
 sure that this was indeed the issue.
 
 Does it seem reasonable that this card would kick out interference like this?

Yes, it is plausible.

Perhaps you may also wish to consider an external (USB connected)
capture device.  A PC can internally have many sources of square waves
that have either fundamental or harmonic frequencies in UHF.  The metal
case of a PC can greatly reduce the EMI on outside of the case.

Regards,
Andy

 -Rob
 
 On Fri, Dec 18, 2009 at 3:13 PM, Steven Toth st...@kernellabs.com wrote:
  So it looks like the problem is restricted to my mythbuntu box.
 
  Congrats, that's better news.
 
  --
  Steven Toth - 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


[patch 2/3] proc_fops: convert av7110

2009-12-21 Thread akpm
From: Alexey Dobriyan adobri...@gmail.com

Drop S_IRUGO, proc entry doesn't contain read hooks.
Drop S_IFREG, simply unnecessary.

Signed-off-by: Alexey Dobriyan adobri...@gmail.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/media/dvb/ttpci/av7110_ir.c |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff -puN drivers/media/dvb/ttpci/av7110_ir.c~proc_fops-convert-av7110 
drivers/media/dvb/ttpci/av7110_ir.c
--- a/drivers/media/dvb/ttpci/av7110_ir.c~proc_fops-convert-av7110
+++ a/drivers/media/dvb/ttpci/av7110_ir.c
@@ -268,8 +268,8 @@ int av7110_check_ir_config(struct av7110
 
 
 /* /proc/av7110_ir interface */
-static int av7110_ir_write_proc(struct file *file, const char __user *buffer,
-   unsigned long count, void *data)
+static ssize_t av7110_ir_proc_write(struct file *file, const char __user 
*buffer,
+   size_t count, loff_t *pos)
 {
char *page;
u32 ir_config;
@@ -309,6 +309,10 @@ static int av7110_ir_write_proc(struct f
return count;
 }
 
+static const struct file_operations av7110_ir_proc_fops = {
+   .owner  = THIS_MODULE,
+   .write  = av7110_ir_proc_write,
+};
 
 /* interrupt handler */
 static void ir_handler(struct av7110 *av7110, u32 ircom)
@@ -368,11 +372,9 @@ int __devinit av7110_ir_init(struct av71
input_dev-timer.data = (unsigned long) av7110-ir;
 
if (av_cnt == 1) {
-   e = create_proc_entry(av7110_ir, S_IFREG | S_IRUGO | S_IWUSR, 
NULL);
-   if (e) {
-   e-write_proc = av7110_ir_write_proc;
+   e = proc_create(av7110_ir, S_IWUSR, NULL, 
av7110_ir_proc_fops);
+   if (e)
e-size = 4 + 256 * sizeof(u16);
-   }
}
 
tasklet_init(av7110-ir.ir_tasklet, av7110_emit_key, (unsigned long) 
av7110-ir);
_
--
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 3/3] drivers/media/video/pms.c needs version.h

2009-12-21 Thread akpm
From: Andrew Morton a...@linux-foundation.org

i386 allmodconfig:

drivers/media/video/pms.c: In function 'pms_querycap':
drivers/media/video/pms.c:682: error: implicit declaration of function 
'KERNEL_VERSION'

Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/media/video/pms.c |1 +
 1 file changed, 1 insertion(+)

diff -puN drivers/media/video/pms.c~drivers-media-video-pmsc-needs-versionh 
drivers/media/video/pms.c
--- a/drivers/media/video/pms.c~drivers-media-video-pmsc-needs-versionh
+++ a/drivers/media/video/pms.c
@@ -24,6 +24,7 @@
 #include linux/delay.h
 #include linux/errno.h
 #include linux/fs.h
+#include linux/version.h
 #include linux/kernel.h
 #include linux/slab.h
 #include linux/mm.h
_
--
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 1/3] drivers/media/video: Move dereference after NULL test

2009-12-21 Thread akpm
From: Julia Lawall ju...@diku.dk

In quickcam_messenger.c, if the NULL test on uvd is needed, then the
dereference should be after the NULL test.

In vpif_display.c, std_info is initialized to the address of a structure
field.  This seems unlikely to be NULL.  If it could somehow be NULL, then
the assignment should be moved after the NULL test.  Alternatively, perhaps
the NULL test is intended to test std_info-stdid rather than std_info?

In saa7134-alsa.c, the function is only called from one place, where the
chip argument has already been dereferenced.  On the other hand, if it
should be kept, then card should be initialized after it.

A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):

// smpl
@match exists@
expression x, E;
identifier fld;
@@

* x-fld
  ... when != \(x = E\|x\)
* x == NULL
// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk
Cc: Mauro Carvalho Chehab mche...@infradead.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---

 drivers/media/video/davinci/vpif_display.c|2 --
 drivers/media/video/saa7134/saa7134-alsa.c|2 --
 drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
 3 files changed, 2 insertions(+), 5 deletions(-)

diff -puN 
drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
 drivers/media/video/davinci/vpif_display.c
--- 
a/drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/davinci/vpif_display.c
@@ -383,8 +383,6 @@ static int vpif_get_std_info(struct chan
int index;
 
std_info-stdid = vid_ch-stdid;
-   if (!std_info)
-   return -1;
 
for (index = 0; index  ARRAY_SIZE(ch_params); index++) {
config = ch_params[index];
diff -puN 
drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-move-dereference-after-null-test
 drivers/media/video/saa7134/saa7134-alsa.c
--- 
a/drivers/media/video/saa7134/saa7134-alsa.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int snd_card_saa7134_new_mixer(sn
unsigned int idx;
int err, addr;
 
-   if (snd_BUG_ON(!chip))
-   return -EINVAL;
strcpy(card-mixername, SAA7134 Mixer);
 
for (idx = 0; idx  ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff -puN 
drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-video-move-dereference-after-null-test
 drivers/media/video/usbvideo/quickcam_messenger.c
--- 
a/drivers/media/video/usbvideo/quickcam_messenger.c~drivers-media-video-move-dereference-after-null-test
+++ a/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uv
 
 static void qcm_stop_data(struct uvd *uvd)
 {
-   struct qcm *cam = (struct qcm *) uvd-user_data;
+   struct qcm *cam;
int i, j;
int ret;
 
if ((uvd == NULL) || (!uvd-streaming) || (uvd-dev == NULL))
return;
+   cam = (struct qcm *) uvd-user_data;
 
ret = qcm_camera_off(uvd);
if (ret)
_
--
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://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-21 Thread hermann pitton
Hi,

Am Sonntag, den 20.12.2009, 22:44 -0500 schrieb Andy Walls:
 On Sun, 2009-12-20 at 22:33 -0500, Devin Heitmueller wrote:
  On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls awa...@radix.net wrote:
   Hmmm on the current v4l-dvb tree, the command
  
   $ v4l/scripts/checkpatch.pl --no-tree --strict  \
  -f linux/drivers/media/video/cx18/cx18-driver.c
  
   yields warnings about pre-existing 80 column lines and
   LINUX_VERSION_CODE checks.
  
   Was there something else?
  
  No, that's what I'm talking about.  I figured if you wanted to split
  the CX18_ERR messages to fit on 80 columns, that is really at your
  discretion, not mine.   I can certainly do it, of course, but I
  personally believe it's one of those cases where it is better to not
  split them.
 
 Ah.  No I wouldn't bother.  The LKML has some churn on checkpatch's 80
 column warning in the past few days:
 
 http://lkml.org/lkml/2009/12/17/208
 
 In that thread Joe Perches posted a compromise:
 
 http://lkml.org/lkml/2009/12/18/3
 
 I'll wait and see how it comes out.
 
 BTW I have got unsubscribe from the LKML - way too many emails in my
 inbox.
 
 Regards,
 Andy
  Devin
 

just as a side note.

IIRC, this took about two years to come through now.

http://lkml.org/lkml/2009/12/18/276

Some people did stop to post patches at all and other patches were lost,
because such last steps of bureaucrac(z)y were too much for more than a
few ...

Most annoying, since also lines in patch offsets were marked as errors,
residing since many years in kernel and accepted once without
complaints, now should be corrected by one just trying to add a new
similar functional device.

It is often hard enough to figure out some new unknown hardware.

Then, given the back and forth on it and all, even with best will, one
could trap into cases even a full weekend is not enough to add some five
to eight lines of code correctly within some such minefield
exposed/created by such rules for an average contributor ...

Alone, that counted code lines in kernel can nearly double by doing so
should be enough to make it never a strict rule, I thought ...

Cheers,
Hermann











 

--
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://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-21 Thread Mauro Carvalho Chehab
Em 21-12-2009 01:44, Andy Walls escreveu:
 On Sun, 2009-12-20 at 22:33 -0500, Devin Heitmueller wrote:
 On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls awa...@radix.net wrote:
 Hmmm on the current v4l-dvb tree, the command

 $ v4l/scripts/checkpatch.pl --no-tree --strict  \
-f linux/drivers/media/video/cx18/cx18-driver.c

 yields warnings about pre-existing 80 column lines and
 LINUX_VERSION_CODE checks.

 Was there something else?

 No, that's what I'm talking about.  I figured if you wanted to split
 the CX18_ERR messages to fit on 80 columns, that is really at your
 discretion, not mine.   I can certainly do it, of course, but I
 personally believe it's one of those cases where it is better to not
 split them.
 
 Ah.  No I wouldn't bother.  The LKML has some churn on checkpatch's 80
 column warning in the past few days:

The 80 cols is just a warning. It is useful basically to point places where
perhaps the logic is being too complex (for example, cases where there are
several loops inside). 

In the case of this patch series, the complains are not related to 80 cols:

cx18-alsa: Initial non-working cx18-alsa files
ERROR: need consistent spacing around '+' (ctx:WxV)
#124: FILE: linux/drivers/media/video/cx18/cx18-alsa-mixer.c:95:
+   uinfo-value.integer.max  =  +8;
 ^

total: 1 errors, 0 warnings, 579 lines checked

/tmp/newpatches/hg_hvr-1600-alsa-2_02.patch:
cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss

/tmp/newpatches/hg_hvr-1600-alsa-2_04.patch:
cx18: make it so cx18-alsa-main.c compiles
WARNING: line over 80 characters
#44: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:44:
+#define CX18_DEBUG_ALSA_INFO(fmt, arg...) printk(KERN_INFO %s:  fmt, 
cx18-alsa, ## arg)

WARNING: printk() should include KERN_ facility level
#89: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:254:
+   printk(cx18-alsa: drv was null\n);

total: 0 errors, 2 warnings, 74 lines checked

/tmp/newpatches/hg_hvr-1600-alsa-2_06.patch:
cx18: overhaul ALSA PCM device handling so it works
WARNING: externs should be avoided in .c files
#41: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:40:
+extern int cx18_alsa_debug;

WARNING: externs should be avoided in .c files
#50: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:49:
+void cx18_alsa_announce_pcm_data(struct snd_cx18_card *cxsc, u8 *pcm_data,

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#53: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:52:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#162: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:164:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#169: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:171:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#232: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:240:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)

WARNING: line over 80 characters
#361: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:389:
+   snd_pcm_set_ops(sp, SNDRV_PCM_STREAM_CAPTURE, 
snd_cx18_pcm_capture_ops);

total: 0 errors, 7 warnings, 396 lines checked

/tmp/newpatches/hg_hvr-1600-alsa-2_10.patch:
cx18: rework cx18-alsa module loading to support automatic loading
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
#100: FILE: linux/drivers/media/video/cx18/cx18-driver.c:52:
+EXPORT_SYMBOL(cx18_ext_init);

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#131: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1220:
+#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,20)

ERROR: space required after that ',' (ctx:VxV)
#131: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1220:
+#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,20)
  ^

ERROR: space required after that ',' (ctx:VxV)
#131: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1220:
+#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,20)
^

ERROR: spaces required around that '=' (ctx:VxV)
#138: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1227:
+   struct cx18 *dev=container_of(work, struct cx18, request_module_wk);
^

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#151: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1240:
+#if LINUX_VERSION_CODE  KERNEL_VERSION(2,6,20)

ERROR: space required after that ',' (ctx:VxV)
#151: FILE: linux/drivers/media/video/cx18/cx18-driver.c:1240:
+#if LINUX_VERSION_CODE  

Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-21 Thread Devin Heitmueller
On Mon, Dec 21, 2009 at 10:24 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 In the case of this patch series, the complains are not related to 80 cols:
snip

In this case, there was a mix of 80-column issues, as well as some
other issues.  I did fix the issues other than the 80-column issues
through patches added to the tree last night (and in fact I did fix
all the 80 column issues in my actual changes - but did not fix 80
column issues that happened to appear in the diff but were
pre-existing).

Please let me know if you have any other issues.

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