[PATCH v2] media: adv7343: accept configuration through platform data
From: Lad, Prabhakar
The current code was implemented with some default configurations,
this default configuration works on board and doesn't work on other.
This patch accepts the configuration through platform data and configures
the encoder depending on the data passed.
Signed-off-by: Lad, Prabhakar
Cc: Hans Verkuil
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
---
Changes for v2:
1: Fixed review comments pointed by Hans.
drivers/media/i2c/adv7343.c | 36 +
include/media/adv7343.h | 52 +++
2 files changed, 83 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index 2b5aa67..a058058 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -43,6 +43,7 @@ MODULE_PARM_DESC(debug, "Debug level 0-1");
struct adv7343_state {
struct v4l2_subdev sd;
struct v4l2_ctrl_handler hdl;
+ const struct adv7343_platform_data *pdata;
u8 reg00;
u8 reg01;
u8 reg02;
@@ -215,12 +216,23 @@ static int adv7343_setoutput(struct v4l2_subdev *sd, u32
output_type)
/* Enable Appropriate DAC */
val = state->reg00 & 0x03;
- if (output_type == ADV7343_COMPOSITE_ID)
- val |= ADV7343_COMPOSITE_POWER_VALUE;
- else if (output_type == ADV7343_COMPONENT_ID)
- val |= ADV7343_COMPONENT_POWER_VALUE;
+ /* configure default configuration */
+ if (!state->pdata)
+ if (output_type == ADV7343_COMPOSITE_ID)
+ val |= ADV7343_COMPOSITE_POWER_VALUE;
+ else if (output_type == ADV7343_COMPONENT_ID)
+ val |= ADV7343_COMPONENT_POWER_VALUE;
+ else
+ val |= ADV7343_SVIDEO_POWER_VALUE;
else
- val |= ADV7343_SVIDEO_POWER_VALUE;
+ val = state->pdata->mode_config.sleep_mode << 0 |
+ state->pdata->mode_config.pll_control << 1 |
+ state->pdata->mode_config.dac_3 << 2 |
+ state->pdata->mode_config.dac_2 << 3 |
+ state->pdata->mode_config.dac_1 << 4 |
+ state->pdata->mode_config.dac_6 << 5 |
+ state->pdata->mode_config.dac_5 << 6 |
+ state->pdata->mode_config.dac_4 << 7;
err = adv7343_write(sd, ADV7343_POWER_MODE_REG, val);
if (err < 0)
@@ -238,6 +250,17 @@ static int adv7343_setoutput(struct v4l2_subdev *sd, u32
output_type)
/* configure SD DAC Output 2 and SD DAC Output 1 bit to zero */
val = state->reg82 & (SD_DAC_1_DI & SD_DAC_2_DI);
+
+ if (state->pdata && state->pdata->sd_config.sd_dac_out1)
+ val = val | (state->pdata->sd_config.sd_dac_out1 << 1);
+ else if (state->pdata && !state->pdata->sd_config.sd_dac_out1)
+ val = val & ~(state->pdata->sd_config.sd_dac_out1 << 1);
+
+ if (state->pdata && state->pdata->sd_config.sd_dac_out2)
+ val = val | (state->pdata->sd_config.sd_dac_out2 << 2);
+ else if (state->pdata && !state->pdata->sd_config.sd_dac_out2)
+ val = val & ~(state->pdata->sd_config.sd_dac_out2 << 2);
+
err = adv7343_write(sd, ADV7343_SD_MODE_REG2, val);
if (err < 0)
goto setoutput_exit;
@@ -401,6 +424,9 @@ static int adv7343_probe(struct i2c_client *client,
if (state == NULL)
return -ENOMEM;
+ /* Copy board specific information here */
+ state->pdata = client->dev.platform_data;
+
state->reg00= 0x80;
state->reg01= 0x00;
state->reg02= 0x20;
diff --git a/include/media/adv7343.h b/include/media/adv7343.h
index d6f8a4e..944757b 100644
--- a/include/media/adv7343.h
+++ b/include/media/adv7343.h
@@ -20,4 +20,56 @@
#define ADV7343_COMPONENT_ID (1)
#define ADV7343_SVIDEO_ID (2)
+/**
+ * adv7343_power_mode - power mode configuration.
+ * @sleep_mode: on enable the current consumption is reduced to micro ampere
+ * level. All DACs and the internal PLL circuit are disabled.
+ * Registers can be read from and written in sleep mode.
+ * @pll_control: PLL and oversampling control. This control allows internal
+ * PLL 1 circuit to be powered down and the oversampling to be
+ * switched off.
+ * @dac_1: power on/off DAC 1.
+ * @dac_2: power on/off DAC 2.
+ * @dac_3: power on/off DAC 3.
+ * @dac_4: power on/off DAC 4.
+ * @dac_5: power on/off DAC 5.
+ * @dac_6: power on/off DAC 6.
+ *
+ * Power mode register (Register 0x0), for more info refer REGISTER MAP ACCESS
+ * section of datasheet[1], table 17 page no 30.
+ *
+ * [1] http://www.analog.com/static/imported-files/data_sheets/ADV7342_7343.pdf
+ */
+struct adv7343_power_mode {
+ bool sleep_mode;
+ bool pll_control;
+ bool dac_1;
+ bool dac_2;
+ bool dac_3;
+
[PATCH 1/1] [media] s5p-mfc: Use WARN_ON(condition) directly
Use WARN_ON(condition) directly instead of wrapping around an if condition. Signed-off-by: Sachin Kamat --- drivers/media/platform/s5p-mfc/s5p_mfc.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index b1d7f9a..37a17b8 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -596,8 +596,7 @@ static void s5p_mfc_handle_stream_complete(struct s5p_mfc_ctx *ctx, clear_work_bit(ctx); - if (test_and_clear_bit(0, &dev->hw_lock) == 0) - WARN_ON(1); + WARN_ON(test_and_clear_bit(0, &dev->hw_lock) == 0); s5p_mfc_clock_off(); wake_up(&ctx->queue); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/15] media: coda: don't build on multiplatform
On Mon, Jan 21, 2013 at 05:16:02PM +, Arnd Bergmann wrote: > The coda video codec driver depends on a mach-imx or mach-mxs specific > header file "mach/iram.h". This is not available when building for > multiplatform, so let us disable this driver for v3.8 when building > multiplatform, and hopefully find a proper fix for v3.9. > > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file > or directory > > Signed-off-by: Arnd Bergmann > Cc: Javier Martin > Cc: Fabio Estevam > Cc: Sascha Hauer > Cc: Shawn Guo Acked-by: Shawn Guo > Cc: Mauro Carvalho Chehab > Cc: linux-media@vger.kernel.org > --- > drivers/media/platform/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 3dcfea6..049d2b2 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS > > config VIDEO_CODA > tristate "Chips&Media Coda multi-standard codec IP" > - depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC > + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM > select VIDEOBUF2_DMA_CONTIG > select V4L2_MEM2MEM_DEV > select IRAM_ALLOC if SOC_IMX53 > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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] OMAP3 ISP: Simplify clock usage
On Mon, 21 Jan 2013, Laurent Pinchart wrote: > OK. The omap3isp patch can go through Paul's tree as well, it won't conflict > with other changes to the driver in this merge window. > > Paul, can you take both patches together ? If so I'll send you a pull request. Yes I'll take them, as long as they won't cause conflicts outside of arch/arm/mach-omap2. Otherwise the OMAP3 ISP patch should wait until the early v3.9-rc integration fixes timeframe. - Paul -- 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 01/24] use IS_ENABLED() macro
Hans de Goede wrote: > Thanks for the patches I'll pick up 5 - 21 and add them to > my tree for Mauro. Ack on patch 1, BTW. Thanks, Jonathan -- 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: ERRORS
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:Mon Jan 21 19:00:16 CET 2013 git hash:3151d14aa6e983aa36d51a80d0477859f9ba12af gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: WARNINGS linux-3.8-rc1-i686: OK linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: WARNINGS linux-3.8-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: 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: V4L2 spec / core questions
On Mon January 21 2013 22:25:37 Frank Schäfer wrote: > Hi Hans, > > Am 21.01.2013 09:59, schrieb Hans Verkuil: > > On Sun January 20 2013 22:15:51 Frank Schäfer wrote: > >> Hi Hans, > >> > >> I noticed that there's code in the v4l2 core that enables/disables > >> ioctls and checks some of the parameters depending on the device type. > >> While reading the code an comparing it to the V4L2 API document, some > >> more questions came up: > >> > >> 1) Video devices with VBI functionality: > >> The spec says: "To address the problems of finding related video and VBI > >> devices VBI capturing and output is also available as device function > >> under /dev/video". > >> Is that still valid ? > > No, that's not valid. It really was never valid: most drivers didn't > > implement > > this, and those that did likely didn't work. During one of the media summits > > we decided not to allow this. Allowing VBI functionality in video node has a > > number of problems: > > > > 1) it's confusing: why have a vbi node at all if you can do it with a video > > node as well? > > Yeah, although I think the problem described in the spec document is real. > No idea how good applications are in finding the correct VBI device > belonging to a specific video device node... > > Hmm... yeah... why have separate device nodes at all ? We could provide > the same functionality with a single device node (e.g. /dev/multimediaX). > I assume separation into radio / video / vbi device nodes gears towards > typical feature sets of applications. > Probably something to think about for V4L3... ;) This is an ongoing issue for many years. Laurent and Sakari are working on a library that apps can call that tries to find these related devices. For drivers that implement the media controller API the MC device can be used to obtain this information. > > In fact, applications always use the vbi node for vbi data. > > > > 2) it breaks down when you want to read() the data: read() can handle only > > one 'format' at a time. So if you want to read both video and vbi at the > > same > > time then you need to nodes. > > Ouch, yes ! > Ok, so the traditional read() concept is probably the _real_ reason for > having separate device nodes... > > > 3) it makes drivers quite complex: separating this functionality in distinct > > nodes makes life much easier. > > It looks like the v4l2 core has been improved a lot and now does most of > the work for the driver, so it's probably not that complex anymore. > > >> What about VBI "configuration" (e.g. > >> VIDIOC_G/S/TRY_FMT for VBI formats) ? > >> Looking into the v4l2 core code, it seems that the VBI buffer types > >> (field "type" in struct v4l2_format) are only accepted, if the device is > >> a VBI device. > > That's correct. I've added these checks because drivers often didn't test > > that themselves. It's also much easier to test in the v4l2 core than > > repeating the same test in every driver. > > > >> 2) VIDIOC_G/S/TRY_FMT and VBI devices: > >> The sepc says: "VBI devices must implement both the VIDIOC_G_FMT and > >> VIDIOC_S_FMT ioctl, even if VIDIOC_S_FMT ignores all requests and always > >> returns default parameters as VIDIOC_G_FMT does. VIDIOC_TRY_FMT is > >> optional." What's the reason for this ? Is it still valid ? > > This is still valid (in fact, v4l2-compliance requires the presence of > > TRY_FMT as well as I don't think there is a good reason not to implement > > it). The reason for this is that this simplifies applications: no need to > > test for the presence of S_FMT. > > > >> 3) VIDIOC_S_TUNER: field "type" in struct v4l2_tuner > >> Are radio tuners accessable through video devices (and the other way > >> around) ? > > Not anymore. This used to be possible, although because it was never > > properly tested most drivers probably didn't implement that correctly. > > > > The radio API has always been a bit messy and we have been slowly cleaning > > it up. > > Yeah, I think the most confusing things are input/output/routing > (G/S_INPUT, G/S_AUDIO). > > > > >> Has this field to be set by the application ? > > No, it is filled in by the core based on the device node used. This follows > > the spec which does not require apps to set the type. > > > >> If yes: driver overwrites > >> the value or returns with an error if the type doesn't match the tuner > >> at the requested index ? > >> I wonder if it would make sense to check the tuner type inside the v4l > >> core (like the fmt/buffer type check for G/S_PARM). > >> > >> 4) VIDIOC_DBG_G_CHIP_IDENT: > >> Is it part of CONFIG_VIDEO_ADV_DEBUG just like VIDIOC_DBG_G/S_REGISTER ? > > No. It just returns some chip info, it doesn't access the hardware, so there > > is no need to put it under ADV_DEBUG. > > Ok. I just noticed that in most drivers it's inside the #ifdef > CONFIG_VIDEO_ADV_DEBUG. That's unnecessarily strict. > It also has been renamed from VIDIOC_G_CHIP_IDENT to > VIDIOC_DBG_G_CHIP_IDENT which somehow suggests that it's an adv
Re: Patchwork / Bugzilla update
Am 21.01.2013 14:51, schrieb Mauro Carvalho Chehab: ,,, >> The following kernel bugs can be closed as "resolved - fixed": >> - bug 26572 "rmmod em28xx or unplugging em28xx tv adapter problem" >> => resolved with commit 05fe2175cf87da8a5475aed422bd636475ab0412 >> "em28xx: refactor the code in em28xx_usb_disconnect()" >> - bug 14126 "Audio input for TV mode of Terratec Cinergy 250 is >> misconfigured" >> => resolved with commit 5e8d02bb346d6240b029f1990ddc295d7d59685b >> "em28xx: fix audio input for TV mode of device Terratec Cinergy 250" > Feel free to close them there directly. Unfortunately, I don't have the necessary rights to change bug statuses. :( Regards, Frank -- 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: V4L2 spec / core questions
Hi Hans, Am 21.01.2013 09:59, schrieb Hans Verkuil: > On Sun January 20 2013 22:15:51 Frank Schäfer wrote: >> Hi Hans, >> >> I noticed that there's code in the v4l2 core that enables/disables >> ioctls and checks some of the parameters depending on the device type. >> While reading the code an comparing it to the V4L2 API document, some >> more questions came up: >> >> 1) Video devices with VBI functionality: >> The spec says: "To address the problems of finding related video and VBI >> devices VBI capturing and output is also available as device function >> under /dev/video". >> Is that still valid ? > No, that's not valid. It really was never valid: most drivers didn't implement > this, and those that did likely didn't work. During one of the media summits > we decided not to allow this. Allowing VBI functionality in video node has a > number of problems: > > 1) it's confusing: why have a vbi node at all if you can do it with a video > node as well? Yeah, although I think the problem described in the spec document is real. No idea how good applications are in finding the correct VBI device belonging to a specific video device node... Hmm... yeah... why have separate device nodes at all ? We could provide the same functionality with a single device node (e.g. /dev/multimediaX). I assume separation into radio / video / vbi device nodes gears towards typical feature sets of applications. Probably something to think about for V4L3... ;) > In fact, applications always use the vbi node for vbi data. > > 2) it breaks down when you want to read() the data: read() can handle only > one 'format' at a time. So if you want to read both video and vbi at the same > time then you need to nodes. Ouch, yes ! Ok, so the traditional read() concept is probably the _real_ reason for having separate device nodes... > 3) it makes drivers quite complex: separating this functionality in distinct > nodes makes life much easier. It looks like the v4l2 core has been improved a lot and now does most of the work for the driver, so it's probably not that complex anymore. >> What about VBI "configuration" (e.g. >> VIDIOC_G/S/TRY_FMT for VBI formats) ? >> Looking into the v4l2 core code, it seems that the VBI buffer types >> (field "type" in struct v4l2_format) are only accepted, if the device is >> a VBI device. > That's correct. I've added these checks because drivers often didn't test > that themselves. It's also much easier to test in the v4l2 core than > repeating the same test in every driver. > >> 2) VIDIOC_G/S/TRY_FMT and VBI devices: >> The sepc says: "VBI devices must implement both the VIDIOC_G_FMT and >> VIDIOC_S_FMT ioctl, even if VIDIOC_S_FMT ignores all requests and always >> returns default parameters as VIDIOC_G_FMT does. VIDIOC_TRY_FMT is >> optional." What's the reason for this ? Is it still valid ? > This is still valid (in fact, v4l2-compliance requires the presence of > TRY_FMT as well as I don't think there is a good reason not to implement > it). The reason for this is that this simplifies applications: no need to > test for the presence of S_FMT. > >> 3) VIDIOC_S_TUNER: field "type" in struct v4l2_tuner >> Are radio tuners accessable through video devices (and the other way >> around) ? > Not anymore. This used to be possible, although because it was never > properly tested most drivers probably didn't implement that correctly. > > The radio API has always been a bit messy and we have been slowly cleaning > it up. Yeah, I think the most confusing things are input/output/routing (G/S_INPUT, G/S_AUDIO). > >> Has this field to be set by the application ? > No, it is filled in by the core based on the device node used. This follows > the spec which does not require apps to set the type. > >> If yes: driver overwrites >> the value or returns with an error if the type doesn't match the tuner >> at the requested index ? >> I wonder if it would make sense to check the tuner type inside the v4l >> core (like the fmt/buffer type check for G/S_PARM). >> >> 4) VIDIOC_DBG_G_CHIP_IDENT: >> Is it part of CONFIG_VIDEO_ADV_DEBUG just like VIDIOC_DBG_G/S_REGISTER ? > No. It just returns some chip info, it doesn't access the hardware, so there > is no need to put it under ADV_DEBUG. Ok. I just noticed that in most drivers it's inside the #ifdef CONFIG_VIDEO_ADV_DEBUG. It also has been renamed from VIDIOC_G_CHIP_IDENT to VIDIOC_DBG_G_CHIP_IDENT which somehow suggests that it's an advanced debug feature. > >> In determine_valid_ioctls(), it is placed outside the #ifdef >> CONFIG_VIDEO_ADV_DEBUG section. >> The spec says "Identify the chips on a TV card" but isn't it suitable >> for all device types (radio/video/vbi) ? > That's correct. A patch is welcome :-) To be sure that I understood you correctly: VIDIOC_DBG_G_CHIP_IDENT is suitable for all device types ? Then no patch is needed but the spec document has to be fixed. >> determine_valid_ioctls() in >> v4l2-dev.c enables it for all devices. >> >> 5) The buffer ioct
Re: dvb-usb-it913x dissapeared kernel 3.7.2
Em Mon, 21 Jan 2013 15:47:49 + Mike Martin escreveu: > After updating the kernel on Fedora 18 module dvb-usb-it913x seems to > have dissapeared. > > This has meant my dvb stick ( ID 1b80:e409 Afatech IT9137FN Dual DVB-T > [KWorld UB499-2T]) no longer works > > Is this a Redhat only thing or is it upstream See this bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895460 Basically, DVB_USB_V2 wasn't selected. The kernel-3.7.2-204.fc18 should fix this issue. > -- > 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 -- Cheers, Mauro -- 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] OMAP3 ISP: Simplify clock usage
Quoting Laurent Pinchart (2013-01-21 10:54:38) > Hi Tony, > > On Monday 21 January 2013 09:18:12 Tony Lindgren wrote: > > * Laurent Pinchart [130121 05:37]: > > > On Monday 14 January 2013 17:10:15 Mike Turquette wrote: > > > > Quoting Laurent Pinchart (2013-01-08 05:43:52) > > > > > > > > > Hello, > > > > > > > > > > Now that the OMAP3 supports the common clock framework, clock rate > > > > > back-propagation is available for the ISP clocks. Instead of setting > > > > > the cam_mclk parent clock rate to control the cam_mclk clock rate, we > > > > > can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting > > > > > back-propagation, and set the cam_mclk rate directly. This simplifies > > > > > the ISP clocks configuration. > > > > > > > > I'm pleased to see this feature get used on OMAP. Plus your driver gets > > > > a negative diffstat :) > > > > > > > > Reviewed-by: Mike Turquette > > > > > > Thanks. > > > > > > Would you like to take the arch/ patch in your tree, or should I push it > > > through the linux-media tree along with the omap3isp patch ? > > > > The arch/arm/*omap* clock changes need to be queued by Paul to avoid > > potential stupid merge conflicts when the clock data gets moved to > > live under drivers/clk/omap. > > OK. The omap3isp patch can go through Paul's tree as well, it won't conflict > with other changes to the driver in this merge window. > > Paul, can you take both patches together ? If so I'll send you a pull request. > +1 I don't take in driver changes/adaptations through the clk tree unless it is necessary to avoid painful conflicts or merge ordering issues. This has only happened a few times for MFD devices, etc. Typically the clk-next branch is only used for changes to the clk framework core or clk drivers. Regards, Mike > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 ISP: Simplify clock usage
Hi Tony, On Monday 21 January 2013 09:18:12 Tony Lindgren wrote: > * Laurent Pinchart [130121 05:37]: > > On Monday 14 January 2013 17:10:15 Mike Turquette wrote: > > > Quoting Laurent Pinchart (2013-01-08 05:43:52) > > > > > > > Hello, > > > > > > > > Now that the OMAP3 supports the common clock framework, clock rate > > > > back-propagation is available for the ISP clocks. Instead of setting > > > > the cam_mclk parent clock rate to control the cam_mclk clock rate, we > > > > can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting > > > > back-propagation, and set the cam_mclk rate directly. This simplifies > > > > the ISP clocks configuration. > > > > > > I'm pleased to see this feature get used on OMAP. Plus your driver gets > > > a negative diffstat :) > > > > > > Reviewed-by: Mike Turquette > > > > Thanks. > > > > Would you like to take the arch/ patch in your tree, or should I push it > > through the linux-media tree along with the omap3isp patch ? > > The arch/arm/*omap* clock changes need to be queued by Paul to avoid > potential stupid merge conflicts when the clock data gets moved to > live under drivers/clk/omap. OK. The omap3isp patch can go through Paul's tree as well, it won't conflict with other changes to the driver in this merge window. Paul, can you take both patches together ? If so I'll send you a pull request. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] tda8290: Allow disabling I2C gate
On Monday 21 January 2013 10:06:01 Antti Palosaari wrote:
> On 01/21/2013 10:18 AM, Ondrej Zary wrote:
> > On Monday 21 January 2013, Antti Palosaari wrote:
> >> On 01/20/2013 11:22 PM, Ondrej Zary wrote:
> >>> Allow disabling I2C gate handling by external configuration.
> >>> This is required by cards that have all devices on a single I2C bus,
> >>> like AverMedia A706.
> >>
> >> My personal opinion is that I2C gate control should be disabled setting
> >> callback to NULL (same for the other unwanted callbacks too). There is
> >> checks for callback existence in DVB-core, it does not call callback if
> >> it is NULL.
> >
> > This is TDA8290 internal I2C gate which is used by tda8290 internally and
> > also by tda827x or tda18271.
>
> That sounds like there is some logical problems in the driver then, not
> split correctly?
>
> What I think, scenario is tda8290 is analog decoder, tda18271 is silicon
> tuner, which is connected (usually) to the tda8290 I2C bus. tda18271
> calls tda8290 I2C-gate control when needed. Analog or digital demod
> should not call its own I2C gate directly - and if it was done in some
> weird reason then it should call own callback conditionally, checking
> whether or not it is NULL.
Something like this? It seems to work for both cases (I2C gate control
enabled and disabled) - tested with Pinnacle PCTV 110i and this AverMedia
A706.
---
drivers/media/tuners/tda8290.c | 49 +++
drivers/media/tuners/tda8290.h |1 +
2 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
index 8c48521..a2b7a9f 100644
--- a/drivers/media/tuners/tda8290.c
+++ b/drivers/media/tuners/tda8290.c
@@ -233,7 +233,8 @@ static void tda8290_set_params(struct dvb_frontend *fe,
}
- tda8290_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
if (fe->ops.tuner_ops.set_analog_params)
fe->ops.tuner_ops.set_analog_params(fe, params);
@@ -302,7 +303,8 @@ static void tda8290_set_params(struct dvb_frontend *fe,
}
}
- tda8290_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
tuner_i2c_xfer_send(&priv->i2c_props, if_agc_set, 2);
}
@@ -424,7 +426,8 @@ static void tda8295_set_params(struct dvb_frontend *fe,
tuner_i2c_xfer_send(&priv->i2c_props, blanking_mode, 2);
msleep(20);
- tda8295_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
if (fe->ops.tuner_ops.set_analog_params)
fe->ops.tuner_ops.set_analog_params(fe, params);
@@ -437,7 +440,8 @@ static void tda8295_set_params(struct dvb_frontend *fe,
else
tuner_dbg("tda8295 not locked, no signal?\n");
- tda8295_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
}
/*-*/
@@ -465,11 +469,13 @@ static void tda8290_standby(struct dvb_frontend *fe)
unsigned char tda8290_agc_tri[] = { 0x02, 0x20 };
struct i2c_msg msg = {.addr = priv->tda827x_addr, .flags=0, .buf=cb1,
.len = 2};
- tda8290_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
if (priv->ver & TDA8275A)
cb1[1] = 0x90;
i2c_transfer(priv->i2c_props.adap, &msg, 1);
- tda8290_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
tuner_i2c_xfer_send(&priv->i2c_props, tda8290_agc_tri, 2);
tuner_i2c_xfer_send(&priv->i2c_props, tda8290_standby, 2);
}
@@ -537,9 +543,11 @@ static void tda8290_init_tuner(struct dvb_frontend *fe)
if (priv->ver & TDA8275A)
msg.buf = tda8275a_init;
- tda8290_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
i2c_transfer(priv->i2c_props.adap, &msg, 1);
- tda8290_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
}
/*-*/
@@ -565,19 +573,13 @@ static struct tda18271_config tda829x_tda18271_config = {
static int tda829x_find_tuner(struct dvb_frontend *fe)
{
struct tda8290_priv *priv = fe->analog_demod_priv;
- struct analog_demod_ops *analog_ops = &fe->ops.analog_ops;
int i, ret, tuners_found;
u32 tuner_addrs;
u8 data;
struct i2c_msg msg = { .flags = I2C_M_RD, .buf = &data, .len = 1 };
- if (!analog_ops->i2c_gate_ctrl) {
- printk(KERN_ERR "tda
[PATCH 09/15] media: coda: don't build on multiplatform
The coda video codec driver depends on a mach-imx or mach-mxs specific header file "mach/iram.h". This is not available when building for multiplatform, so let us disable this driver for v3.8 when building multiplatform, and hopefully find a proper fix for v3.9. drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory Signed-off-by: Arnd Bergmann Cc: Javier Martin Cc: Fabio Estevam Cc: Sascha Hauer Cc: Shawn Guo Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org --- drivers/media/platform/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 3dcfea6..049d2b2 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -142,7 +142,7 @@ if V4L_MEM2MEM_DRIVERS config VIDEO_CODA tristate "Chips&Media Coda multi-standard codec IP" - depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC && !ARCH_MULTIPLATFORM select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV select IRAM_ALLOC if SOC_IMX53 -- 1.7.10.4 -- 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] OMAP3 ISP: Simplify clock usage
* Laurent Pinchart [130121 05:37]: > Hi Mike, > > On Monday 14 January 2013 17:10:15 Mike Turquette wrote: > > Quoting Laurent Pinchart (2013-01-08 05:43:52) > > > > > Hello, > > > > > > Now that the OMAP3 supports the common clock framework, clock rate > > > back-propagation is available for the ISP clocks. Instead of setting the > > > cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark > > > the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting > > > back-propagation, and set the cam_mclk rate directly. This simplifies the > > > ISP clocks configuration. > > > > I'm pleased to see this feature get used on OMAP. Plus your driver gets > > a negative diffstat :) > > > > Reviewed-by: Mike Turquette > > Thanks. > > Would you like to take the arch/ patch in your tree, or should I push it > through the linux-media tree along with the omap3isp patch ? The arch/arm/*omap* clock changes need to be queued by Paul to avoid potential stupid merge conflicts when the clock data gets moved to live under drivers/clk/omap. Regards, Tony -- 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 00/15] ARM build regressions in v3.8
I know this comes late, but we have a number of broken
configurations in ARM in v3.8 that were still building
in v3.7, and I'd like to get them all fixed in the
final 3.8 release.
It would be nice if the respective maintainers could
have a look at these patches and apply them directly
when they are happy with them.
The first patch in the series is strictly speaking
not a build error but just a warning, but it is a
particularly annoying one that came in through the
latest binutils release rather than a kernel change.
The same binutils update also broke the samsung
and w90x900 platforms.
A few of the other changes are the result of the
imx multiplatform conversion. I'm not really fixing
those here, just picking up the pieces. It would
be much nicer if we could actually get those drivers
to work again with CONFIG_MULTIPLATFORM enabled
rather than just disabling them, but it may be
much too late for that. At least the drivers don't
seem to be too essential, as they are only built
in allyesconfig but not in any of the defconfigs.
Arnd
Arnd Bergmann (15):
ARM: compressed/head.S: work around new binutils warning
ARM: mvebu: build coherency_ll.S for arch=armv7-a
ARM: samsung: fix assembly syntax for new gas
ARM: w90x900: fix legacy assembly syntax
ASoC: fsl: fiq and dma cannot both be modules
clk: export __clk_get_name
drm/exynos: don't include plat/gpio-cfg.h
drm/exynos: fimd and ipp are broken on multiplatform
media: coda: don't build on multiplatform
mfd/vexpress: export vexpress_config_func_{put,get}
mtd: davinci_nand: fix OF support
USB: gadget/freescale: disable non-multiplatform drivers
USB: ehci: make orion and mxc bus glues coexist
samples/seccomp: be less stupid about cross compiling
staging/omapdrm: don't build on multiplatform
arch/arm/boot/compressed/Makefile|2 +-
arch/arm/boot/compressed/head.S | 12
arch/arm/mach-mvebu/coherency_ll.S |1 +
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 12 ++--
arch/arm/mach-s3c24xx/include/mach/entry-macro.S |4 ++--
arch/arm/mach-s3c24xx/pm-h1940.S |2 +-
arch/arm/mach-s3c24xx/sleep-s3c2410.S| 12 ++--
arch/arm/mach-s3c24xx/sleep-s3c2412.S| 12 ++--
arch/arm/mach-w90x900/include/mach/entry-macro.S |4 ++--
arch/arm/plat-samsung/include/plat/debug-macro.S | 18 +-
drivers/clk/clk.c|1 +
drivers/gpu/drm/exynos/Kconfig |4 ++--
drivers/gpu/drm/exynos/exynos_hdmi.c |1 -
drivers/media/platform/Kconfig |2 +-
drivers/mfd/vexpress-config.c|3 ++-
drivers/mtd/nand/davinci_nand.c |2 +-
drivers/staging/omapdrm/Kconfig |2 +-
drivers/usb/gadget/Kconfig |3 ++-
drivers/usb/host/ehci-hcd.c | 16 +++-
samples/seccomp/Makefile |2 ++
sound/soc/fsl/Kconfig|3 +++
21 files changed, 76 insertions(+), 42 deletions(-)
--
1.7.10.4
Cc: Artem Bityutskiy
Cc: Ben Dooks
Cc: David Airlie
Cc: Greg Kroah-Hartman
Cc: James Morris
Cc: Mark Brown
Cc: Mauro Carvalho Chehab
Cc: Mike Turquette
Cc: Rob Clark
Cc: Russell King
Cc: Shawn Guo
Cc: alsa-de...@alsa-project.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-media@vger.kernel.org
Cc: linux-...@vger.kernel.org
--
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
dvb-usb-it913x dissapeared kernel 3.7.2
After updating the kernel on Fedora 18 module dvb-usb-it913x seems to have dissapeared. This has meant my dvb stick ( ID 1b80:e409 Afatech IT9137FN Dual DVB-T [KWorld UB499-2T]) no longer works Is this a Redhat only thing or is it upstream -- 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/3] v4l: Set proper timestamp type in selected drivers which use videobuf2
Hi, > From: Sakari Ailus [mailto:sakari.ai...@iki.fi] > Sent: Saturday, January 19, 2013 6:43 PM > Hi Kamil, > > Thanks for the patch. > > On Mon, Jan 14, 2013 at 10:36:04AM +0100, Kamil Debski wrote: > > Set proper timestamp type in drivers that I am sure that use either > > MONOTONIC or COPY timestamps. Other drivers will correctly report > > UNKNOWN timestamp type instead of assuming that all drivers use > > monotonic timestamps. > > What other kind of timestamps there can be? All drivers (at least those > not > mem-to-mem) that do obtain timestamps using system clock use monotonic > ones. Not set. It is not a COPY or MONOTONIC either. Any new or custom kind of timestamp, maybe? > I'd think that there should no longer be any drivers using the UNKNOWN > timestamp type: UNKNOWN is either from monotonic or realtime clock, and > we just replaced all of them with the monotonic ones. No driver uses > realtime timestamps anymore. Maybe there should be no drivers using UNKNOWN. But definitely there should be no driver reporting MONOTONIC when the timestamp is not monotonic. > How about making MONOTONIC timestamps default instead, or at least > assigning all drivers something else than UNKNOWN? So why did you add the UNKNOWN flag? The way I see it - UNKNOWN is the default and the one who coded the driver will set it to either MONOTONIC or COPY if it is one of these two. It won't be changed otherwise. There are drivers, which do not fill the timestamp field at all: - drivers/media/platform/coda.c - drivers/media/platform/exynos-gsc/gsc-m2m.c - drivers/media/platform/m2m-deinterlace.c - drivers/media/platform/mx2_emmaprp.c - drivers/media/platform/s5p-fimc/fimc-m2m.c - drivers/media/platform/s5p-g2d.c - drivers/media/platform/s5p-jpeg/jpeg-core.c The way you did it in your patches left no room for any kind of choice. I did comment at least twice about mem-2-mem devices in your RFCs, if I remember correctly. I think Sylwester was also writing about this. Still everything got marked as MONOTONIC. If we were to assume that there were no other timestamp types then monotonic (which is not true, but this was your assumption), then what was the reason to add this timestamp framework? Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- 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: Patchwork / Bugzilla update
Em Sun, 20 Jan 2013 14:07:07 +0100 Frank Schäfer escreveu: > Hi Mauro, > > the patches 16225, 16231, 16232 at patchwork are superseeded: > > pwclient update -s 'superseded' 16225 > pwclient update -s 'superseded' 16231 > pwclient update -s 'superseded' 16232 Updated. > The following kernel bugs can be closed as "resolved - fixed": > - bug 26572 "rmmod em28xx or unplugging em28xx tv adapter problem" > => resolved with commit 05fe2175cf87da8a5475aed422bd636475ab0412 > "em28xx: refactor the code in em28xx_usb_disconnect()" > - bug 14126 "Audio input for TV mode of Terratec Cinergy 250 is > misconfigured" > => resolved with commit 5e8d02bb346d6240b029f1990ddc295d7d59685b > "em28xx: fix audio input for TV mode of device Terratec Cinergy 250" Feel free to close them there directly. Regards, Mauro -- 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] OMAP3 ISP: Simplify clock usage
Hi Mike, On Monday 14 January 2013 17:10:15 Mike Turquette wrote: > Quoting Laurent Pinchart (2013-01-08 05:43:52) > > > Hello, > > > > Now that the OMAP3 supports the common clock framework, clock rate > > back-propagation is available for the ISP clocks. Instead of setting the > > cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark > > the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting > > back-propagation, and set the cam_mclk rate directly. This simplifies the > > ISP clocks configuration. > > I'm pleased to see this feature get used on OMAP. Plus your driver gets > a negative diffstat :) > > Reviewed-by: Mike Turquette Thanks. Would you like to take the arch/ patch in your tree, or should I push it through the linux-media tree along with the omap3isp patch ? > > Laurent Pinchart (2): > > ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to > > dpll4_m5 > > omap3isp: Set cam_mclk rate directly > > > > arch/arm/mach-omap2/cclock3xxx_data.c | 10 +- > > drivers/media/platform/omap3isp/isp.c | 18 ++ > > drivers/media/platform/omap3isp/isp.h |8 +++- > > 3 files changed, 14 insertions(+), 22 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
Re: [PATCH 01/24] use IS_ENABLED() macro
On Mon, Jan 21, 2013 at 10:47 AM, Hans de Goede wrote:
> Hi,
>
> Thanks for the patches I'll pick up 5 - 21 and add them to
> my tree for Mauro.
I have sent V2 of this patches with another subject and with fixed
commit message for two patches.
>
> Regards,
>
> Hans
>
>
>
> On 01/19/2013 05:33 PM, Peter Senna Tschudin wrote:
>>
>> replace:
>> #if defined(CONFIG_VIDEO_CX88_DVB) || \
>> defined(CONFIG_VIDEO_CX88_DVB_MODULE)
>> with:
>> #if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
>>
>> This change was made for: CONFIG_VIDEO_CX88_DVB,
>> CONFIG_VIDEO_CX88_BLACKBIRD, CONFIG_VIDEO_CX88_VP3054
>>
>> Reported-by: Mauro Carvalho Chehab
>> Signed-off-by: Peter Senna Tschudin
>> ---
>> drivers/media/pci/cx88/cx88.h | 10 --
>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
>> index ba0dba4..feff53c 100644
>> --- a/drivers/media/pci/cx88/cx88.h
>> +++ b/drivers/media/pci/cx88/cx88.h
>> @@ -363,7 +363,7 @@ struct cx88_core {
>> unsigned int tuner_formats;
>>
>> /* config info -- dvb */
>> -#if defined(CONFIG_VIDEO_CX88_DVB) ||
>> defined(CONFIG_VIDEO_CX88_DVB_MODULE)
>> +#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
>> int(*prev_set_voltage)(struct dvb_frontend
>> *fe, fe_sec_voltage_t voltage);
>> #endif
>> void (*gate_ctrl)(struct cx88_core *core,
>> int open);
>> @@ -562,8 +562,7 @@ struct cx8802_dev {
>>
>> /* for blackbird only */
>> struct list_head devlist;
>> -#if defined(CONFIG_VIDEO_CX88_BLACKBIRD) || \
>> -defined(CONFIG_VIDEO_CX88_BLACKBIRD_MODULE)
>> +#if IS_ENABLED(CONFIG_VIDEO_CX88_BLACKBIRD)
>> struct video_device*mpeg_dev;
>> u32mailbox;
>> intwidth;
>> @@ -574,13 +573,12 @@ struct cx8802_dev {
>> struct cx2341x_handler cxhdl;
>> #endif
>>
>> -#if defined(CONFIG_VIDEO_CX88_DVB) ||
>> defined(CONFIG_VIDEO_CX88_DVB_MODULE)
>> +#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
>> /* for dvb only */
>> struct videobuf_dvb_frontends frontends;
>> #endif
>>
>> -#if defined(CONFIG_VIDEO_CX88_VP3054) || \
>> -defined(CONFIG_VIDEO_CX88_VP3054_MODULE)
>> +#if IS_ENABLED(CONFIG_VIDEO_CX88_VP3054)
>> /* For VP3045 secondary I2C bus support */
>> struct vp3054_i2c_state*vp3054;
>> #endif
>>
>
--
Peter
--
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 01/24] use IS_ENABLED() macro
Hi,
Thanks for the patches I'll pick up 5 - 21 and add them to
my tree for Mauro.
Regards,
Hans
On 01/19/2013 05:33 PM, Peter Senna Tschudin wrote:
replace:
#if defined(CONFIG_VIDEO_CX88_DVB) || \
defined(CONFIG_VIDEO_CX88_DVB_MODULE)
with:
#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
This change was made for: CONFIG_VIDEO_CX88_DVB,
CONFIG_VIDEO_CX88_BLACKBIRD, CONFIG_VIDEO_CX88_VP3054
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Peter Senna Tschudin
---
drivers/media/pci/cx88/cx88.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index ba0dba4..feff53c 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -363,7 +363,7 @@ struct cx88_core {
unsigned int tuner_formats;
/* config info -- dvb */
-#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
int(*prev_set_voltage)(struct dvb_frontend *fe,
fe_sec_voltage_t voltage);
#endif
void (*gate_ctrl)(struct cx88_core *core, int
open);
@@ -562,8 +562,7 @@ struct cx8802_dev {
/* for blackbird only */
struct list_head devlist;
-#if defined(CONFIG_VIDEO_CX88_BLACKBIRD) || \
-defined(CONFIG_VIDEO_CX88_BLACKBIRD_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_BLACKBIRD)
struct video_device*mpeg_dev;
u32mailbox;
intwidth;
@@ -574,13 +573,12 @@ struct cx8802_dev {
struct cx2341x_handler cxhdl;
#endif
-#if defined(CONFIG_VIDEO_CX88_DVB) || defined(CONFIG_VIDEO_CX88_DVB_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_DVB)
/* for dvb only */
struct videobuf_dvb_frontends frontends;
#endif
-#if defined(CONFIG_VIDEO_CX88_VP3054) || \
-defined(CONFIG_VIDEO_CX88_VP3054_MODULE)
+#if IS_ENABLED(CONFIG_VIDEO_CX88_VP3054)
/* For VP3045 secondary I2C bus support */
struct vp3054_i2c_state*vp3054;
#endif
--
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 RFC v3 02/15] [media] Add a V4L2 OF parser
Hi Sylwester,
Just two comments...
On Thu January 3 2013 18:09:22 Sylwester Nawrocki wrote:
> From: Guennadi Liakhovetski
>
> Add a V4L2 OF parser, implementing bindings documented in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> Signed-off-by: Guennadi Liakhovetski
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes since v2:
> - added missing EXPORT_SYMBOL for v4l2_of_parse_mipi_csi2()
>and v4l2_of_parse_parallel_bus() functions,
> - include string.h header instead of slab.h.
>
> drivers/media/v4l2-core/Makefile |3 +
> drivers/media/v4l2-core/v4l2-of.c | 251
> +
> include/media/v4l2-of.h | 79
> 3 files changed, 333 insertions(+)
> create mode 100644 drivers/media/v4l2-core/v4l2-of.c
> create mode 100644 include/media/v4l2-of.h
>
> diff --git a/drivers/media/v4l2-core/Makefile
> b/drivers/media/v4l2-core/Makefile
> index c2d61d4..00f64d6 100644
> --- a/drivers/media/v4l2-core/Makefile
> +++ b/drivers/media/v4l2-core/Makefile
> @@ -9,6 +9,9 @@ videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o
> v4l2-fh.o \
> ifeq ($(CONFIG_COMPAT),y)
>videodev-objs += v4l2-compat-ioctl32.o
> endif
> +ifeq ($(CONFIG_OF),y)
> + videodev-objs += v4l2-of.o
> +endif
>
> obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o
> obj-$(CONFIG_VIDEO_V4L2) += v4l2-common.o
> diff --git a/drivers/media/v4l2-core/v4l2-of.c
> b/drivers/media/v4l2-core/v4l2-of.c
> new file mode 100644
> index 000..483245c
> --- /dev/null
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -0,0 +1,251 @@
> +/*
> + * V4L2 OF binding parsing library
> + *
> + * Copyright (C) 2012 Renesas Electronics Corp.
> + * Author: Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/**
> + * v4l2_of_parse_mipi_csi2() - parse MIPI CSI-2 bus properties
> + * @node: pointer to endpoint device_node
> + * @endpoint: pointer to v4l2_of_endpoint data structure
> + *
> + * Return: 0 on success or negative error value otherwise.
> + */
> +int v4l2_of_parse_mipi_csi2(const struct device_node *node,
> + struct v4l2_of_endpoint *endpoint)
> +{
> + struct v4l2_of_mipi_csi2 *mipi_csi2 = &endpoint->mipi_csi_2;
> + u32 data_lanes[ARRAY_SIZE(mipi_csi2->data_lanes)];
> + struct property *prop;
> + const __be32 *lane = NULL;
> + u32 v;
> + int i = 0;
> +
> + prop = of_find_property(node, "data-lanes", NULL);
> + if (!prop)
> + return -EINVAL;
> + do {
> + lane = of_prop_next_u32(prop, lane, &data_lanes[i]);
> + } while (lane && i++ < ARRAY_SIZE(data_lanes));
> +
> + mipi_csi2->num_data_lanes = i;
> + while (i--)
> + mipi_csi2->data_lanes[i] = data_lanes[i];
> +
> + if (!of_property_read_u32(node, "clock-lanes", &v))
> + mipi_csi2->clock_lane = v;
Hmm, the property name is 'clock-lanes', but only one lane is obtained here.
Why is the property name plural in that case?
> +
> + if (of_get_property(node, "clock-noncontinuous", &v))
> + endpoint->mbus_flags |= V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(v4l2_of_parse_mipi_csi2);
> +
> +/**
> + * v4l2_of_parse_parallel_bus() - parse parallel bus properties
> + * @node: pointer to endpoint device_node
> + * @endpoint: pointer to v4l2_of_endpoint data structure
> + */
> +void v4l2_of_parse_parallel_bus(const struct device_node *node,
> + struct v4l2_of_endpoint *endpoint)
> +{
> + unsigned int flags = 0;
> + u32 v;
> +
> + if (WARN_ON(!endpoint))
> + return;
> +
> + if (!of_property_read_u32(node, "hsync-active", &v))
> + flags |= v ? V4L2_MBUS_HSYNC_ACTIVE_HIGH :
> + V4L2_MBUS_HSYNC_ACTIVE_LOW;
> +
> + if (!of_property_read_u32(node, "vsync-active", &v))
> + flags |= v ? V4L2_MBUS_VSYNC_ACTIVE_HIGH :
> + V4L2_MBUS_VSYNC_ACTIVE_LOW;
> +
> + if (!of_property_read_u32(node, "pclk-sample", &v))
> + flags |= v ? V4L2_MBUS_PCLK_SAMPLE_RISING :
> + V4L2_MBUS_PCLK_SAMPLE_FALLING;
> +
> + if (!of_property_read_u32(node, "field-even-active", &v))
> + flags |= v ? V4L2_MBUS_FIELD_EVEN_HIGH :
> + V4L2_MBUS_FIELD_EVEN_LOW;
> + if (flags)
> + endpoint->mbus_type = V4L2_MBUS_PARALLEL;
> + else
> + endpoint->mbus_type = V4L2_MBUS_BT656;
> +
> + if (!of_property_read_u32(node, "data-active", &v))
> + flags |= v ? V4L2_MBUS_DATA_ACTIVE_HIGH :
> + V4L2_MBUS_DATA_ACTIVE_LOW;
> +
> + if (of_get_property(node, "slave-mode", &v))
[Q] Querying Y/Gb Average Level in a sensor.
Hi, ov7670 and ov7675 sensors have the possibility of querying the average value of the Y/Cb components of the image reading a register. This could be useful for applications such as calise [1]. This program grabs frames from a video camera, calculates the average brightness and then adjusts screen's backlight accordingly. If the user could query the value of this register t in cameras that support it we could save a lot of processing effort. The first idea that came into my mind was to define a new v4l2-ctrl for this but I'm not sure if it is a common feature in other sensors. Is it worth it to define a new v4l2-ctrl for this or should I use a private ctrl instead? Regards. [1] http://calise.sourceforge.net/wordpress/ -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: RFC: add parameters to V4L controls
Hi Andrzej, On Tuesday 15 January 2013 15:34:47 Andrzej Hajda wrote: > On 12.01.2013 23:05, Sakari Ailus wrote: > > Andrzej Hajda wrote: > >> Hi, > >> > >> I have included this proposition already in the post "[PATCH RFC 0/2] > >> V4L: Add auto focus area control and selection" but it left unanswered. > >> I repost it again in a separate e-mail, I hope this way it will be > >> easier to attract attention. > >> > >> Problem description > >> > >> Currently V4L2 controls can have only single value (of type int, int64, > >> string). Some hardware controls require more than single int parameter, > >> for example to set auto-focus (AF) rectangle four coordinates should be > >> passed, to set auto-focus spot two coordinates should be passed. > >> > >> Current solution > >> > >> In case of AF rectangle we can reuse selection API as in "[PATCH RFC > >> 0/2] V4L: Add auto focus area control and selection" post. > >> Pros: > >> - reuse existing API, > >> Cons: > >> - two IOCTL's to perform one action, > > > > I think changing AF mode and AF window of interest are still two > > operations: you may well change just either one, and be happy with it. > > I see no point in changing AF window of interest without applying area AF. > So we will have here always two operations in that case. > > > You might want to disable AF during the configuration from the > > application. Would this work for you? > > > >> - non-atomic operation, > > > > True, but this is the way V4L2 works. > > > > There are many cases where implementing multiple more or less unrelated > > operations atomically would be beneficial, but so far there always have > > been workarounds to perform those actions non-atomicly. Format > > configuration, for example. > > > > Atomic operations are hard to get right and typically the required > > effort refutes the gain of doing so in drivers, and everything that may > > be done atomically always must be implemented beforehand in drivers. > > > > Your use case would be from the more simple end, though. > > > >> - fits well only for rectangles and spots (but with unused fields width, > >> height), in case of other parameters we should find a different way. > >> > >> Proposed solution > >> > >> The solution takes an advantage of the fact VIDIOC_(G/S/TRY)_EXT_CTRLS > >> ioctls can be called with multiple controls per call. > >> > >> I will present it using AF area control example. > >> > >> There could be added four pseudo-controls, lets call them for short: > >> LEFT, TOP, WIDTH, HEIGHT. > >> Those controls could be passed together with > >> V4L2_AUTO_FOCUS_AREA_RECTANGLE > >> control in one ioctl as a kind of parameters. > >> > >> For example setting auto-focus spot would require calling > >> VIDIOC_S_EXT_CTRLS > >> with the following controls: > >> - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_RECTANGLE > >> - LEFT = ... > >> - RIGHT = ... > >> > >> Setting AF rectangle: > >> - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_RECTANGLE > >> - LEFT = ... > >> - TOP = ... > >> - WIDTH = ... > >> - HEIGHT = ... > >> > >> Setting AF object detection (no parameters required): > >> - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION > >> > >> I have presented all three cases to show the advantages of this solution: > >> - atomicity - control and its parameters are passed in one call, > >> - flexibility - we are not limited by a fixed number of parameters, > >> - no-redundancy - we can pass only required parameters > >> > >> (no need to pass null width and height in case of spot selection), > >> > >> - extensibility - it is possible to extend parameters in the future, > >> for example add parameters to V4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION, > >> without breaking API, > >> - backward compatibility, > >> - re-usability - this schema could be used in other controls, > >> > >> pseudo-controls could be re-used in other controls as well. > >> > >> - API backward compatibility. > > > > What I'm not terribly fond of in the above proposal is that it uses > > several controls to describe rectangles which are an obvious domain of > > the selection API: selections are roughly like controls but rather use a > > rectangle type instead of a single integer value (or a string). > > The problem wit AF is that it can require different set of parameters > depending on the hardware: > - spots (ex. Galaxy S3), > - rectangles (ex. Samsung NX210), > - multiple rectangles with weight or priority (ex. Samsung DV300F), If it gets that complex, I wonder whether a custom ioctl wouldn't be better. I'm not sure we could really standardize multiple rectangles with weights in a useful way. > - ... > (To be honest I am sure only for GalaxyS3, other examples is just my > prediction based on the analysis of user manuals of those cameras) > > Implementation of all those cases would be quite straightforward (for > me) using proposed pseudo-controls, without it every time it would > require serious br
[GIT PULL FOR v3.9] uvcvideo fixes
Hi Mauro, The following changes since commit 3151d14aa6e983aa36d51a80d0477859f9ba12af: [media] media: remove __dev* annotations (2013-01-11 13:03:24 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Ezequiel Garcia (1): uvcvideo: Replace memcpy with struct assignment Oliver Neukum (1): uvcvideo: Fix race of open and suspend in error case drivers/media/usb/uvc/uvc_ctrl.c |2 +- drivers/media/usb/uvc/uvc_v4l2.c |8 2 files changed, 5 insertions(+), 5 deletions(-) The corresponding patchwork commands are pwclient update -s 'accepted' 16201 pwclient update -s 'accepted' 16253 -- 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
[PATCH v16 RESEND 7/7] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Tested-by: Afzal Mohammed
---
drivers/gpu/drm/drm_modes.c | 33 +
include/drm/drmP.h |4
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 184a22d..fd53454 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
/**
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_videomode(&vm, dmode);
+
+ pr_debug("%s: got %dx%d display mode from %s\n",
+ of_node_full_name(np), vm.hactive, vm.vactive, np->name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5fbb0fe..e26ca59 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
struct drm_file;
struct drm_device;
+struct device_node;
struct videomode;
#include
@@ -1458,6 +1459,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
--
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 v16 RESEND 2/7] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off
As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.
Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.
The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.
This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Tested-by: Afzal Mohammed
---
drivers/video/Kconfig |6 ++
drivers/video/Makefile |2 +
drivers/video/display_timing.c | 24
drivers/video/videomode.c | 39 +
include/video/display_timing.h | 124
include/video/videomode.h | 48
6 files changed, 243 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/video/display_timing.h
create mode 100644 include/video/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool
+
+config VIDEOMODE
+ bool
+
menuconfig FB
tristate "Support for frame buffer devices"
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..5e1822c
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include
+#include
+#include
+
+void display_timings_release(struct display_timings *disp)
+{
+ if (disp->timings) {
+ unsigned int i;
+
+ for (i = 0; i < disp->num_timings; i++)
+ kfree(disp->timings[i]);
+ kfree(disp->timings);
+ }
+ kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..21c47a2
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,39 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar , Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include
+#include
+#include
+#include
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+ struct display_timing *dt;
+
+ dt = display_timings_get(disp, index);
+ if (!dt)
+ return -EINVAL;
+
+ vm->pixelclock = display_timing_get_value(&dt->pixelclock, TE_TYP);
+ vm->hactive = display_timing_get_value(&dt->hactive, TE_TYP);
+ vm->hfront_porch = display_timing_get_value(&dt->hfront_porch, TE_TYP);
+ vm->hback_porch = display_timing_get_value(&dt->hback_porch, TE_TYP);
+ vm->hsync_len = display_timing_get_value(&dt->hsync_len, TE_TYP);
+
+ vm->vactive = display_timing_get_value(&dt->vactive, TE_TYP);
+ vm->vfront_porch = display_timing_get_value(&dt->vfro
[PATCH v16 RESEND 1/7] viafb: rename display_timing to via_display_timing
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar
---
drivers/video/via/hw.c |6 +++---
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c |2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c |8
drivers/video/via/via_modesetting.h |6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct
fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var->xres, cyres ? cyres : var->yres);
if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo
*var, u16 cxres,
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include "debug.h"
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total / 8 - 5;
raw.hor_addr = timing->hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing->hor_total - 1;
raw.hor_addr = timing->hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing *timing);
void v
[PATCH v16 RESEND 0/7] of: add display helper
Hi!
There was still no maintainer, that commented, ack'd, nack'd, apply'd the
series. So, this is just a resend.
The patches were tested with:
- v15 on Tegra by Thierry
- sh-mobile-lcdcfb by Laurent
- MX53QSB by Marek
- Exynos: smdk5250 by Leela
- AM335X EVM & AM335X EVM-SK by Afzal
- imx6q: sabrelite, sabresd by Philipp and me
- imx53: tqma53/mba53 by me
Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: add VESA flags and data flags
- let pixelclock in struct videomode be unsigned long
- rename of_display_timings_exists to of_display_timings_exist
- revise logging/error messages: replace __func__ with np->full_name
- rename pixelclk-inverted to pixelclk-active
- revise comments in code
Changes since v14:
- fix "const struct *" warning
(reported by: Leela Krishna Amudala )
- return -EINVAL when htotal or vtotal are zero
- remove unreachable code in of_get_display_timings
- include headers in .c files and not implicit in .h
- sort includes alphabetically
- fix lower/uppercase in binding documentation
- rebase onto v3.7-rc7
Changes since v13:
- fix "const struct *" warning
(reported by: Laurent Pinchart
)
- prevent division by zero in fb_videomode_from_videomode
Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix "const struct *" warnings
(reported by: Manjunathappa, Prakash )
- some CodingStyle fixes
- rewrite parts of commit messages and display-timings.txt
- let display_timing_get_value get all values instead of just typical
Changes since v11:
- make pointers const where applicable
- add reviewed-by Laurent Pinchart
Changes since v10:
- fix function name (drm_)display_mode_from_videomode
- add acked-by, reviewed-by, tested-by
Changes since v9:
- don't leak memory when previous timings were correct
- CodingStyle fixes
- move blank lines around
Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct
foo))
- include headers were necessary
- misc minor bugfixes
Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes
Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions
Changes since v5:
- removed all display stuff and just describe timings
Changes since v4:
- refactored functions
Changes since v3:
- print error messages
- free alloced memory
- general cleanup
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties ()
- functions to get display_mode or fb_videomode
Regards,
Steffen
Steffen Trumtrar (7):
viafb: rename display_timing to via_display_timing
video: add display_timing and videomode
video: add of helper for display timings/videomode
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
.../devicetree/bindings/video/display-timing.txt | 109 +
drivers/gpu/drm/drm_modes.c| 70 ++
drivers/video/Kconfig | 21 ++
drivers/video/Makefile |4 +
drivers/video/display_timing.c | 24 ++
drivers/video/fbmon.c | 94
drivers/video/of_display_timing.c | 239
drivers/video/of_videomode.c | 54 +
drivers/video/via/hw.c |6 +-
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c|2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c|8 +-
drivers/video/via/via_modesetting.h|6 +-
drivers/video/videomode.c | 39
include/drm/drmP.h |9 +
include/linux/fb.h |8 +
include/video/display_timing.h | 124 ++
include/video/of_display_timing.h | 20 ++
include/video/of_videomode.h | 18
[PATCH v16 RESEND 3/7] video: add of helper for display timings/videomode
This adds support for reading display timings from DT into a struct display_timings. The of_display_timing implementation supports multiple subnodes. All children are read into an array, that can be queried. If no native mode is specified, the first subnode will be used. For cases where the graphics driver knows there can be only one mode description or where the driver only supports one mode, a helper function of_get_videomode is added, that gets a struct videomode from DT. Signed-off-by: Steffen Trumtrar Signed-off-by: Philipp Zabel Acked-by: Stephen Warren Reviewed-by: Thierry Reding Acked-by: Thierry Reding Tested-by: Thierry Reding Tested-by: Philipp Zabel Reviewed-by: Laurent Pinchart Acked-by: Laurent Pinchart Tested-by: Afzal Mohammed --- .../devicetree/bindings/video/display-timing.txt | 109 + drivers/video/Kconfig | 15 ++ drivers/video/Makefile |2 + drivers/video/of_display_timing.c | 239 drivers/video/of_videomode.c | 54 + include/video/of_display_timing.h | 20 ++ include/video/of_videomode.h | 18 ++ 7 files changed, 457 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 include/video/of_display_timing.h create mode 100644 include/video/of_videomode.h diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt new file mode 100644 index 000..1500385 --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timing.txt @@ -0,0 +1,109 @@ +display-timing bindings +=== + +display-timings node + + +required properties: + - none + +optional properties: + - native-mode: The native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +timing subnode +-- + +required properties: + - hactive, vactive: display resolution + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: vertical display timing parameters in + lines + - clock-frequency: display clock in Hz + +optional properties: + - hsync-active: hsync pulse is active low/high/ignored + - vsync-active: vsync pulse is active low/high/ignored + - de-active: data-enable pulse is active low/high/ignored + - pixelclk-active: with + - active high = drive pixel data on rising edge/ + sample data on falling edge + - active low = drive pixel data on falling edge/ + sample data on rising edge + - ignored = ignored + - interlaced (bool): boolean to enable interlaced mode + - doublescan (bool): boolean to enable doublescan mode + +All the optional properties that are not bool follow the following logic: +<1>: high active +<0>: low active +omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The +devicetree representation corresponds to the one commonly found in datasheets +for displays. If a display supports multiple signal timings, the native-mode +can be specified. + +The parameters are defined as: + + +--+-+--+---+ + | |↑| | | + | ||vback_porch | | | + | |↓| | | + +--###--+---+ + | #↑# | | + | #|# | | + | hback #|# hfront | hsync | + | porch #| hactive # porch | len | + |<>#<---+--->#<>|<->| + | #|# | | + | #|vactive # | | + | #|# | | + | #↓# | | + +--###--+---+ + | |↑| | | + | ||vfront_porch| | | + | |↓| | | + +--+-+--+---+ + | |↑
[PATCH v16 RESEND 4/7] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Tested-by: Afzal Mohammed
---
drivers/video/fbmon.c | 52 +
include/linux/fb.h|4
2 files changed, 56 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..17ce135 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_PPC_OF
#include
#include
@@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ fbmode->xres = vm->hactive;
+ fbmode->left_margin = vm->hback_porch;
+ fbmode->right_margin = vm->hfront_porch;
+ fbmode->hsync_len = vm->hsync_len;
+
+ fbmode->yres = vm->vactive;
+ fbmode->upper_margin = vm->vback_porch;
+ fbmode->lower_margin = vm->vfront_porch;
+ fbmode->vsync_len = vm->vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode->pixclock = vm->pixelclock ?
+ KHZ2PICOS(vm->pixelclock / 1000) : 0;
+
+ fbmode->sync = 0;
+ fbmode->vmode = 0;
+ if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+ if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+ fbmode->flag = 0;
+
+ htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
+vm->hsync_len;
+ vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
+vm->vsync_len;
+ /* prevent division by zero */
+ if (htotal && vtotal) {
+ fbmode->refresh = vm->pixelclock / (htotal * vtotal);
+ /* a mode must have htotal and vtotal != 0 or it is invalid */
+ } else {
+ fbmode->refresh = 0;
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..100a176 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode);
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
1.7.10.4
--
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 v16 RESEND 5/7] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Tested-by: Afzal Mohammed
---
drivers/video/fbmon.c | 42 ++
include/linux/fb.h|4
2 files changed, 46 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 17ce135..94ad0f7 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PPC_OF
#include
@@ -1425,6 +1426,47 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u
%u\n",
+m->xres, m->yres, m->refresh, m->pixclock, m->left_margin,
+m->right_margin, m->upper_margin, m->lower_margin,
+m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_videomode(&vm, fb);
+
+ pr_debug("%s: got %dx%d display mode from %s\n",
+ of_node_full_name(np), vm.hactive, vm.vactive, np->name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 100a176..58b9860 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ int index);
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
1.7.10.4
--
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 v16 RESEND 6/7] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
Tested-by: Afzal Mohammed
---
drivers/gpu/drm/drm_modes.c | 37 +
include/drm/drmP.h |5 +
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..184a22d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode)
+{
+ dmode->hdisplay = vm->hactive;
+ dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+ dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+ dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+ dmode->vdisplay = vm->vactive;
+ dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+ dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+ dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+ dmode->clock = vm->pixelclock / 1000;
+
+ dmode->flags = 0;
+ if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+ else if (vm->dmt_flags & VESA_DMT_HSYNC_LOW)
+ dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
+ dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+ else if (vm->dmt_flags & VESA_DMT_VSYNC_LOW)
+ dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+ dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+ dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..5fbb0fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
struct drm_file;
struct drm_device;
+struct videomode;
+
#include
#include
#include
@@ -1454,6 +1456,9 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode);
+
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
--
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] uvcvideo: Implement videobuf2 .wait_prepare and .wait_finish operations
Those optional operations are used to release and reacquire the queue
lock when videobuf2 needs to perform operations that sleep for a long
time, such as waiting for a buffer to be complete. Implement them to
avoid blocking qbuf or streamoff calls when a dqbuf is in progress.
Signed-off-by: Laurent Pinchart
---
drivers/media/usb/uvc/uvc_queue.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index 778addc..6c233a5 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -115,11 +115,27 @@ static int uvc_buffer_finish(struct vb2_buffer *vb)
return 0;
}
+static void uvc_wait_prepare(struct vb2_queue *vq)
+{
+ struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
+
+ mutex_unlock(&queue->mutex);
+}
+
+static void uvc_wait_finish(struct vb2_queue *vq)
+{
+ struct uvc_video_queue *queue = vb2_get_drv_priv(vq);
+
+ mutex_lock(&queue->mutex);
+}
+
static struct vb2_ops uvc_queue_qops = {
.queue_setup = uvc_queue_setup,
.buf_prepare = uvc_buffer_prepare,
.buf_queue = uvc_buffer_queue,
.buf_finish = uvc_buffer_finish,
+ .wait_prepare = uvc_wait_prepare,
+ .wait_finish = uvc_wait_finish,
};
int uvc_queue_init(struct uvc_video_queue *queue, enum v4l2_buf_type type,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 01/15] [media] Add common video interfaces OF bindings documentation
On Thu January 3 2013 18:03:49 Sylwester Nawrocki wrote:
> From: Guennadi Liakhovetski
>
> This patch adds a document describing common OF bindings for video
> capture, output and video processing devices. It is curently mainly
> focused on video capture devices, with data busses defined by
> standards like ITU-R BT.656 or MIPI-CSI2.
> It also documents a method of describing data links between devices.
>
> Signed-off-by: Guennadi Liakhovetski
> Signed-off-by: Sylwester Nawrocki
> Reviewed-by: Stephen Warren
> Acked-by: Rob Herring
As promised, here is my review:
> ---
>
> Changes since v2:
>
> - corrected pclk-sample property definition,
> - s/buses/busses,
> - whitespace changes.
>
> .../devicetree/bindings/media/video-interfaces.txt | 199
>
> 1 file changed, 199 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/video-interfaces.txt
>
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt
> b/Documentation/devicetree/bindings/media/video-interfaces.txt
> new file mode 100644
> index 000..9e9e95a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -0,1 +1,199 @@
> +Common bindings for video data receiver and transmitter interfaces
> +
> +General concept
> +---
> +
> +Video data pipelines usually consist of external devices, e.g. camera
> sensors,
> +controlled over an I2C, SPI or UART bus, and SoC internal IP blocks,
> including
> +video DMA engines and video data processors.
> +
> +SoC internal blocks are described by DT nodes, placed similarly to other SoC
> +blocks. External devices are represented as child nodes of their respective
> +bus controller nodes, e.g. I2C.
> +
> +Data interfaces on all video devices are described by their child 'port'
> nodes.
> +Configuration of a port depends on other devices participating in the data
> +transfer and is described by 'endpoint' subnodes.
> +
> +dev {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + endpoint@0 { ... };
> + endpoint@1 { ... };
> + };
> + port@1 { ... };
> +};
> +
> +If a port can be configured to work with more than one other device on the
> same
> +bus, an 'endpoint' child node must be provided for each of them. If more
> than
> +one port is present in a device node or there is more than one endpoint at a
> +port, a common scheme, using '#address-cells', '#size-cells' and 'reg'
> properties
> +is used.
> +
> +Two 'endpoint' nodes are linked with each other through their
> 'remote-endpoint'
> +phandles. An endpoint subnode of a device contains all properties needed for
> +configuration of this device for data exchange with the other device. In
> most
> +cases properties at the peer 'endpoint' nodes will be identical, however
> +they might need to be different when there is any signal modifications on the
> +bus between two devices, e.g. there are logic signal inverters on the lines.
> +
> +Required properties
> +---
> +
> +If there is more than one 'port' or more than one 'endpoint' node following
> +properties are required in relevant parent node:
> +
> +- #address-cells : number of cells required to define port number, should be
> 1.
> +- #size-cells: should be zero.
> +
> +Optional endpoint properties
> +
> +
> +- remote-endpoint: phandle to an 'endpoint' subnode of the other device node.
> +- slave-mode: a boolean property, run the link in slave mode. Default is
> master
> + mode.
> +- bus-width: number of data lines, valid for parallel busses.
> +- data-shift: on parallel data busses, if bus-width is used to specify the
> + number of data lines, data-shift can be used to specify which data lines
> are
> + used, e.g. "bus-width=<10>; data-shift=<2>;" means, that lines 9:2 are
> used.
> +- hsync-active: active state of HSYNC signal, 0/1 for LOW/HIGH respectively.
> +- vsync-active: active state of VSYNC signal, 0/1 for LOW/HIGH respectively.
> + Note, that if HSYNC and VSYNC polarities are not specified, embedded
> + synchronization may be required, where supported.
> +- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
> +- field-even-active: field signal level during the even field data
> transmission.
> +- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel
> clock
> + signal.
> +- data-lanes: an array of physical data lane indexes. Position of an entry
> + determines logical lane number, while the value of an entry indicates
> physical
> + lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1>,
> <2>;",
> + assuming the clock lane is on hardware lane 0. This property is valid for
> + serial busses only (e.g. MIPI CSI-2).
> +- clock-lanes: a number of physical lane used as a clock lane.
This doesn't parse. Do you mean:
"a number of physical lanes used as clock lanes."?
> +- clock-noncontinuous: a boo
Re: [PATCH] media: adv7343: accept configuration through platform data
Hi Hans,
Thanks for the review!
On Mon, Jan 21, 2013 at 3:31 PM, Hans Verkuil wrote:
> On Tue January 15 2013 09:00:53 Lad, Prabhakar wrote:
>> The current code was implemented with some default configurations,
>> this default configuration works on board and doesn't work on other.
>>
>> This patch accepts the configuration through platform data and configures
>> the encoder depending on the data set.
>
> Just one small comment...
>
>>
>> Signed-off-by: Lad, Prabhakar
>> ---
>> drivers/media/i2c/adv7343.c | 36 +++-
>> include/media/adv7343.h | 32
>> 2 files changed, 63 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
>> index 2b5aa67..a058058 100644
>> --- a/drivers/media/i2c/adv7343.c
>> +++ b/drivers/media/i2c/adv7343.c
>> @@ -43,6 +43,7 @@ MODULE_PARM_DESC(debug, "Debug level 0-1");
>> struct adv7343_state {
>> struct v4l2_subdev sd;
>> struct v4l2_ctrl_handler hdl;
>> + const struct adv7343_platform_data *pdata;
>> u8 reg00;
>> u8 reg01;
>> u8 reg02;
>> @@ -215,12 +216,23 @@ static int adv7343_setoutput(struct v4l2_subdev *sd,
>> u32 output_type)
>> /* Enable Appropriate DAC */
>> val = state->reg00 & 0x03;
>>
>> - if (output_type == ADV7343_COMPOSITE_ID)
>> - val |= ADV7343_COMPOSITE_POWER_VALUE;
>> - else if (output_type == ADV7343_COMPONENT_ID)
>> - val |= ADV7343_COMPONENT_POWER_VALUE;
>> + /* configure default configuration */
>> + if (!state->pdata)
>> + if (output_type == ADV7343_COMPOSITE_ID)
>> + val |= ADV7343_COMPOSITE_POWER_VALUE;
>> + else if (output_type == ADV7343_COMPONENT_ID)
>> + val |= ADV7343_COMPONENT_POWER_VALUE;
>> + else
>> + val |= ADV7343_SVIDEO_POWER_VALUE;
>> else
>> - val |= ADV7343_SVIDEO_POWER_VALUE;
>> + val = state->pdata->mode_config.sleep_mode << 0 |
>> + state->pdata->mode_config.pll_control << 1 |
>> + state->pdata->mode_config.dac_3 << 2 |
>> + state->pdata->mode_config.dac_2 << 3 |
>> + state->pdata->mode_config.dac_1 << 4 |
>> + state->pdata->mode_config.dac_6 << 5 |
>> + state->pdata->mode_config.dac_5 << 6 |
>> + state->pdata->mode_config.dac_4 << 7;
>>
>> err = adv7343_write(sd, ADV7343_POWER_MODE_REG, val);
>> if (err < 0)
>> @@ -238,6 +250,17 @@ static int adv7343_setoutput(struct v4l2_subdev *sd,
>> u32 output_type)
>>
>> /* configure SD DAC Output 2 and SD DAC Output 1 bit to zero */
>> val = state->reg82 & (SD_DAC_1_DI & SD_DAC_2_DI);
>> +
>> + if (state->pdata && state->pdata->sd_config.sd_dac_out1)
>> + val = val | (state->pdata->sd_config.sd_dac_out1 << 1);
>> + else if (state->pdata && !state->pdata->sd_config.sd_dac_out1)
>> + val = val & ~(state->pdata->sd_config.sd_dac_out1 << 1);
>> +
>> + if (state->pdata && state->pdata->sd_config.sd_dac_out2)
>> + val = val | (state->pdata->sd_config.sd_dac_out2 << 2);
>> + else if (state->pdata && !state->pdata->sd_config.sd_dac_out2)
>> + val = val & ~(state->pdata->sd_config.sd_dac_out2 << 2);
>> +
>> err = adv7343_write(sd, ADV7343_SD_MODE_REG2, val);
>> if (err < 0)
>> goto setoutput_exit;
>> @@ -401,6 +424,9 @@ static int adv7343_probe(struct i2c_client *client,
>> if (state == NULL)
>> return -ENOMEM;
>>
>> + /* Copy board specific information here */
>> + state->pdata = client->dev.platform_data;
>> +
>> state->reg00= 0x80;
>> state->reg01= 0x00;
>> state->reg02= 0x20;
>> diff --git a/include/media/adv7343.h b/include/media/adv7343.h
>> index d6f8a4e..8086e46 100644
>> --- a/include/media/adv7343.h
>> +++ b/include/media/adv7343.h
>> @@ -20,4 +20,36 @@
>> #define ADV7343_COMPONENT_ID (1)
>> #define ADV7343_SVIDEO_ID(2)
>>
>> +struct adv7343_power_mode {
>> + bool sleep_mode;
>> + bool pll_control;
>> + bool dac_1;
>> + bool dac_2;
>> + bool dac_3;
>> + bool dac_4;
>> + bool dac_5;
>> + bool dac_6;
>> +};
>
> Can you add a short description for struct adv7343_power_mode? It's
> sufficient to point to the relevant section in the datasheet (add a url
> or something like that).
>
Ok I'll do the needy. and respin v2.
Regards,
--Prabhakar
> Regards,
>
> Hans
>
>> +
>> +/**
>> + * struct adv7343_sd_config - SD Only Output Configuration.
>> + * @sd_dac_out1: Configure SD DAC Output 1.
>> + * @sd_dac_out2: Configure SD DAC Output 2.
>> + */
>> +struct adv7343_sd_config {
>> + /* SD only Output Configuration */
>> + bool sd_dac_out1;
>> + bool sd_dac_out2;
>> +};
>> +
>> +/**
>> + * struct adv7343_platform_data - Pl
Re: [PATCH] omap3isp: Fix histogram regions
Hi Johannes,
On Friday 11 January 2013 16:00:19 Johannes Schellen wrote:
> From: Johannes Schellen
>
> This patch fixes a bug which causes all histogram regions to start in the
> top left corner of the image. The histogram region coordinates are 16 bit
> values which share a 32 bit register. The bug is due to the region end
> value assignments overwriting the region start values with zero.
> Signed-off-by: Johannes Schellen
Good catch, thanks.
I've applied the patch to my tree.
> ---
> The patch is against v3.8-rc3
>
> --- linux-3.8-rc3/drivers/media/platform/omap3isp/isphist.c.orig
> +++ linux-3.8-rc3/drivers/media/platform/omap3isp/isphist.c
> @@ -114,14 +114,14 @@ static void hist_setup_regs(struct ispst
> /* Regions size and position */
> for (c = 0; c < OMAP3ISP_HIST_MAX_REGIONS; c++) {
> if (c < conf->num_regions) {
> - reg_hor[c] = conf->region[c].h_start <<
> - ISPHIST_REG_START_SHIFT;
> - reg_hor[c] = conf->region[c].h_end <<
> - ISPHIST_REG_END_SHIFT;
> - reg_ver[c] = conf->region[c].v_start <<
> - ISPHIST_REG_START_SHIFT;
> - reg_ver[c] = conf->region[c].v_end <<
> - ISPHIST_REG_END_SHIFT;
> + reg_hor[c] = (conf->region[c].h_start <<
> + ISPHIST_REG_START_SHIFT)
> +| (conf->region[c].h_end <<
> + ISPHIST_REG_END_SHIFT);
> + reg_ver[c] = (conf->region[c].v_start <<
> + ISPHIST_REG_START_SHIFT)
> +| (conf->region[c].v_end <<
> + ISPHIST_REG_END_SHIFT);
> } else {
> reg_hor[c] = 0;
> reg_ver[c] = 0;
--
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
[PATCH 14/33] media: Convert to devm_ioremap_resource()
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Thierry Reding
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/platform/exynos-gsc/gsc-core.c | 8 +++-
drivers/media/platform/mx2_emmaprp.c | 6 +++---
drivers/media/platform/s3c-camif/camif-core.c | 8 +++-
drivers/media/platform/s5p-fimc/fimc-core.c| 8 +++-
drivers/media/platform/s5p-fimc/fimc-lite.c| 8 +++-
drivers/media/platform/s5p-fimc/mipi-csis.c| 8 +++-
drivers/media/platform/s5p-g2d/g2d.c | 8 +++-
drivers/media/platform/s5p-jpeg/jpeg-core.c| 8 +++-
drivers/media/platform/s5p-mfc/s5p_mfc.c | 8 +++-
drivers/media/platform/soc_camera/mx2_camera.c | 12 ++--
10 files changed, 33 insertions(+), 49 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 2b1b9f3..c1a0713 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1098,11 +1098,9 @@ static int gsc_probe(struct platform_device *pdev)
mutex_init(&gsc->lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- gsc->regs = devm_request_and_ioremap(dev, res);
- if (!gsc->regs) {
- dev_err(dev, "failed to map registers\n");
- return -ENOENT;
- }
+ gsc->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(gsc->regs))
+ return PTR_ERR(gsc->regs);
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
diff --git a/drivers/media/platform/mx2_emmaprp.c
b/drivers/media/platform/mx2_emmaprp.c
index 6b155d7..4b9e0a2 100644
--- a/drivers/media/platform/mx2_emmaprp.c
+++ b/drivers/media/platform/mx2_emmaprp.c
@@ -941,9 +941,9 @@ static int emmaprp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, pcdev);
- pcdev->base_emma = devm_request_and_ioremap(&pdev->dev, res_emma);
- if (!pcdev->base_emma) {
- ret = -ENXIO;
+ pcdev->base_emma = devm_ioremap_resource(&pdev->dev, res_emma);
+ if (IS_ERR(pcdev->base_emma)) {
+ ret = PTR_ERR(pcdev->base_emma);
goto rel_vdev;
}
diff --git a/drivers/media/platform/s3c-camif/camif-core.c
b/drivers/media/platform/s3c-camif/camif-core.c
index e2716c3..09a8c9c 100644
--- a/drivers/media/platform/s3c-camif/camif-core.c
+++ b/drivers/media/platform/s3c-camif/camif-core.c
@@ -433,11 +433,9 @@ static int s3c_camif_probe(struct platform_device *pdev)
mres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- camif->io_base = devm_request_and_ioremap(dev, mres);
- if (!camif->io_base) {
- dev_err(dev, "failed to obtain I/O memory\n");
- return -ENOENT;
- }
+ camif->io_base = devm_ioremap_resource(dev, mres);
+ if (IS_ERR(camif->io_base))
+ return PTR_ERR(camif->io_base);
ret = camif_request_irqs(pdev, camif);
if (ret < 0)
diff --git a/drivers/media/platform/s5p-fimc/fimc-core.c
b/drivers/media/platform/s5p-fimc/fimc-core.c
index 545b46a..acc0f84 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.c
+++ b/drivers/media/platform/s5p-fimc/fimc-core.c
@@ -909,11 +909,9 @@ static int fimc_probe(struct platform_device *pdev)
mutex_init(&fimc->lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- fimc->regs = devm_request_and_ioremap(&pdev->dev, res);
- if (fimc->regs == NULL) {
- dev_err(&pdev->dev, "Failed to obtain io memory\n");
- return -ENOENT;
- }
+ fimc->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(fimc->regs))
+ return PTR_ERR(fimc->regs);
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res == NULL) {
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index ed67220..67db9f8 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -1426,11 +1426,9 @@ static int fimc_lite_probe(struct platform_device *pdev)
mutex_init(&fimc->lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- fimc->regs = devm_request_and_ioremap(&pdev->dev, res);
- if (fimc->regs == NULL) {
- dev_err(&pdev->dev, "Failed to obtain io memory\n");
- return -ENOENT;
- }
+ fimc->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(fimc->regs))
+ return PTR_ERR(fimc->regs);
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res == NUL
Re: [PATCH] omap3isp: Add support for interlaced input data
Hi William, On Monday 14 January 2013 14:21:29 William Swanson wrote: > On 01/09/2013 02:35 PM, Laurent Pinchart wrote: > > On Tuesday 08 January 2013 14:49:41 William Swanson wrote: > >> I believe the data is combined in a single buffer, with alternate fields > >> interleaved. > > > > Could you please double-check that ? I'd like to be sure, not just believe > > :-) > > Sorry for the delay in getting back to you. I have checked it, and the > fields are indeed interlaced into a single buffer. On the other hand, > looking at this caused me to discover another problem with the patch. > > According to the TI documentation, the CCDC_SDOFST register controls the > deinterlacing process. My patch never configures this register, however, > which is surprising. The reason things work on our boards is because we are > carrying a separate patch which changes the register by accident. Oops! I > have fixed this, and will be sending another patch with the CCDC_SDOFST > changes. > > > In that case the OMAP3 ISP driver should set the v4l2_pix_format::field to > > V4L2_FIELD_INTERLACED in the format-related ioctl when an interlaced > > format is used. I suppose this could be added later - Sakari, any opinion > > ? > > I don't have a lot of time to work on this stuff, so my main focus is just > getting the data to flow. Changing the output format information involves > other parts of the driver that I am not familiar with, so I don't know if I > will be able to work on that bit. OK. I will wait for the patch you mention above and I will then try to fix the field reporting issue. I might need your help to test the result. > By the way, thanks for taking the time to review this, Laurent. You're welcome. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] uvc: Replace memcpy with struct assignment
Hi,
On Monday 14 January 2013 15:22:55 Ezequiel Garcia wrote:
> This kind of memcpy() is error-prone. Its replacement with a struct
> assignment is prefered because it's type-safe and much easier to read.
>
> Cc: Laurent Pinchart
> Signed-off-by: Peter Senna Tschudin
> Signed-off-by: Ezequiel Garcia
Thank you for the patch. I've applied it to my tree.
> ---
> Changes from v1:
> * Replaced a memcpy() in ucv_ctrl_add_info(),
>originally missed by the coccinelle script.
>
> drivers/media/usb/uvc/uvc_ctrl.c |2 +-
> drivers/media/usb/uvc/uvc_v4l2.c |6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index 516a5b1..f2f6443 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1839,7 +1839,7 @@ static int uvc_ctrl_add_info(struct uvc_device *dev,
> struct uvc_control *ctrl, {
> int ret = 0;
>
> - memcpy(&ctrl->info, info, sizeof(*info));
> + ctrl->info = *info;
> INIT_LIST_HEAD(&ctrl->info.mappings);
>
> /* Allocate an array to save control values (cur, def, max, etc.) */
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
> b/drivers/media/usb/uvc/uvc_v4l2.c index 8e05604..36e79ed 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -315,7 +315,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming
> *stream, goto done;
> }
>
> - memcpy(&stream->ctrl, &probe, sizeof probe);
> + stream->ctrl = probe;
> stream->cur_format = format;
> stream->cur_frame = frame;
>
> @@ -387,7 +387,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming
> *stream, return -EBUSY;
> }
>
> - memcpy(&probe, &stream->ctrl, sizeof probe);
> + probe = stream->ctrl;
> probe.dwFrameInterval =
> uvc_try_frame_interval(stream->cur_frame, interval);
>
> @@ -398,7 +398,7 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming
> *stream, return ret;
> }
>
> - memcpy(&stream->ctrl, &probe, sizeof probe);
> + stream->ctrl = probe;
> mutex_unlock(&stream->mutex);
>
> /* Return the actual frame period. */
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: adv7343: accept configuration through platform data
On Tue January 15 2013 09:00:53 Lad, Prabhakar wrote:
> The current code was implemented with some default configurations,
> this default configuration works on board and doesn't work on other.
>
> This patch accepts the configuration through platform data and configures
> the encoder depending on the data set.
Just one small comment...
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/i2c/adv7343.c | 36 +++-
> include/media/adv7343.h | 32
> 2 files changed, 63 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
> index 2b5aa67..a058058 100644
> --- a/drivers/media/i2c/adv7343.c
> +++ b/drivers/media/i2c/adv7343.c
> @@ -43,6 +43,7 @@ MODULE_PARM_DESC(debug, "Debug level 0-1");
> struct adv7343_state {
> struct v4l2_subdev sd;
> struct v4l2_ctrl_handler hdl;
> + const struct adv7343_platform_data *pdata;
> u8 reg00;
> u8 reg01;
> u8 reg02;
> @@ -215,12 +216,23 @@ static int adv7343_setoutput(struct v4l2_subdev *sd,
> u32 output_type)
> /* Enable Appropriate DAC */
> val = state->reg00 & 0x03;
>
> - if (output_type == ADV7343_COMPOSITE_ID)
> - val |= ADV7343_COMPOSITE_POWER_VALUE;
> - else if (output_type == ADV7343_COMPONENT_ID)
> - val |= ADV7343_COMPONENT_POWER_VALUE;
> + /* configure default configuration */
> + if (!state->pdata)
> + if (output_type == ADV7343_COMPOSITE_ID)
> + val |= ADV7343_COMPOSITE_POWER_VALUE;
> + else if (output_type == ADV7343_COMPONENT_ID)
> + val |= ADV7343_COMPONENT_POWER_VALUE;
> + else
> + val |= ADV7343_SVIDEO_POWER_VALUE;
> else
> - val |= ADV7343_SVIDEO_POWER_VALUE;
> + val = state->pdata->mode_config.sleep_mode << 0 |
> + state->pdata->mode_config.pll_control << 1 |
> + state->pdata->mode_config.dac_3 << 2 |
> + state->pdata->mode_config.dac_2 << 3 |
> + state->pdata->mode_config.dac_1 << 4 |
> + state->pdata->mode_config.dac_6 << 5 |
> + state->pdata->mode_config.dac_5 << 6 |
> + state->pdata->mode_config.dac_4 << 7;
>
> err = adv7343_write(sd, ADV7343_POWER_MODE_REG, val);
> if (err < 0)
> @@ -238,6 +250,17 @@ static int adv7343_setoutput(struct v4l2_subdev *sd, u32
> output_type)
>
> /* configure SD DAC Output 2 and SD DAC Output 1 bit to zero */
> val = state->reg82 & (SD_DAC_1_DI & SD_DAC_2_DI);
> +
> + if (state->pdata && state->pdata->sd_config.sd_dac_out1)
> + val = val | (state->pdata->sd_config.sd_dac_out1 << 1);
> + else if (state->pdata && !state->pdata->sd_config.sd_dac_out1)
> + val = val & ~(state->pdata->sd_config.sd_dac_out1 << 1);
> +
> + if (state->pdata && state->pdata->sd_config.sd_dac_out2)
> + val = val | (state->pdata->sd_config.sd_dac_out2 << 2);
> + else if (state->pdata && !state->pdata->sd_config.sd_dac_out2)
> + val = val & ~(state->pdata->sd_config.sd_dac_out2 << 2);
> +
> err = adv7343_write(sd, ADV7343_SD_MODE_REG2, val);
> if (err < 0)
> goto setoutput_exit;
> @@ -401,6 +424,9 @@ static int adv7343_probe(struct i2c_client *client,
> if (state == NULL)
> return -ENOMEM;
>
> + /* Copy board specific information here */
> + state->pdata = client->dev.platform_data;
> +
> state->reg00= 0x80;
> state->reg01= 0x00;
> state->reg02= 0x20;
> diff --git a/include/media/adv7343.h b/include/media/adv7343.h
> index d6f8a4e..8086e46 100644
> --- a/include/media/adv7343.h
> +++ b/include/media/adv7343.h
> @@ -20,4 +20,36 @@
> #define ADV7343_COMPONENT_ID (1)
> #define ADV7343_SVIDEO_ID(2)
>
> +struct adv7343_power_mode {
> + bool sleep_mode;
> + bool pll_control;
> + bool dac_1;
> + bool dac_2;
> + bool dac_3;
> + bool dac_4;
> + bool dac_5;
> + bool dac_6;
> +};
Can you add a short description for struct adv7343_power_mode? It's
sufficient to point to the relevant section in the datasheet (add a url
or something like that).
Regards,
Hans
> +
> +/**
> + * struct adv7343_sd_config - SD Only Output Configuration.
> + * @sd_dac_out1: Configure SD DAC Output 1.
> + * @sd_dac_out2: Configure SD DAC Output 2.
> + */
> +struct adv7343_sd_config {
> + /* SD only Output Configuration */
> + bool sd_dac_out1;
> + bool sd_dac_out2;
> +};
> +
> +/**
> + * struct adv7343_platform_data - Platform data values and access functions.
> + * @mode_config: Configuration for power mode.
> + * @sd_config: SD Only Configuration.
> + */
> +struct adv7343_platform_data {
> + struct adv7343_power_mode mode_config;
> + struct adv7343_sd_config sd_config;
> +};
Re: [PATCH] media: tvp514x: remove field description
On Tue January 15 2013 08:55:40 Lad, Prabhakar wrote:
> This patch removes the field description of fields that no
> longer exists, along side aligns the field description of
> fields.
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> include/media/tvp514x.h |7 ++-
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/include/media/tvp514x.h b/include/media/tvp514x.h
> index 74387e8..86ed7e8 100644
> --- a/include/media/tvp514x.h
> +++ b/include/media/tvp514x.h
> @@ -96,12 +96,9 @@ enum tvp514x_output {
>
> /**
> * struct tvp514x_platform_data - Platform data values and access functions.
> - * @power_set: Power state access function, zero is off, non-zero is on.
> - * @ifparm: Interface parameters access function.
> - * @priv_data_set: Device private data (pointer) access function.
> * @clk_polarity: Clock polarity of the current interface.
> - * @ hs_polarity: HSYNC Polarity configuration for current interface.
> - * @ vs_polarity: VSYNC Polarity configuration for current interface.
> + * @hs_polarity: HSYNC Polarity configuration for current interface.
> + * @vs_polarity: VSYNC Polarity configuration for current interface.
> */
> struct tvp514x_platform_data {
> /* Interface control params */
>
--
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: [cx231xx] Support for Arm / Omap working at all?
On Thu January 17 2013 08:31:50 Jan Stumpf wrote: > Hi! > > I'm trying to get an Hauppauge Live Usb 2 video grabber to run on on Omap4 > (Gumstix Duovero). I'm using Sakomans omap-3.6 head kernel sources from > http://git.sakoman.com/git/gitweb.cgi?p=linux.git;a=summary . The hardware is > successfully detected on the USB host port, the driver loads perfectly > including the firmware. With v4l2-ctl --all I can see if thee video signal on > the composite port is ok or if the sync is lost, but as soon as I use any > v4l2 software (e.g. yavta) to grab some images the driver uses 100% of the > cpu, returns the first image and after some seconds I see EPROTO (-71) errors > in dmesg. First I get " cx231xx #0: can't change interface 3 alt. no to 0 > (err=-71)" and then "UsbInterface::sendCommand, failed with status --71" > > I did the following tests: > > - checked that all patches I found (e.g from > http://git.linuxtv.org/mchehab/cx231xx.git) are included in my kernel, > including the URB DMA related patches and the timing patches > - tried the same on an Gumstix Overo (Overo Fire and Overo WarerStorm) on > several different header boards. > - tried older kernels (3.2 and 2.6.32) with rougly the same results or known > errors due to missing patches > > Unfortunately I can't use other capture devices because the final hardware is > custom made with the cx23102 chip :-( I could use an omap3 instead of an > omap4, but omap4 is preferred. > > My questions are: > > - Did anybody ever used the cx231xx driver with an omap3 or omap4 > successfully? I'm pretty sure the answer is that you're the first to try it. > - If yes, could you let me know the kernel version and maybe the config? > - Any hints what I could try? I'm an expirienced embedded C programmer but I > dont have much expirience in USB kernel drivers. A few months back I was working on improving this driver and I made a number of fixes that are available in my git tree: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cx231xx In particular this patch might be relevant: http://git.linuxtv.org/hverkuil/media_tree.git/commit/7bcf29cf460569c523b15d3c0dfed1397a7b770e Regards, Hans > > Any help is greatly appriciated! > > Thanks in Advance! > > Jan-- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] noon010p30: Remove unneeded v4l2 control compatibility ops
On Sat January 19 2013 22:38:13 Sylwester Nawrocki wrote:
> All host drivers using this subdev driver are already converted
> to use the control framework so the compatibility ops can be dropped.
>
> Signed-off-by: Sylwester Nawrocki
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/i2c/noon010pc30.c |7 ---
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/i2c/noon010pc30.c b/drivers/media/i2c/noon010pc30.c
> index 440c129..8554b47 100644
> --- a/drivers/media/i2c/noon010pc30.c
> +++ b/drivers/media/i2c/noon010pc30.c
> @@ -660,13 +660,6 @@ static const struct v4l2_ctrl_ops noon010_ctrl_ops = {
>
> static const struct v4l2_subdev_core_ops noon010_core_ops = {
> .s_power= noon010_s_power,
> - .g_ctrl = v4l2_subdev_g_ctrl,
> - .s_ctrl = v4l2_subdev_s_ctrl,
> - .queryctrl = v4l2_subdev_queryctrl,
> - .querymenu = v4l2_subdev_querymenu,
> - .g_ext_ctrls= v4l2_subdev_g_ext_ctrls,
> - .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
> - .s_ext_ctrls= v4l2_subdev_s_ext_ctrls,
> .log_status = noon010_log_status,
> };
>
>
--
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 V2 24/24] v4l2-core/v4l2-common.c: use IS_ENABLED() macro
On Sun January 20 2013 00:41:31 Peter Senna Tschudin wrote:
> replace:
> #if defined(CONFIG_MEDIA_TUNER_TEA5761) || \
> defined(CONFIG_MEDIA_TUNER_TEA5761_MODULE)
> with:
> #if IS_ENABLED(CONFIG_MEDIA_TUNER_TEA5761)
>
> This change was made for: CONFIG_MEDIA_TUNER_TEA5761
>
> Also replaced:
> #if defined(CONFIG_I2C) || (defined(CONFIG_I2C_MODULE) && defined(MODULE))
> with:
> #if IS_ENABLED(CONFIG_I2C)
>
> Reported-by: Mauro Carvalho Chehab
> Signed-off-by: Peter Senna Tschudin
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> Changes from V1:
>Updated subject
>Fixed commit message
>
> drivers/media/v4l2-core/v4l2-common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c
> b/drivers/media/v4l2-core/v4l2-common.c
> index 614316f..aa044f4 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -238,7 +238,7 @@ int v4l2_chip_match_host(const struct v4l2_dbg_match
> *match)
> }
> EXPORT_SYMBOL(v4l2_chip_match_host);
>
> -#if defined(CONFIG_I2C) || (defined(CONFIG_I2C_MODULE) && defined(MODULE))
> +#if IS_ENABLED(CONFIG_I2C)
> int v4l2_chip_match_i2c_client(struct i2c_client *c, const struct
> v4l2_dbg_match *match)
> {
> int len;
> @@ -384,7 +384,7 @@ EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_addr);
> const unsigned short *v4l2_i2c_tuner_addrs(enum v4l2_i2c_tuner_type type)
> {
> static const unsigned short radio_addrs[] = {
> -#if defined(CONFIG_MEDIA_TUNER_TEA5761) ||
> defined(CONFIG_MEDIA_TUNER_TEA5761_MODULE)
> +#if IS_ENABLED(CONFIG_MEDIA_TUNER_TEA5761)
> 0x10,
> #endif
> 0x60,
>
--
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/3] V4L: Add driver for OV9650/52 image sensors
On Sat January 19 2013 22:27:22 Sylwester Nawrocki wrote:
> This patch adds V4L2 sub-device driver for OV9650/OV9652 image sensors.
>
> The driver exposes following V4L2 controls:
> - auto/manual exposure,
> - auto/manual white balance,
> - auto/manual gain,
> - brightness, saturation, sharpness,
> - horizontal/vertical flip,
> - color bar test pattern,
> - banding filter (power line frequency).
>
> Frame rate can be configured with g/s_frame_interval pad level ops.
> Supported resolution are only: SXGA, VGA, QVGA.
>
> Signed-off-by: Sylwester Nawrocki
Some small comments:
> +
> +static int ov965x_log_status(struct v4l2_subdev *sd)
> +{
> + v4l2_ctrl_handler_log_status(sd->ctrl_handler, sd->name);
> + return 0;
> +}
A short helper function (v4l2_ctrl_subdev_log_status) would simplify this
as that can be used as a core op directly.
> +
> +
> +static int ov965x_subscribe_event(struct v4l2_subdev *sd, struct v4l2_fh *fh,
> + struct v4l2_event_subscription *sub)
> +{
> + return v4l2_ctrl_subscribe_event(fh, sub);
> +}
> +
> +static int ov965x_unsubscribe_event(struct v4l2_subdev *sd, struct v4l2_fh
> *fh,
> + struct v4l2_event_subscription *sub)
> +{
> + return v4l2_event_unsubscribe(fh, sub);
> +}
I suggest that two helper functions are added (v4l2_ctrl_subdev_subscribe_event
and v4l2_event_subdev_unsubscribe) that can be used as a core op directly.
> diff --git a/include/media/ov9650.h b/include/media/ov9650.h
> new file mode 100644
> index 000..2fab780
> --- /dev/null
> +++ b/include/media/ov9650.h
> @@ -0,0 +1,27 @@
> +/*
> + * OV9650/OV9652 camera sensors driver
> + *
> + * Copyright (C) 2013 Sylwester Nawrocki
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef OV9650_H_
> +#define OV9650_H_
> +
> +/**
> + * struct ov9650_platform_data - ov9650 driver platform data
> + * @mclk_frequency: the sensor's master clock frequency
What's the unit? Hz?
> + * @gpio_pwdn: number of a GPIO connected to OV965X PWDN pin
> + * @gpio_reset: number of a GPIO connected to OV965X RESET pin
> + *
> + * If any of @gpio_pwdn or @gpio_reset are unused then should be
s/then should/then they should/
> + * set to negative value. @mclk_frequency must always be specified.
s/set to/set to a/
> + */
> +struct ov9650_platform_data {
> + unsigned long mclk_frequency;
> + int gpio_pwdn;
> + int gpio_reset;
> +};
> +#endif /* OV9650_H_ */
>
Regards,
Hans
--
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 1/4] tda8290: Allow disabling I2C gate
On 01/21/2013 10:18 AM, Ondrej Zary wrote: On Monday 21 January 2013, Antti Palosaari wrote: On 01/20/2013 11:22 PM, Ondrej Zary wrote: Allow disabling I2C gate handling by external configuration. This is required by cards that have all devices on a single I2C bus, like AverMedia A706. My personal opinion is that I2C gate control should be disabled setting callback to NULL (same for the other unwanted callbacks too). There is checks for callback existence in DVB-core, it does not call callback if it is NULL. This is TDA8290 internal I2C gate which is used by tda8290 internally and also by tda827x or tda18271. That sounds like there is some logical problems in the driver then, not split correctly? What I think, scenario is tda8290 is analog decoder, tda18271 is silicon tuner, which is connected (usually) to the tda8290 I2C bus. tda18271 calls tda8290 I2C-gate control when needed. Analog or digital demod should not call its own I2C gate directly - and if it was done in some weird reason then it should call own callback conditionally, checking whether or not it is NULL. regards 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
Re: [PATCH 1/3] [media] Add header file defining standard image sizes
On Sat January 19 2013 22:27:20 Sylwester Nawrocki wrote: > Add common header file defining standard image sizes, so we can > avoid redefining those in each driver. > > Signed-off-by: Sylwester Nawrocki > --- > include/media/image-sizes.h | 34 ++ Since this is a v4l2 core header it should be renamed with a 'v4l2-' prefix. Regards, Hans > 1 files changed, 34 insertions(+), 0 deletions(-) > create mode 100644 include/media/image-sizes.h > > diff --git a/include/media/image-sizes.h b/include/media/image-sizes.h > new file mode 100644 > index 000..10daf92 > --- /dev/null > +++ b/include/media/image-sizes.h > @@ -0,0 +1,34 @@ > +/* > + * Standard image size definitions > + * > + * Copyright (C) 2013, Sylwester Nawrocki > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > +#ifndef _IMAGE_SIZES_H > +#define _IMAGE_SIZES_H > + > +#define CIF_WIDTH352 > +#define CIF_HEIGHT 288 > + > +#define QCIF_WIDTH 176 > +#define QCIF_HEIGHT 144 > + > +#define QQCIF_WIDTH 88 > +#define QQCIF_HEIGHT 72 > + > +#define QQVGA_WIDTH 160 > +#define QQVGA_HEIGHT 120 > + > +#define QVGA_WIDTH 320 > +#define QVGA_HEIGHT 240 > + > +#define SXGA_WIDTH 1280 > +#define SXGA_HEIGHT 1024 > + > +#define VGA_WIDTH640 > +#define VGA_HEIGHT 480 > + > +#endif /* _IMAGE_SIZES_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
Re: V4L2 spec / core questions
On Sun January 20 2013 22:15:51 Frank Schäfer wrote: > Hi Hans, > > I noticed that there's code in the v4l2 core that enables/disables > ioctls and checks some of the parameters depending on the device type. > While reading the code an comparing it to the V4L2 API document, some > more questions came up: > > 1) Video devices with VBI functionality: > The spec says: "To address the problems of finding related video and VBI > devices VBI capturing and output is also available as device function > under /dev/video". > Is that still valid ? No, that's not valid. It really was never valid: most drivers didn't implement this, and those that did likely didn't work. During one of the media summits we decided not to allow this. Allowing VBI functionality in video node has a number of problems: 1) it's confusing: why have a vbi node at all if you can do it with a video node as well? In fact, applications always use the vbi node for vbi data. 2) it breaks down when you want to read() the data: read() can handle only one 'format' at a time. So if you want to read both video and vbi at the same time then you need to nodes. 3) it makes drivers quite complex: separating this functionality in distinct nodes makes life much easier. > What about VBI "configuration" (e.g. > VIDIOC_G/S/TRY_FMT for VBI formats) ? > Looking into the v4l2 core code, it seems that the VBI buffer types > (field "type" in struct v4l2_format) are only accepted, if the device is > a VBI device. That's correct. I've added these checks because drivers often didn't test that themselves. It's also much easier to test in the v4l2 core than repeating the same test in every driver. > > 2) VIDIOC_G/S/TRY_FMT and VBI devices: > The sepc says: "VBI devices must implement both the VIDIOC_G_FMT and > VIDIOC_S_FMT ioctl, even if VIDIOC_S_FMT ignores all requests and always > returns default parameters as VIDIOC_G_FMT does. VIDIOC_TRY_FMT is > optional." What's the reason for this ? Is it still valid ? This is still valid (in fact, v4l2-compliance requires the presence of TRY_FMT as well as I don't think there is a good reason not to implement it). The reason for this is that this simplifies applications: no need to test for the presence of S_FMT. > > 3) VIDIOC_S_TUNER: field "type" in struct v4l2_tuner > Are radio tuners accessable through video devices (and the other way > around) ? Not anymore. This used to be possible, although because it was never properly tested most drivers probably didn't implement that correctly. The radio API has always been a bit messy and we have been slowly cleaning it up. > Has this field to be set by the application ? No, it is filled in by the core based on the device node used. This follows the spec which does not require apps to set the type. > If yes: driver overwrites > the value or returns with an error if the type doesn't match the tuner > at the requested index ? > I wonder if it would make sense to check the tuner type inside the v4l > core (like the fmt/buffer type check for G/S_PARM). > > 4) VIDIOC_DBG_G_CHIP_IDENT: > Is it part of CONFIG_VIDEO_ADV_DEBUG just like VIDIOC_DBG_G/S_REGISTER ? No. It just returns some chip info, it doesn't access the hardware, so there is no need to put it under ADV_DEBUG. > In determine_valid_ioctls(), it is placed outside the #ifdef > CONFIG_VIDEO_ADV_DEBUG section. > The spec says "Identify the chips on a TV card" but isn't it suitable > for all device types (radio/video/vbi) ? That's correct. A patch is welcome :-) > determine_valid_ioctls() in > v4l2-dev.c enables it for all devices. > > 5) The buffer ioctls (VIDIOC_REQBUFS, VIDIOC_CREATE_BUFS, > VIDIOC_PREPARE_BUF, VIDIOC_QUERYBUF, VIDIOC_QBUF, VIDIOC_DQBUF) are not > applicable to radio devices, right ? That's correct. > In function determine_valid_ioctls() in v4l2-dev.c they are enabled for > all device types. A patch fixing this is welcome! > 6) VIDIOC_G/S_AUDIO: Shouldn't it be disabled in > determine_valid_ioctls() for VBI devices ? No. VBI devices still allow this. Strictly speaking it isn't useful for vbi devices, but allowing G/S_INPUT but not G/S_AUDIO feels inconsistent to me. While it isn't useful, it doesn't hurt either. > Btw: function determine_valid_ioctls() in v4l2-dev.c is a good summary > that explains which ioctls are suitable for which device types > (radio/video/vbi). > Converting its content into a table would be a great > extension/clarifaction of the V4L2 API spec document ! We played around with the idea of 'profiles' where for each type of device you have a table listing what can and cannot be done. The problem is time... If you are interesting in pursuing this, then I am happy to help with advice and pointers (v4l2-compliance is also a great source of information). > Thanks for your patience ! My pleasure! Regards, Hans -- 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
Re: [PATCH 2/3] v4l2-ctrl: Add helper function for control range update
Hi Sylwester!
On Sat January 19 2013 22:27:21 Sylwester Nawrocki wrote:
> This patch adds a helper function that allows to modify range,
> i.e. minimum, maximum, step and default value of a v4l2 control,
> after the control has been created and initialized. This is helpful
> in situations when range of a control depends on user configurable
> parameters, e.g. camera sensor absolute exposure time depending on
> an output image resolution and frame rate.
>
> v4l2_ctrl_modify_range() function allows to modify range of an
> INTEGER, BOOL, MENU, INTEGER_MENU and BITMASK type controls.
>
> Based on a patch from Hans Verkuil http://patchwork.linuxtv.org/patch/8654.
>
> Signed-off-by: Sylwester Nawrocki
This is a very nice patch. I found only one small mistake:
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index f6ee201..d68fb57 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -2721,10 +2751,44 @@ int v4l2_ctrl_s_ctrl_int64(struct v4l2_ctrl *ctrl,
> s64 val)
> /* It's a driver bug if this happens. */
> WARN_ON(ctrl->type != V4L2_CTRL_TYPE_INTEGER64);
> c.value64 = val;
> - return set_ctrl(NULL, ctrl, &c);
> + return set_ctrl_lock(NULL, ctrl, &c);
> }
> EXPORT_SYMBOL(v4l2_ctrl_s_ctrl_int64);
>
> +int v4l2_ctrl_modify_range(struct v4l2_ctrl *ctrl,
> + s32 min, s32 max, u32 step, s32 def)
> +{
> + int ret = check_range(ctrl->type, min, max, step, def);
> + struct v4l2_ext_control c;
> +
> + switch (ctrl->type) {
> + case V4L2_CTRL_TYPE_INTEGER:
> + case V4L2_CTRL_TYPE_BOOLEAN:
> + case V4L2_CTRL_TYPE_MENU:
> + case V4L2_CTRL_TYPE_BITMASK:
TYPE_INTEGER_MENU is missing here!
> + if (ret)
> + return ret;
> + break;
> + default:
> + return -EINVAL;
> + }
> + v4l2_ctrl_lock(ctrl);
> + ctrl->minimum = min;
> + ctrl->maximum = max;
> + ctrl->step = step;
> + ctrl->default_value = def;
> + c.value = ctrl->cur.val;
> + if (validate_new(ctrl, &c))
> + c.value = def;
> + if (c.value != ctrl->cur.val)
> + ret = set_ctrl(NULL, ctrl, &c, V4L2_EVENT_CTRL_CH_RANGE);
> + else
> + send_event(NULL, ctrl, V4L2_EVENT_CTRL_CH_RANGE);
> + v4l2_ctrl_unlock(ctrl);
> + return ret;
> +}
> +EXPORT_SYMBOL(v4l2_ctrl_modify_range);
> +
> static int v4l2_ctrl_add_event(struct v4l2_subscribed_event *sev, unsigned
> elems)
> {
> struct v4l2_ctrl *ctrl = v4l2_ctrl_find(sev->fh->ctrl_handler, sev->id);
After correcting that missing case you can add my ack:
Acked-by: Hans Verkuil
Regards,
Hans
--
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 1/4] tda8290: Allow disabling I2C gate
On Monday 21 January 2013, Antti Palosaari wrote:
> On 01/20/2013 11:22 PM, Ondrej Zary wrote:
> > Allow disabling I2C gate handling by external configuration.
> > This is required by cards that have all devices on a single I2C bus,
> > like AverMedia A706.
>
> My personal opinion is that I2C gate control should be disabled setting
> callback to NULL (same for the other unwanted callbacks too). There is
> checks for callback existence in DVB-core, it does not call callback if
> it is NULL.
This is TDA8290 internal I2C gate which is used by tda8290 internally and also
by tda827x or tda18271.
> regards
> Antti
>
> > Signed-off-by: Ondrej Zary
> > ---
> > drivers/media/tuners/tda8290.c | 13 +++--
> > drivers/media/tuners/tda8290.h |1 +
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/tuners/tda8290.c
> > b/drivers/media/tuners/tda8290.c index 8c48521..16dfbf2 100644
> > --- a/drivers/media/tuners/tda8290.c
> > +++ b/drivers/media/tuners/tda8290.c
> > @@ -54,6 +54,7 @@ struct tda8290_priv {
> > #define TDA18271 16
> >
> > struct tda827x_config cfg;
> > + bool no_i2c_gate;
> > };
> >
> >
> > /*-*/
> > @@ -66,6 +67,9 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe,
> > int close) unsigned char disable[2] = { 0x21, 0x00 };
> > unsigned char *msg;
> >
> > + if (priv->no_i2c_gate)
> > + return 0;
> > +
> > if (close) {
> > msg = enable;
> > tuner_i2c_xfer_send(&priv->i2c_props, msg, 2);
> > @@ -88,6 +92,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe,
> > int close) unsigned char buf[3] = { 0x45, 0x01, 0x00 };
> > unsigned char *msg;
> >
> > + if (priv->no_i2c_gate)
> > + return 0;
> > +
> > if (close) {
> > msg = enable;
> > tuner_i2c_xfer_send(&priv->i2c_props, msg, 2);
> > @@ -740,8 +747,10 @@ struct dvb_frontend *tda829x_attach(struct
> > dvb_frontend *fe, priv->i2c_props.addr = i2c_addr;
> > priv->i2c_props.adap = i2c_adap;
> > priv->i2c_props.name = "tda829x";
> > - if (cfg)
> > - priv->cfg.config = cfg->lna_cfg;
> > + if (cfg) {
> > + priv->cfg.config = cfg->lna_cfg;
> > + priv->no_i2c_gate = cfg->no_i2c_gate;
> > + }
> >
> > if (tda8290_probe(&priv->i2c_props) == 0) {
> > priv->ver = TDA8290;
> > diff --git a/drivers/media/tuners/tda8290.h
> > b/drivers/media/tuners/tda8290.h index 7e288b2..9959cc8 100644
> > --- a/drivers/media/tuners/tda8290.h
> > +++ b/drivers/media/tuners/tda8290.h
> > @@ -26,6 +26,7 @@ struct tda829x_config {
> > unsigned int probe_tuner:1;
> > #define TDA829X_PROBE_TUNER 0
> > #define TDA829X_DONT_PROBE 1
> > + unsigned int no_i2c_gate:1;
> > };
> >
> > #if defined(CONFIG_MEDIA_TUNER_TDA8290) ||
> > (defined(CONFIG_MEDIA_TUNER_TDA8290_MODULE) && defined(MODULE))
--
Ondrej Zary
--
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 1/4] tda8290: Allow disabling I2C gate
On 01/20/2013 11:22 PM, Ondrej Zary wrote:
Allow disabling I2C gate handling by external configuration.
This is required by cards that have all devices on a single I2C bus,
like AverMedia A706.
My personal opinion is that I2C gate control should be disabled setting
callback to NULL (same for the other unwanted callbacks too). There is
checks for callback existence in DVB-core, it does not call callback if
it is NULL.
regards
Antti
Signed-off-by: Ondrej Zary
---
drivers/media/tuners/tda8290.c | 13 +++--
drivers/media/tuners/tda8290.h |1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
index 8c48521..16dfbf2 100644
--- a/drivers/media/tuners/tda8290.c
+++ b/drivers/media/tuners/tda8290.c
@@ -54,6 +54,7 @@ struct tda8290_priv {
#define TDA18271 16
struct tda827x_config cfg;
+ bool no_i2c_gate;
};
/*-*/
@@ -66,6 +67,9 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int
close)
unsigned char disable[2] = { 0x21, 0x00 };
unsigned char *msg;
+ if (priv->no_i2c_gate)
+ return 0;
+
if (close) {
msg = enable;
tuner_i2c_xfer_send(&priv->i2c_props, msg, 2);
@@ -88,6 +92,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int
close)
unsigned char buf[3] = { 0x45, 0x01, 0x00 };
unsigned char *msg;
+ if (priv->no_i2c_gate)
+ return 0;
+
if (close) {
msg = enable;
tuner_i2c_xfer_send(&priv->i2c_props, msg, 2);
@@ -740,8 +747,10 @@ struct dvb_frontend *tda829x_attach(struct dvb_frontend
*fe,
priv->i2c_props.addr = i2c_addr;
priv->i2c_props.adap = i2c_adap;
priv->i2c_props.name = "tda829x";
- if (cfg)
- priv->cfg.config = cfg->lna_cfg;
+ if (cfg) {
+ priv->cfg.config = cfg->lna_cfg;
+ priv->no_i2c_gate = cfg->no_i2c_gate;
+ }
if (tda8290_probe(&priv->i2c_props) == 0) {
priv->ver = TDA8290;
diff --git a/drivers/media/tuners/tda8290.h b/drivers/media/tuners/tda8290.h
index 7e288b2..9959cc8 100644
--- a/drivers/media/tuners/tda8290.h
+++ b/drivers/media/tuners/tda8290.h
@@ -26,6 +26,7 @@ struct tda829x_config {
unsigned int probe_tuner:1;
#define TDA829X_PROBE_TUNER 0
#define TDA829X_DONT_PROBE 1
+ unsigned int no_i2c_gate:1;
};
#if defined(CONFIG_MEDIA_TUNER_TDA8290) ||
(defined(CONFIG_MEDIA_TUNER_TDA8290_MODULE) && defined(MODULE))
--
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
