RE: [PATCH] Davinci VPFE Capture: Add Suspend/Resume Support
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);
>> >+
Re: Pinnacle PCTV Hybrid (2) dvb woes
On Sun, Dec 20, 2009 at 6:40 PM, Pedro Ribeiro 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?
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
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, wrote:
From: Santiago Nunez-Corrales
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
---
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
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tvp7002_reg.h"
+
+MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
+MODULE_AUTHOR("Santiago Nunez-Corrales ");
+MODULE_LICENSE("GPL");
+
+/* Module Name */
+#define TVP7002_MODULE_NAME"tvp7002"
+
+/* 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 },
+ { TVP7002_IN_MUX_SEL_1, 0x00, T
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
At Sun, 13 Dec 2009 10:22:44 -0500, Devin Heitmueller wrote: > > On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab > 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
On Mon, Dec 21, 2009 at 12:21 PM, Takashi Iwai 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
From: Santiago Nunez-Corrales
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
---
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
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tvp7002_reg.h"
+
+MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
+MODULE_AUTHOR("Santiago Nunez-Corrales ");
+MODULE_LICENSE("GPL");
+
+/* Module Name */
+#define TVP7002_MODULE_NAME"tvp7002"
+
+/* 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 },
+ { TVP7002_IN_MUX_SEL_1, 0x00, TVP7002_WRITE },
+ { TVP7002_IN_MUX_SEL_2, 0x67, TVP7002_WRITE },
+ { TVP7002_B_AND_G_COARSE_GAIN, 0x77, TVP7002_WRITE },
+ { TVP7002_R_COARSE_GAIN, 0x07, TVP7002_WRIT
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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?
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 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?
On Mon, Dec 21, 2009 at 3:09 PM, 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? 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
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?
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 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
From: Alexey Dobriyan
Drop S_IRUGO, proc entry doesn't contain read hooks.
Drop S_IFREG, simply unnecessary.
Signed-off-by: Alexey Dobriyan
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
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
From: Andrew Morton 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 Cc: Hans Verkuil Signed-off-by: Andrew Morton --- 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 #include #include +#include #include #include #include _ -- 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
From: Julia Lawall
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/):
//
@match exists@
expression x, E;
identifier fld;
@@
* x->fld
... when != \(x = E\|&x\)
* x == NULL
//
Signed-off-by: Julia Lawall
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
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
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 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
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 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:
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 21, 2009 at 10:24 PM, Mauro Carvalho Chehab wrote: > In the case of this patch series, the complains are not related to 80 cols: 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
