Re: [PATCH 0/2] V4L2 OF fixes
Hi Sylwester, On Wednesday 03 July 2013 22:36:28 Sylwester Nawrocki wrote: > On 07/03/2013 12:52 PM, Laurent Pinchart wrote: > > Hello, > > > > Here are two small fixes for the V4L2 OF parsing code. The patches should > > be self-explanatory. > > Hi Laurent, > > Thank you for fixing what I've messed up in the Guennadi's original patch. > For both patches: > > Acked-by: Sylwester Nawrocki No worries :-) Thanks for your ack. > > > Laurent Pinchart (2): > >v4l: of: Use of_get_child_by_name() > >v4l: of: Drop acquired reference to node when getting next endpoint > > > > drivers/media/v4l2-core/v4l2-of.c | 9 +++-- > > 1 file changed, 3 insertions(+), 6 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 0/3] saa7115: Implement i2c_board_info.platform_data
This patch set adds handling of the i2c_board_info struct to the saa7115 driver. The main goal of this patch is to give the different devices with the gm7113c chip an opportunity to configure the chip to their needs. I've only implemented the overrides I know are necessary to get the stk1160 and the smi2021 drivers to work. This is the third version of this patch series. The second version of the RFC was posted on 2013/5/31 and can be found here: http://lkml.indiana.edu/hypermail/linux/kernel/1305.3/03747.html The first version of the RFC can be found here: https://lkml.org/lkml/2013/5/29/558 Jon Arne Jørgensen (3): saa7115: Fix saa711x_set_v4lstd for gm7113c saa7115: Do not load saa7115_init_misc for gm7113c saa7115: Implement i2c_board_info.platform_data drivers/media/i2c/saa7115.c | 183 +++ drivers/media/i2c/saa711x_regs.h | 19 include/media/saa7115.h | 65 ++ 3 files changed, 233 insertions(+), 34 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 2/3] saa7115: Do not load saa7115_init_misc for gm7113c
Most of the registers changed in saa7115_init_misc table are out of range for the gm7113c chip. The only register that's within range doesn't need to be changed here. Signed-off-by: Jon Arne Jørgensen --- drivers/media/i2c/saa7115.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c index 41408dd..17a464d 100644 --- a/drivers/media/i2c/saa7115.c +++ b/drivers/media/i2c/saa7115.c @@ -1769,7 +1769,7 @@ static int saa711x_probe(struct i2c_client *client, state->crystal_freq = SAA7115_FREQ_32_11_MHZ; saa711x_writeregs(sd, saa7115_init_auto_input); } - if (state->ident > SAA7111A) + if (state->ident > SAA7111A && state->ident != GM7113C) saa711x_writeregs(sd, saa7115_init_misc); saa711x_set_v4lstd(sd, V4L2_STD_NTSC); v4l2_ctrl_handler_setup(hdl); -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 1/3] saa7115: Fix saa711x_set_v4lstd for gm7113c
saa711x_set_v4lstd would toggle several bits that should not be touched
when changing std.
This could potentially override configurations set in platform_data.
This patch should fix that problem.
Signed-off-by: Jon Arne Jørgensen
---
drivers/media/i2c/saa7115.c | 37 +
drivers/media/i2c/saa711x_regs.h | 4
2 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index 7fd766e..41408dd 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -462,24 +462,6 @@ static const unsigned char saa7115_cfg_50hz_video[] = {
/* == SAA7715 VIDEO templates (end) === */
-/* == GM7113C VIDEO templates = */
-static const unsigned char gm7113c_cfg_60hz_video[] = {
- R_08_SYNC_CNTL, 0x68, /* 0xBO: auto detection, 0x68 =
NTSC */
- R_0E_CHROMA_CNTL_1, 0x07, /* video autodetection is on */
-
- 0x00, 0x00
-};
-
-static const unsigned char gm7113c_cfg_50hz_video[] = {
- R_08_SYNC_CNTL, 0x28, /* 0x28 = PAL */
- R_0E_CHROMA_CNTL_1, 0x07,
-
- 0x00, 0x00
-};
-
-/* == GM7113C VIDEO templates (end) === */
-
-
static const unsigned char saa7115_cfg_vbi_on[] = {
R_80_GLOBAL_CNTL_1, 0x00, /* reset tasks */
R_88_POWER_SAVE_ADC_PORT_CNTL, 0xd0,/* reset scaler */
@@ -964,17 +946,24 @@ static void saa711x_set_v4lstd(struct v4l2_subdev *sd,
v4l2_std_id std)
// This works for NTSC-M, SECAM-L and the 50Hz PAL variants.
if (std & V4L2_STD_525_60) {
v4l2_dbg(1, debug, sd, "decoder set standard 60 Hz\n");
- if (state->ident == GM7113C)
- saa711x_writeregs(sd, gm7113c_cfg_60hz_video);
- else
+ if (state->ident == GM7113C) {
+ u8 reg = saa711x_read(sd, R_08_SYNC_CNTL);
+ reg &= ~(SAA7113_R_08_FSEL | SAA7113_R_08_AUFD);
+ reg |= SAA7113_R_08_FSEL;
+ saa711x_write(sd, R_08_SYNC_CNTL, reg);
+ } else {
saa711x_writeregs(sd, saa7115_cfg_60hz_video);
+ }
saa711x_set_size(sd, 720, 480);
} else {
v4l2_dbg(1, debug, sd, "decoder set standard 50 Hz\n");
- if (state->ident == GM7113C)
- saa711x_writeregs(sd, gm7113c_cfg_50hz_video);
- else
+ if (state->ident == GM7113C) {
+ u8 reg = saa711x_read(sd, R_08_SYNC_CNTL);
+ reg &= ~(SAA7113_R_08_FSEL | SAA7113_R_08_AUFD);
+ saa711x_write(sd, R_08_SYNC_CNTL, reg);
+ } else {
saa711x_writeregs(sd, saa7115_cfg_50hz_video);
+ }
saa711x_set_size(sd, 720, 576);
}
diff --git a/drivers/media/i2c/saa711x_regs.h b/drivers/media/i2c/saa711x_regs.h
index 4e5f2eb..70c56d1 100644
--- a/drivers/media/i2c/saa711x_regs.h
+++ b/drivers/media/i2c/saa711x_regs.h
@@ -201,6 +201,10 @@
#define R_FB_PULSE_C_POS_MSB 0xfb
#define R_FF_S_PLL_MAX_PHASE_ERR_THRESH_NUM_LINES 0xff
+/* SAA7113 bit-masks */
+#define SAA7113_R_08_FSEL 0x40
+#define SAA7113_R_08_AUFD 0x80
+
#if 0
/* Those structs will be used in the future for debug purposes */
struct saa711x_reg_descr {
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v3 3/3] saa7115: Implement i2c_board_info.platform_data
Implement i2c_board_info.platform_data handling in the driver so we can
make device specific changes to the chips we support.
I'm adding a new init table for the gm7113c chip because the old saa7113
init table has a illegal and wrong defaults according to the datasheet.
I'm also adding an option to the platform_data struct to choose the gm7113c_init
table even if you are writing a driver for the saa7113 chip.
This implementation is only adding overrides for the SAA7113 and GM7113C chips.
Signed-off-by: Jon Arne Jørgensen
---
drivers/media/i2c/saa7115.c | 144 ---
drivers/media/i2c/saa711x_regs.h | 15
include/media/saa7115.h | 65 ++
3 files changed, 215 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
index 17a464d..dd51e16 100644
--- a/drivers/media/i2c/saa7115.c
+++ b/drivers/media/i2c/saa7115.c
@@ -225,19 +225,55 @@ static const unsigned char saa7111_init[] = {
0x00, 0x00
};
-/* SAA7113/GM7113C init codes
- * It's important that R_14... R_17 == 0x00
- * for the gm7113c chip to deliver stable video
- */
+/* This table has one illegal value, and some values that are not
+ correct according to the datasheet initialization table.
+
+ If you need a table with legal/default values tell the driver in
+ i2c_board_info.platform_data, and you will get the gm7113c_init
+ table instead. */
+
+/* SAA7113 Init codes */
static const unsigned char saa7113_init[] = {
R_01_INC_DELAY, 0x08,
R_02_INPUT_CNTL_1, 0xc2,
R_03_INPUT_CNTL_2, 0x30,
R_04_INPUT_CNTL_3, 0x00,
R_05_INPUT_CNTL_4, 0x00,
- R_06_H_SYNC_START, 0x89,
+ R_06_H_SYNC_START, 0x89,/* Illegal value - min. value = 0x94 */
+ R_07_H_SYNC_STOP, 0x0d,
+ R_08_SYNC_CNTL, 0x88, /* OBS. HTC = VTR Mode - Not default */
+ R_09_LUMA_CNTL, 0x01,
+ R_0A_LUMA_BRIGHT_CNTL, 0x80,
+ R_0B_LUMA_CONTRAST_CNTL, 0x47,
+ R_0C_CHROMA_SAT_CNTL, 0x40,
+ R_0D_CHROMA_HUE_CNTL, 0x00,
+ R_0E_CHROMA_CNTL_1, 0x01,
+ R_0F_CHROMA_GAIN_CNTL, 0x2a,
+ R_10_CHROMA_CNTL_2, 0x08, /* Not datasheet default */
+ R_11_MODE_DELAY_CNTL, 0x0c,
+ R_12_RT_SIGNAL_CNTL, 0x07, /* Not datasheet default */
+ R_13_RT_X_PORT_OUT_CNTL, 0x00,
+ R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
+ R_15_VGATE_START_FID_CHG, 0x00,
+ R_16_VGATE_STOP, 0x00,
+ R_17_MISC_VGATE_CONF_AND_MSB, 0x00,
+
+ 0x00, 0x00
+};
+
+/* GM7113C is a clone of the SAA7113 chip
+ This init table is copied out of the saa7113 datasheet.
+ In R_08 we enable "Automatic Field Detection" [AUFD],
+ this is disabled when saa711x_set_v4lstd is called. */
+static const unsigned char gm7113c_init[] = {
+ R_01_INC_DELAY, 0x08,
+ R_02_INPUT_CNTL_1, 0xc0,
+ R_03_INPUT_CNTL_2, 0x33,
+ R_04_INPUT_CNTL_3, 0x00,
+ R_05_INPUT_CNTL_4, 0x00,
+ R_06_H_SYNC_START, 0xe9,
R_07_H_SYNC_STOP, 0x0d,
- R_08_SYNC_CNTL, 0x88,
+ R_08_SYNC_CNTL, 0x98, /* AUFD - BIT7 Enabled */
R_09_LUMA_CNTL, 0x01,
R_0A_LUMA_BRIGHT_CNTL, 0x80,
R_0B_LUMA_CONTRAST_CNTL, 0x47,
@@ -245,9 +281,9 @@ static const unsigned char saa7113_init[] = {
R_0D_CHROMA_HUE_CNTL, 0x00,
R_0E_CHROMA_CNTL_1, 0x01,
R_0F_CHROMA_GAIN_CNTL, 0x2a,
- R_10_CHROMA_CNTL_2, 0x08,
+ R_10_CHROMA_CNTL_2, 0x00,
R_11_MODE_DELAY_CNTL, 0x0c,
- R_12_RT_SIGNAL_CNTL, 0x07,
+ R_12_RT_SIGNAL_CNTL, 0x01,
R_13_RT_X_PORT_OUT_CNTL, 0x00,
R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
R_15_VGATE_START_FID_CHG, 0x00,
@@ -1585,6 +1621,85 @@ static const struct v4l2_subdev_ops saa711x_ops = {
/* --- */
+static void saa711x_write_platform_data(struct saa711x_state *state,
+ struct saa7115_platform_data *data)
+{
+ struct v4l2_subdev *sd = &state->sd;
+ u8 work;
+
+ if (state->ident != GM7113C &&
+ state->ident != SAA7113)
+ return;
+
+ if (data->saa7113_r08_htc) {
+ work = saa711x_read(sd, R_08_SYNC_CNTL);
+ work &= ~SAA7113_R_08_HTC_MASK;
+ work |= ((*data->saa7113_r08_htc) << SAA7113_R_08_HTC_OFFSET);
+ if (*data->saa7113_r08_htc != SAA7113_HTC_RESERVED) {
+ v4l2_dbg(1, debug, sd,
+ "set R_08 HTC [Mask 0x%02x] [Value 0x%02x]\n",
+ SAA7113_R_08_HTC_MASK, *data->saa7113_r08_htc);
+ saa711x_write(sd, R_08_SYNC_CNTL, work);
+ }
+ }
+
+ if (data->saa7113_r10_vrln) {
+ work = saa711x_read(sd, R_10_CHROMA_CNTL_2);
+ work &= ~SAA7113_R_10_VRLN_MASK;
+ if (*data->saa7113_r10_vrln)
+
Re: Samsung i2c subdev drivers that set sd->name
Hello, On Thursday 27 June 2013 11:53:15 Sylwester Nawrocki wrote: > On 06/27/2013 08:43 AM, Hans Verkuil wrote: > > On Wed June 26 2013 11:00:51 Sakari Ailus wrote: > >> On Tue, Jun 25, 2013 at 06:55:49PM +0200, Sylwester Nawrocki wrote: > >>> On 06/24/2013 10:54 AM, Hans Verkuil wrote: > Hi Sylwester, > > It came to my attention that several i2c subdev drivers overwrite the > sd->name as set by v4l2_i2c_subdev_init with a custom name. > > This is wrong if it is possible that there are multiple identical > sensors in the system. The sd->name must be unique since it is used to > prefix kernel messages etc, so you have to be able to tell the sensor > devices apart. > >>> > >>> This has been discussed in the past, please see thread [1]. > >>> > It concerns the following Samsung-contributed drivers: > > drivers/media/i2c/s5k4ecgx.c: strlcpy(sd->name, S5K4ECGX_DRIVER_NAME, > sizeof(sd->name)); drivers/media/i2c/s5c73m3/s5c73m3-core.c: > strlcpy(sd->name, "S5C73M3", sizeof(sd->name)); > drivers/media/i2c/s5c73m3/s5c73m3-core.c: strcpy(oif_sd->name, > "S5C73M3-OIF"); drivers/media/i2c/sr030pc30.c: strcpy(sd->name, > MODULE_NAME); > drivers/media/i2c/noon010pc30.c:strlcpy(sd->name, MODULE_NAME, > sizeof(sd->name)); drivers/media/i2c/m5mols/m5mols_core.c: > strlcpy(sd->name, MODULE_NAME, sizeof(sd->name)); > drivers/media/i2c/s5k6aa.c: strlcpy(sd->name, DRIVER_NAME, > sizeof(sd->name));>>> > >>> It seems ov9650 is missing on this list, > >>> > >>> $ git grep ".*cpy.*(.*sd\|subdev.*name" -- drivers/media/i2c > >>> drivers/media/i2c/m5mols/m5mols_core.c: strlcpy(sd->name, MODULE_NAME, > >>> sizeof(sd->name)); > >>> drivers/media/i2c/noon010pc30.c:strlcpy(sd->name, MODULE_NAME, > >>> sizeof(sd->name)); > >>> drivers/media/i2c/ov9650.c: strlcpy(sd->name, DRIVER_NAME, > >>> sizeof(sd->name)); > >>> drivers/media/i2c/s5c73m3/s5c73m3-core.c: strlcpy(sd->name, > >>> "S5C73M3", sizeof(sd->name)); > >>> drivers/media/i2c/s5c73m3/s5c73m3-core.c: strcpy(oif_sd->name, > >>> "S5C73M3-OIF"); > >>> drivers/media/i2c/s5k4ecgx.c: strlcpy(sd->name, > >>> S5K4ECGX_DRIVER_NAME, sizeof(sd->name)); > >>> drivers/media/i2c/s5k6aa.c: strlcpy(sd->name, > >>> DRIVER_NAME, sizeof(sd->name)); > >>> drivers/media/i2c/smiapp/smiapp-core.c: subdev->name, > >>> code->pad, code->index); > >>> drivers/media/i2c/smiapp/smiapp-core.c: strlcpy(subdev->name, > >>> sensor->minfo.name, sizeof(subdev->name)); > >> > >> For smiapp the issue is that smiapp is the name of the driver; there's no > >> sensor which would be called "smiapp" but a large number of different > >> devices that implement the SMIA or SMIA++ standard. The driver can > >> recognise some of them and call them according to their real name. > > > > But the smiapp driver can still prefix that real name with the i2c bus > > info, right? Just as v4l2_i2c_subdev_init does. Do you mean postfix instead of prefix ? > >>> drivers/media/i2c/sr030pc30.c: strcpy(sd->name, MODULE_NAME); > >>> drivers/media/i2c/tvp514x.c:strlcpy(sd->name, TVP514X_MODULE_NAME, > >>> sizeof(sd->name)); > >>> > If there can be only one sensor (because it is integrated in the SoC), > then there is no problem with doing this. But it is not obvious to me > which of these drivers are for integrated systems, and which aren't. > >>> > >>> Those sensors are standalone devices, I'm not aware of any of them to be > >>> integrated with an Application Processor SoC. I've never seen something > >>> like that. However some of those devices are hybrid modules with a raw > >>> image sensor and an ISP SoC. > >>> So in theory there could be multiple such devices in a single system, > >>> although personally I've never seen something like that. > >>> > I can make patches for those that need to be fixed if you can tell me > which drivers are affected. > >>> > >>> You may want to have a look at the commits listed below, and the > >>> comments I received to that [2] patch series... > > > > What comments? I see no comments. > > Yes, that's the point :) IMHO it's a bit late for reverting that, and > breaking existing user space. > > > I would have Nacked those patches, but I probably never saw them since you > > posted them during a period where I was mostly absent from the list. > > Fair enough. > > >>> commit 2138d73b69be1cfa4982c9949f2445ec77ea9edc > >>> [media] noon010pc30: Make subdev name independent of the I2C slave > >>> address > >>> > >>> commit 14b702dd71d38b6d0662251b3f8cd60da98602ce > >>> [media] s5k6aa: Make subdev name independent of the I2C slave address > >>> > >>> commit c5024a70bb60b678f08586ed786340ec162d250f > >>> [media] m5mols: Make subdev name independent of the I2C slave address > >>> > >>> Before we start messing with those drivers it would be nic
Re: Question: interaction between selection API, ENUM_FRAMESIZES and S_FMT?
Hi Hans, On Tue, Jun 25, 2013 at 11:02:51AM +0200, Hans Verkuil wrote: > On Tue 25 June 2013 10:21:19 Sakari Ailus wrote: > > Hi Hans, > > > > On Mon, Jun 24, 2013 at 02:48:15PM +0200, Hans Verkuil wrote: > > > Hi all, > > > > > > While working on extending v4l2-compliance with cropping/selection test > > > cases > > > I decided to add support for that to vivi as well (this would give > > > applications > > > a good test driver to work with). > > > > > > However, I ran into problems how this should be implemented for V4L2 > > > devices > > > (we are not talking about complex media controller devices where the video > > > pipelines are setup manually). > > > > > > There are two problems, one related to ENUM_FRAMESIZES and one to S_FMT. > > > > > > The ENUM_FRAMESIZES issue is simple: if you have a sensor that has several > > > possible frame sizes, and that can crop, compose and/or scale, then you > > > need > > > to be able to set the frame size. Currently this is decided by S_FMT which > > > > Sensors have a single "frame size". Other sizes are achieved by using > > cropping and scaling (or binning) from the native pixel array size. The > > drivers should probably also expose these properties rather than advertise > > multiple frame sizes. > > The problem is that from the point of view of a generic application you really > don't want to know about that. You have a number of possible framesizes and > you > just want to pick one. > > Also, the hardware may hide how each framesize was achieved and in the case of > vivi or mem2mem devices things are even murkier. > > > > maps the format size to the closest valid frame size. This however makes > > > it impossible to e.g. scale up a frame, or compose the image into a larger > > > buffer. > > > > > > For video receivers this issue doesn't exist: there the size of the > > > incoming > > > video is decided by S_STD or S_DV_TIMINGS, but no equivalent exists for > > > sensors. > > > > > > I propose that a new selection target is added: V4L2_SEL_TGT_FRAMESIZE. > > > > The smiapp (well, subdev) driver uses V4L2_SEL_TGT_CROP_BOUNDS rectangle for > > this purpose. It was agreed to use that instead of creating a separate > > "pixel array size" rectangle back then. Could it be used for the same > > purpose on video nodes, too? If not, then smiapp should also be switched to > > use the new "frame size" rectangle. > > The problem with CROP_BOUNDS is that it may be larger than the actual > framesize, > as it can include blanking (for video) or the additional border pixels in a > sensor. I don't think it should include anything else than just the image. Blanking isn't valid image data, and I'd also leave any possible borders out: this is hardly interesting to the user, nor is really part of the image. That's what the user expects, right? The rest can't be meaningfully processed in anyway by hardware blocks, which would mix badly with configuring the pipeline from the user space. A lower level mechanism is needed: frame descriptors. > I would prefer a new selection target for this. It was decided to use the crop bounds for the purpose a few years back, and I don't see a need to change it. (I actually was for having such a rectangle back then, but the rough concensus was different. :)) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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 0/2] V4L2 OF fixes
On 07/03/2013 12:52 PM, Laurent Pinchart wrote: Hello, Here are two small fixes for the V4L2 OF parsing code. The patches should be self-explanatory. Hi Laurent, Thank you for fixing what I've messed up in the Guennadi's original patch. For both patches: Acked-by: Sylwester Nawrocki Laurent Pinchart (2): v4l: of: Use of_get_child_by_name() v4l: of: Drop acquired reference to node when getting next endpoint drivers/media/v4l2-core/v4l2-of.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) Thanks, Sylwester -- 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] [media] hdpvr: fix iteration over uninitialized lists in hdpvr_probe()
free_buff_list and rec_buff_list are initialized in the middle of hdpvr_probe(),
but if something bad happens before that, error handling code calls
hdpvr_delete(),
which contains iteration over the lists (via hdpvr_free_buffers()).
The patch moves the lists initialization to the beginning and by the way fixes
goto label in error handling of registering videodev.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/media/usb/hdpvr/hdpvr-core.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/hdpvr/hdpvr-core.c
b/drivers/media/usb/hdpvr/hdpvr-core.c
index 8247c19..77d7b7f 100644
--- a/drivers/media/usb/hdpvr/hdpvr-core.c
+++ b/drivers/media/usb/hdpvr/hdpvr-core.c
@@ -311,6 +311,11 @@ static int hdpvr_probe(struct usb_interface *interface,
dev->workqueue = 0;
+ /* init video transfer queues first of all */
+ /* to prevent oops in hdpvr_delete() on error paths */
+ INIT_LIST_HEAD(&dev->free_buff_list);
+ INIT_LIST_HEAD(&dev->rec_buff_list);
+
/* register v4l2_device early so it can be used for printks */
if (v4l2_device_register(&interface->dev, &dev->v4l2_dev)) {
dev_err(&interface->dev, "v4l2_device_register failed\n");
@@ -333,10 +338,6 @@ static int hdpvr_probe(struct usb_interface *interface,
if (!dev->workqueue)
goto error;
- /* init video transfer queues */
- INIT_LIST_HEAD(&dev->free_buff_list);
- INIT_LIST_HEAD(&dev->rec_buff_list);
-
dev->options = hdpvr_default_options;
if (default_video_input < HDPVR_VIDEO_INPUTS)
@@ -413,7 +414,7 @@ static int hdpvr_probe(struct usb_interface *interface,
video_nr[atomic_inc_return(&dev_nr)]);
if (retval < 0) {
v4l2_err(&dev->v4l2_dev, "registering videodev failed\n");
- goto error;
+ goto reg_fail;
}
/* let the user know what node this device is now attached to */
--
1.8.1.2
--
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: [DTV Update] Re: Änderung der Sendefrequenzen bei KabelBW
Pushed to the dtv-scan-tables tree. A package should be generated thanks to mauro soon, so if packagers download tomorrow, or pull from git now, they have the new version. On 07/03/13 20:32, Dirk Ritter wrote: Hello Oliver! :-) Am Mittwoch, den 03.07.2013, 19:54 +0200 schrieb Oliver Schinagl: Ich habe in der Datei in dieser Datei die einzig relevante Zeile von "C 11300 690 NONE QAM64" auf "C 11400 690 NONE QAM256" korrigieren müssen, so dass der Scan wieder geklappt hat. It looks like they changed frequencies. Yes. Their site confirms that a big changeover happened in June. I have staged this commit and will push it tomorrow unless anybody objects, Dirk, can you confirm/deny this being correct? It is correct. I got an e-mail from Martin Klar who lives in a KabelBW area that got the change earlier than mine. I did wait for the change and can positively confirm it. Based on data available (I did try to make sense of his change beforehand) and based on testing done using Kaffeine just after KabelBW changed it in Stuttgart. I already have it in my private repo [0] Life took it's toll, so I didn't manage to forward this. Martin already tried without any luck and that's why he contacted me so that I could try. It was a rather difficult story back then I first cooked it up since there was disagreement between documents floating around and actual frequencies used and as a result of further difficulties with different tables for different service levels we concluded it would be best to just have one frequency, especially since that worked across both levels, i.e. for both fully and partly populated network areas within KabelBW. I guess Martin would love to see the file changed as he did, see attachment... ;-) BTW - what about Kaffeeine? How do they handle it? I just changed it locally and it works, but I don't think they did update it either. They probably maintain their own (bad). Hopefully, this will propagate fast... Cheers! Dirk oliver -- 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: [RFC] Support for events with a large payload
On Wednesday 03 July 2013 02:01:59 Sakari Ailus wrote: > On Mon, Jun 24, 2013 at 03:40:14PM +0200, Hans Verkuil wrote: > ... > > > Since the payloads are larger I am less concerned about speed. There is > > one problem, though: if you dequeue the event and the buffer that should > > receive the payload is too small, then you have lost that payload. You > > can't allocate a new, larger, buffer and retry. So this approach can only > > work if you really know the maximum payload size. > > > > The advantage is also that you won't lose payloads. > > Forgot to answer this one --- I think it's fair to assume the user knows the > maximum size of the payload. What we also could do in such a case is to > return the error (e.g. ENOSPC) and put the required size to the large event > size field. But first someone must come up with a variable size event > without well defined maximum size for this to make much sense. And while we're discussing use cases, Hans, what are you current use cases for >64 bytes event payloads ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
scan file change needed for de-Kabel_BW
Hello! According to Martin Klar, the scan file for de-Kabel_BW needs to get changed. I verified his change beforehand based on documents from KabelBW and an external help desk and later on, when KabelBW actually changed it in my city, on actual usage with Kaffeine and can positively confirm it. See attachment for the update. Kind Regards, Dirk # Kabel-BW, Stand 04/2007 # # Nur eine Anfangsfrequenz ist noetig, um den Ball ins # Rollen zu bringen. Quasi als Einstiegspunkt fuer eine # umfassende Suche. Es besteht kein Grund, sich um all die # vielen anderen Frequenzen und deren aktuell verwendete # Parameter zu kuemmern und diese dann womoeglich auch # noch auf einem aktuellen Stand halten zu wollen. Bei der # schieren Anzahl der innerhalb des Ausbaugebiets durch # Kabel BW genutzten Frequenzen waere das nur zeitraubend # und fehleranfaellig... ;-) # # Dirk Ritter # # Kabel-BW, Stand 06/2013 # # Anpassung nach DVB-C Aenderung von Kabelbw # # # Martin Klar # # freq sr fec mod C 11400 690 NONE QAM256
Technisat SkyStar USB HD & DiSEqC motor
Hello. I've been viewing FTA satellite for a few years using an up-to-date ubuntu distro and a Technisat SkyStar USB HD; http://www.linuxtv.org/wiki/index.php/Technisat_SkyStar_USB_HD Recently I decided to upgrade my setup and try out a DiSEqC motor on my dish. Cdtronix NH-210 DiSEqC 1.2 Motor http://cdtronix.com/motorised/new-horizons-nh-210-diseqc-1.2-motor I am able to view/switch channels with the rotor inline between my SkyStar and LNB on the dish, which suggests to me the cabling is all good. However I cannot get the rotor to rotate. I've used the 'gotox' util avaiable from dvb-apps and also 'rotor' from this source https://svn.tuxicoman.be/filedetails.php?repname=dvbgyver&path=%2Ftrunk%2Frotor.c as suggested by 'GMsoft' in the #linuxtv room on irc.freenode.net Both utils seem to supply power to the rotor but they never rotate it. Whilst they supply power I can press manual buttons on the device to rotate East/West which tells me the rotor is receiving enough power. I upped the verbosity of stv090x.ko which is itself loaded by dvb_usb_technisat_usb2.ko Patrick Boettch the author of dvb_usb_technisat_usb2 told me it used stv090x for DiSEqC commands & suggested I shout out on this mailing list. Here are a few logs from my syslog (verbosity of stv090x upped to 5). Inital loading of device. (Works as I can view satellite tv) http://bpaste.net/show/qFEde74lwn4cFquli0cx/ Command '# ./rotor -t 5 limits_off' - seems to return quickly. http://bpaste.net/show/EskG9QAFjTbevReVcYVm/ Command '# ./rotor -t 30 goto_x 28.2e' - DOESN'T ROTOTE ROTOR!! ;( http://bpaste.net/show/uJBtLqQA3VVnmCTebOPz/ Command '# ./rotor -t 5 stop' - seems to return quickly, its not moving anyway right? http://bpaste.net/show/eR1GmJnOWOQhFDlM4oMv/ The 'gotox' from dvb-app doesn't ever move it either. I've used numerous different bits of cabling to eliminate that also. Hoping somebody can suggest something either to fix or help debug futher. Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jul 3 19:00:28 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API 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
[DTV Update] Re: Änderung der Sendefrequenzen bei KabelBW
On 07/03/13 18:35, Hermann Ulrichskötter wrote: Hallo Oliver, Hi Hermann, ich bin am Wochenende bei der TVHeadend-Installation auf meiner Synology über das Problem gestolpert, dass die Kanäle von Kabel-BW nicht mehr gescannt wurden. Kabel-BW hatte am Donnerstag hier in Freiburg einige Sendefrequenzen geändert, so dass die Datei tvheadend/share/tvheadend/data/dvb-scan/dvb-c/de-Kabel_BW nicht mehr korrekt ist. Ich habe in der Datei in dieser Datei die einzig relevante Zeile von "C 11300 690 NONE QAM64" auf "C 11400 690 NONE QAM256" korrigieren müssen, so dass der Scan wieder geklappt hat. It looks like they changed frequencies. Their site confirms that a big changeover happened in June. I have staged this commit and will push it tomorrow unless anybody objects, Dirk, can you confirm/deny this being correct? I already have it in my private repo [0] Vielleicht sollte die Datei in dtv-scan-tables/dvb-c entsprechend angepasst werden? Die neue Frequenzbelegung findet sich hier: https://www.kabelbw.de/kabelbw/cms/downloads/kabel-bw-programmuebersicht.pdf Schönen Gruß, Hermann Thank you for the information, Oliver [0] http://git.schinagl.nl/cgi-bin/cgit.cgi/dtv-scan-tables.git/commit/?id=d913405dec10c60e852c55e77dc115ca94a2b74c -- 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] usbtv: fix dependency
On 06/28/13 10:54, Mauro Carvalho Chehab wrote: > Em Fri, 28 Jun 2013 10:55:15 -0300 > Mauro Carvalho Chehab escreveu: > >>> This patch >>> >>> http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/commitdiff/a92d0222c693db29a5d00eaedcdebf748789c38e >>> >>> has been pushed 3 days ago: >>> >>> https://patchwork.linuxtv.org/patch/19090/ >> >> As, according with: >> https://lwn.net/Articles/556034/rss >> >> -rc7 is likely the last one before 3.10, that means that the media merge >> window for 3.11 is closed already (as we close it one week before, in order >> to give more time for reviewing the patches better at -next). >> >> So, please split the fix patches from it on a separate pull request. > > Hmm... just took a look at the actual pull request... from the description, > it seems to contain just fixes/documentation, so, I'll be handling it > in a few. Has this patch been merged yet? If so, where? This build failure is still occurring in linux-next-20130703. thanks, -- ~Randy -- 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: drivers:media:tuners:fc2580c fix for Asus U3100Mini Plus error while loading driver (-19)
i don't know how to "sniff" the usb port. if you want i can give you root access to the machine with the device plugged into it. it's a raspberry pi with raspbian wheezy. From: Antti Palosaari To: Oliver Schinagl Cc: Bogdan Oprea ; "linux-media@vger.kernel.org" Sent: Tuesday, July 2, 2013 10:55 PM Subject: Re: drivers:media:tuners:fc2580c fix for Asus U3100Mini Plus error while loading driver (-19) On 07/02/2013 10:04 AM, Oliver Schinagl wrote: > On 02-07-13 00:37, Antti Palosaari wrote: >> On 07/02/2013 12:03 AM, Oliver Schinagl wrote: >>> On 07/01/13 22:51, Antti Palosaari wrote: On 07/01/2013 11:39 PM, Oliver Schinagl wrote: > On 07/01/13 15:26, Oliver Schinagl wrote: >> On 01-07-13 15:23, Antti Palosaari wrote: >>> On 07/01/2013 10:52 AM, Oliver Schinagl wrote: On 01-07-13 08:53, Bogdan Oprea wrote: > this is a fix for this type of error > > [18384.579235] usb 6-5: dvb_usb_v2: 'Asus U3100Mini Plus' error > while > loading driver (-19) > [18384.580621] usb 6-5: dvb_usb_v2: 'Asus U3100Mini Plus' > successfully > deinitialized and disconnected > This isn't really a fix, I think i mentioned this on the ML ages ago, >>> >>> Argh, I just replied that same. Oliver, do you has that same >>> device? Is >>> it working? Could you tweak to see if I2C readings are working at >>> all? >> I have the same device, but mine works normally (though I haven't >> checked for ages), I will try it tonight when I'm at home and don't >> forget what happens with my current kernel. > > Hard to test when it 'just works (tm)' :) > The bad firmware wories me, no clue where that error is from, using: > 862604ab3fec0c94f4bf22b4cffd0d89 /lib/firmware/dvb-usb-af9035-02.fw It means firmware is too short or long what is calculated. I added that printing to notify users firmware is broken and could cause problems. >>> Ah, good call, it did get me to re-download it. no clue why it was >>> broken all of a sudden. I suspect it is same issue what is with MxL5007t tuners too. Maybe that kind of fix is needed: https://patchwork.kernel.org/patch/2418471/ Someone should really find out whether or not these are coming with register read operation with REPEATED START of STOP condition. Attach hardware sniffer to device tuner I2C bus and look what kind of messages there is actually. >>> Well mine works fine, so hard to say. IF you have a buspirate you should >>> be able to intercept the i2c bus ON the device though :) Good luck >>> Bogdan, I wish I could help here, but lack the broken hardware. >> >> I have one AF9035 + FC0012 device having similar problems. Unfortunately >> I wasn't able to detect I2C bus to take capture using Bus Pirate. > Actually, I have the af9035b (see the picture i uploaded to the wiki) >> >> There seems to be two revisions of AF9035 chips, AF9035A and AF9035B. I >> suspect it is newer B version which has these problems. I also visually >> compared to A and B versions and I suspect pinout is different. >> >> Could you take USB sniffs from that device? Just install sniffer (like >> SniffUSB), tune to channel and stop immediately when there is picture. >> FC2580 driver does some register reads, so it should be possible to see >> what is correct I2C access format by looking sniffs. > Of my working version? I can try, i'll see if I have time to work with > sniffusb, but if I load the driver from linux, won't we already know > whats on the USB bus? If you speak of windows, I don't have that. I wonder if Bogdan could took the sniffs as his device has the problems. My FC0012 sniffs are useless as FC0012 windows does not any register reads. Your sniffs could be also handy, better than nothing, even likely produce just same logs as Bogdan (I suspect it is issue AF9035A vs AF9035B). >> Here is few good pictures from my problematic AF9035B + FC0012 device. >> If someone could say which are FC0012 I2C pins, I could use Pirate to >> check (as that device has same problem). >> http://blog.palosaari.fi/2013/05/naked-hardware-8-cabletech-urz0185.html >> >> regards >> Antti >> > Antti -- http://palosaari.fi/ -- 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/2] v4l: of: Use of_get_child_by_name()
Replace a manual loop through child nodes with a call to
of_get_child_by_name().
Signed-off-by: Laurent Pinchart
---
drivers/media/v4l2-core/v4l2-of.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..f64d953 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -173,12 +173,8 @@ struct device_node *v4l2_of_get_next_endpoint(const struct
device_node *parent,
if (node)
parent = node;
- for_each_child_of_node(parent, node) {
- if (!of_node_cmp(node->name, "port")) {
- port = node;
- break;
- }
- }
+ port = of_get_child_by_name(parent, "port");
+
if (port) {
/* Found a port, get an endpoint. */
endpoint = of_get_next_child(port, NULL);
--
1.8.1.5
--
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/2] v4l: of: Drop acquired reference to node when getting next endpoint
The of_get_child_by_name() function takes a reference to the node it
returns. Make sure to drop it when looking for the ports node in
v4l2_of_get_next_endpoint().
Signed-off-by: Laurent Pinchart
---
drivers/media/v4l2-core/v4l2-of.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index f64d953..ed305d8 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -186,6 +186,7 @@ struct device_node *v4l2_of_get_next_endpoint(const struct
device_node *parent,
if (!endpoint)
pr_err("%s(): no endpoint nodes specified for %s\n",
__func__, parent->full_name);
+ of_node_put(node);
} else {
port = of_get_parent(prev);
if (!port)
--
1.8.1.5
--
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 0/2] V4L2 OF fixes
Hello, Here are two small fixes for the V4L2 OF parsing code. The patches should be self-explanatory. Laurent Pinchart (2): v4l: of: Use of_get_child_by_name() v4l: of: Drop acquired reference to node when getting next endpoint drivers/media/v4l2-core/v4l2-of.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
