Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D
On 6 February 2013 13:02, Inki Dae inki@samsung.com wrote: Looks good to me but please add document for it. Yes. I will. I was planning to send the bindings document patch along with the dt patches (adding node entries to dts files). Sylwester had suggested adding this to Documentation/devicetree/bindings/media/ which contains other media IPs. To other guys, And is there anyone who know where this document should be added to? I'm not sure that the g2d document should be placed in Documentation/devicetree/bindings/gpu, media, drm/exynos or arm/exynos. At least, this document should be shared with the g2d hw relevant drivers such as v4l2 and drm. So is .../bindings/gpu proper place? -- With warm regards, Sachin -- 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 2/2] drm/exynos: Add device tree based discovery support for G2D
-Original Message- From: Sachin Kamat [mailto:sachin.ka...@linaro.org] Sent: Wednesday, February 06, 2013 5:03 PM To: Inki Dae Cc: linux-media@vger.kernel.org; dri-de...@lists.freedesktop.org; devicetree-disc...@lists.ozlabs.org; k.deb...@samsung.com; s.nawro...@samsung.com; kgene@samsung.com; patc...@linaro.org; Ajay Kumar Subject: Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D On 6 February 2013 13:02, Inki Dae inki@samsung.com wrote: Looks good to me but please add document for it. Yes. I will. I was planning to send the bindings document patch along with the dt patches (adding node entries to dts files). Sylwester had suggested adding this to Documentation/devicetree/bindings/media/ which contains other media IPs. I think that it's better to go to gpu than media and we can divide Exynos IPs into the bellow categories, Media : mfc GPU : g2d, g3d, fimc, gsc Video : fimd, hdmi, eDP, MIPI-DSI And I think that the device-tree describes hardware so possibly, all documents in .../bindings/drm/exynos/* should be moved to proper place also. Please give me any opinions. Thanks, Inki Dae To other guys, And is there anyone who know where this document should be added to? I'm not sure that the g2d document should be placed in Documentation/devicetree/bindings/gpu, media, drm/exynos or arm/exynos. At least, this document should be shared with the g2d hw relevant drivers such as v4l2 and drm. So is .../bindings/gpu proper place? -- With warm regards, Sachin -- 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: [git:v4l-dvb/for_v3.9] [media] drivers/media/usb/dvb-usb/dib0700_core.c: fix left shift
Hello Mauro,
I do not agree with the patch. Let's take an example: adap-id = 0. Then:
* 1 ~(adap-id) = 1 ~(0) = 0
* ~(1 adap-id) = ~(1 0) = 0xFE
The correct change should be: st-channel_state |= 1 (1 - adap-id); Indeed,
the original source code was not correct.
Regards,
Olivier
-Message d'origine-
De : Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Envoyé : mardi 5 février 2013 22:04
À : linuxtv-comm...@linuxtv.org
Cc : Patrick BOETTCHER; Olivier GRENIE; Nickolai Zeldovich
Objet : [git:v4l-dvb/for_v3.9] [media]
drivers/media/usb/dvb-usb/dib0700_core.c: fix left shift
This is an automatic generated email to let you know that the following patch
were queued at the http://git.linuxtv.org/media_tree.git tree:
Subject: [media] drivers/media/usb/dvb-usb/dib0700_core.c: fix left shift
Author: Nickolai Zeldovich nicko...@csail.mit.edu
Date:Sat Jan 5 15:13:05 2013 -0300
Fix bug introduced in 7757ddda6f4febbc52342d82440dd4f7a7d4f14f, where instead
of bit-negating the bitmask, the bit position was bit-negated instead.
Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
Cc: Olivier Grenie olivier.gre...@dibcom.fr
Cc: Patrick Boettcher patrick.boettc...@dibcom.fr
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/usb/dvb-usb/dib0700_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=7e20f6bfc47992d93b36f4ed068782f8726b75a3
diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
b/drivers/media/usb/dvb-usb/dib0700_core.c
index bf2a908..bd6a437 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -584,7 +584,7 @@ int dib0700_streaming_ctrl(struct dvb_usb_adapter *adap,
int onoff)
if (onoff)
st-channel_state |=1 (adap-id);
else
- st-channel_state |=1 ~(adap-id);
+ st-channel_state = ~(1 (adap-id));
} else {
if (onoff)
st-channel_state |=1
(adap-fe_adap[0].stream.props.endpoint-2);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: ths7353: add support for ths7353 video amplifier
Hi Prabhakar,
Here is my review. There are a few things that need to be fixed before I
can Ack it.
On Tue 5 February 2013 20:20:21 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
The patch adds support for THS7353 video amplifier.
The the THS7353 amplifier is very much similar to the
existing THS7303 video amplifier driver.
This patch appropriately makes changes to the existing
ths7303 driver and adds support for the THS7353.
This patch also adds V4L2_IDENT_THS7353 for the THS7353
chip and appropriate changes to Kconfig file for building.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
Cc: Chaithrika U S chaithr...@ti.com
---
Changes for v2:
1: Merged the driver in existing ths7303 driver.
2: Merged the patch which adds the chip indent in same patch.
drivers/media/i2c/Kconfig |4 +-
drivers/media/i2c/ths7303.c | 334
+--
include/media/ths7303.h | 35
include/media/v4l2-chip-ident.h |3 +
4 files changed, 327 insertions(+), 49 deletions(-)
create mode 100644 include/media/ths7303.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 1e4b2d0..2e02916 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -563,9 +563,9 @@ comment Miscelaneous helper chips
config VIDEO_THS7303
tristate THS7303 Video Amplifier
- depends on I2C
+ depends on VIDEO_V4L2 I2C
help
- Support for TI THS7303 video amplifier
+ Support for TI THS7303/53 video amplifier
To compile this driver as a module, choose M here: the
module will be called ths7303.
diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
index e747524..e7f8c59 100644
--- a/drivers/media/i2c/ths7303.c
+++ b/drivers/media/i2c/ths7303.c
@@ -1,7 +1,15 @@
/*
- * ths7303- THS7303 Video Amplifier driver
+ * ths7303/53- THS7303/53 Video Amplifier driver
*
* Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates.
+ *
+ * Author: Chaithrika U S chaithr...@ti.com
+ *
+ * Contributors:
+ * Lad, Prabhakar prabhakar@ti.com
+ * Hans Verkuil hans.verk...@cisco.com
+ * Martin Bugge marbu...@cisco.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -13,25 +21,27 @@
* GNU General Public License for more details.
*/
-#include linux/kernel.h
-#include linux/init.h
-#include linux/ctype.h
-#include linux/slab.h
#include linux/i2c.h
-#include linux/device.h
-#include linux/delay.h
#include linux/module.h
-#include linux/uaccess.h
-#include linux/videodev2.h
+#include linux/slab.h
-#include media/v4l2-device.h
-#include media/v4l2-subdev.h
+#include media/ths7303.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-device.h
#define THS7303_CHANNEL_11
#define THS7303_CHANNEL_22
#define THS7303_CHANNEL_33
+struct ths7303_state {
+ struct v4l2_subdev sd;
+ struct ths7303_platform_data pdata;
+ struct v4l2_dv_timings dv_timings;
+ int std_id;
+ int stream_on;
+ int driver_data;
+};
+
enum ths7303_filter_mode {
THS7303_FILTER_MODE_480I_576I,
THS7303_FILTER_MODE_480P_576P,
@@ -48,64 +58,97 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Debug level 0-1);
+static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ths7303_state, sd);
+}
+
+static int ths7303_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ths7303_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i 3; i++) {
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ return ret;
+}
+
/* following function is used to set ths7303 */
int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
{
- u8 input_bias_chroma = 3;
- u8 input_bias_luma = 3;
- int disable = 0;
- int err = 0;
- u8 val = 0;
- u8 temp;
-
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ths7303_state *state = to_state(sd);
+ struct ths7303_platform_data *pdata = state-pdata;
+ u8 val, sel = 0;
+ int err, disable = 0;
if (!client)
return -EINVAL;
+ if (!state-stream_on) {
+ ths7303_write(sd, THS7303_CHANNEL_1,
+ (ths7303_read(sd,
Re: [PATCH v2] media: ths7353: add support for ths7353 video amplifier
Hi Hans,
Thanks for the review.
On Wed, Feb 6, 2013 at 2:33 PM, Hans Verkuil hansv...@cisco.com wrote:
Hi Prabhakar,
Here is my review. There are a few things that need to be fixed before I
can Ack it.
OK
On Tue 5 February 2013 20:20:21 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
The patch adds support for THS7353 video amplifier.
The the THS7353 amplifier is very much similar to the
existing THS7303 video amplifier driver.
This patch appropriately makes changes to the existing
ths7303 driver and adds support for the THS7353.
This patch also adds V4L2_IDENT_THS7353 for the THS7353
chip and appropriate changes to Kconfig file for building.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
Cc: Chaithrika U S chaithr...@ti.com
---
Changes for v2:
1: Merged the driver in existing ths7303 driver.
2: Merged the patch which adds the chip indent in same patch.
drivers/media/i2c/Kconfig |4 +-
drivers/media/i2c/ths7303.c | 334
+--
include/media/ths7303.h | 35
include/media/v4l2-chip-ident.h |3 +
4 files changed, 327 insertions(+), 49 deletions(-)
create mode 100644 include/media/ths7303.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 1e4b2d0..2e02916 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -563,9 +563,9 @@ comment Miscelaneous helper chips
config VIDEO_THS7303
tristate THS7303 Video Amplifier
- depends on I2C
+ depends on VIDEO_V4L2 I2C
help
- Support for TI THS7303 video amplifier
+ Support for TI THS7303/53 video amplifier
To compile this driver as a module, choose M here: the
module will be called ths7303.
diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
index e747524..e7f8c59 100644
--- a/drivers/media/i2c/ths7303.c
+++ b/drivers/media/i2c/ths7303.c
@@ -1,7 +1,15 @@
/*
- * ths7303- THS7303 Video Amplifier driver
+ * ths7303/53- THS7303/53 Video Amplifier driver
*
* Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates.
+ *
+ * Author: Chaithrika U S chaithr...@ti.com
+ *
+ * Contributors:
+ * Lad, Prabhakar prabhakar@ti.com
+ * Hans Verkuil hans.verk...@cisco.com
+ * Martin Bugge marbu...@cisco.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -13,25 +21,27 @@
* GNU General Public License for more details.
*/
-#include linux/kernel.h
-#include linux/init.h
-#include linux/ctype.h
-#include linux/slab.h
#include linux/i2c.h
-#include linux/device.h
-#include linux/delay.h
#include linux/module.h
-#include linux/uaccess.h
-#include linux/videodev2.h
+#include linux/slab.h
-#include media/v4l2-device.h
-#include media/v4l2-subdev.h
+#include media/ths7303.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-device.h
#define THS7303_CHANNEL_11
#define THS7303_CHANNEL_22
#define THS7303_CHANNEL_33
+struct ths7303_state {
+ struct v4l2_subdev sd;
+ struct ths7303_platform_data pdata;
+ struct v4l2_dv_timings dv_timings;
+ int std_id;
+ int stream_on;
+ int driver_data;
+};
+
enum ths7303_filter_mode {
THS7303_FILTER_MODE_480I_576I,
THS7303_FILTER_MODE_480P_576P,
@@ -48,64 +58,97 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Debug level 0-1);
+static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ths7303_state, sd);
+}
+
+static int ths7303_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ths7303_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i 3; i++) {
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ return ret;
+}
+
/* following function is used to set ths7303 */
int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
{
- u8 input_bias_chroma = 3;
- u8 input_bias_luma = 3;
- int disable = 0;
- int err = 0;
- u8 val = 0;
- u8 temp;
-
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ths7303_state *state = to_state(sd);
+ struct ths7303_platform_data *pdata = state-pdata;
+ u8 val, sel = 0;
+ int err, disable = 0;
if (!client)
return -EINVAL;
+ if (!state-stream_on) {
+
Re: [GIT PULL FOR v3.9] Move cx2341x from media/i2c to media/common
Em Wed, 6 Feb 2013 08:46:35 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Tue February 5 2013 19:49:41 Mauro Carvalho Chehab wrote: Hi Hans, Em Tue, 29 Jan 2013 09:56:20 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, The cx2341x module is a helper module for conexant-based MPEG encoders. It isn't an i2c module at all, instead it should be in common since it is used by 7 pci and usb drivers to handle the MPEG setup. It also shouldn't be visible in the config menu as it is always selected automatically by those drivers that need it. It should be noticed that the other non-i2c helper drivers also at the i2c directories: $ grep -L i2c_client drivers/media/i2c/*.c|grep -v mod drivers/media/i2c/aptina-pll.c drivers/media/i2c/btcx-risc.c drivers/media/i2c/cx2341x.c drivers/media/i2c/smiapp-pll.c A closer look may even hit some weird stuff, like tveeprom. This particular helper driver is not an I2C driver, although it has i2c_client symbol there, in order to optionally read the data via I2C, instead of receiving it via an API call. At least aptina-pll.c, smiapp-pll.c and tveeprom.c all have some relationship with i2c. True, but none of the three are actually i2c drivers; they're just shared functions used by drivers helper code. Hmm... $ git grep aptina-pll.h drivers/media/ drivers/media/i2c/aptina-pll.c:#include aptina-pll.h drivers/media/i2c/mt9m032.c:#include aptina-pll.h drivers/media/i2c/mt9p031.c:#include aptina-pll.h $ git grep smiapp-pll.h drivers/media/ drivers/media/i2c/smiapp-pll.c:#include smiapp-pll.h drivers/media/i2c/smiapp-pll.h: * drivers/media/i2c/smiapp-pll.h drivers/media/i2c/smiapp/smiapp.h:#include smiapp-pll.h $ git grep smiapp.h drivers/media/ drivers/media/i2c/smiapp/smiapp-core.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-limits.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-quirk.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-regs.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp.h: * drivers/media/i2c/smiapp/smiapp.h drivers/media/i2c/smiapp/smiapp.h:#include media/smiapp.h It could make sense to keep those two on I2c, eventually moving smapp-pl to i2c/smiapp. I have conflicting opinions here :) But cx2341x.c and btcx-risc.c do not have that at all. One reason for creating this patch was that I couldn't find the cx2341x.c code until I smiapp-pll.cdid a find. Also, I don't think cx2341x or any of those other helper drivers deserve each its own directory. I thought that the cx2341x.c source in common looked a bit lonely. But if we add other sources as well, then it has company :-) :) So, IMHO, the better is to just live them at the i2c directory. For cx2341x and btcx-risc the i2c directory is completely inappropriate. Nobody is ever going to guess that. Agreed. Those are just leftovers of the tree reorg, as the final patch at v4l side were to rename video to i2c. They might be moved, instead, to drivers/media/common (but without creating subdirs there). In any case, we should do the same for all those non-i2c helper drivers. Just moving cx2341x and letting the others there will just increase the mess. I've no problem moving cx2341x, btcx-risc and tveeprom to common. For the two pll sources I'd like to know if the authors agree (CC-ed) before I make a patch moving them to common. Fair enough. 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: [GIT PULL FOR v3.9] Move cx2341x from media/i2c to media/common
Hi Mauro, On Wednesday 06 February 2013 07:16:04 Mauro Carvalho Chehab wrote: Em Wed, 6 Feb 2013 08:46:35 +0100 Hans Verkuil escreveu: On Tue February 5 2013 19:49:41 Mauro Carvalho Chehab wrote: Em Tue, 29 Jan 2013 09:56:20 +0100 Hans Verkuil escreveu: Hi Mauro, The cx2341x module is a helper module for conexant-based MPEG encoders. It isn't an i2c module at all, instead it should be in common since it is used by 7 pci and usb drivers to handle the MPEG setup. It also shouldn't be visible in the config menu as it is always selected automatically by those drivers that need it. It should be noticed that the other non-i2c helper drivers also at the i2c directories: $ grep -L i2c_client drivers/media/i2c/*.c|grep -v mod drivers/media/i2c/aptina-pll.c drivers/media/i2c/btcx-risc.c drivers/media/i2c/cx2341x.c drivers/media/i2c/smiapp-pll.c A closer look may even hit some weird stuff, like tveeprom. This particular helper driver is not an I2C driver, although it has i2c_client symbol there, in order to optionally read the data via I2C, instead of receiving it via an API call. At least aptina-pll.c, smiapp-pll.c and tveeprom.c all have some relationship with i2c. True, but none of the three are actually i2c drivers; they're just shared functions used by drivers helper code. Hmm... $ git grep aptina-pll.h drivers/media/ drivers/media/i2c/aptina-pll.c:#include aptina-pll.h drivers/media/i2c/mt9m032.c:#include aptina-pll.h drivers/media/i2c/mt9p031.c:#include aptina-pll.h $ git grep smiapp-pll.h drivers/media/ drivers/media/i2c/smiapp-pll.c:#include smiapp-pll.h drivers/media/i2c/smiapp-pll.h: * drivers/media/i2c/smiapp-pll.h drivers/media/i2c/smiapp/smiapp.h:#include smiapp-pll.h $ git grep smiapp.h drivers/media/ drivers/media/i2c/smiapp/smiapp-core.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-limits.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-quirk.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-regs.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp.h: * drivers/media/i2c/smiapp/smiapp.h drivers/media/i2c/smiapp/smiapp.h:#include media/smiapp.h It could make sense to keep those two on I2c, I'd like that :-) Those helper functions will likely never be used by non-I2C drivers. If they are we can reconsider moving them to common/, but for now it makes sense to keep them in i2c/ in my opinion. eventually moving smapp-pl to i2c/smiapp. Just FYI, the smiapp-pll driver will be used by other Aptina drivers for sensors that use a SMIA++-like PLL. I haven't had time to finish the code yet. I have conflicting opinions here :) But cx2341x.c and btcx-risc.c do not have that at all. One reason for creating this patch was that I couldn't find the cx2341x.c code until I smiapp-pll.cdid a find. Also, I don't think cx2341x or any of those other helper drivers deserve each its own directory. I thought that the cx2341x.c source in common looked a bit lonely. But if we add other sources as well, then it has company :-) :) So, IMHO, the better is to just live them at the i2c directory. For cx2341x and btcx-risc the i2c directory is completely inappropriate. Nobody is ever going to guess that. Agreed. Those are just leftovers of the tree reorg, as the final patch at v4l side were to rename video to i2c. They might be moved, instead, to drivers/media/common (but without creating subdirs there). In any case, we should do the same for all those non-i2c helper drivers. Just moving cx2341x and letting the others there will just increase the mess. I've no problem moving cx2341x, btcx-risc and tveeprom to common. For the two pll sources I'd like to know if the authors agree (CC-ed) before I make a patch moving them to common. -- 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 v6 1/2] sta2x11_vip: convert to videobuf2, control framework, file handler
Hi Federico, OK, I'm going to give this my Acked-by, but I really wish you would have split this up into smaller changes. It's hard to review since you have made so many changes in this one patch. Even though I'm giving my ack, Mauro might decide against it, so if you have time to spread out the changes in multiple patches, then please do so. So, given the fact that this changes just a single driver not commonly used in existing deployments, assuming that you have tested the changes (you did that, right? Just checking...), that these are really useful improvements, and that I reviewed the code (as well as I could) and didn't see any problems, I'm giving my ack anyway: Acked-by: Hans Verkuil hans.verk...@cisco.com 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: [RFC v2 0/5] Common Display Framework
On Monday 04 February 2013 03:35 PM, Marcus Lorentzon wrote:
On 02/02/2013 12:35 AM, Laurent Pinchart wrote:
Hi Marcus,
On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
On 01/08/2013 05:36 PM, Tomasz Figa wrote:
On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
[...]
But it is not perfect. After a couple of products we realized that
most
panel drivers want an easy way to send a bunch of init commands in one
go. So I think it should be an op for sending an array of commands at
once. Something like
struct dsi_cmd {
enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */
u8 cmd;
int dataLen;
u8 *data;
}
struct dsi_ops {
int dsi_write(source, int num_cmds, struct dsi_cmd *cmds);
...
}
Do you have DSI IP(s) that can handle a list of commands ? Or would
all DSI
transmitter drivers need to iterate over the commands manually ? In
the later
case a lower-level API might be easier to implement in DSI transmitter
drivers. Helper functions could provide the higher-level API you
proposed.
The HW has a FIFO, so it can handle a few. Currently we use the low
level type of call with one call per command. But we have found DSI
command mode panels that don't accept any commands during the update
(write start+continues). And so we must use a mutex/state machine to
exclude any async calls to send DSI commands during update. But if you
need to send more than one command per frame this will be hard (like
CABC and backlight commands). It will be a ping pong between update and
command calls. One option is to expose the mutex to the caller so it can
make many calls before the next update grabs the mutex again.
So maybe we could create a helper that handle the op for list of
commands and another op for single command that you actually have to
implement.
fyi, the DSI IP on OMAP3+ SoCs also has a FIFO. It can provide
interrupts after each command is pushed out, and also when the FIFO gets
empty(all commands are pushed). The only thing to take care is to not
overflow FIFO.
DSI video mode panels generally have a few dozen internal registers
which need to be configured via DSI commands. It's more fast(and
convenient) to configure a handful of internal registers in one shot,
and then perform a single BTA to know from the panel whether the
commands were received correctly.
Regards,
Archit
--
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: [GIT PULL FOR v3.9] Move cx2341x from media/i2c to media/common
On Wed 6 February 2013 10:16:04 Mauro Carvalho Chehab wrote: Em Wed, 6 Feb 2013 08:46:35 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Tue February 5 2013 19:49:41 Mauro Carvalho Chehab wrote: Hi Hans, Em Tue, 29 Jan 2013 09:56:20 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: Hi Mauro, The cx2341x module is a helper module for conexant-based MPEG encoders. It isn't an i2c module at all, instead it should be in common since it is used by 7 pci and usb drivers to handle the MPEG setup. It also shouldn't be visible in the config menu as it is always selected automatically by those drivers that need it. It should be noticed that the other non-i2c helper drivers also at the i2c directories: $ grep -L i2c_client drivers/media/i2c/*.c|grep -v mod drivers/media/i2c/aptina-pll.c drivers/media/i2c/btcx-risc.c drivers/media/i2c/cx2341x.c drivers/media/i2c/smiapp-pll.c A closer look may even hit some weird stuff, like tveeprom. This particular helper driver is not an I2C driver, although it has i2c_client symbol there, in order to optionally read the data via I2C, instead of receiving it via an API call. At least aptina-pll.c, smiapp-pll.c and tveeprom.c all have some relationship with i2c. True, but none of the three are actually i2c drivers; they're just shared functions used by drivers helper code. Hmm... $ git grep aptina-pll.h drivers/media/ drivers/media/i2c/aptina-pll.c:#include aptina-pll.h drivers/media/i2c/mt9m032.c:#include aptina-pll.h drivers/media/i2c/mt9p031.c:#include aptina-pll.h $ git grep smiapp-pll.h drivers/media/ drivers/media/i2c/smiapp-pll.c:#include smiapp-pll.h drivers/media/i2c/smiapp-pll.h: * drivers/media/i2c/smiapp-pll.h drivers/media/i2c/smiapp/smiapp.h:#include smiapp-pll.h $ git grep smiapp.h drivers/media/ drivers/media/i2c/smiapp/smiapp-core.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-limits.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-quirk.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp-regs.c:#include smiapp.h drivers/media/i2c/smiapp/smiapp.h: * drivers/media/i2c/smiapp/smiapp.h drivers/media/i2c/smiapp/smiapp.h:#include media/smiapp.h It could make sense to keep those two on I2c, eventually moving smapp-pl to i2c/smiapp. I have conflicting opinions here :) But cx2341x.c and btcx-risc.c do not have that at all. One reason for creating this patch was that I couldn't find the cx2341x.c code until I smiapp-pll.cdid a find. Also, I don't think cx2341x or any of those other helper drivers deserve each its own directory. I thought that the cx2341x.c source in common looked a bit lonely. But if we add other sources as well, then it has company :-) :) So, IMHO, the better is to just live them at the i2c directory. For cx2341x and btcx-risc the i2c directory is completely inappropriate. Nobody is ever going to guess that. Agreed. Those are just leftovers of the tree reorg, as the final patch at v4l side were to rename video to i2c. They might be moved, instead, to drivers/media/common (but without creating subdirs there). In any case, we should do the same for all those non-i2c helper drivers. Just moving cx2341x and letting the others there will just increase the mess. I've no problem moving cx2341x, btcx-risc and tveeprom to common. For the two pll sources I'd like to know if the authors agree (CC-ed) before I make a patch moving them to common. Fair enough. OK, I'll prepare patches today moving cx2341x, btcx-risc and tveeprom to common. I agree with Laurent that the pll sources are better placed in i2c, at least for now. 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: [GIT PULL FOR 3.8] Exynos/s5p driver fixes
Hi Mauro, On 02/05/2013 09:43 PM, Mauro Carvalho Chehab wrote: [..] The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git v3.8-rc5-fixes Kamil Debski (1): s5p-mfc: end-of-stream handling in encoder bug fix Sylwester Nawrocki (2): s5p-fimc: Fix fimc-lite entities deregistration s5p-csis: Fix clock handling on error path in probe() drivers/media/platform/s5p-fimc/fimc-mdevice.c |2 +- drivers/media/platform/s5p-fimc/mipi-csis.c|2 +- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) pwclient update -s accepted 16223 pwclient update -s accepted 16206 pwclient update -s accepted 16314 Error: Importing patches from git://linuxtv.org/snawrocki/samsung.git v3.8-rc5-fixes fatal: Couldn't find remote ref v3.8-rc5-fixes Here is the updated pull request, after rebase onto staging/for_v3.9: The following changes since commit 9b4539bebb86310afdc5563653ec4475ae110088: [media] em28xx: input: use common work_struct callback function for IR RC key polling (2013-02-05 20:43:16 -0200) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git v3.8-rc5-fixes-2 for you to fetch changes up to 4a3dd932afe11a5edb3e5747a4d943b14062023f: s5p-fimc: Fix fimc-lite entities deregistration (2013-02-06 11:35:34 +0100) Kamil Debski (1): s5p-mfc: end-of-stream handling in encoder bug fix Sylwester Nawrocki (2): s5p-csis: Fix clock handling on error path in probe() s5p-fimc: Fix fimc-lite entities deregistration drivers/media/platform/s5p-fimc/fimc-mdevice.c |2 +- drivers/media/platform/s5p-fimc/mipi-csis.c|7 --- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |2 ++ 3 files changed, 7 insertions(+), 4 deletions(-) -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.9] Move cx2341x, btcx-risc and tveeprom to common
Hi Mauro,
As discussed earlier, this pull requests moves cx2341x, btcx-risc and
tveeprom to media/common.
The cx2341x and btcx-risc modules should definitely be moved there as they
have absolutely nothing to do with i2c, but I leave the decision whether
tveeprom should be moved or not up to you.
Most drivers use the i2c part of tveeprom as well, and those that do not still
use i2c to get hold of the eeprom data. So there is a strong relationship with
i2c regardless.
IMHO the i2c directory is slightly more appropriate for tveeprom than the
common directory.
Regards,
Hans
The following changes since commit f85ed0ceeba78b6b15a857ce4fdb52de28d0:
Revert [media] drivers/media/usb/dvb-usb/dib0700_core.c: fix left shift
(2013-02-06 08:31:55 -0200)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git common
for you to fetch changes up to 8d6e9928d56ae92fe8118a2c6aef7b219c3b1399:
tveeprom: move from media/i2c to media/common (2013-02-06 12:03:41 +0100)
Hans Verkuil (3):
cx2341x: move from media/i2c to media/common
btcx-risc: move from media/i2c to media/common
tveeprom: move from media/i2c to media/common
drivers/media/common/Kconfig | 11 +++
drivers/media/common/Makefile |3 +++
drivers/media/{i2c = common}/btcx-risc.c |0
drivers/media/{i2c = common}/btcx-risc.h |0
drivers/media/{i2c = common}/cx2341x.c |0
drivers/media/{i2c = common}/tveeprom.c |0
drivers/media/i2c/Kconfig | 26 --
drivers/media/i2c/Makefile|3 ---
drivers/media/pci/bt8xx/Makefile |1 +
drivers/media/pci/cx23885/Makefile|1 +
drivers/media/pci/cx25821/Makefile|1 +
drivers/media/pci/cx88/Makefile |1 +
12 files changed, 18 insertions(+), 29 deletions(-)
rename drivers/media/{i2c = common}/btcx-risc.c (100%)
rename drivers/media/{i2c = common}/btcx-risc.h (100%)
rename drivers/media/{i2c = common}/cx2341x.c (100%)
rename drivers/media/{i2c = common}/tveeprom.c (100%)
--
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 2/2] drm/exynos: Add device tree based discovery support for G2D
On 2013년 02월 06일 17:51, Inki Dae wrote:
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: Wednesday, February 06, 2013 5:03 PM
To: Inki Dae
Cc: linux-media@vger.kernel.org; dri-de...@lists.freedesktop.org;
devicetree-disc...@lists.ozlabs.org; k.deb...@samsung.com;
s.nawro...@samsung.com; kgene@samsung.com; patc...@linaro.org; Ajay
Kumar
Subject: Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery
support for G2D
On 6 February 2013 13:02, Inki Dae inki@samsung.com wrote:
Looks good to me but please add document for it.
Yes. I will. I was planning to send the bindings document patch along
with the dt patches (adding node entries to dts files).
Sylwester had suggested adding this to
Documentation/devicetree/bindings/media/ which contains other media
IPs.
I think that it's better to go to gpu than media and we can divide Exynos
IPs into the bellow categories,
Media : mfc
GPU : g2d, g3d, fimc, gsc
Video : fimd, hdmi, eDP, MIPI-DSI
Hm, here is another considering point. Some device can be used as one of
two sub-system. For example g2d can be used as V4L2 driver or DRM
driver. And more specific case, multiple fimc/gsc deivces can be
separately used as both drivers: two fimc devices are used as V4L2
driver and other devices are used as DRM driver.
Current discussion, without change of build configuration, device can be
only used as one driver.
So I want to discuss about how we can bind device and driver just with
dts configuration.
IMO, there are two options.
First, driver usage is set on configurable node.
g2d: g2d {
compatible = samsung,exynos4212-g2d;
...
*subsystem = v4l2* or *subsystem = drm*
};
Node name and type is just an example to describe.
With this option, driver which is not matched with subsystem node should
return with fail during its probing.
Second, using dual compatible strings.
g2d: g2d {
*compatible = samsung,exynos4212-v4l2-g2d; or
compatible = samsung,exynos4212-v4l2-g2d;*
...
};
String is just an example so don't mind if it is ugly. Actually, with
this option, compatible string has non HW information. But this option
does not need fail in probing.
I'm not sure these options are fit to DT concept. Please let me know if
anyone has idea.
Best Regards,
- Seung-Woo Kim
And I think that the device-tree describes hardware so possibly, all
documents in .../bindings/drm/exynos/* should be moved to proper place also.
Please give me any opinions.
Thanks,
Inki Dae
To other guys,
And is there anyone who know where this document should be added to?
I'm not sure that the g2d document should be placed in
Documentation/devicetree/bindings/gpu, media, drm/exynos or arm/exynos.
At
least, this document should be shared with the g2d hw relevant drivers
such
as v4l2 and drm. So is .../bindings/gpu proper place?
--
With warm regards,
Sachin
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 2/2] drm/exynos: Add device tree based discovery support for G2D
On 02/06/2013 09:51 AM, Inki Dae wrote: [...] I think that it's better to go to gpu than media and we can divide Exynos IPs into the bellow categories, Media : mfc GPU : g2d, g3d, fimc, gsc Heh, nice try! :) GPU and FIMC ? FIMC is a camera subsystem (hence 'C' in the acronym), so what it has really to do with GPU ? All right, this IP has really two functions: camera capture and video post-processing (colorspace conversion, scaling), but the main feature is camera capture (fimc-lite is a camera capture interface IP only). Also, Exynos5 GScaler is used as a DMA engine for camera capture data pipelines, so it will be used by a camera capture driver as well. It really belongs to Media and GPU, as this is a multifunctional device (similarly to FIMC). So I propose following classification, which seems less inaccurate: GPU: g2d, g3d Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc Video: fimd, hdmi, eDP, mipi-dsim I have already a DT bindings description prepared for fimc [1]. (probably it needs to be rephrased a bit not to refer to the linux device model). I put it in Documentation/devicetree/bindings/media/soc, but likely there is no need for the 'soc' subdirectory... Video : fimd, hdmi, eDP, MIPI-DSI And I think that the device-tree describes hardware so possibly, all documents in .../bindings/drm/exynos/* should be moved to proper place also. Please give me any opinions. Yes, I agree. If possible, it would be nice to have some Linux API agnostic locations. [1] goo.gl/eTGOl -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D
On 6 February 2013 16:53, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 02/06/2013 09:51 AM, Inki Dae wrote: [...] So I propose following classification, which seems less inaccurate: GPU: g2d, g3d Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc Video: fimd, hdmi, eDP, mipi-dsim Thanks Inki and Sylwester for your inputs. We need to figure out some sensible location for these drivers' documentation though I liked what you have proposed for now. I will add g2d document to gpu directory as both of you suggest the same. If there are better opinions will move it later. -- With warm regards, Sachin -- 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 2/2] drm/exynos: Add device tree based discovery support for G2D
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki Sent: Wednesday, February 06, 2013 8:24 PM To: Inki Dae Cc: 'Sachin Kamat'; linux-media@vger.kernel.org; dri- de...@lists.freedesktop.org; devicetree-disc...@lists.ozlabs.org; k.deb...@samsung.com; kgene@samsung.com; patc...@linaro.org; 'Ajay Kumar'; kyungmin.p...@samsung.com; sw0312@samsung.com; jy0922.s...@samsung.com Subject: Re: [PATCH v2 2/2] drm/exynos: Add device tree based discovery support for G2D On 02/06/2013 09:51 AM, Inki Dae wrote: [...] I think that it's better to go to gpu than media and we can divide Exynos IPs into the bellow categories, Media : mfc GPU : g2d, g3d, fimc, gsc Heh, nice try! :) GPU and FIMC ? FIMC is a camera subsystem (hence 'C' in the acronym), so what it has really to do with GPU ? All right, this IP has really two functions: camera capture and video post-processing (colorspace conversion, scaling), but the main feature is camera capture (fimc-lite is a camera capture interface IP only). Also, Exynos5 GScaler is used as a DMA engine for camera capture data pipelines, so it will be used by a camera capture driver as well. It really belongs to Media and GPU, as this is a multifunctional device (similarly to FIMC). So I propose following classification, which seems less inaccurate: GPU: g2d, g3d Media: mfc, fimc, fimc-lite, fimc-is, mipi-csis, gsc Video: fimd, hdmi, eDP, mipi-dsim Ok, it seems that your propose is better. :) To Sachin, Please add g2d document to .../bindings/gpu To Rahul, Could you please move .../drm/exynos/* to .../bindings/video? Probably you need to rename the files there to exynos*.txt If there are no other opinions, let's start :) Thanks, Inki Dae I have already a DT bindings description prepared for fimc [1]. (probably it needs to be rephrased a bit not to refer to the linux device model). I put it in Documentation/devicetree/bindings/media/soc, but likely there is no need for the 'soc' subdirectory... Video : fimd, hdmi, eDP, MIPI-DSI And I think that the device-tree describes hardware so possibly, all documents in .../bindings/drm/exynos/* should be moved to proper place also. Please give me any opinions. Yes, I agree. If possible, it would be nice to have some Linux API agnostic locations. [1] goo.gl/eTGOl -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [git:v4l-dvb/for_v3.9] [media] media: Convert to devm_ioremap_resource()
On Wed, Feb 06, 2013 at 12:33:04PM +0100, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] media: Convert to devm_ioremap_resource() Author: Thierry Reding thierry.red...@avionic-design.de Date:Mon Jan 21 06:09:07 2013 -0300 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 thierry.red...@avionic-design.de Acked-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Hi Mauro, Greg already took this through the driver-core tree because of the dependencies, so I don't think it's necessary to have it in yours as well. Thierry pgpwHHYjgnziw.pgp Description: PGP signature
Re: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On 02/05/13 14:48, Chris Clayton wrote:
[snip]
Well, after lots of hacking diagnostics into cx23885-i2c.c, I'm pretty
sure that this is a timing problem. I've eventually found that if I
insert a short delay into the top of i2c_sendbytes(), my HVR-1400
expresscard dvb-t gadget starts to work. When I run a dvb scan, it finds
all 117 services that are found using the same device on Windows 7 (and
by a nearby Samsung TV). I have no idea why the delay makes the card work.
A patch that makes this change is:
[snip]
OK, here's what I believe to be a better version of the patch:
--- linux-3.7.6/drivers/media/pci/cx23885/cx23885-i2c.c~
2013-02-01 19:46:56.0 +
+++ linux-3.7.6/drivers/media/pci/cx23885/cx23885-i2c.c 2013-02-06
11:08:31.0 +
@@ -92,6 +92,13 @@ static int i2c_sendbytes(struct i2c_adap
else
dprintk(1, %s(msg-len=%d)\n, __func__, msg-len);
+ /* The XC3028L tuner on a WinTV-HVR-1400 fails to tune without
this */
+ if (dev-board == CX23885_BOARD_HAUPPAUGE_HVR1400) {
+ printk_once(KERN_INFO %s - extra delay being applied for
+ HVR1400\n, i2c_adap-name);
+ udelay(8);
+ }
+
/* Deal with i2c probe functions with zero payload */
if (msg-len == 0) {
cx_write(bus-reg_addr, msg-addr 25);
Signed-off-by: Chris Clayton chris2...@googlemail.com
It applies cleanly to 3.7.6 and to 3.80-rc6+ (pulled this morning).
Chris
--
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
em28xx: fix bytesperline calculation in TRY_FMT
Compared to the previous patch I've removed the calculation change (I still think it is wrong, but this needs to be considered in a wider perspective). But the more obvious problem where the current width instead of the one provided by the application is used still needed to be fixed, which is done by this patch. 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
[REVIEW PATCH] em28xx: fix bytesperline calculation in TRY_FMT
From: Hans Verkuil hans.verk...@cisco.com The bytesperline calculation was incorrect: it used the old width instead of the provided width. Fixed. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/usb/em28xx/em28xx-video.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index 2eabf2a..32bd7de 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -906,7 +906,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv, f-fmt.pix.width = width; f-fmt.pix.height = height; f-fmt.pix.pixelformat = fmt-fourcc; - f-fmt.pix.bytesperline = (dev-width * fmt-depth + 7) 3; + f-fmt.pix.bytesperline = (width * fmt-depth + 7) 3; f-fmt.pix.sizeimage = f-fmt.pix.bytesperline * height; f-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; if (dev-progressive) -- 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
kernel 3.6.7: sysfs: cannot create duplicate filename warnings
Hi, I've been investigating problem with my Hauppauge WinTV HVR-1400 TV card (an expresscard) [1], and I've come across warnings produced when I unload and then reload the cx23885 driver. Attached is the output from dmesg that shows the card being detected (by the PCI express hotplug driver) when it is inserted, the drivers being loaded and unloaded and, finally, the driver being reloaded and producing the warnings. I get the same warning with 3.8.0-rc6+ (freshly pulled this morning). I've searched Google and find thousands of hits going back over two years, but none of the first 20 pages of hits provided a solution. Please let me know if I can provide any additional diagnostics, but cc me on any reply as I'm not subscribed. Chris [1] http://www.spinics.net/lists/linux-media/msg59468.html Plug in the hvr1400 [ 165.300637] pciehp :00:1c.3:pcie04: Card present on Slot(3) [ 165.401471] pci :02:00.0: [14f1:8852] type 00 class 0x04 [ 165.401528] pci :02:00.0: reg 10: [mem 0x-0x001f 64bit] [ 165.401678] pci :02:00.0: supports D1 D2 [ 165.401679] pci :02:00.0: PME# supported from D0 D1 D2 D3hot [ 165.409465] pci :02:00.0: BAR 0: assigned [mem 0xf0e0-0xf0ff 64bit] [ 165.409501] pcieport :00:1c.3: PCI bridge to [bus 02-06] [ 165.409505] pcieport :00:1c.3: bridge window [io 0x3000-0x3fff] [ 165.409510] pcieport :00:1c.3: bridge window [mem 0xf0d0-0xf14f] [ 165.409514] pcieport :00:1c.3: bridge window [mem 0xf040-0xf0bf 64bit pref] [ 165.409530] pci :02:00.0: no hotplug settings from platform Load the drivers [ 211.641874] cx23885 driver version 0.0.3 loaded [ 211.641897] cx23885 :02:00.0: enabling device ( - 0002) [ 211.642000] CORE cx23885[0]: subsystem: 0070:8010, board: Hauppauge WinTV-HVR1400 [card=9,autodetected] [ 211.781181] cx23885[0] - extra delay being applied for HVR1400 [ 211.809194] tveeprom 7-0050: Hauppauge model 80019, rev B2F1, serial# 3758890 [ 211.809197] tveeprom 7-0050: MAC address is 00:0d:fe:39:5b:2a [ 211.809198] tveeprom 7-0050: tuner model is Xceive XC3028L (idx 151, type 4) [ 211.809200] tveeprom 7-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [ 211.809201] tveeprom 7-0050: audio processor is CX23885 (idx 39) [ 211.809202] tveeprom 7-0050: decoder processor is CX23885 (idx 33) [ 211.809203] tveeprom 7-0050: has radio [ 211.809204] cx23885[0]: hauppauge eeprom: model=80019 [ 211.809205] cx23885_dvb_register() allocating 1 frontend(s) [ 211.809207] cx23885[0]: cx23885 based dvb card [ 211.915346] xc2028 8-0064: creating new instance [ 211.915349] xc2028 8-0064: type set to XCeive xc2028/xc3028 tuner [ 211.915353] DVB: registering new adapter (cx23885[0]) [ 211.915357] cx23885 :02:00.0: DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 211.915576] cx23885_dev_checkrevision() Hardware revision = 0xb0 [ 211.915582] cx23885[0]/0: found at :02:00.0, rev: 2, irq: 19, latency: 0, mmio: 0xf0e0 [ 211.977653] xc2028 8-0064: Loading 81 firmware images from xc3028L-v36.fw, type: xc2028 firmware, ver 3.6 Unload the drivers [ 228.016560] xc2028 8-0064: destroying instance Reload the drivers [ 240.384907] cx23885 driver version 0.0.3 loaded [ 240.385099] CORE cx23885[0]: subsystem: 0070:8010, board: Hauppauge WinTV-HVR1400 [card=9,autodetected] [ 240.524290] cx23885[0] - extra delay being applied for HVR1400 [ 240.552265] tveeprom 7-0050: Hauppauge model 80019, rev B2F1, serial# 3758890 [ 240.552267] tveeprom 7-0050: MAC address is 00:0d:fe:39:5b:2a [ 240.552268] tveeprom 7-0050: tuner model is Xceive XC3028L (idx 151, type 4) [ 240.552269] tveeprom 7-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [ 240.552270] tveeprom 7-0050: audio processor is CX23885 (idx 39) [ 240.552271] tveeprom 7-0050: decoder processor is CX23885 (idx 33) [ 240.552272] tveeprom 7-0050: has radio [ 240.552273] cx23885[0]: hauppauge eeprom: model=80019 [ 240.552275] cx23885_dvb_register() allocating 1 frontend(s) [ 240.552277] cx23885[0]: cx23885 based dvb card [ 240.626253] xc2028 8-0064: creating new instance [ 240.626255] xc2028 8-0064: type set to XCeive xc2028/xc3028 tuner [ 240.626258] DVB: registering new adapter (cx23885[0]) [ 240.626263] cx23885 :02:00.0: DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 240.626316] xc2028 8-0064: Loading 81 firmware images from xc3028L-v36.fw, type: xc2028 firmware, ver 3.6 [ 240.626366] [ cut here ] [ 240.626371] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0xae/0xe0() [ 240.626372] Hardware name: LIFEBOOK AH531 [ 240.626373] sysfs: cannot create duplicate filename '/devices/pci:00/:00:1c.3/:02:00.0/dvb/dvb0.frontend0' [ 240.626374] Modules linked in: cx23885(+) tveeprom btcx_risc videobuf_dvb cx2341x videobuf_dma_sg videobuf_core dib7000p
Re: [PATCH RESEND] media: rc: gpio-ir-recv: add support for device tree parsing
Hi,
On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but optional properties allow linux specific support for rc
protocols and maps.
There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
...
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..937760c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible = gpio-ir-receiver;
+ - gpios: OF device-tree gpio specification.
+
+Optional properties:
+ - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
+ rc protocols.
You likely need to specify in these bindings documentation which bit
corresponds to which RC protocol.
I'm not very familiar with the RC internals, but why it has to be
specified statically in the device tree, when decoding seems to be
mostly software defined ? I might be missing something though..
Couldn't this be configured at run time, with all protocols allowed
as the default ?
+ - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+ ir: ir-receiver {
+ compatible = gpio-ir-receiver;
+ gpios = gpio0 19 1;
+ /* allow rc protocols 1-4 */
+ linux,allowed-rc-protocols = 0x 0x001e;
+ linux,rc-map-name = rc-rc6-mce;
+ };
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4f71a7d..25e09fa 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -16,6 +16,7 @@
#include linux/interrupt.h
#include linux/gpio.h
#include linux/slab.h
+#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/irq.h
#include media/rc-core.h
@@ -30,6 +31,63 @@ struct gpio_rc_dev {
bool active_low;
};
+#ifdef CONFIG_OF
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct gpio_ir_recv_platform_data *pdata;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_find_property(np, gpios, NULL)) {
Why do you need this ? Isn't of_get_gpio_flags() sufficient ?
+ dev_err(dev, Found gpio-ir-receiver without gpios\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ gpio = of_get_gpio_flags(np, 0, flags);
+ if (gpio 0) {
+ if (gpio != -EPROBE_DEFER)
+ dev_err(dev, Failed to get gpio flags, error: %d\n,
+ gpio);
+ return ERR_PTR(gpio);
+ }
+
+ pdata-gpio_nr = gpio;
+ pdata-active_low = (flags OF_GPIO_ACTIVE_LOW) ? true : false;
+ pdata-map_name = of_get_property(np, linux,rc-map-name, NULL);
+ of_property_read_u64(np, linux,allowed-rc-protocols,
+ pdata-allowed_protos);
+
+ return pdata;
+}
+
+static struct of_device_id gpio_ir_recv_of_match[] = {
+ { .compatible = gpio-ir-receiver, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match);
+
+#else /* !CONFIG_OF */
+
+static inline struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+#endif
+
static irqreturn_t gpio_ir_recv_irq(int irq, void *dev_id)
{
struct gpio_rc_dev *gpio_dev = dev_id;
@@ -66,8 +124,11 @@ static int gpio_ir_recv_probe(struct platform_device
*pdev)
pdev-dev.platform_data;
int rc;
- if (!pdata)
- return -EINVAL;
+ if (!pdata) {
+ pdata = gpio_ir_recv_get_devtree_pdata(pdev-dev);
Could assigning to pdev-dev.platform_data be avoided here ?
platform_data is only referenced in probe(), so maybe something like
this would be better:
const struct gpio_ir_recv_platform_data *pdata = NULL;
if (pdev-dev.of_node) {
ret = gpio_ir_recv_parse_dt(pdev-dev, pdata);
if (ret 0)
return ret;
} else {
pdata = pdev-dev.platform_data;
}
if (!pdata)
return -EINVAL;
+ if
Replacement for vloopback?
Hello I need to have access to my webcam from two applications (one is motion, the other a video sip phone). I have googled a lot, but only found vloopback as a method to access a video device from two applications. However, vloopback seems to rely on V4L1 which is mostly no longer compiled into the kernel by most distros. Additionally, it does not seem to compile against newer kernels. So, my question ist: Is vloopback the right way to go for this requirement? If yes, how to get it working? If not, what can I use to have two apps accessing the video stream from the webcam? Thanks a lot for any help Michael -- 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: mb86a20s and cx23885
Hi
El 28/01/13 17:47, Alfredo Jesús Delaiti escribió:
Hi
El 28/01/13 07:23, Mauro Carvalho Chehab escribió:
Em Sun, 27 Jan 2013 18:48:57 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi
El 27/01/13 13:16, Mauro Carvalho Chehab escribió:
Em Sun, 27 Jan 2013 12:27:21 -0300
Alfredo Jesús Delaiti alfredodela...@netscape.net escreveu:
Hi all
I'm trying to run the digital part of the card MyGica X8507 and I
need
help on some issues.
Need data sheet of IC MB86A20S and no where to get it. Fujitsu
People of
Germany told me: This is a very old product and not supported any
more. Does anyone know where to get it?
I never found any public datasheet for this device.
Congratulations for driver you have made
Thanks!
linux-puon:/home/alfredo # modprobe cx23885 i2c_scan=1
...
[ 7011.618381] cx23885[0]: scan bus 0:
[ 7011.620759] cx23885[0]: i2c scan: found device @ 0x20 [???]
[ 7011.625653] cx23885[0]: i2c scan: found device @ 0x66 [???]
[ 7011.629702] cx23885[0]: i2c scan: found device @ 0xa0 [eeprom]
[ 7011.629983] cx23885[0]: i2c scan: found device @ 0xa4 [???]
[ 7011.630267] cx23885[0]: i2c scan: found device @ 0xa8 [???]
[ 7011.630548] cx23885[0]: i2c scan: found device @ 0xac [???]
[ 7011.636438] cx23885[0]: scan bus 1:
[ 7011.650108] cx23885[0]: i2c scan: found device @ 0xc2
[tuner/mt2131/tda8275/xc5000/xc3028]
[ 7011.654460] cx23885[0]: scan bus 2:
[ 7011.656434] cx23885[0]: i2c scan: found device @ 0x66 [???]
[ 7011.657087] cx23885[0]: i2c scan: found device @ 0x88 [cx25837]
[ 7011.657393] cx23885[0]: i2c scan: found device @ 0x98 [flatiron]
...
In the bus 0 is demodulator mb86a20s 0x20 (0x10) and in the bus 1 the
tuner (xc5000). I understand that would have to be cancel the
mb86a20s
i2c_gate_ctrl similarly as in the IC zl10353. If this is possible, is
not yet implemented in the controller of mb86a20s. The IC cx23885 is
always who controls the tuner i2c bus.
Well, if you don't add an i2c_gate_ctrl() callback, the mb86a20s won't
be calling it. So, IMO, the cleanest approach would simply to do:
fe-dvb.frontend-ops.i2c_gate_ctrl = NULL;
after tuner attach, if the tuner or the bridge driver implements an
i2c gate.
I don't think xc5000 does. The mb86a20s also has its own i2c gate
and gpio
ports that might be used to control an external gate, but support
for it is
currently not implemented, as no known device uses it.
If in this way, it does not work:
case CX23885_BOARD_MYGICA_X8507:
i2c_bus = dev-i2c_bus[0];
i2c_bus2 = dev-i2c_bus[1];
fe0-dvb.frontend = dvb_attach(mb86a20s_attach,
mygica_x8507_mb86a20s_config,
i2c_bus-i2c_adap);
if (fe0-dvb.frontend != NULL) {
dvb_attach(xc5000_attach,
fe0-dvb.frontend,
i2c_bus2-i2c_adap,
mygica_x8507_xc5000_config);
fe0-dvb.frontend-ops.i2c_gate_ctrl = NULL;
fe0-dvb.frontend-ops.tuner_ops.init(fe0-dvb.frontend);
I get:
...dmesg
...
[ 964.105688] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01
[ 964.105696] mb86a20s: mb86a20s_set_frontend:
[ 964.105700] mb86a20s: mb86a20s_set_frontend: Calling tuner set
parameters
It seems that the driver is able to talk with mb86a20s and read the
status
and version registers. If the xc5000 firmware got loaded, that means
that
there's no issue with I2C.
So, the issue is likely something else.
From this:
;Demod Comm mode : 0x00 = Serial, 0x01 = Parallel
HKR,DriverData,DemodTransferMode,0x00010001, 0x01, 0x00, 0x00, 0x00
mb86a20s_config.is_serial should be false (default).
static struct mb86a20s_config mygica_x8507_mb86a20s_config = {
.demod_address = 0x10,
};
nothing of .is_serial
Can you confirm if the XTAL at the side of mb86a20s is 32.57MHz?
The exact value is 32.571MHz
If the XTAL is the same and the device driver is set to parallel mode,
then we'll need to investigate other setups that happen during init
time.
There are a few places at the driver that you could play with.
For example, on this register set:
{ 0x09, 0x3e },
You could try, instead of 0x3e, 0x1e, 0x1a or 0x3a.
I tested with the three new values and get nothing different
However, I recommend you to sniff the PCI traffic, in order to be
sure about
what this specific device does.
For this I need a little more time to study and apply. In a few days
it I obtained commented
When I was writing the driver for mb86a20s, I used this technique to
be sure about what it was needed to make one PCI card to work with it.
What I did then was to patch kvm to force it to emulate all DMA
transfers,
writing a dump of all such transfers at the host kernel. Then, I ran
some
parsing scripts to get the mb86a20s and tuner initialization. I made the
patches available at:
http://git.linuxtv.org/v4l-utils.git/tree/HEAD:/contrib/pci_traffic
I documented what it was needed to sniff the traffic at:
Re: [PATCH v6 1/2] sta2x11_vip: convert to videobuf2, control framework, file handler
Hi Hans, thank you very much for your review and your patience. OK, I'm going to give this my Acked-by, but I really wish you would have split this up into smaller changes. It's hard to review since you have made so many changes in this one patch. Even though I'm giving my ack, Mauro might decide against it, so if you have time to spread out the changes in multiple patches, then please do so. I tried to do smaller patch but there is always some incoherent part and the driver cannot work without all the patches. I should write some fake patches to make a coherent series. I reduce the size of the patch since v4/5; I leaved unchanged some code/comments to simplify the patch. So, given the fact that this changes just a single driver not commonly used in existing deployments, assuming that you have tested the changes (you did that, right? Just checking...), that these are really useful improvements, and that I reviewed the code (as well as I could) and didn't see any problems, I'm giving my ack anyway: Tested every time I sent a patch Acked-by: Hans Verkuil hans.verk...@cisco.com Thank you again -- Federico Vaga -- 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: Replacement for vloopback?
On Wed, 06 Feb 2013 14:57:43 +0100, Neuer User auslands...@gmx.de wrote: So, my question ist: Is vloopback the right way to go for this requirement? If yes, how to get it working? No. Video loopback is just a way for an application to expose a virtual camera, for another application to use. It is not a way to share a camera within two applications. Sharing a camera is fundamentally impossible due to the limitation of the hardware, which cannot capture in two different formats and sets of buffers simultaneously. Live with it. -- Rémi Denis-Courmont Sent from my collocated server -- 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: Replacement for vloopback?
Thanks for answering. The vloopback description seems to imply that it is possible to share a camera stream: How to use multiple webcam applications with vloopback [...] Do modprobe vloopback pipes=2. Then resize /dev/video0 /dev/video1 640x480 640x480 resize /dev/video2 /dev/video3 640x480 320x240. (Assuming that you have only one real video device at /dev/video0. You can check with dmesg). Now, you can watch your webcam with camstream at 640x480 (choose the device called vloopback0 output in camstream's menu, which is /dev/video2), at the sime time you can record a video of your webcam stream at 320x240 by doing ffmpeg -vd /dev/video4 -s 320x240 picture.mpeg, you can at the same time run a webcam http server by running camsource (after editting camsource.conf to choose /dev/video2 or /dev/video4 as v4l_input source). If it is not possible to have two applications access the same video stream, that is pretty detrimentical to quite a lot of use cases, e.g.: a.) Use motion to detect motion and record video. At the same time view the camera output on the screen. b.) Stream a webcam output over the net and at the same time view it on the screen. Actually, for me it would be no problem, if the stream needs to be the same format etc. So, really no way? :-( Thanks Michael On Wed, 06 Feb 2013 14:57:43 +0100, Neuer User auslands...@gmx.de wrote: So, my question ist: Is vloopback the right way to go for this requirement? If yes, how to get it working? No. Video loopback is just a way for an application to expose a virtual camera, for another application to use. It is not a way to share a camera within two applications. Sharing a camera is fundamentally impossible due to the limitation of the hardware, which cannot capture in two different formats and sets of buffers simultaneously. Live with it. -- Rémi Denis-Courmont Sent from my collocated server -- 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: CDF meeting @FOSDEM report
On Wed, Feb 6, 2013 at 6:11 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On 2013-02-06 00:27, Laurent Pinchart wrote: Hello, We've hosted a CDF meeting at the FOSDEM on Sunday morning. Here's a summary of the discussions. Thanks for the summary. I've been on a longish leave, and just got back, so I haven't read the recent CDF discussions on lists yet. I thought I'll start by replying to this summary first =). 0. Abbreviations DBI - Display Bus Interface, a parallel video control and data bus that transmits data using parallel data, read/write, chip select and address signals, similarly to 8051-style microcontroller parallel busses. This is a mixed video control and data bus. DPI - Display Pixel Interface, a parallel video data bus that transmits data using parallel data, h/v sync and clock signals. This is a video data bus only. DSI - Display Serial Interface, a serial video control and data bus that transmits data using one or more differential serial lines. This is a mixed video control and data bus. In case you'll re-use these abbrevs in later posts, I think it would be good to mention that DPI is a one-way bus, whereas DBI and DSI are two-way (perhaps that's implicit with control bus, though). 1. Goals The meeting started with a brief discussion about the CDF goals. Tomi Valkeinin and Tomasz Figa have sent RFC patches to show their views of what CDF could/should be. Many others have provided very valuable feedback. Given the early development stage propositions were sometimes contradictory, and focused on different areas of interest. We have thus started the meeting with a discussion about what CDF should try to achieve, and what it shouldn't. CDF has two main purposes. The original goal was to support display panels in a platform- and subsystem-independent way. While mostly useful for embedded systems, the emergence of platforms such as Intel Medfield and ARM-based PCs that blends the embedded and PC worlds makes panel support useful for the PC world as well. The second purpose is to provide a cross-subsystem interface to support video encoders. The idea originally came from a generalisation of the original RFC that supported panels only. While encoder support is considered as lower priority than display panel support by developers focussed on display controller driver (Intel, Renesas, ST Ericsson, TI), companies that produce video encoders (Analog Devices, and likely others) don't share that point of view and would like to provide a single encoder driver that can be used in both KMS and V4L2 drivers. What is an encoder? Something that takes a video signal in, and lets the CPU store the received data to memory? Isn't that a decoder? Or do you mean something that takes a video signal in, and outputs a video signal in another format? (transcoder?) In KMS parlance, we have two objects a crtc and an encoder. A crtc reads data from memory and produces a data stream with display timing. The encoder then takes that datastream and timing from the crtc and converts it some sort of physical signal (LVDS, TMDS, DP, etc.). It's not always a perfect match to the hardware. For example a lot of GPUs have a DVO encoder which feeds a secondary encoder like an sil164 DVO to TMDS encoder. Alex -- 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: Replacement for vloopback?
On Wed, Feb 6, 2013 at 9:42 AM, Neuer User auslands...@gmx.de wrote: If it is not possible to have two applications access the same video stream, that is pretty detrimentical to quite a lot of use cases, e.g.: a.) Use motion to detect motion and record video. At the same time view the camera output on the screen. b.) Stream a webcam output over the net and at the same time view it on the screen. FWIW: usually when people ask for this sort of functionality (performing multiple functions on the same stream), they will typically use frameworks like gstreamer, which allow for creation of pipelines to perform the sorts of use cases you have described. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] mt9v022 driver: send valid HORIZONTAL_BLANKING values to mt9v024 soc camera
This patch fixes the issue that appears when mt9v024 camera is used with the
mt9v022 soc camera driver. The minimum total row time is 690 columns
(horizontal width + horizontal blanking). The minimum horizontal
blanking is 61. Thus, when the window width is set below 627, horizontal
blanking must
be increased. For the mt9v024 camera the values above are correct and
for the mt9v022 camera the correct values are in the existing kernel driver.
Signed-off-by: Andrei Andreyanau a.andreya...@sam-solutions.net
--- linux/drivers/media/i2c/soc_camera/mt9v022.c.orig 2013-02-06
15:43:35.522079869 +0300
+++ linux/drivers/media/i2c/soc_camera/mt9v022.c2013-02-06
14:53:44.0 +0300
@@ -275,6 +275,7 @@ static int mt9v022_s_crop(struct v4l2_su
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct v4l2_rect rect = a-c;
+ int min_row, min_blank;
int ret;
/* Bayer format - even size lengths */
@@ -310,13 +311,21 @@ static int mt9v022_s_crop(struct v4l2_su
ret = reg_write(client, MT9V022_COLUMN_START, rect.left);
if (!ret)
ret = reg_write(client, MT9V022_ROW_START, rect.top);
+ /*
+* mt9v022: min total row time is 660 columns, min blanking is 43
+* mt9v024: min total row time is 690 columns, min blanking is 61
+*/
+ if (is_mt9v024(mt9v022-chip_version)) {
+ min_row = 690;
+ min_blank = 61;
+ } else {
+ min_row = 660;
+ min_blank = 43;
+ }
if (!ret)
- /*
-* Default 94, Phytec driver says:
-* width + horizontal blank = 660
-*/
ret = v4l2_ctrl_s_ctrl(mt9v022-hblank,
- rect.width 660 - 43 ? 43 : 660 - rect.width);
+ rect.width min_row - min_blank ?
+ min_blank : min_row - rect.width);
if (!ret)
ret = v4l2_ctrl_s_ctrl(mt9v022-vblank, 45);
if (!ret)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replacement for vloopback?
Well, I have a (what I think) pretty simple use case here, but without any gstreamer involved: I have a software video sip phone (based on pjsip). I would like to automatically initiate a video call when there is a certain amount of motion detected. Both software packages access a v4l device. I have no idea how to change that to a gstreamer pipe. Ma guess is that it will probably be very difficult :-( Michael Am 06.02.2013 15:51, schrieb Devin Heitmueller: On Wed, Feb 6, 2013 at 9:42 AM, Neuer User auslands...@gmx.de wrote: If it is not possible to have two applications access the same video stream, that is pretty detrimentical to quite a lot of use cases, e.g.: a.) Use motion to detect motion and record video. At the same time view the camera output on the screen. b.) Stream a webcam output over the net and at the same time view it on the screen. FWIW: usually when people ask for this sort of functionality (performing multiple functions on the same stream), they will typically use frameworks like gstreamer, which allow for creation of pipelines to perform the sorts of use cases you have described. Devin -- 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: CDF meeting @FOSDEM report
On 2013-02-06 16:44, Alex Deucher wrote: On Wed, Feb 6, 2013 at 6:11 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: What is an encoder? Something that takes a video signal in, and lets the CPU store the received data to memory? Isn't that a decoder? Or do you mean something that takes a video signal in, and outputs a video signal in another format? (transcoder?) In KMS parlance, we have two objects a crtc and an encoder. A crtc reads data from memory and produces a data stream with display timing. The encoder then takes that datastream and timing from the crtc and converts it some sort of physical signal (LVDS, TMDS, DP, etc.). It's Isn't the video stream between CRTC and encoder just as physical, it just happens to be inside the GPU? This is the case for OMAP, at least, where DISPC could be considered CRTC, and DSI/HDMI/etc could be considered encoder. The stream between DISPC and DSI/HDMI is plain parallel RGB signal. The video stream could as well be outside OMAP. not always a perfect match to the hardware. For example a lot of GPUs have a DVO encoder which feeds a secondary encoder like an sil164 DVO to TMDS encoder. Right. I think mapping the DRM entities to CDF ones is one of the bigger question marks we have with CDF. While I'm no expert on DRM, I think we have the following options: 1. Force DRM's model to CDF, meaning one encoder. 2. Extend DRM to support multiple encoders in a chain. 3. Support multiple encoders in a chain in CDF, but somehow map them to a single encoder in DRM side. I really dislike the first option, as it would severely limit where CDF can be used, or would force you to write some kind of combined drivers, so that you can have one encoder driver running multiple encoder devices. Tomi signature.asc Description: OpenPGP digital signature
Re: Replacement for vloopback?
Thanks everybody so far. I just found v4l2loopback and also some examples with gestreamer. I will do some testing and see if I can get my use case done with that. Kind regards Michael Am 06.02.2013 14:57, schrieb Neuer User: Hello I need to have access to my webcam from two applications (one is motion, the other a video sip phone). I have googled a lot, but only found vloopback as a method to access a video device from two applications. However, vloopback seems to rely on V4L1 which is mostly no longer compiled into the kernel by most distros. Additionally, it does not seem to compile against newer kernels. So, my question ist: Is vloopback the right way to go for this requirement? If yes, how to get it working? If not, what can I use to have two apps accessing the video stream from the webcam? Thanks a lot for any help Michael -- 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] em28xx: fix usb alternate setting for analog and digital video endpoints 0
Am 05.02.2013 23:06, schrieb Mauro Carvalho Chehab:
Em Tue, 05 Feb 2013 22:37:50 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 05.02.2013 21:57, schrieb Mauro Carvalho Chehab:
Em Fri, 18 Jan 2013 18:25:48 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
While the current code handles sound interfaces with a number 0
correctly, it
assumes that the interface number for analog + digital video is always 0
when
changing the alternate setting.
(NOTE: the SpeedLink VAD Laplace webcam (EM2765) uses interface number 3
for video)
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-audio.c | 10 +-
drivers/media/usb/em28xx/em28xx-cards.c |2 +-
drivers/media/usb/em28xx/em28xx-core.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx.h |3 +--
5 Dateien geändert, 9 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 2fdb66e..cdbfe0a 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -283,15 +283,15 @@ static int snd_em28xx_capture_open(struct
snd_pcm_substream *substream)
}
runtime-hw = snd_em28xx_hw_capture;
- if ((dev-alt == 0 || dev-audio_ifnum) dev-adev.users == 0) {
- if (dev-audio_ifnum)
+ if ((dev-alt == 0 || dev-ifnum) dev-adev.users == 0) {
+ if (dev-ifnum)
Please don't merge a non-fix change (variable rename) with a fix.
Ok, sorry, it seems to be trivial...
Btw, audio_ifnum is a better name, as it avoids it to be miss-interpreted.
Did you read the complete patch ? ;)
Or do you really want the video interface number to be called audio_ifnum ?
There are two types of em28xx audio vendor class. In one type, the audio IF
is the same as the video one, but on the other one, it is different.
Sure, but if I'm not misunderstanding the code, we have two device
instances with separate device structs when audio is on a separate
interface.
Hence we don't need two fields for the interface number in the struct
and that's why renamed it.
Regards,
Frank
That's why audio_ifnum were added in the first place.
See this commit:
commit 4f83e7b3ef938eb9a01eadf81a0f3b2c67d3afb6
Author: Mauro Carvalho Chehab mche...@redhat.com
Date: Fri Jun 17 15:15:12 2011 -0300
[media] em28xx: Add support for devices with a separate audio interface
Some devices use a separate interface for the vendor audio class.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
dev-alt = 1;
else
dev-alt = 7;
dprintk(changing alternate number on interface %d to %d\n,
- dev-audio_ifnum, dev-alt);
- usb_set_interface(dev-udev, dev-audio_ifnum, dev-alt);
+ dev-ifnum, dev-alt);
+ usb_set_interface(dev-udev, dev-ifnum, dev-alt);
/* Sets volume, mute, etc */
dev-mute = 0;
@@ -642,7 +642,7 @@ static int em28xx_audio_init(struct em28xx *dev)
static int devnr;
int err;
- if (!dev-has_alsa_audio || dev-audio_ifnum 0) {
+ if (!dev-has_alsa_audio) {
/* This device does not support the extension (in this case
the device is expecting the snd-usb-audio module or
doesn't have analog audio support at all) */
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 0a5aa62..553db17 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3376,7 +3376,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
dev-alt = -1;
dev-is_audio_only = has_audio !(has_video || has_dvb);
dev-has_alsa_audio = has_audio;
- dev-audio_ifnum = ifnum;
+ dev-ifnum = ifnum;
/* Checks if audio is provided by some interface */
for (i = 0; i udev-config-desc.bNumInterfaces; i++) {
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index ce4f252..210859a 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -862,7 +862,7 @@ set_alt:
}
em28xx_coredbg(setting alternate %d with wMaxPacketSize=%u\n,
dev-alt, dev-max_pkt_size);
- errCode = usb_set_interface(dev-udev, 0, dev-alt);
+ errCode = usb_set_interface(dev-udev, dev-ifnum, dev-alt);
if (errCode 0) {
em28xx_errdev(cannot change alternate number to %d
(error=%i)\n,
dev-alt, errCode);
This hunk doesn't apply upstream:
patching file drivers/media/usb/em28xx/em28xx-core.c
Hunk #1 FAILED at 862.
1 out of 1 hunk FAILED -- rejects in file
drivers/media/usb/em28xx/em28xx-core.c
It applies after
Re: Patch update notification: 2 patches updated
Am 05.02.2013 23:08, schrieb Mauro Carvalho Chehab: Em Tue, 05 Feb 2013 22:46:10 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 05.02.2013 22:33, schrieb Patchwork: Hello, The following patches (submitted by you) have been updated in patchwork: ... * [RFC] em28xx: fix analog streaming with USB bulk transfers - http://patchwork.linuxtv.org/patch/16197/ was: New now: RFC What's your plan with this patch ? We have this regression in the media-tree since a few weeks now. Nobody replied to it or came up with a better solution... Well, you tagged it as RFC. I just marked as such at patchwork. I don't even read patches tagged as [RFC] or [REVIEW], Uhm... even patches which are sent to you as the maintainer of the _driver_ ? Isn't commenting / reviewing patches the maintainers job ? as those patches will be resubmitted later by the patch author, if they're ok, or a new version will be sent instead. That's what I'm asking you. Is this patch ok / ready ? Or can I generally conclude that patches are fine when there is no reaction on them ? 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: [PATCH] em28xx: overhaul em28xx_capture_area_set()
Am 05.02.2013 23:48, schrieb Mauro Carvalho Chehab:
Em Sun, 20 Jan 2013 14:26:47 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
- move the bit shifting of width+height values inside the function
- fix the debug message format and output values
- add comment about the size limit (e.g. EM277x supports 2MPix)
- make void, because error checking is incomplete and we never check the
returned value (we would continue anyway)
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-core.c | 22 --
1 Datei geändert, 12 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index 210859a..f516a63 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -733,22 +733,24 @@ static int em28xx_accumulator_set(struct em28xx *dev,
u8 xmin, u8 xmax,
return em28xx_write_regs(dev, EM28XX_R2B_YMAX, ymax, 1);
}
-static int em28xx_capture_area_set(struct em28xx *dev, u8 hstart, u8 vstart,
+static void em28xx_capture_area_set(struct em28xx *dev, u8 hstart, u8
vstart,
u16 width, u16 height)
{
-u8 cwidth = width;
-u8 cheight = height;
-u8 overflow = (height 7 0x02) | (width 8 0x01);
+u8 cwidth = width 2;
+u8 cheight = height 2;
+u8 overflow = (height 9 0x02) | (width 10 0x01);
Hmm.. why did you change the above overflow bits?
Read the complete patch, the answer is...
...
That change doesn't
sound right to me. Ok, I don't have the datasheets, so I might be
wrong, but if is there a bug there, please submit the bug fix into a
separate patch, clearly explaining why such change is needed.
+/* NOTE: size limit: 2047x1023 = 2MPix */
-em28xx_coredbg(em28xx Area Set: (%d,%d)\n,
-(width | (overflow 2) 7),
-(height | (overflow 1) 8));
+em28xx_coredbg(capture area set to (%d,%d): %dx%d\n,
+ hstart, vstart,
+ ((overflow 2) 9 | cwidth 2),
+ ((overflow 1) 10 | cheight 2));
em28xx_write_regs(dev, EM28XX_R1C_HSTART, hstart, 1);
em28xx_write_regs(dev, EM28XX_R1D_VSTART, vstart, 1);
em28xx_write_regs(dev, EM28XX_R1E_CWIDTH, cwidth, 1);
em28xx_write_regs(dev, EM28XX_R1F_CHEIGHT, cheight, 1);
-return em28xx_write_regs(dev, EM28XX_R1B_OFLOW, overflow, 1);
+em28xx_write_regs(dev, EM28XX_R1B_OFLOW, overflow, 1);
}
static int em28xx_scaler_set(struct em28xx *dev, u16 h, u16 v)
@@ -801,9 +803,9 @@ int em28xx_resolution_set(struct em28xx *dev)
it out, we end up with the same format as the rest of the VBI
region */
if (em28xx_vbi_supported(dev) == 1)
-em28xx_capture_area_set(dev, 0, 2, width 2, height 2);
+em28xx_capture_area_set(dev, 0, 2, width, height);
else
-em28xx_capture_area_set(dev, 0, 0, width 2, height 2);
+em28xx_capture_area_set(dev, 0, 0, width, height);
... here !
So it's not a real change.
Regards,
Frank
return em28xx_scaler_set(dev, dev-hscale, dev-vscale);
}
--
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: [REVIEW PATCH] em28xx: fix bytesperline calculation in TRY_FMT
Am 06.02.2013 13:14, schrieb Hans Verkuil: From: Hans Verkuil hans.verk...@cisco.com The bytesperline calculation was incorrect: it used the old width instead of the provided width. Fixed. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/usb/em28xx/em28xx-video.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c index 2eabf2a..32bd7de 100644 --- a/drivers/media/usb/em28xx/em28xx-video.c +++ b/drivers/media/usb/em28xx/em28xx-video.c @@ -906,7 +906,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv, f-fmt.pix.width = width; f-fmt.pix.height = height; f-fmt.pix.pixelformat = fmt-fourcc; - f-fmt.pix.bytesperline = (dev-width * fmt-depth + 7) 3; + f-fmt.pix.bytesperline = (width * fmt-depth + 7) 3; f-fmt.pix.sizeimage = f-fmt.pix.bytesperline * height; f-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; if (dev-progressive) Acked-by: Frank Schäfer fschaefer@googlemail.com Also Cc: sta...@kernel.org ? 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
[REVIEW PATCH 00/17] bttv v4l2-compliance fixes
This is based on work I did a few months ago. It's been cleaned up and rebased so it is time to have this reviewed. I want to do some more testing in the next few days, but with this patch series another driver has been updated. 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
[REVIEW PATCH 02/17] bttv: fix querycap and radio v4l2-compliance issues.
From: Hans Verkuil hans.verk...@cisco.com
The querycap ioctl didn't support V4L2_CAP_DEVICE_CAPS and the radio device
implemented audio and video inputs and s_std, which are not part of the radio
API.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 101 +
1 file changed, 27 insertions(+), 74 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index ccd18e4..cc7f58f 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -2630,6 +2630,7 @@ static int bttv_s_fmt_vid_overlay(struct file *file, void
*priv,
static int bttv_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
+ struct video_device *vdev = video_devdata(file);
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
@@ -2642,11 +2643,15 @@ static int bttv_querycap(struct file *file, void *priv,
PCI:%s, pci_name(btv-c.pci));
cap-capabilities =
V4L2_CAP_VIDEO_CAPTURE |
- V4L2_CAP_VBI_CAPTURE |
V4L2_CAP_READWRITE |
- V4L2_CAP_STREAMING;
+ V4L2_CAP_STREAMING |
+ V4L2_CAP_DEVICE_CAPS;
if (no_overlay = 0)
cap-capabilities |= V4L2_CAP_VIDEO_OVERLAY;
+ if (btv-vbi_dev)
+ cap-capabilities |= V4L2_CAP_VBI_CAPTURE;
+ if (btv-radio_dev)
+ cap-capabilities |= V4L2_CAP_RADIO;
/*
* No need to lock here: those vars are initialized during board
@@ -2656,6 +2661,25 @@ static int bttv_querycap(struct file *file, void *priv,
cap-capabilities |= V4L2_CAP_RDS_CAPTURE;
if (btv-tuner_type != TUNER_ABSENT)
cap-capabilities |= V4L2_CAP_TUNER;
+ if (vdev-vfl_type == VFL_TYPE_GRABBER)
+ cap-device_caps = cap-capabilities
+ (V4L2_CAP_VIDEO_CAPTURE |
+V4L2_CAP_READWRITE |
+V4L2_CAP_STREAMING |
+V4L2_CAP_VIDEO_OVERLAY |
+V4L2_CAP_TUNER);
+ else if (vdev-vfl_type == VFL_TYPE_VBI)
+ cap-device_caps = cap-capabilities
+ (V4L2_CAP_VBI_CAPTURE |
+V4L2_CAP_READWRITE |
+V4L2_CAP_STREAMING |
+V4L2_CAP_TUNER);
+ else {
+ cap-device_caps = V4L2_CAP_RADIO | V4L2_CAP_TUNER;
+ if (btv-has_saa6588)
+ cap-device_caps |= V4L2_CAP_READWRITE |
+ V4L2_CAP_RDS_CAPTURE;
+ }
return 0;
}
@@ -3430,20 +3454,6 @@ static int radio_release(struct file *file)
return 0;
}
-static int radio_querycap(struct file *file, void *priv,
- struct v4l2_capability *cap)
-{
- struct bttv_fh *fh = priv;
- struct bttv *btv = fh-btv;
-
- strcpy(cap-driver, bttv);
- strlcpy(cap-card, btv-radio_dev-name, sizeof(cap-card));
- sprintf(cap-bus_info, PCI:%s, pci_name(btv-c.pci));
- cap-capabilities = V4L2_CAP_TUNER;
-
- return 0;
-}
-
static int radio_g_tuner(struct file *file, void *priv, struct v4l2_tuner *t)
{
struct bttv_fh *fh = priv;
@@ -3464,29 +3474,6 @@ static int radio_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
return 0;
}
-static int radio_enum_input(struct file *file, void *priv,
- struct v4l2_input *i)
-{
- if (i-index != 0)
- return -EINVAL;
-
- strcpy(i-name, Radio);
- i-type = V4L2_INPUT_TYPE_TUNER;
-
- return 0;
-}
-
-static int radio_g_audio(struct file *file, void *priv,
- struct v4l2_audio *a)
-{
- if (unlikely(a-index))
- return -EINVAL;
-
- strcpy(a-name, Radio);
-
- return 0;
-}
-
static int radio_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
{
@@ -3500,28 +3487,6 @@ static int radio_s_tuner(struct file *file, void *priv,
return 0;
}
-static int radio_s_audio(struct file *file, void *priv,
- const struct v4l2_audio *a)
-{
- if (unlikely(a-index))
- return -EINVAL;
-
- return 0;
-}
-
-static int radio_s_input(struct file *filp, void *priv, unsigned int i)
-{
- if (unlikely(i))
- return -EINVAL;
-
- return 0;
-}
-
-static int radio_s_std(struct file *file, void *fh, v4l2_std_id *norm)
-{
- return 0;
-}
-
static int radio_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *c)
{
@@ -3540,12 +3505,6 @@ static int radio_queryctrl(struct file *file, void *priv,
return 0;
}
[REVIEW PATCH 01/17] tda7432: convert to the control framework
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/tda7432.c | 276 +--
1 file changed, 110 insertions(+), 166 deletions(-)
diff --git a/drivers/media/i2c/tda7432.c b/drivers/media/i2c/tda7432.c
index f7707e6..28b5121 100644
--- a/drivers/media/i2c/tda7432.c
+++ b/drivers/media/i2c/tda7432.c
@@ -35,6 +35,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include media/i2c-addr.h
#ifndef VIDEO_AUDIO_BALANCE
@@ -60,13 +61,17 @@ MODULE_PARM_DESC(maxvol, Set maximium volume to +20dB(0)
else +0dB(1). Default
struct tda7432 {
struct v4l2_subdev sd;
- int addr;
- int input;
- int volume;
- int muted;
- int bass, treble;
- int lf, lr, rf, rr;
- int loud;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* bass/treble cluster */
+ struct v4l2_ctrl *bass;
+ struct v4l2_ctrl *treble;
+ };
+ struct {
+ /* mute/balance cluster */
+ struct v4l2_ctrl *mute;
+ struct v4l2_ctrl *balance;
+ };
};
static inline struct tda7432 *to_state(struct v4l2_subdev *sd)
@@ -74,6 +79,11 @@ static inline struct tda7432 *to_state(struct v4l2_subdev
*sd)
return container_of(sd, struct tda7432, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct tda7432, hdl)-sd;
+}
+
/* The TDA7432 is made by STS-Thompson
* http://www.st.com
* http://us.st.com/stonline/books/pdf/docs/4056.pdf
@@ -227,24 +237,22 @@ static int tda7432_write(struct v4l2_subdev *sd, int
subaddr, int val)
static int tda7432_set(struct v4l2_subdev *sd)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
- struct tda7432 *t = to_state(sd);
unsigned char buf[16];
- v4l2_dbg(1, debug, sd,
- tda7432:
7432_set(0x%02x,0x%02x,0x%02x,0x%02x,0x%02x,0x%02x,0x%02x,0x%02x,0x%02x)\n,
- t-input, t-volume, t-bass, t-treble, t-lf, t-lr,
- t-rf, t-rr, t-loud);
buf[0] = TDA7432_IN;
- buf[1] = t-input;
- buf[2] = t-volume;
- buf[3] = t-bass;
- buf[4] = t-treble;
- buf[5] = t-lf;
- buf[6] = t-lr;
- buf[7] = t-rf;
- buf[8] = t-rr;
- buf[9] = t-loud;
- if (10 != i2c_master_send(client, buf, 10)) {
+ buf[1] = TDA7432_STEREO_IN | /* Main (stereo) input */
+ TDA7432_BASS_SYM | /* Symmetric bass cut*/
+ TDA7432_BASS_NORM; /* Normal bass range */
+ buf[2] = 0x3b;
+ if (loudness)/* Turn loudness on? */
+ buf[2] |= TDA7432_LD_ON;
+ buf[3] = TDA7432_TREBLE_0DB | (TDA7432_BASS_0DB 4);
+ buf[4] = TDA7432_ATTEN_0DB;
+ buf[5] = TDA7432_ATTEN_0DB;
+ buf[6] = TDA7432_ATTEN_0DB;
+ buf[7] = TDA7432_ATTEN_0DB;
+ buf[8] = loudness;
+ if (9 != i2c_master_send(client, buf, 9)) {
v4l2_err(sd, I/O error, trying tda7432_set\n);
return -1;
}
@@ -252,174 +260,86 @@ static int tda7432_set(struct v4l2_subdev *sd)
return 0;
}
-static void do_tda7432_init(struct v4l2_subdev *sd)
-{
- struct tda7432 *t = to_state(sd);
-
- v4l2_dbg(2, debug, sd, In tda7432_init\n);
-
- t-input = TDA7432_STEREO_IN | /* Main (stereo) input */
- TDA7432_BASS_SYM | /* Symmetric bass cut*/
- TDA7432_BASS_NORM; /* Normal bass range */
- t-volume = 0x3b ; /* -27dB Volume
*/
- if (loudness)/* Turn loudness on? */
- t-volume |= TDA7432_LD_ON;
- t-muted= 1;
- t-treble = TDA7432_TREBLE_0DB; /* 0dB Treble*/
- t-bass = TDA7432_BASS_0DB; /* 0dB Bass */
- t-lf = TDA7432_ATTEN_0DB; /* 0dB attenuation */
- t-lr = TDA7432_ATTEN_0DB; /* 0dB attenuation */
- t-rf = TDA7432_ATTEN_0DB; /* 0dB attenuation */
- t-rr = TDA7432_ATTEN_0DB; /* 0dB attenuation */
- t-loud = loudness;/* insmod parameter */
-
- tda7432_set(sd);
-}
-
-static int tda7432_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+static int tda7432_log_status(struct v4l2_subdev *sd)
{
- struct tda7432 *t = to_state(sd);
+ struct tda7432 *state = to_state(sd);
- switch (ctrl-id) {
- case V4L2_CID_AUDIO_MUTE:
- ctrl-value=t-muted;
- return 0;
- case V4L2_CID_AUDIO_VOLUME:
- if (!maxvol){ /* max +20db */
- ctrl-value = ( 0x6f - (t-volume 0x7F) ) * 630;
- } else { /* max 0db */
-
[REVIEW PATCH 03/17] bttv: add VIDIOC_DBG_G_CHIP_IDENT
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_DBG_G_CHIP_IDENT is a prerequisite for the G/S_REGISTER ioctls.
In addition, add support to call G/S_REGISTER for supporting i2c devices.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 40 +
drivers/media/pci/bt8xx/bttv.h|3 +++
include/media/v4l2-chip-ident.h |8 +++
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index cc7f58f..b36d675 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -49,6 +49,7 @@
#include bttvp.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
#include media/tvaudio.h
#include media/msp3400.h
@@ -2059,6 +2060,28 @@ static int bttv_log_status(struct file *file, void *f)
return 0;
}
+static int bttv_g_chip_ident(struct file *file, void *f, struct
v4l2_dbg_chip_ident *chip)
+{
+ struct bttv_fh *fh = f;
+ struct bttv *btv = fh-btv;
+
+ chip-ident = V4L2_IDENT_NONE;
+ chip-revision = 0;
+ if (chip-match.type == V4L2_CHIP_MATCH_HOST) {
+ if (v4l2_chip_match_host(chip-match)) {
+ chip-ident = btv-id;
+ if (chip-ident == PCI_DEVICE_ID_FUSION879)
+ chip-ident = V4L2_IDENT_BT879;
+ }
+ return 0;
+ }
+ if (chip-match.type != V4L2_CHIP_MATCH_I2C_DRIVER
+ chip-match.type != V4L2_CHIP_MATCH_I2C_ADDR)
+ return -EINVAL;
+ /* TODO: is this correct? */
+ return bttv_call_all_err(btv, core, g_chip_ident, chip);
+}
+
#ifdef CONFIG_VIDEO_ADV_DEBUG
static int bttv_g_register(struct file *file, void *f,
struct v4l2_dbg_register *reg)
@@ -2069,8 +2092,12 @@ static int bttv_g_register(struct file *file, void *f,
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- if (!v4l2_chip_match_host(reg-match))
- return -EINVAL;
+ if (!v4l2_chip_match_host(reg-match)) {
+ /* TODO: subdev errors should not be ignored, this should
become a
+ subdev helper function. */
+ bttv_call_all(btv, core, g_register, reg);
+ return 0;
+ }
/* bt848 has a 12-bit register space */
reg-reg = 0xfff;
@@ -2089,8 +2116,12 @@ static int bttv_s_register(struct file *file, void *f,
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- if (!v4l2_chip_match_host(reg-match))
- return -EINVAL;
+ if (!v4l2_chip_match_host(reg-match)) {
+ /* TODO: subdev errors should not be ignored, this should
become a
+ subdev helper function. */
+ bttv_call_all(btv, core, s_register, reg);
+ return 0;
+ }
/* bt848 has a 12-bit register space */
reg-reg = 0xfff;
@@ -3394,6 +3425,7 @@ static const struct v4l2_ioctl_ops bttv_ioctl_ops = {
.vidioc_s_frequency = bttv_s_frequency,
.vidioc_log_status = bttv_log_status,
.vidioc_querystd= bttv_querystd,
+ .vidioc_g_chip_ident= bttv_g_chip_ident,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register = bttv_g_register,
.vidioc_s_register = bttv_s_register,
diff --git a/drivers/media/pci/bt8xx/bttv.h b/drivers/media/pci/bt8xx/bttv.h
index 79a1124..6139ce2 100644
--- a/drivers/media/pci/bt8xx/bttv.h
+++ b/drivers/media/pci/bt8xx/bttv.h
@@ -359,6 +359,9 @@ void bttv_gpio_bits(struct bttv_core *core, u32 mask, u32
bits);
#define bttv_call_all(btv, o, f, args...) \
v4l2_device_call_all(btv-c.v4l2_dev, 0, o, f, ##args)
+#define bttv_call_all_err(btv, o, f, args...) \
+ v4l2_device_call_until_err(btv-c.v4l2_dev, 0, o, f, ##args)
+
extern int bttv_I2CRead(struct bttv *btv, unsigned char addr, char *probe_for);
extern int bttv_I2CWrite(struct bttv *btv, unsigned char addr, unsigned char
b1,
unsigned char b2, int both);
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index 4ee125b..b5996f9 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -96,12 +96,20 @@ enum {
/* module au0828 */
V4L2_IDENT_AU0828 = 828,
+ /* module bttv: ident 848 + 849 */
+ V4L2_IDENT_BT848 = 848,
+ V4L2_IDENT_BT849 = 849,
+
/* module bt856: just ident 856 */
V4L2_IDENT_BT856 = 856,
/* module bt866: just ident 866 */
V4L2_IDENT_BT866 = 866,
+ /* module bttv: ident 878 + 879 */
+ V4L2_IDENT_BT878 = 878,
+ V4L2_IDENT_BT879 = 879,
+
/* module ks0127: reserved range 1120-1129 */
[REVIEW PATCH 04/17] bttv: fix ENUM_INPUT and S_INPUT
From: Hans Verkuil hans.verk...@cisco.com
- Fix ENUM_INPUT audioset.
- Fix incorrect input check in s_input.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index b36d675..6e61dbd 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -1923,7 +1923,7 @@ static int bttv_enum_input(struct file *file, void *priv,
}
i-type = V4L2_INPUT_TYPE_CAMERA;
- i-audioset = 1;
+ i-audioset = 0;
if (btv-tuner_type != TUNER_ABSENT i-index == 0) {
sprintf(i-name, Television);
@@ -1964,21 +1964,16 @@ static int bttv_s_input(struct file *file, void *priv,
unsigned int i)
{
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
-
int err;
err = v4l2_prio_check(btv-prio, fh-prio);
- if (unlikely(err))
- goto err;
+ if (err)
+ return err;
- if (i bttv_tvcards[btv-c.type].video_inputs) {
- err = -EINVAL;
- goto err;
- }
+ if (i = bttv_tvcards[btv-c.type].video_inputs)
+ return -EINVAL;
set_input(btv, i, btv-tvnorm);
-
-err:
return 0;
}
--
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
[REVIEW PATCH 10/17] bttv: fill in fb-flags for VIDIOC_G_FBUF
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/pci/bt8xx/bttv-driver.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 70878e6..81886e1 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -2769,6 +2769,7 @@ static int bttv_g_fbuf(struct file *file, void *f, *fb = btv-fbuf; fb-capability = V4L2_FBUF_CAP_LIST_CLIPPING; + fb-flags = V4L2_FBUF_FLAG_PRIMARY; if (fh-ovfmt) fb-fmt.pixelformat = fh-ovfmt-fourcc; return 0; -- 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
[REVIEW PATCH 11/17] bttv: fix field handling inside TRY_FMT.
From: Hans Verkuil hans.verk...@cisco.com
- don't return -EINVAL for invalid field types, handle those as if it
was FIELD_ANY.
- the handling of FIELD_SEQ_BT/TB was wrong as well: if such field formats
aren't supported, then fall back to FIELD_ANY instead of returning an error.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 81886e1..21b38ee 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -2530,6 +2530,7 @@ static int bttv_try_fmt_vid_cap(struct file *file, void
*priv,
struct bttv *btv = fh-btv;
enum v4l2_field field;
__s32 width, height;
+ __s32 height2;
int rc;
fmt = format_by_fourcc(f-fmt.pix.pixelformat);
@@ -2538,30 +2539,25 @@ static int bttv_try_fmt_vid_cap(struct file *file, void
*priv,
field = f-fmt.pix.field;
- if (V4L2_FIELD_ANY == field) {
- __s32 height2;
-
- height2 = btv-crop[!!fh-do_crop].rect.height 1;
- field = (f-fmt.pix.height height2)
- ? V4L2_FIELD_INTERLACED
- : V4L2_FIELD_BOTTOM;
- }
-
- if (V4L2_FIELD_SEQ_BT == field)
- field = V4L2_FIELD_SEQ_TB;
-
switch (field) {
case V4L2_FIELD_TOP:
case V4L2_FIELD_BOTTOM:
case V4L2_FIELD_ALTERNATE:
case V4L2_FIELD_INTERLACED:
break;
+ case V4L2_FIELD_SEQ_BT:
case V4L2_FIELD_SEQ_TB:
- if (fmt-flags FORMAT_FLAGS_PLANAR)
- return -EINVAL;
+ if (!(fmt-flags FORMAT_FLAGS_PLANAR)) {
+ field = V4L2_FIELD_SEQ_TB;
+ break;
+ }
+ /* fall through */
+ default: /* FIELD_ANY case */
+ height2 = btv-crop[!!fh-do_crop].rect.height 1;
+ field = (f-fmt.pix.height height2)
+ ? V4L2_FIELD_INTERLACED
+ : V4L2_FIELD_BOTTOM;
break;
- default:
- return -EINVAL;
}
width = f-fmt.pix.width;
--
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
[REVIEW PATCH 12/17] bttv: convert to the control framework.
From: Hans Verkuil hans.verk...@cisco.com Note that the private chroma agc control has been replaced with the standard CHROMA_AGC control. Also fixes a mute/automute problem where closing the file handle would force mute on. That's not what you want. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/pci/bt8xx/bttv-cards.c |5 +- drivers/media/pci/bt8xx/bttv-driver.c | 682 + drivers/media/pci/bt8xx/bttvp.h | 16 +- include/uapi/linux/v4l2-controls.h|5 + 4 files changed, 271 insertions(+), 437 deletions(-) diff --git a/drivers/media/pci/bt8xx/bttv-cards.c b/drivers/media/pci/bt8xx/bttv-cards.c index c4c5917..682ed89 100644 --- a/drivers/media/pci/bt8xx/bttv-cards.c +++ b/drivers/media/pci/bt8xx/bttv-cards.c @@ -3554,8 +3554,9 @@ void bttv_init_card2(struct bttv *btv) I2C_CLIENT_END }; - if (v4l2_i2c_new_subdev(btv-c.v4l2_dev, - btv-c.i2c_adap, tda7432, 0, addrs)) + btv-sd_tda7432 = v4l2_i2c_new_subdev(btv-c.v4l2_dev, + btv-c.i2c_adap, tda7432, 0, addrs); + if (btv-sd_tda7432) return; } diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 21b38ee..09f58f3 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -94,7 +94,7 @@ static unsigned int combfilter; static unsigned int lumafilter; static unsigned int automute= 1; static unsigned int chroma_agc; -static unsigned int adc_crush = 1; +static unsigned int agc_crush = 1; static unsigned int whitecrush_upper = 0xCF; static unsigned int whitecrush_lower = 0x7F; static unsigned int vcr_hack; @@ -126,7 +126,7 @@ module_param(combfilter,int, 0444); module_param(lumafilter,int, 0444); module_param(automute, int, 0444); module_param(chroma_agc,int, 0444); -module_param(adc_crush, int, 0444); +module_param(agc_crush, int, 0444); module_param(whitecrush_upper, int, 0444); module_param(whitecrush_lower, int, 0444); module_param(vcr_hack, int, 0444); @@ -139,27 +139,27 @@ module_param_array(video_nr,int, NULL, 0444); module_param_array(radio_nr,int, NULL, 0444); module_param_array(vbi_nr, int, NULL, 0444); -MODULE_PARM_DESC(radio,The TV card supports radio, default is 0 (no)); -MODULE_PARM_DESC(bigendian,byte order of the framebuffer, default is native endian); -MODULE_PARM_DESC(bttv_verbose,verbose startup messages, default is 1 (yes)); -MODULE_PARM_DESC(bttv_gpio,log gpio changes, default is 0 (no)); -MODULE_PARM_DESC(bttv_debug,debug messages, default is 0 (no)); -MODULE_PARM_DESC(irq_debug,irq handler debug messages, default is 0 (no)); +MODULE_PARM_DESC(radio, The TV card supports radio, default is 0 (no)); +MODULE_PARM_DESC(bigendian, byte order of the framebuffer, default is native endian); +MODULE_PARM_DESC(bttv_verbose, verbose startup messages, default is 1 (yes)); +MODULE_PARM_DESC(bttv_gpio, log gpio changes, default is 0 (no)); +MODULE_PARM_DESC(bttv_debug, debug messages, default is 0 (no)); +MODULE_PARM_DESC(irq_debug, irq handler debug messages, default is 0 (no)); MODULE_PARM_DESC(disable_ir, disable infrared remote support); -MODULE_PARM_DESC(gbuffers,number of capture buffers. range 2-32, default 8); -MODULE_PARM_DESC(gbufsize,size of the capture buffers, default is 0x208000); -MODULE_PARM_DESC(reset_crop,reset cropping parameters at open(), default +MODULE_PARM_DESC(gbuffers, number of capture buffers. range 2-32, default 8); +MODULE_PARM_DESC(gbufsize, size of the capture buffers, default is 0x208000); +MODULE_PARM_DESC(reset_crop, reset cropping parameters at open(), default is 1 (yes) for compatibility with older applications); -MODULE_PARM_DESC(automute,mute audio on bad/missing video signal, default is 1 (yes)); -MODULE_PARM_DESC(chroma_agc,enables the AGC of chroma signal, default is 0 (no)); -MODULE_PARM_DESC(adc_crush,enables the luminance ADC crush, default is 1 (yes)); -MODULE_PARM_DESC(whitecrush_upper,sets the white crush upper value, default is 207); -MODULE_PARM_DESC(whitecrush_lower,sets the white crush lower value, default is 127); -MODULE_PARM_DESC(vcr_hack,enables the VCR hack (improves synch on poor VCR tapes), default is 0 (no)); -MODULE_PARM_DESC(irq_iswitch,switch inputs in irq handler); -MODULE_PARM_DESC(uv_ratio,ratio between u and v gains, default is 50); -MODULE_PARM_DESC(full_luma_range,use the full luma range, default is 0 (no)); -MODULE_PARM_DESC(coring,set the luma coring level, default is 0 (no)); +MODULE_PARM_DESC(automute, mute audio on bad/missing video signal, default is 1 (yes)); +MODULE_PARM_DESC(chroma_agc, enables the AGC of chroma signal, default is 0 (no)); +MODULE_PARM_DESC(agc_crush, enables the luminance AGC crush, default is 1 (yes));
[REVIEW PATCH 05/17] bttv: remove g/s_audio since there is only one audio input.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 6e61dbd..a02c031 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -3138,23 +3138,6 @@ static int bttv_s_crop(struct file *file, void *f, const
struct v4l2_crop *crop)
return 0;
}
-static int bttv_g_audio(struct file *file, void *priv, struct v4l2_audio *a)
-{
- if (unlikely(a-index))
- return -EINVAL;
-
- strcpy(a-name, audio);
- return 0;
-}
-
-static int bttv_s_audio(struct file *file, void *priv, const struct v4l2_audio
*a)
-{
- if (unlikely(a-index))
- return -EINVAL;
-
- return 0;
-}
-
static ssize_t bttv_read(struct file *file, char __user *data,
size_t count, loff_t *ppos)
{
@@ -3390,8 +3373,6 @@ static const struct v4l2_ioctl_ops bttv_ioctl_ops = {
.vidioc_g_fmt_vbi_cap = bttv_g_fmt_vbi_cap,
.vidioc_try_fmt_vbi_cap = bttv_try_fmt_vbi_cap,
.vidioc_s_fmt_vbi_cap = bttv_s_fmt_vbi_cap,
- .vidioc_g_audio = bttv_g_audio,
- .vidioc_s_audio = bttv_s_audio,
.vidioc_cropcap = bttv_cropcap,
.vidioc_reqbufs = bttv_reqbufs,
.vidioc_querybuf= bttv_querybuf,
--
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
[REVIEW PATCH 08/17] bttv: G_PARM: set readbuffers.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/pci/bt8xx/bttv-driver.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 07c0919..3ba423e 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -2970,6 +2970,9 @@ static int bttv_g_parm(struct file *file, void *f, struct bttv_fh *fh = f; struct bttv *btv = fh-btv; + if (parm-type != V4L2_BUF_TYPE_VIDEO_CAPTURE) + return -EINVAL; + parm-parm.capture.readbuffers = gbuffers; v4l2_video_std_frame_period(bttv_tvnorms[btv-tvnorm].v4l2_id, parm-parm.capture.timeperframe); -- 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
[REVIEW PATCH 17/17] bttv: fix g_tuner capabilities override.
From: Hans Verkuil hans.verk...@cisco.com The capability field of v4l2_tuner should be ORed by the various subdevs and by the main driver. In this case the stereo capability was dropped. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/i2c/tvaudio.c |2 +- drivers/media/pci/bt8xx/bttv-driver.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c index e3b33b7..4c91b35 100644 --- a/drivers/media/i2c/tvaudio.c +++ b/drivers/media/i2c/tvaudio.c @@ -1803,7 +1803,7 @@ static int tvaudio_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner *vt) vt-audmode = chip-audmode; vt-rxsubchans = desc-getrxsubchans(chip); - vt-capability = V4L2_TUNER_CAP_STEREO | + vt-capability |= V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_LANG1 | V4L2_TUNER_CAP_LANG2; return 0; diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 98b8fd2..0492fff 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -2787,9 +2787,9 @@ static int bttv_g_tuner(struct file *file, void *priv, return -EINVAL; t-rxsubchans = V4L2_TUNER_SUB_MONO; + t-capability = V4L2_TUNER_CAP_NORM; bttv_call_all(btv, tuner, g_tuner, t); strcpy(t-name, Television); - t-capability = V4L2_TUNER_CAP_NORM; t-type = V4L2_TUNER_ANALOG_TV; if (btread(BT848_DSTATUS)BT848_DSTATUS_HLOC) t-signal = 0x; -- 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
[REVIEW PATCH 15/17] bttv: use centralized std and implement g_std.
From: Hans Verkuil hans.verk...@cisco.com
The 'current_norm' field cannot be used if multiple device nodes (video and
vbi in this case) set the same std.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 13 -
drivers/media/pci/bt8xx/bttvp.h |1 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 559c1d9..98b8fd2 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -1716,6 +1716,7 @@ static int bttv_s_std(struct file *file, void *priv,
v4l2_std_id *id)
goto err;
}
+ btv-std = *id;
set_tvnorm(btv, i);
err:
@@ -1723,6 +1724,15 @@ err:
return err;
}
+static int bttv_g_std(struct file *file, void *priv, v4l2_std_id *id)
+{
+ struct bttv_fh *fh = priv;
+ struct bttv *btv = fh-btv;
+
+ *id = btv-std;
+ return 0;
+}
+
static int bttv_querystd(struct file *file, void *f, v4l2_std_id *id)
{
struct bttv_fh *fh = f;
@@ -3147,6 +3157,7 @@ static const struct v4l2_ioctl_ops bttv_ioctl_ops = {
.vidioc_qbuf= bttv_qbuf,
.vidioc_dqbuf = bttv_dqbuf,
.vidioc_s_std = bttv_s_std,
+ .vidioc_g_std = bttv_g_std,
.vidioc_enum_input = bttv_enum_input,
.vidioc_g_input = bttv_g_input,
.vidioc_s_input = bttv_s_input,
@@ -3177,7 +3188,6 @@ static struct video_device bttv_video_template = {
.fops = bttv_fops,
.ioctl_ops= bttv_ioctl_ops,
.tvnorms = BTTV_NORMS,
- .current_norm = V4L2_STD_PAL,
};
/* --- */
@@ -4173,6 +4183,7 @@ static int bttv_probe(struct pci_dev *dev, const struct
pci_device_id *pci_id)
bttv_set_frequency(btv, init_freq);
btv-radio_freq = 90500 * 16; /* 90.5Mhz default */
}
+ btv-std = V4L2_STD_PAL;
init_irqreg(btv);
v4l2_ctrl_handler_setup(hdl);
diff --git a/drivers/media/pci/bt8xx/bttvp.h b/drivers/media/pci/bt8xx/bttvp.h
index 12cc4eb..86d67bb 100644
--- a/drivers/media/pci/bt8xx/bttvp.h
+++ b/drivers/media/pci/bt8xx/bttvp.h
@@ -424,6 +424,7 @@ struct bttv {
unsigned int mute;
unsigned long tv_freq;
unsigned int tvnorm;
+ v4l2_std_id std;
int hue, contrast, bright, saturation;
struct v4l2_framebuffer fbuf;
unsigned int field_count;
--
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
[REVIEW PATCH 09/17] bttv: fill in colorspace.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/pci/bt8xx/bttv-driver.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c index 3ba423e..70878e6 100644 --- a/drivers/media/pci/bt8xx/bttv-driver.c +++ b/drivers/media/pci/bt8xx/bttv-driver.c @@ -2506,6 +2506,7 @@ static int bttv_g_fmt_vid_cap(struct file *file, void *priv, fh-width, fh-height); f-fmt.pix.field= fh-cap.field; f-fmt.pix.pixelformat = fh-fmt-fourcc; + f-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; return 0; } @@ -2577,6 +2578,7 @@ static int bttv_try_fmt_vid_cap(struct file *file, void *priv, /* update data for the application */ f-fmt.pix.field = field; pix_format_set_size(f-fmt.pix, fmt, width, height); + f-fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; return 0; } -- 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
[REVIEW PATCH 16/17] bttv: there may be multiple tvaudio/tda7432 devices.
From: Hans Verkuil hans.verk...@cisco.com
Probe for additional tvaudio devices, and allow tvaudio+tda7432 to
co-exist. My STB TV PCI FM bttv card has a tda7432, a tda9850 and a
tea6420.
Unfortunately, even with this patch I still don't get audio out, but
at least all the devices are recognized.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-cards.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-cards.c
b/drivers/media/pci/bt8xx/bttv-cards.c
index 682ed89..fa0faaa 100644
--- a/drivers/media/pci/bt8xx/bttv-cards.c
+++ b/drivers/media/pci/bt8xx/bttv-cards.c
@@ -3547,6 +3547,16 @@ void bttv_init_card2(struct bttv *btv)
if (btv-sd_msp34xx)
return;
+ /* Now see if we can find one of the tvaudio devices. */
+ btv-sd_tvaudio = v4l2_i2c_new_subdev(btv-c.v4l2_dev,
+ btv-c.i2c_adap, tvaudio, 0, tvaudio_addrs());
+ if (btv-sd_tvaudio) {
+ /* There may be two tvaudio chips on the card, so try to
+ find another. */
+ v4l2_i2c_new_subdev(btv-c.v4l2_dev,
+ btv-c.i2c_adap, tvaudio, 0, tvaudio_addrs());
+ }
+
/* it might also be a tda7432. */
if (!bttv_tvcards[btv-c.type].no_tda7432) {
static const unsigned short addrs[] = {
@@ -3559,10 +3569,6 @@ void bttv_init_card2(struct bttv *btv)
if (btv-sd_tda7432)
return;
}
-
- /* Now see if we can find one of the tvaudio devices. */
- btv-sd_tvaudio = v4l2_i2c_new_subdev(btv-c.v4l2_dev,
- btv-c.i2c_adap, tvaudio, 0, tvaudio_addrs());
if (btv-sd_tvaudio)
return;
--
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
[REVIEW PATCH 14/17] bttv: fix priority handling.
From: Hans Verkuil hans.verk...@cisco.com
Replace the - incorrect - manual priority handling with the core priority
implementation.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 61 -
drivers/media/pci/bt8xx/bttvp.h |6
2 files changed, 6 insertions(+), 61 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 96aa2c9..559c1d9 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -1706,11 +1706,7 @@ static int bttv_s_std(struct file *file, void *priv,
v4l2_std_id *id)
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
unsigned int i;
- int err;
-
- err = v4l2_prio_check(btv-prio, fh-prio);
- if (err)
- goto err;
+ int err = 0;
for (i = 0; i BTTV_TVNORMS; i++)
if (*id bttv_tvnorms[i].v4l2_id)
@@ -1793,11 +1789,6 @@ static int bttv_s_input(struct file *file, void *priv,
unsigned int i)
{
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
- int err;
-
- err = v4l2_prio_check(btv-prio, fh-prio);
- if (err)
- return err;
if (i = bttv_tvcards[btv-c.type].video_inputs)
return -EINVAL;
@@ -1811,15 +1802,10 @@ static int bttv_s_tuner(struct file *file, void *priv,
{
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
- int err;
if (t-index)
return -EINVAL;
- err = v4l2_prio_check(btv-prio, fh-prio);
- if (err)
- return err;
-
bttv_call_all(btv, tuner, s_tuner, t);
if (btv-audio_mode_gpio)
@@ -1862,14 +1848,10 @@ static int bttv_s_frequency(struct file *file, void
*priv,
{
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
- int err;
if (f-tuner)
return -EINVAL;
- err = v4l2_prio_check(btv-prio, fh-prio);
- if (err)
- return err;
bttv_set_frequency(btv, f);
return 0;
}
@@ -2808,28 +2790,6 @@ static int bttv_g_tuner(struct file *file, void *priv,
return 0;
}
-static int bttv_g_priority(struct file *file, void *f, enum v4l2_priority *p)
-{
- struct bttv_fh *fh = f;
- struct bttv *btv = fh-btv;
-
- *p = v4l2_prio_max(btv-prio);
-
- return 0;
-}
-
-static int bttv_s_priority(struct file *file, void *f,
- enum v4l2_priority prio)
-{
- struct bttv_fh *fh = f;
- struct bttv *btv = fh-btv;
- int rc;
-
- rc = v4l2_prio_change(btv-prio, fh-prio, prio);
-
- return rc;
-}
-
static int bttv_cropcap(struct file *file, void *priv,
struct v4l2_cropcap *cap)
{
@@ -2882,11 +2842,6 @@ static int bttv_s_crop(struct file *file, void *f, const
struct v4l2_crop *crop)
/* Make sure tvnorm, vbi_end and the current cropping
parameters remain consistent until we're done. Note
read() may change vbi_end in check_alloc_btres_lock(). */
- retval = v4l2_prio_check(btv-prio, fh-prio);
- if (0 != retval) {
- return retval;
- }
-
retval = -EBUSY;
if (locked_btres(fh-btv, VIDEO_RESOURCES)) {
@@ -3068,8 +3023,6 @@ static int bttv_open(struct file *file)
fh-type = type;
fh-ov.setup_ok = 0;
- v4l2_prio_open(btv-prio, fh-prio);
-
videobuf_queue_sg_init(fh-cap, bttv_video_qops,
btv-c.pci-dev, btv-s_lock,
V4L2_BUF_TYPE_VIDEO_CAPTURE,
@@ -3139,7 +3092,6 @@ static int bttv_release(struct file *file)
videobuf_mmap_free(fh-cap);
videobuf_mmap_free(fh-vbi);
- v4l2_prio_close(btv-prio, fh-prio);
file-private_data = NULL;
btv-users--;
@@ -3207,8 +3159,6 @@ static const struct v4l2_ioctl_ops bttv_ioctl_ops = {
.vidioc_g_fbuf = bttv_g_fbuf,
.vidioc_s_fbuf = bttv_s_fbuf,
.vidioc_overlay = bttv_overlay,
- .vidioc_g_priority = bttv_g_priority,
- .vidioc_s_priority = bttv_s_priority,
.vidioc_g_parm = bttv_g_parm,
.vidioc_g_frequency = bttv_g_frequency,
.vidioc_s_frequency = bttv_s_frequency,
@@ -3249,13 +3199,13 @@ static int radio_open(struct file *file)
return -ENOMEM;
file-private_data = fh;
*fh = btv-init;
-
- v4l2_prio_open(btv-prio, fh-prio);
+ v4l2_fh_init(fh-fh, vdev);
btv-radio_user++;
bttv_call_all(btv, tuner, s_radio);
audio_input(btv,TVAUDIO_INPUT_RADIO);
+ v4l2_fh_add(fh-fh);
return 0;
}
@@ -3266,8 +3216,9 @@ static int radio_release(struct file *file)
struct bttv *btv = fh-btv;
[REVIEW PATCH 13/17] bttv: add support for control events.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 48 -
drivers/media/pci/bt8xx/bttvp.h |4 +++
2 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 09f58f3..96aa2c9 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -49,6 +49,7 @@
#include bttvp.h
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
+#include media/v4l2-event.h
#include media/v4l2-chip-ident.h
#include media/tvaudio.h
#include media/msp3400.h
@@ -2982,34 +2983,43 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
struct bttv_fh *fh = file-private_data;
struct bttv_buffer *buf;
enum v4l2_field field;
- unsigned int rc = POLLERR;
+ unsigned int rc = 0;
+ unsigned long req_events = poll_requested_events(wait);
+
+ if (v4l2_event_pending(fh-fh))
+ rc = POLLPRI;
+ else if (req_events POLLPRI)
+ poll_wait(file, fh-fh.wait, wait);
+
+ if (!(req_events (POLLIN | POLLRDNORM)))
+ return rc;
if (V4L2_BUF_TYPE_VBI_CAPTURE == fh-type) {
if (!check_alloc_btres_lock(fh-btv,fh,RESOURCE_VBI))
- return POLLERR;
- return videobuf_poll_stream(file, fh-vbi, wait);
+ return rc | POLLERR;
+ return rc | videobuf_poll_stream(file, fh-vbi, wait);
}
if (check_btres(fh,RESOURCE_VIDEO_STREAM)) {
/* streaming capture */
if (list_empty(fh-cap.stream))
- goto err;
+ return rc | POLLERR;
buf = list_entry(fh-cap.stream.next,struct
bttv_buffer,vb.stream);
} else {
/* read() capture */
if (NULL == fh-cap.read_buf) {
/* need to capture a new frame */
if (locked_btres(fh-btv,RESOURCE_VIDEO_STREAM))
- goto err;
+ return rc | POLLERR;
fh-cap.read_buf = videobuf_sg_alloc(fh-cap.msize);
if (NULL == fh-cap.read_buf)
- goto err;
+ return rc | POLLERR;
fh-cap.read_buf-memory = V4L2_MEMORY_USERPTR;
field = videobuf_next_field(fh-cap);
if (0 !=
fh-cap.ops-buf_prepare(fh-cap,fh-cap.read_buf,field)) {
kfree (fh-cap.read_buf);
fh-cap.read_buf = NULL;
- goto err;
+ return rc | POLLERR;
}
fh-cap.ops-buf_queue(fh-cap,fh-cap.read_buf);
fh-cap.read_off = 0;
@@ -3020,10 +3030,7 @@ static unsigned int bttv_poll(struct file *file,
poll_table *wait)
poll_wait(file, buf-vb.done, wait);
if (buf-vb.state == VIDEOBUF_DONE ||
buf-vb.state == VIDEOBUF_ERROR)
- rc = POLLIN|POLLRDNORM;
- else
- rc = 0;
-err:
+ rc = rc | POLLIN|POLLRDNORM;
return rc;
}
@@ -3056,6 +3063,7 @@ static int bttv_open(struct file *file)
file-private_data = fh;
*fh = btv-init;
+ v4l2_fh_init(fh-fh, vdev);
fh-type = type;
fh-ov.setup_ok = 0;
@@ -3095,6 +3103,7 @@ static int bttv_open(struct file *file)
bttv_vbi_fmt_reset(fh-vbi_fmt, btv-tvnorm);
bttv_field_count(btv);
+ v4l2_fh_add(fh-fh);
return 0;
}
@@ -3132,7 +3141,6 @@ static int bttv_release(struct file *file)
videobuf_mmap_free(fh-vbi);
v4l2_prio_close(btv-prio, fh-prio);
file-private_data = NULL;
- kfree(fh);
btv-users--;
bttv_field_count(btv);
@@ -3140,6 +3148,9 @@ static int bttv_release(struct file *file)
if (!btv-users)
audio_mute(btv, btv-mute);
+ v4l2_fh_del(fh-fh);
+ v4l2_fh_exit(fh-fh);
+ kfree(fh);
return 0;
}
@@ -3203,6 +3214,8 @@ static const struct v4l2_ioctl_ops bttv_ioctl_ops = {
.vidioc_s_frequency = bttv_s_frequency,
.vidioc_log_status = bttv_log_status,
.vidioc_querystd= bttv_querystd,
+ .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
.vidioc_g_chip_ident= bttv_g_chip_ident,
#ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register = bttv_g_register,
@@ -3315,10 +3328,17 @@ static unsigned int radio_poll(struct file *file,
poll_table *wait)
{
struct bttv_fh *fh =
[REVIEW PATCH 07/17] bttv: set initial tv/radio frequencies
From: Hans Verkuil hans.verk...@cisco.com
Set an initial frequencies when the driver is loaded. That way G_FREQUENCY will
give a frequency that corresponds with reality.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 34 +++--
drivers/media/pci/bt8xx/bttvp.h |3 ++-
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 228b7c1..07c0919 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -2007,10 +2007,27 @@ static int bttv_g_frequency(struct file *file, void
*priv,
if (f-tuner)
return -EINVAL;
- f-frequency = btv-freq;
+ f-frequency = f-type == V4L2_TUNER_RADIO ?
+ btv-radio_freq : btv-tv_freq;
+
return 0;
}
+static void bttv_set_frequency(struct bttv *btv, struct v4l2_frequency *f)
+{
+ bttv_call_all(btv, tuner, s_frequency, f);
+ /* s_frequency may clamp the frequency, so get the actual
+ frequency before assigning radio/tv_freq. */
+ bttv_call_all(btv, tuner, g_frequency, f);
+ if (f-type == V4L2_TUNER_RADIO) {
+ btv-radio_freq = f-frequency;
+ if (btv-has_matchbox)
+ tea5757_set_freq(btv, btv-radio_freq);
+ } else {
+ btv-tv_freq = f-frequency;
+ }
+}
+
static int bttv_s_frequency(struct file *file, void *priv,
struct v4l2_frequency *f)
{
@@ -2024,11 +2041,7 @@ static int bttv_s_frequency(struct file *file, void
*priv,
err = v4l2_prio_check(btv-prio, fh-prio);
if (err)
return err;
-
- btv-freq = f-frequency;
- bttv_call_all(btv, tuner, s_frequency, f);
- if (btv-has_matchbox btv-radio_user)
- tea5757_set_freq(btv, btv-freq);
+ bttv_set_frequency(btv, f);
return 0;
}
@@ -4216,6 +4229,11 @@ static void pci_set_command(struct pci_dev *dev)
static int bttv_probe(struct pci_dev *dev, const struct pci_device_id *pci_id)
{
+ struct v4l2_frequency init_freq = {
+ .tuner = 0,
+ .type = V4L2_TUNER_ANALOG_TV,
+ .frequency = 980,
+ };
int result;
unsigned char lat;
struct bttv *btv;
@@ -4356,6 +4374,10 @@ static int bttv_probe(struct pci_dev *dev, const struct
pci_device_id *pci_id)
/* some card-specific stuff (needs working i2c) */
bttv_init_card2(btv);
bttv_init_tuner(btv);
+ if (btv-tuner_type != TUNER_ABSENT) {
+ bttv_set_frequency(btv, init_freq);
+ btv-radio_freq = 90500 * 16; /* 90.5Mhz default */
+ }
init_irqreg(btv);
/* register video4linux + input */
diff --git a/drivers/media/pci/bt8xx/bttvp.h b/drivers/media/pci/bt8xx/bttvp.h
index 9ec0adb..528e03e 100644
--- a/drivers/media/pci/bt8xx/bttvp.h
+++ b/drivers/media/pci/bt8xx/bttvp.h
@@ -418,7 +418,7 @@ struct bttv {
unsigned int input;
unsigned int audio;
unsigned int mute;
- unsigned long freq;
+ unsigned long tv_freq;
unsigned int tvnorm;
int hue, contrast, bright, saturation;
struct v4l2_framebuffer fbuf;
@@ -442,6 +442,7 @@ struct bttv {
int has_radio;
int radio_user;
int radio_uses_msp_demodulator;
+ unsigned long radio_freq;
/* miro/pinnacle + Aimslab VHX
philips matchbox (tea5757 radio tuner) support */
--
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
[REVIEW PATCH 06/17] bttv: disable g/s_tuner and g/s_freq when no tuner present, fix return codes.
From: Hans Verkuil hans.verk...@cisco.com
If no tuner is present, then disable the tuner and frequency ioctls.
We can remove a number of checks from those ioctls testing for the presence
of a tuner.
Also remove some tuner type checks (now done by the core) and fix an
error return when the prio check fails.
Finally some 'unlikely' statements are removed since those only make sense
in tightly often executed loops, otherwise they just clutter up the code.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/bt8xx/bttv-driver.c | 44 -
1 file changed, 16 insertions(+), 28 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index a02c031..228b7c1 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -1984,25 +1984,17 @@ static int bttv_s_tuner(struct file *file, void *priv,
struct bttv *btv = fh-btv;
int err;
- if (unlikely(0 != t-index))
+ if (t-index)
return -EINVAL;
- if (unlikely(btv-tuner_type == TUNER_ABSENT)) {
- err = -EINVAL;
- goto err;
- }
-
err = v4l2_prio_check(btv-prio, fh-prio);
- if (unlikely(err))
- goto err;
+ if (err)
+ return err;
bttv_call_all(btv, tuner, s_tuner, t);
if (btv-audio_mode_gpio)
btv-audio_mode_gpio(btv, t, 1);
-
-err:
-
return 0;
}
@@ -2012,9 +2004,10 @@ static int bttv_g_frequency(struct file *file, void
*priv,
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
- f-type = btv-radio_user ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
- f-frequency = btv-freq;
+ if (f-tuner)
+ return -EINVAL;
+ f-frequency = btv-freq;
return 0;
}
@@ -2025,24 +2018,17 @@ static int bttv_s_frequency(struct file *file, void
*priv,
struct bttv *btv = fh-btv;
int err;
- if (unlikely(f-tuner != 0))
+ if (f-tuner)
return -EINVAL;
err = v4l2_prio_check(btv-prio, fh-prio);
- if (unlikely(err))
- goto err;
+ if (err)
+ return err;
- if (unlikely(f-type != (btv-radio_user
- ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV))) {
- err = -EINVAL;
- goto err;
- }
btv-freq = f-frequency;
bttv_call_all(btv, tuner, s_frequency, f);
if (btv-has_matchbox btv-radio_user)
tea5757_set_freq(btv, btv-freq);
-err:
-
return 0;
}
@@ -2983,8 +2969,6 @@ static int bttv_g_tuner(struct file *file, void *priv,
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
- if (btv-tuner_type == TUNER_ABSENT)
- return -EINVAL;
if (0 != t-index)
return -EINVAL;
@@ -3467,8 +3451,6 @@ static int radio_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
struct bttv_fh *fh = priv;
struct bttv *btv = fh-btv;
- if (btv-tuner_type == TUNER_ABSENT)
- return -EINVAL;
if (0 != t-index)
return -EINVAL;
strcpy(t-name, Radio);
@@ -4112,7 +4094,7 @@ static irqreturn_t bttv_irq(int irq, void *dev_id)
/* --- */
-/* initialitation */
+/* initialization */
static struct video_device *vdev_init(struct bttv *btv,
const struct video_device *template,
@@ -4131,6 +4113,12 @@ static struct video_device *vdev_init(struct bttv *btv,
snprintf(vfd-name, sizeof(vfd-name), BT%d%s %s (%s),
btv-id, (btv-id==848 btv-revision==0x12) ? A : ,
type_name, bttv_tvcards[btv-c.type].name);
+ if (btv-tuner_type == TUNER_ABSENT) {
+ v4l2_disable_ioctl(vfd, VIDIOC_G_FREQUENCY);
+ v4l2_disable_ioctl(vfd, VIDIOC_S_FREQUENCY);
+ v4l2_disable_ioctl(vfd, VIDIOC_G_TUNER);
+ v4l2_disable_ioctl(vfd, VIDIOC_S_TUNER);
+ }
return vfd;
}
--
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 update notification: 2 patches updated
Em Wed, 06 Feb 2013 16:35:06 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 05.02.2013 23:08, schrieb Mauro Carvalho Chehab: Em Tue, 05 Feb 2013 22:46:10 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 05.02.2013 22:33, schrieb Patchwork: Hello, The following patches (submitted by you) have been updated in patchwork: ... * [RFC] em28xx: fix analog streaming with USB bulk transfers - http://patchwork.linuxtv.org/patch/16197/ was: New now: RFC What's your plan with this patch ? We have this regression in the media-tree since a few weeks now. Nobody replied to it or came up with a better solution... Well, you tagged it as RFC. I just marked as such at patchwork. I don't even read patches tagged as [RFC] or [REVIEW], Uhm... even patches which are sent to you as the maintainer of the _driver_ ? Isn't commenting / reviewing patches the maintainers job ? as those patches will be resubmitted later by the patch author, if they're ok, or a new version will be sent instead. That's what I'm asking you. Is this patch ok / ready ? Or can I generally conclude that patches are fine when there is no reaction on them ? Frank, As you may notice, my main job with regards to media stuff is to be the media core maintainer. My work as a driver maintainer or as a developer is forced to go to a second plane, as my time is limited. So, I generally trust that driver developers are doing the right thing. ATM, I won't have anytime soon to test patches. So, if those patches require any test from me, they'll need to be postponed to 3.10, as I'm finishing the handling of the patches for 3.9 today. Also, from my side, there are simply too much patches sent to me, either on my inbox (where I never read) and/or at linux-media ML. The last ones I get from patchwork. Sometimes, even before picking the patches, I tag everything with RFC or REVIEW on it as RFC. Then I handle the remaining ones. This is to reduce the load to an acceptable work queue. So, if you think that the USB patches are ok, just send it to the ML without tagging it, and I'll analyze and apply if I believe that they're ok. I'll eventually test the em28xx driver later, when I found some time. If otherwise you think they may not be ready yet, the better to wait for Devin to test, if it has some time, or send me a separate email asking for me to test the patches. 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] em28xx: fix usb alternate setting for analog and digital video endpoints 0
Em Wed, 06 Feb 2013 16:31:41 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 05.02.2013 23:06, schrieb Mauro Carvalho Chehab:
Em Tue, 05 Feb 2013 22:37:50 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 05.02.2013 21:57, schrieb Mauro Carvalho Chehab:
Em Fri, 18 Jan 2013 18:25:48 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
While the current code handles sound interfaces with a number 0
correctly, it
assumes that the interface number for analog + digital video is always 0
when
changing the alternate setting.
(NOTE: the SpeedLink VAD Laplace webcam (EM2765) uses interface number
3 for video)
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-audio.c | 10 +-
drivers/media/usb/em28xx/em28xx-cards.c |2 +-
drivers/media/usb/em28xx/em28xx-core.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx.h |3 +--
5 Dateien geändert, 9 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 2fdb66e..cdbfe0a 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -283,15 +283,15 @@ static int snd_em28xx_capture_open(struct
snd_pcm_substream *substream)
}
runtime-hw = snd_em28xx_hw_capture;
-if ((dev-alt == 0 || dev-audio_ifnum) dev-adev.users ==
0) {
-if (dev-audio_ifnum)
+if ((dev-alt == 0 || dev-ifnum) dev-adev.users == 0) {
+if (dev-ifnum)
Please don't merge a non-fix change (variable rename) with a fix.
Ok, sorry, it seems to be trivial...
Btw, audio_ifnum is a better name, as it avoids it to be miss-interpreted.
Did you read the complete patch ? ;)
Or do you really want the video interface number to be called audio_ifnum ?
There are two types of em28xx audio vendor class. In one type, the audio IF
is the same as the video one, but on the other one, it is different.
Sure, but if I'm not misunderstanding the code, we have two device
instances with separate device structs when audio is on a separate
interface.
Hence we don't need two fields for the interface number in the struct
and that's why renamed it.
No. The way the extension mechanism was written, the same data instance
is used by all modules. This is what is there at em28xx core:
void em28xx_init_extension(struct em28xx *dev)
{
const struct em28xx_ops *ops = NULL;
mutex_lock(em28xx_devlist_mutex);
list_add_tail(dev-devlist, em28xx_devlist);
list_for_each_entry(ops, em28xx_extension_devlist, next) {
if (ops-init)
ops-init(dev);
}
mutex_unlock(em28xx_devlist_mutex);
}
The ops-init() receives the data from the main driver. It doesn't matter
if the USB interface is the same or not.
If the changes at the probing code changed that, then it broke audio
support for several devices.
Regards,
Frank
That's why audio_ifnum were added in the first place.
See this commit:
commit 4f83e7b3ef938eb9a01eadf81a0f3b2c67d3afb6
Author: Mauro Carvalho Chehab mche...@redhat.com
Date: Fri Jun 17 15:15:12 2011 -0300
[media] em28xx: Add support for devices with a separate audio interface
Some devices use a separate interface for the vendor audio class.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
dev-alt = 1;
else
dev-alt = 7;
dprintk(changing alternate number on interface %d to
%d\n,
-dev-audio_ifnum, dev-alt);
-usb_set_interface(dev-udev, dev-audio_ifnum,
dev-alt);
+dev-ifnum, dev-alt);
+usb_set_interface(dev-udev, dev-ifnum, dev-alt);
/* Sets volume, mute, etc */
dev-mute = 0;
@@ -642,7 +642,7 @@ static int em28xx_audio_init(struct em28xx *dev)
static int devnr;
int err;
-if (!dev-has_alsa_audio || dev-audio_ifnum 0) {
+if (!dev-has_alsa_audio) {
/* This device does not support the extension (in this
case
the device is expecting the snd-usb-audio module or
doesn't have analog audio support at all) */
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 0a5aa62..553db17 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3376,7 +3376,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
dev-alt = -1;
dev-is_audio_only = has_audio !(has_video ||
Re: [Linaro-mm-sig] CDF meeting @FOSDEM report
On Wed, Feb 6, 2013 at 4:00 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: not always a perfect match to the hardware. For example a lot of GPUs have a DVO encoder which feeds a secondary encoder like an sil164 DVO to TMDS encoder. Right. I think mapping the DRM entities to CDF ones is one of the bigger question marks we have with CDF. While I'm no expert on DRM, I think we have the following options: 1. Force DRM's model to CDF, meaning one encoder. 2. Extend DRM to support multiple encoders in a chain. 3. Support multiple encoders in a chain in CDF, but somehow map them to a single encoder in DRM side. 4. Ignore drm kms encoders. They are only exposed to userspace as a means for userspace to discover very simple constraints, e.g. 1 encoder connected to 2 outputs means you can only use one of the outputs at the same time. They are completely irrelevant for the actual modeset interface exposed to drivers, so you could create a fake kms encoder for each connector you expose through kms. The crtc helpers use the encoders as a real entity, and if you opt to use the crtc helpers to implement the modeset sequence in your driver it makes sense to map them to some real piece of hw. But you can essentially pick any transcoder in your crtc - final output chain for this. Generic userspace needs to be able to cope with a failed modeset due to arbitrary reasons anyway, so can't presume that simply because the currently exposed constraints are fulfilled it'll work. I really dislike the first option, as it would severely limit where CDF can be used, or would force you to write some kind of combined drivers, so that you can have one encoder driver running multiple encoder devices. Imo CDF and drm encoders don't really have that much to do with each another, it should just be a driver implementation detail. Of course, if common patterns emerge we could extract them somehow. E.g. if many drivers end up exposing the CDF transcoder chain as a drm encoder using the crtc helpers, we could add some library functions to make that simpler. Another conclusion (at least from my pov) from the fosdem discussion is that we should separate the panel interface from the actual control/pixel data buses. That should give us more flexibility for insane hw and also directly exposing properties and knobs to the userspace interface from e.g. dsi transcoders. So I don't think we'll end up with _the_ canonical CDF sink interface anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 RESEND] media: rc: gpio-ir-recv: add support for device tree parsing
On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
This patch adds device tree parsing for gpio_ir_recv platform_data and
the mandatory binding documentation. It basically follows what we already
have for e.g. gpio_keys. All required device tree properties are OS
independent but optional properties allow linux specific support for rc
protocols and maps.
There was a similar patch sent by Matus Ujhelyi but that discussion
died after the first reviews.
Signed-off-by: Sebastian Hesselbarthsebastian.hesselba...@gmail.com
---
...
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
new file mode 100644
index 000..937760c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for GPIO IR receiver
+
+Required properties:
+ - compatible = gpio-ir-receiver;
+ - gpios: OF device-tree gpio specification.
+
+Optional properties:
+ - linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
+ rc protocols.
You likely need to specify in these bindings documentation which bit
corresponds to which RC protocol.
I'm not very familiar with the RC internals, but why it has to be
specified statically in the device tree, when decoding seems to be
mostly software defined ? I might be missing something though..
Sylwester,
I am not familiar with RC internals either. Maybe somebody with more
insight in media/rc can clarify the specific needs for the rc subsystem.
I was just transferring the DT support approach taken by gpio_keys to
gpio_ir_recv as I will be using it on mach-dove/cubox soon.
Couldn't this be configured at run time, with all protocols allowed
as the default ?
Actually, this is how the internal rc code works. If there is nothing
defined for allowed_protocols it assumes that all protocols are supported.
That is why above node properties are optional.
About the binding documentation of allowed_protocols, rc_map, or the
default behavior of current linux code, I don't think they will stay
in-sync for long. I'd rather completely remove those os-specific properties
from DT, but that hits the above statement about the needs of media/rc
subsystem.
+ - linux,rc-map-name: Linux specific remote control map name.
+
+Example node:
+
+ ir: ir-receiver {
+ compatible = gpio-ir-receiver;
+ gpios =gpio0 19 1;
+ /* allow rc protocols 1-4 */
+ linux,allowed-rc-protocols =0x 0x001e;
+ linux,rc-map-name = rc-rc6-mce;
+ };
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 4f71a7d..25e09fa 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -16,6 +16,7 @@
#includelinux/interrupt.h
#includelinux/gpio.h
#includelinux/slab.h
+#includelinux/of_gpio.h
#includelinux/platform_device.h
#includelinux/irq.h
#includemedia/rc-core.h
@@ -30,6 +31,63 @@ struct gpio_rc_dev {
bool active_low;
};
+#ifdef CONFIG_OF
+/*
+ * Translate OpenFirmware node properties into platform_data
+ */
+static struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct gpio_ir_recv_platform_data *pdata;
+ enum of_gpio_flags flags;
+ int gpio;
+
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ if (!of_find_property(np, gpios, NULL)) {
Why do you need this ? Isn't of_get_gpio_flags() sufficient ?
Ok. Now that you point at it, I agree that this check and the error
below is not needed. It is in gpio_keys, so that explains why it also
moved in here.
+ dev_err(dev, Found gpio-ir-receiver without gpios\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ gpio = of_get_gpio_flags(np, 0,flags);
+ if (gpio 0) {
+ if (gpio != -EPROBE_DEFER)
+ dev_err(dev, Failed to get gpio flags, error: %d\n,
+ gpio);
+ return ERR_PTR(gpio);
+ }
+
+ pdata-gpio_nr = gpio;
+ pdata-active_low = (flags OF_GPIO_ACTIVE_LOW) ? true : false;
+ pdata-map_name = of_get_property(np, linux,rc-map-name, NULL);
+ of_property_read_u64(np, linux,allowed-rc-protocols,
+ pdata-allowed_protos);
+
+ return pdata;
+}
+
+static struct of_device_id gpio_ir_recv_of_match[] = {
+ { .compatible = gpio-ir-receiver, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_recv_of_match);
+
+#else /* !CONFIG_OF */
+
+static inline struct gpio_ir_recv_platform_data *
+gpio_ir_recv_get_devtree_pdata(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+#endif
Re: Patch update notification: 2 patches updated
Am 06.02.2013 16:58, schrieb Mauro Carvalho Chehab: Em Wed, 06 Feb 2013 16:35:06 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 05.02.2013 23:08, schrieb Mauro Carvalho Chehab: Em Tue, 05 Feb 2013 22:46:10 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 05.02.2013 22:33, schrieb Patchwork: Hello, The following patches (submitted by you) have been updated in patchwork: ... * [RFC] em28xx: fix analog streaming with USB bulk transfers - http://patchwork.linuxtv.org/patch/16197/ was: New now: RFC What's your plan with this patch ? We have this regression in the media-tree since a few weeks now. Nobody replied to it or came up with a better solution... Well, you tagged it as RFC. I just marked as such at patchwork. I don't even read patches tagged as [RFC] or [REVIEW], Uhm... even patches which are sent to you as the maintainer of the _driver_ ? Isn't commenting / reviewing patches the maintainers job ? as those patches will be resubmitted later by the patch author, if they're ok, or a new version will be sent instead. That's what I'm asking you. Is this patch ok / ready ? Or can I generally conclude that patches are fine when there is no reaction on them ? Frank, As you may notice, my main job with regards to media stuff is to be the media core maintainer. My work as a driver maintainer or as a developer is forced to go to a second plane, as my time is limited. So, I generally trust that driver developers are doing the right thing. ATM, I won't have anytime soon to test patches. So, if those patches require any test from me, they'll need to be postponed to 3.10, as I'm finishing the handling of the patches for 3.9 today. Also, from my side, there are simply too much patches sent to me, either on my inbox (where I never read) and/or at linux-media ML. The last ones I get from patchwork. Sometimes, even before picking the patches, I tag everything with RFC or REVIEW on it as RFC. Then I handle the remaining ones. This is to reduce the load to an acceptable work queue. So, if you think that the USB patches are ok, just send it to the ML without tagging it, and I'll analyze and apply if I believe that they're ok. I'll eventually test the em28xx driver later, when I found some time. If otherwise you think they may not be ready yet, the better to wait for Devin to test, if it has some time, or send me a separate email asking for me to test the patches. Regards, Mauro Mauro, I know you are very busy and I agree that maintaining the media-tree has a higher priority than maintaining a driver. You are doing a good job and if there's anything I can do to make your life easier, please tell me ! But this is about regression which exists now for several weeks in the media-tree and we are getting close to the next merge window. As you have said yourself before, if you have set a patch to RFC, you usually never look at it again. Which means that this regression very likely makes it into mainline in a few days. Don't you think this is a valid case for people to bother you ? ;) Everthing you need to know to decide about this patch is written in the patch description and the reply I've sent. Anyway, I will resend the patch without RFC and I will also resend the ioctl-fixes series marked with REVIEW. For me, it seems to be unnecessary extra work for you, but if you prefer it that way - no problem for me. 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: [PATCH] em28xx: fix usb alternate setting for analog and digital video endpoints 0
Am 06.02.2013 17:03, schrieb Mauro Carvalho Chehab:
Em Wed, 06 Feb 2013 16:31:41 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 05.02.2013 23:06, schrieb Mauro Carvalho Chehab:
Em Tue, 05 Feb 2013 22:37:50 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 05.02.2013 21:57, schrieb Mauro Carvalho Chehab:
Em Fri, 18 Jan 2013 18:25:48 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
While the current code handles sound interfaces with a number 0
correctly, it
assumes that the interface number for analog + digital video is always 0
when
changing the alternate setting.
(NOTE: the SpeedLink VAD Laplace webcam (EM2765) uses interface number
3 for video)
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/em28xx/em28xx-audio.c | 10 +-
drivers/media/usb/em28xx/em28xx-cards.c |2 +-
drivers/media/usb/em28xx/em28xx-core.c |2 +-
drivers/media/usb/em28xx/em28xx-dvb.c |2 +-
drivers/media/usb/em28xx/em28xx.h |3 +--
5 Dateien geändert, 9 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 2fdb66e..cdbfe0a 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -283,15 +283,15 @@ static int snd_em28xx_capture_open(struct
snd_pcm_substream *substream)
}
runtime-hw = snd_em28xx_hw_capture;
-if ((dev-alt == 0 || dev-audio_ifnum) dev-adev.users ==
0) {
-if (dev-audio_ifnum)
+if ((dev-alt == 0 || dev-ifnum) dev-adev.users == 0) {
+if (dev-ifnum)
Please don't merge a non-fix change (variable rename) with a fix.
Ok, sorry, it seems to be trivial...
Btw, audio_ifnum is a better name, as it avoids it to be miss-interpreted.
Did you read the complete patch ? ;)
Or do you really want the video interface number to be called audio_ifnum ?
There are two types of em28xx audio vendor class. In one type, the audio IF
is the same as the video one, but on the other one, it is different.
Sure, but if I'm not misunderstanding the code, we have two device
instances with separate device structs when audio is on a separate
interface.
Hence we don't need two fields for the interface number in the struct
and that's why renamed it.
No. The way the extension mechanism was written, the same data instance
is used by all modules. This is what is there at em28xx core:
void em28xx_init_extension(struct em28xx *dev)
{
const struct em28xx_ops *ops = NULL;
mutex_lock(em28xx_devlist_mutex);
list_add_tail(dev-devlist, em28xx_devlist);
list_for_each_entry(ops, em28xx_extension_devlist, next) {
if (ops-init)
ops-init(dev);
}
mutex_unlock(em28xx_devlist_mutex);
}
The ops-init() receives the data from the main driver. It doesn't matter
if the USB interface is the same or not.
Sure, but the device struct pointer dev passed to the module is different.
If the changes at the probing code changed that, then it broke audio
support for several devices.
If I'm not misunderstanding the code completely, em28xx_usb_probe() is
called for each USB interface.
If an analog video, audio or DVB endpoint ist detected, it creates a new
device instance (which has it's own device struct).
I don't know if this has ever been working differently, but at least it
didn't change recently. I also think this is how it should be.
Unfortunately I don't have one of these device for testing, so I don't
know if audio is currently broken for them.
What I can say for sure is, that devices with the isoc video/DVB
endpoints at an interface 0 are currently broken, which is what I'm
trying to fix with this patch.
Regards,
Frank
Regards,
Frank
That's why audio_ifnum were added in the first place.
See this commit:
commit 4f83e7b3ef938eb9a01eadf81a0f3b2c67d3afb6
Author: Mauro Carvalho Chehab mche...@redhat.com
Date: Fri Jun 17 15:15:12 2011 -0300
[media] em28xx: Add support for devices with a separate audio interface
Some devices use a separate interface for the vendor audio class.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
dev-alt = 1;
else
dev-alt = 7;
dprintk(changing alternate number on interface %d to
%d\n,
-dev-audio_ifnum, dev-alt);
-usb_set_interface(dev-udev, dev-audio_ifnum,
dev-alt);
+dev-ifnum, dev-alt);
+usb_set_interface(dev-udev, dev-ifnum, dev-alt);
/* Sets volume, mute, etc */
dev-mute = 0;
@@ -642,7 +642,7 @@ static int em28xx_audio_init(struct em28xx *dev)
static int devnr;
int err;
-if
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: Wed Feb 6 19:00:29 CET 2013 git branch: for_v3.9 git hash: 248ac368ce4b3cd36515122d888403909d7a2500 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-rc4-i686: ERRORS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-rc4-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
media controller interface
Any idea why /dev/media0 is not available to media users, in particular those in group 'video'? On my system I see: $ ls -l /dev/vid* crw-rw 1 root video 81, 0 Feb 6 18:45 /dev/video0 crw-rw 1 root video 81, 1 Feb 6 18:45 /dev/video1 crw-rw 1 root video 81, 2 Feb 6 18:45 /dev/video2 crw-rw 1 root video 81, 3 Feb 6 18:45 /dev/video3 $ ls -l /dev/media0 crw--- 1 root root 253, 0 Feb 6 18:45 /dev/media0 So my actual media files are usable by my 'video' user, but not the media controller interface. Also, where are these devices created? I'm running udev 182 Thanks for any pointers -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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 Sylwester, On Sun, Feb 03, 2013 at 07:53:50PM +0100, Sylwester Nawrocki wrote: Hi Laurent, On 02/01/2013 11:17 PM, Laurent Pinchart wrote: [...] 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 If you want to do this, then you have to make LEFT/TOP/WIDTH/HEIGHT real controls. There is no such thing as a pseudo control. So you need five new controls in total: V4L2_CID_AUTO_FOCUS_AREA V4L2_CID_AUTO_FOCUS_LEFT V4L2_CID_AUTO_FOCUS_RIGHT V4L2_CID_AUTO_FOCUS_WIDTH V4L2_CID_AUTO_FOCUS_HEIGHT I have no problem with this from the point of view of the control API, but whether this is the best solution for implementing auto-focus is a different issue and input from sensor specialists is needed as well (added Laurent and Sakari to the CC list). The primary concern I have is that this does not scale to multiple focus rectangles. This might not be relevant to auto focus, though. I think for more advanced hardware/configurations there is a need to associate more information with the rectangles anyway. So the selections API seems too limited. Probably a new IOCTL would be needed for that, either standard or private. We've discussed it here with Andrzej and using such 4 controls to specify the AF rectangle looks sufficient from our POV. I would just probably rename LEFT/RIGHT to POS_X/POS_Y or something, as these 2 controls could be used in a focus mode where only spot position needs to be specified. If position and size are sufficient, could we use the selection API instead ? An alternative would be to introduce rectangle controls. I'm a bit uncomfortable with using 4 controls here, as this could quickly grow out of control. Yes, the selection API could be used as well. I actually have tested this in the past with the s5c73m3 camera and its spot auto focus mode. I just wanted to be sure there is no better alternatives, as it looked a bit unusual to handle single feature with a mix of the controls and the selection API calls. Although it works, such an interface looks a bit clumsy to me, especially in cases where all we need is to pass just (x,y) coordinates. Selections are essentially controls but for rectangles. The original use case was to support configuring scaling, cropping etc. on subdevs but they're not really bound to image processing configuration. Controls have been more generic to begin with. I have quickly added support for rectangle controls type [1] to see how big changes it would require and what would be missing without significant changes in the controls API. So the main issues there are: the min/max/step/default value cannot be queried (VIDIOC_QUERYCTRL) and it is troublesome to handle them in the kernel, the control value change events wouldn't really work. I learnt VIDIOC_QUERYCTRL is not supported for V4L2_CTRL_TYPE_INTEGER64 control type, then maybe we could have similarly some features not available for V4L2_CTRL_TYPE_RECTANGLE ? Until there are further extensions that address this;) [1] http://git.linuxtv.org/snawrocki/media.git/ov965x-2-rect-type-ctrl Hmm. Had you proposed this two years ago, selections could well look entirely different. We still have them now. There would be use cases for pad specific controls, too; pixel rate for instance should be one. For this reason I don't see selections really much different from controls. The selections are the same on subdevs and video nodes. Unifying them (with some compat code for either of the current interfaces) and providing a new IOCTL to access both was what I thought could be one solution to the problem. Or --- we could add selection controls which would be just like selections but with the control interface. What's relevant in struct v4l2_ext_control would be the ID field, while the value field in struct v4l2_ext_control would be a pointer to a struct describing the selection control. Half of the reserved field could be used for the pad (they're 16-bit ints). No control ID clashes with the selection IDs, so this could even work with the existing selection targets. Either solution would avoid creating another rectangle type with an ID that would be separate from selections. Thoughts, comments? -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the
[PATCH FOR V3.9] Remove __devinit/exit annotations: these are no longer supported
Hi all,
The daily build broke on this.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index c143c9e..9b351d6 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -1561,7 +1561,7 @@ static int s5c73m3_configure_gpios(struct s5c73m3 *state,
return 0;
}
-static int __devinit s5c73m3_probe(struct i2c_client *client,
+static int s5c73m3_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct device *dev = client-dev;
@@ -1666,7 +1666,7 @@ out_err1:
return ret;
}
-static int __devexit s5c73m3_remove(struct i2c_client *client)
+static int s5c73m3_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct s5c73m3 *state = sensor_sd_to_s5c73m3(sd);
@@ -1693,7 +1693,7 @@ static struct i2c_driver s5c73m3_i2c_driver = {
.name = DRIVER_NAME,
},
.probe = s5c73m3_probe,
- .remove = __devexit_p(s5c73m3_remove),
+ .remove = s5c73m3_remove,
.id_table = s5c73m3_id,
};
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
index 889139c..6f3a9c0 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
@@ -111,7 +111,7 @@ int s5c73m3_spi_read(struct s5c73m3 *state, void *addr,
return 0;
}
-static int __devinit s5c73m3_spi_probe(struct spi_device *spi)
+static int s5c73m3_spi_probe(struct spi_device *spi)
{
int r;
struct s5c73m3 *state = container_of(spi-dev.driver, struct s5c73m3,
@@ -132,7 +132,7 @@ static int __devinit s5c73m3_spi_probe(struct spi_device
*spi)
return 0;
}
-static int __devexit s5c73m3_spi_remove(struct spi_device *spi)
+static int s5c73m3_spi_remove(struct spi_device *spi)
{
return 0;
}
@@ -141,7 +141,7 @@ int s5c73m3_register_spi_driver(struct s5c73m3 *state)
{
struct spi_driver *spidrv = state-spidrv;
- spidrv-remove = __devexit_p(s5c73m3_spi_remove);
+ spidrv-remove = s5c73m3_spi_remove;
spidrv-probe = s5c73m3_spi_probe;
spidrv-driver.name = S5C73M3_SPI_DRV_NAME;
spidrv-driver.bus = spi_bus_type;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media_build update IS_ENABLED macro
Fix media_build by updating IS_ENABLED macro Signed-off-by: Eddi De Pieri e...@depieri.net diff --git a/v4l/compat.h b/v4l/compat.h index 8ef90aa..fd0d139 100644 --- a/v4l/compat.h +++ b/v4l/compat.h @@ -1102,7 +1102,7 @@ static inline void i2c_unlock_adapter(struct i2c_adapter *adapter) #define __config_enabled(arg1_or_junk) ___config_enabled(arg1_or_junk 1, 0) #define ___config_enabled(__ignored, val, ...) val #define IS_ENABLED(option) \ - (config_enabled(option) || config_enabled(option##_MODULE)) + (defined(__enabled_ ## option) || defined(__enabled_ ## option ## _MODULE)) #endif #ifdef NEED_USB_TRANSLATE_ERRORS -- 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_build update IS_ENABLED macro
Sorry ignore my patch.. it's broken Regards Eddi On Wed, Feb 6, 2013 at 9:48 PM, Eddi De Pieri e...@depieri.net wrote: Fix media_build by updating IS_ENABLED macro Signed-off-by: Eddi De Pieri e...@depieri.net diff --git a/v4l/compat.h b/v4l/compat.h index 8ef90aa..fd0d139 100644 --- a/v4l/compat.h +++ b/v4l/compat.h @@ -1102,7 +1102,7 @@ static inline void i2c_unlock_adapter(struct i2c_adapter *adapter) #define __config_enabled(arg1_or_junk) ___config_enabled(arg1_or_junk 1, 0) #define ___config_enabled(__ignored, val, ...) val #define IS_ENABLED(option) \ - (config_enabled(option) || config_enabled(option##_MODULE)) + (defined(__enabled_ ## option) || defined(__enabled_ ## option ## _MODULE)) #endif #ifdef NEED_USB_TRANSLATE_ERRORS -- 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
IS_ENABLED media_build issue
Hi, I'm backporting media_tree drivers to linux 3.3.6. For a strange reason, IS_ENABLED macro fails. I had to force definition of NEED_IS_ENABLED to make drivers to build. Any idea? Regards, Eddi -- 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] s5c73m3: Remove __dev* attributes
Remove no longer supported __devinit, __devexit attributes.
Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com
---
Hi Hans,
I've noticed this last night, prepared a patch but forgot
to send it out today :/
Here is the one with a relevant summary line, I don't
want a patch with [,FOR,V3.9] in it applied..
Thanks,
Sylwester
drivers/media/i2c/s5c73m3/s5c73m3-core.c |8
drivers/media/i2c/s5c73m3/s5c73m3-spi.c |6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index c143c9e..5dbb65e 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -1561,8 +1561,8 @@ static int s5c73m3_configure_gpios(struct s5c73m3 *state,
return 0;
}
-static int __devinit s5c73m3_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
+static int s5c73m3_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
{
struct device *dev = client-dev;
const struct s5c73m3_platform_data *pdata = client-dev.platform_data;
@@ -1666,7 +1666,7 @@ out_err1:
return ret;
}
-static int __devexit s5c73m3_remove(struct i2c_client *client)
+static int s5c73m3_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct s5c73m3 *state = sensor_sd_to_s5c73m3(sd);
@@ -1693,7 +1693,7 @@ static struct i2c_driver s5c73m3_i2c_driver = {
.name = DRIVER_NAME,
},
.probe = s5c73m3_probe,
- .remove = __devexit_p(s5c73m3_remove),
+ .remove = s5c73m3_remove,
.id_table = s5c73m3_id,
};
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
index 889139c..6f3a9c0 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-spi.c
@@ -111,7 +111,7 @@ int s5c73m3_spi_read(struct s5c73m3 *state, void *addr,
return 0;
}
-static int __devinit s5c73m3_spi_probe(struct spi_device *spi)
+static int s5c73m3_spi_probe(struct spi_device *spi)
{
int r;
struct s5c73m3 *state = container_of(spi-dev.driver, struct s5c73m3,
@@ -132,7 +132,7 @@ static int __devinit s5c73m3_spi_probe(struct spi_device
*spi)
return 0;
}
-static int __devexit s5c73m3_spi_remove(struct spi_device *spi)
+static int s5c73m3_spi_remove(struct spi_device *spi)
{
return 0;
}
@@ -141,7 +141,7 @@ int s5c73m3_register_spi_driver(struct s5c73m3 *state)
{
struct spi_driver *spidrv = state-spidrv;
- spidrv-remove = __devexit_p(s5c73m3_spi_remove);
+ spidrv-remove = s5c73m3_spi_remove;
spidrv-probe = s5c73m3_spi_probe;
spidrv-driver.name = S5C73M3_SPI_DRV_NAME;
spidrv-driver.bus = spi_bus_type;
--
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: On MIPI-CSI2 YUV420 formats and V4L2 Media Bus formats
On Wed, 30 Jan 2013 01:23:48 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Antonio, Sorry for the delay Laurent and thanks for your reply, some more questions below. On Monday 28 January 2013 13:22:10 Antonio Ospite wrote: Hi, looking at the MIPI Alliance Specification for Camera Serial Interface 2 (I'll call it MIPI-CSI2 from now on, the document I am referring to is mentioned at [1] and available at [2]), I see there is an YUV420 8 bit format (MIPI Data Type 0x18) specified with interleaved components in the form of: ... (odd lines) UYVYUYVY... (even lines) With even lines twice the size of odd lines. Such format is also supported by some sensors, for instance ov5640, and by MIPI-CSI2 receivers like OMAP4 ISS. The doubt I have is: how should I represent those formats as media bus formats? We likely need new media bus formats to describe those. OK, I'll think to some names if I am going to actually use them. I've seen that some drivers (sensors and SoC, for instance[3]) tend to identify the MIPI-CSI2 format above (0x18) with media bus formats like V4L2_MBUS_FMT_UYVY8_1_5X8 (actually the code above uses V4L2_MBUS_FMT_YUYV8_1_5X8 is this OK?), but from the v4l2 documentation [4] I understand that this format is supposed to have data in this configuration: ... ... ... ... ... ... Not exactly, the UYVY8_1_5X8 is transmits Y, U and V samples as UYYVYY... Wait, am I misunderstanding the documentation at http://kernel.org/doc/htmldocs/media/subdev.html#v4l2-mbus-pixelcode-yuv8 ? From the tables there it looks like that in UYVY8_1_5X8 the components are not interleaved on the same line, only the lines are. And that's why I was believing the code in [3] which maps YUYV8_1_5X8 (line interleaved, according to my interpretation of the v4l doc) to the MIPI-CSI2 0x18 format (components interleaved), was inaccurate (in the sense that I would have expected another [new] media bus format). That is with interleaved lines, but NOT interleaved components. Should new media bus formats be added for .../UYVYUYVY...? Yes, I think so. Another doubt I have is: how is the .../UYVYUYVY... data supposed to be processed in userspace? Is the MIPI Receiver (i.e, the SoC) expected to be able to convert it to a more usable format like YUV420P or NV12/NV21? Or are there applications capable of handling this data directly, or efficiently convert them to planar or semi-planar YUV420 formats? The bridge (receiver and DMA engine) driver will expose V4L2 pixel formats corresponding to the bridge capabilities. If the bridge can store the above stream in memory in NV12 it will expose that to applications. If the bridge stores data in memory as described above, it will just expose that format (it seems to correspond to the V4L2 M420 pixel format), and applications will need to handle that explicitly. I see, so what I can get in userspace obviously depends on the hardware _and_ the driver (i.e. how complete it is in exposing the hardware capabilities), but that means that if a bridge can transparently pass the data it gets from the sensor (in a given mediabus format) we could have as many pixelformats as we have media bus formats, I know these latter won't be added in practice, but is my reasoning right in principle? Each mediabus format is a possible candidate for a new pixelformat. Maybe I am asking the obvious but I am trying to complete my understanding about the relationship between media bus formats and pixelformats. BTW that M420 format you mention is a bit different, from what I can see[6] it is something like a line interleaved NV12: ... ... UVUV... ... ... UVUV... [6] http://www.linuxtv.org/downloads/v4l-dvb-apis/V4L2-PIX-FMT-M420.html So still another variation on the theme :) Or am I still reading the documentation the wrong way? In particular I am curios if the OMAP4 ISS can do the conversion to NV12, I understand that the formats with interleaved _lines_ can be produced by the resizer and handled by the OMAP ISP DMA-Engine by setting buffers offsets to Y and UV in order to send NV12 data to userspace, but I couldn't find info about how to handle the YUV420 MIPI-CSI2 formats (interleaved components) without the resizer in the Developer Manual [5]; having NV12 data directly from the hardware without using the OMAP4 ISS/ISP Resizer can be valuable in some use cases (e.g. dual camera setups). No idea about that, sorry. Not at all. I was hoping Sergio would step up here. Thanks again, Antonio [1] http://www.mipi.org/specifications/camera-interface#CSI2 [2] http://ishare.sina.cn/dintro.php?id=20498632 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=driver s/media/platform/soc_camera/sh_mobile_csi2.c;h=a17aba9a0104c41cbc4e5e5d27701
Re: [PATCH 0/2] A couple documentation fixes for media stuff
On Mon, 28 Jan 2013 22:45:30 +0100 Antonio Ospite osp...@studenti.unina.it wrote: From: Antonio Ospite a...@amarulasolutions.com Take a look at the per-patch annotations too, please. Ping on this series. Thanks, Antonio Antonio Ospite (2): [media] Documentation/media-framework.txt: fix a sentence [media] Documentation/DocBook/media/v4l/subdev-formats.xml: fix a typo Documentation/DocBook/media/v4l/subdev-formats.xml |2 +- Documentation/media-framework.txt |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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 v4 01/10] s5p-csis: Add device tree support
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC device. This patch support for binding the driver to the MIPI-CSIS devices instantiated from device tree and for parsing all SoC and board specific properties. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt +Optional properties: + +- clock-frequency : The IP's main (system bus) clock frequency in Hz, default + value when this property is not specified is 166 MHz; Shouldn't this be a clocks property, so that the driver can call clk_get(), clk_prepare_enable(), clk_get_rate(), etc. on it? Other than that this binding seems fine to me at a quick glance. -- 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 v4 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: This patch adds support for FIMC devices instantiated from devicetree for S5PV210 and Exynos4 SoCs. The FIMC IP features include colorspace conversion and scaling (mem-to-mem) and parallel/MIPI CSI2 bus video capture interface. Multiple SoC revisions specific parameters are defined statically in the driver and are used for both dt and non-dt. The driver's static data is selected based on the compatible property. Previously the platform device name was used to match driver data and a specific SoC/IP version. Aliases are used to determine an index of the IP which is essential for linking FIMC IP with other entities, like MIPI-CSIS (the MIPI CSI-2 bus frontend) or FIMC-LITE and FIMC-IS ISP. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) +-- + +The Exynos Camera subsystem comprises of multiple sub-devices that are +represented by separate platform devices. Some of the IPs come in different platform devices is a rather Linux-centric term, and DT bindings should be OS-agnostic. Perhaps use device tree nodes here? +variants across the SoC revisions (FIMC) and some remain mostly unchanged +(MIPI CSIS, FIMC-LITE). + +All those sub-subdevices are defined as parent nodes of the common device s/parent nodes/child node/ I think? +For every fimc node a numbered alias should be present in the aliases node. +Aliases are of the form fimcn, where n is an integer (0...N) specifying +the IP's instance index. Why? Isn't it up to the DT author whether they care if each fimc node is assigned a specific identification v.s. whether identification is assigned automatically? +Optional properties + + - clock-frequency - maximum FIMC local clock (LCLK) frequency Again, I'd expect a clocks property here instead. -- 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 v4 05/10] s5p-fimc: Add device tree based sensors registration
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: The sensor (I2C and/or SPI client) devices are instantiated by their corresponding control bus drivers. Since the I2C client's master clock is often provided by a video bus receiver (host interface) or other than I2C/SPI controller device, the drivers of those client devices are not accessing hardware in their driver's probe() callback. Instead, after enabling clock, the host driver calls back into a sub-device when it wants to activate them. This pattern is used by some in-tree drivers and this patch also uses it for DT case. This patch is intended as a first step for adding device tree support to the S5P/Exynos SoC camera drivers. The second one is adding support for asynchronous sub-devices registration and clock control from sub-device driver level. The bindings shall not change when asynchronous probing support is added. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +The sensor device nodes should be added as their control bus controller I think as should be to? +(e.g. I2C0) child nodes and linked to a port node in the csis or parallel-ports +node, using common the common video interfaces bindings, i.e. port/endpoint +node pairs. The implementation of this binding requires clock-frequency +property to be present in the sensor device nodes. -- 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 v4 06/10] s5p-fimc: Use pinctrl API for camera ports configuration
On 02/01/2013 12:09 PM, Sylwester Nawrocki wrote: Before the camera ports can be used the pinmux needs to be configured properly. This patch adds a function to set the camera ports pinctrl to a default state within the media driver's probe(). The camera port(s) are then configured for the video bus operation. diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt +- pinctrl-names: pinctrl names for camera port pinmux control, at least + default needs to be specified. +- pinctrl-0...N : pinctrl properties corresponding to pinctrl-names + A reference to the binding document describing the pin control bindings would be appropriate here. Given that reference, I'm not sure if spelling out the property names makes sense since it feels a little like duplication; an alternative might be simply: The pinctrl bindings defined in ../../../pinctrl/pinctrl-bindings.txt must be used to define a pinctrl state named default. However, this isn't a big deal; it's fine either way. -- 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: Hi again
Hi Alexander, Thanks for the update ;) On 02/05/2013 11:50 PM, Alexander Nestorov wrote: Hi Sylwester :) I have been working wth 2 guys from Collabora (company behind GStreamer/Farstream) and there has been some progress. We saw that if I run gst-launch v4l2src ! dfbvideosink (without any caps) then gstreamer won't show anything at all. But as soon as I force caps, like v4l2src ! video/x-raw-rgb,width=XXX,height=YYY,bpp=16 ! dfbvideosink everything starts working. Same way, if I launch my Farstream app without any parameters, it crashes. But if I specify bpp and depth then it starts working. I don't want to confuse you so I'll copy exactly what one of the guys said: [23:02]alexandernst_ KaKaRoTo: I have another question regarding the CMOS and the caps hack [23:03]alexandernst_ we're setting bpp and depth because the driver isn't returning: a) anything at all b) invalid values c) ??? [23:06]KaKaRoTo alexandernst_, because the driver is reporting big endian for 16 bits, and it could easily be a gstreamer issue not supporting big endian 16bits rgb.. or the driver is reporting the endianness wrong... [23:06]KaKaRoTo alexandernst_, the other reason is because the driver isn't giving us the capabilities of the CMOS, so we don't knowh Yes, the driver doesn't implement VIDIOC_ENUM_FRAMESIZES ioctl at /dev/video? device node. These parameters are supposed to be retrieved by a driver-specific plugin at the libv4l [1] (it still don't exists yet..) library. And applications (e.g. v4l2src) should use v4l2_* calls from this library, rather than plain ioctl(). Until the plugin for the s3c-camif driver (or a generic Media Controller plugin) is added to libv4l there is no way v4l2src can query the list of supported resolutions by the CMOS sensor. Well, it could be hacked in the driver, but I don't want to do that. I could send you a patch for your own use if you wish, and if I find some time to write it. ;) which resolutions it supports, so we're forced to manually setting it, otherwise it tries to do 2048x4096 and it doesn't work.. This looks suspicious, let me check it... Hmm, no, its GStreamer that forces the s3c-camif driver to use its maximum supported resolution at /dev/video?. root@mini2440:~ v4l2-ctl -d /dev/video0 --all Driver Info (not using libv4l2): Driver name : s3c-camif Card type : s3c-camif Bus info : platform:s3c2440-camif.0 Driver version: 3.8.0 Capabilities : 0x8401 Video Capture Streaming Device Capabilities Device Caps : 0x0401 Video Capture Streaming Format Video Capture: Width/Height : 1280/1024 Pixel Format : '422P' Field : None Bytes per Line: 1280 Size Image: 614400 Colorspace: JPEG (JFIF/ITU601) Selection: compose, Left 0, Top 0, Width 1280, Height 1024 Selection: compose_default, Left 0, Top 0, Width 1280, Height 1024 Selection: compose_bounds, Left 0, Top 0, Width 1280, Height 1024 Video input : 0 (OV9650: ok) Priority: 2 The default resolution is 1280/1024. The problem is that there is not enough memory in your system to allocate all 2048x4096 buffers (it's 16 MB each, 2 bytes per pixel for 422P format). The driver doesn't enforce any policy on memory allocation, i.e. there is no limit in the driver. I could add some module parameter for that if required. But in general it's the v4l2 memory allocator that should return an allocation error and it should be propagated up to v4l2 videobuf2 layer and to GStreamer (e.g. through VIDIOC_REQBUFS ioctl). IIRC there were some issues in the videobuf2 about reporting memory allocation errors back to user space. Not sure if this is already fixed. I'll investigate it and will let you know. I have enabled debug in videobuf2 and got something like below, which looks like something unexpected: root@mini2440:~ echo 100 /sys/module/videobuf2_core/parameters/debug root@mini2440:~ gst-launch -v v4l2src device=/dev/video0 queue-size=2 ! video/x-raw-yuv,format='(fourcc)'YV12 ! ffmpegcolorspace ! fbdevsink root@mini2440:~ dmesg -c [ 1907.11] s3c-camif s3c2440-camif: dma_alloc_coherent of size 12582912 failed [ 1907.115000] vb2: Failed allocating memory for buffer 1 The error is ignored here, it should all fail at this point. [ 1907.12] vb2: Buffer 0, plane 0 offset 0x [ 1907.125000] vb2: Allocated 1 buffers, 1 plane(s) each [ 1907.22] vb2: Buffer 0, plane 0 successfully mapped [ 1907.225000] vb2: qbuf of buffer 0 succeeded [ 1907.23] vb2: Streamon successful [23:07]KaKaRoTo which is also why it freezes (doesn't output buffers) instead of giving an error when you try to set that resolution I made a bug report here, and there are 2 REs which might be really helpful: https://bugzilla.gnome.org/show_bug.cgi?id=693175 On the other hand, I haven't noticed till now because I compile with -j9,
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: Wed Feb 6 22:29:20 CET 2013 git branch: for_v3.9 git hash: 248ac368ce4b3cd36515122d888403909d7a2500 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS 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.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-rc4-i686: ERRORS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-rc4-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [media] v4l2-mem2mem: use CAPTURE queue lock
From: John Sheu s...@chromium.org
In v4l2_m2m_try_schedule(), use the CAPTURE queue lock when accessing
the CAPTURE queue, instead of relying on just holding the OUTPUT queue
lock.
Signed-off-by: John Sheu s...@google.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 438ea45..c52a2c5 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -230,12 +230,15 @@ static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx
*m2m_ctx)
dprintk(No input buffers available\n);
return;
}
+ spin_lock_irqsave(m2m_ctx-cap_q_ctx.rdy_spinlock, flags);
if (list_empty(m2m_ctx-cap_q_ctx.rdy_queue)) {
+ spin_unlock_irqrestore(m2m_ctx-cap_q_ctx.rdy_spinlock, flags);
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock, flags);
spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
dprintk(No output buffers available\n);
return;
}
+ spin_unlock_irqrestore(m2m_ctx-cap_q_ctx.rdy_spinlock, flags);
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock, flags);
if (m2m_dev-m2m_ops-job_ready
--
1.8.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
[PATCH 3/3] dma-buf: restore args on failure of dma_buf_mmap
From: John Sheu s...@chromium.org
Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure. Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
Signed-off-by: John Sheu s...@google.com
---
drivers/base/dma-buf.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index a3f79c4..01daf9c 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -446,6 +446,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ struct file *oldfile;
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -459,14 +462,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- if (vma-vm_file)
- fput(vma-vm_file);
-
+ oldfile = vma-vm_file;
vma-vm_file = get_file(dmabuf-file);
vma-vm_pgoff = pgoff;
- return dmabuf-ops-mmap(dmabuf, vma);
+ ret = dmabuf-ops-mmap(dmabuf, vma);
+ if (ret) {
+ /* restore old parameters on failure */
+ vma-vm_file = oldfile;
+ fput(dmabuf-file);
+ } else {
+ if (oldfile)
+ fput(oldfile);
+ }
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
1.8.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
[PATCH 2/3] [media]: v4l2-mem2mem: drop rdy_queue on STREAMOFF
From: John Sheu s...@chromium.org
When a v4l2-mem2mem context gets a STREAMOFF call on either its CAPTURE
or OUTPUT queues, we should:
* Drop the corresponding rdy_queue, since a subsequent STREAMON expects
an empty queue.
* Deschedule the context, as it now has at least one empty queue and
cannot run.
Signed-off-by: John Sheu s...@google.com
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index c52a2c5..c5c9d24 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -408,10 +408,35 @@ EXPORT_SYMBOL_GPL(v4l2_m2m_streamon);
int v4l2_m2m_streamoff(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
enum v4l2_buf_type type)
{
- struct vb2_queue *vq;
+ struct v4l2_m2m_dev *m2m_dev;
+ struct v4l2_m2m_queue_ctx *q_ctx;
+ unsigned long flags_job, flags;
+ int ret;
- vq = v4l2_m2m_get_vq(m2m_ctx, type);
- return vb2_streamoff(vq, type);
+ q_ctx = get_queue_ctx(m2m_ctx, type);
+ ret = vb2_streamoff(q_ctx-q, type);
+ if (ret)
+ return ret;
+
+ m2m_dev = m2m_ctx-m2m_dev;
+ spin_lock_irqsave(m2m_dev-job_spinlock, flags_job);
+ /* We should not be scheduled anymore, since we're dropping a queue. */
+ INIT_LIST_HEAD(m2m_ctx-queue);
+ m2m_ctx-job_flags = 0;
+
+ spin_lock_irqsave(q_ctx-rdy_spinlock, flags);
+ /* Drop queue, since streamoff returns device to the same state as after
+* calling reqbufs. */
+ INIT_LIST_HEAD(q_ctx-rdy_queue);
+ spin_unlock_irqrestore(q_ctx-rdy_spinlock, flags);
+
+ if (m2m_dev-curr_ctx == m2m_ctx) {
+ m2m_dev-curr_ctx = NULL;
+ wake_up(m2m_ctx-finished);
+ }
+ spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
+
+ return 0;
}
EXPORT_SYMBOL_GPL(v4l2_m2m_streamoff);
--
1.8.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
Invitation to use Google Talk
--- You've been invited by abhishek jain to use Google Talk. If you already have a Google account, login to Gmail and accept this chat invitation: http://mail.google.com/mail/b-e5728e2cb1-4bbffc79f0-p5osIw9xEoJ3lr95g7QxueBjNbI To sign up for a Google account and get started with Google Talk, you can visit: http://mail.google.com/mail/a-e5728e2cb1-4bbffc79f0-p5osIw9xEoJ3lr95g7QxueBjNbI?pc=en-rf---a Learn more at: http://www.google.com/intl/en/landing/accounts/ Thanks, The Google Team -- 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 v3] media: ths7353: add support for ths7353 video amplifier
From: Lad, Prabhakar prabhakar@ti.com
The patch adds support for THS7353 video amplifier.
The the THS7353 amplifier is very much similar to the
existing THS7303 video amplifier driver.
This patch appropriately makes changes to the existing
ths7303 driver and adds support for the THS7353.
This patch also adds V4L2_IDENT_THS7353 for the THS7353
chip and appropriate changes to Kconfig file for building.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
Cc: Chaithrika U S chaithr...@ti.com
---
Changes for v3:
1: Fixed review comments pointed out by Hans.
Changes for v2:
1: Merged the driver in existing ths7303 driver.
2: Merged the patch which adds the chip indent in same patch.
drivers/media/i2c/Kconfig |6 +-
drivers/media/i2c/ths7303.c | 353 ---
include/media/ths7303.h | 42 +
include/media/v4l2-chip-ident.h |3 +
4 files changed, 343 insertions(+), 61 deletions(-)
create mode 100644 include/media/ths7303.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ecdf7e3..bd08541 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -576,10 +576,10 @@ config VIDEO_UPD64083
comment Miscelaneous helper chips
config VIDEO_THS7303
- tristate THS7303 Video Amplifier
- depends on I2C
+ tristate THS7303/53 Video Amplifier
+ depends on VIDEO_V4L2 I2C
help
- Support for TI THS7303 video amplifier
+ Support for TI THS7303/53 video amplifier
To compile this driver as a module, choose M here: the
module will be called ths7303.
diff --git a/drivers/media/i2c/ths7303.c b/drivers/media/i2c/ths7303.c
index e747524..7300abc 100644
--- a/drivers/media/i2c/ths7303.c
+++ b/drivers/media/i2c/ths7303.c
@@ -1,7 +1,15 @@
/*
- * ths7303- THS7303 Video Amplifier driver
+ * ths7303/53- THS7303/53 Video Amplifier driver
*
* Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates.
+ *
+ * Author: Chaithrika U S chaithr...@ti.com
+ *
+ * Contributors:
+ * Lad, Prabhakar prabhakar@ti.com
+ * Hans Verkuil hans.verk...@cisco.com
+ * Martin Bugge marbu...@cisco.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -13,25 +21,27 @@
* GNU General Public License for more details.
*/
-#include linux/kernel.h
-#include linux/init.h
-#include linux/ctype.h
-#include linux/slab.h
#include linux/i2c.h
-#include linux/device.h
-#include linux/delay.h
#include linux/module.h
-#include linux/uaccess.h
-#include linux/videodev2.h
+#include linux/slab.h
-#include media/v4l2-device.h
-#include media/v4l2-subdev.h
+#include media/ths7303.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-device.h
#define THS7303_CHANNEL_1 1
#define THS7303_CHANNEL_2 2
#define THS7303_CHANNEL_3 3
+struct ths7303_state {
+ struct v4l2_subdev sd;
+ struct ths7303_platform_datapdata;
+ struct v4l2_bt_timings bt;
+ int std_id;
+ int stream_on;
+ int driver_data;
+};
+
enum ths7303_filter_mode {
THS7303_FILTER_MODE_480I_576I,
THS7303_FILTER_MODE_480P_576P,
@@ -48,64 +58,84 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Debug level 0-1);
+static inline struct ths7303_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ths7303_state, sd);
+}
+
+static int ths7303_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ths7303_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i 3; i++) {
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ return ret;
+}
+
/* following function is used to set ths7303 */
int ths7303_setval(struct v4l2_subdev *sd, enum ths7303_filter_mode mode)
{
- u8 input_bias_chroma = 3;
- u8 input_bias_luma = 3;
- int disable = 0;
- int err = 0;
- u8 val = 0;
- u8 temp;
-
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct ths7303_state *state = to_state(sd);
+ struct ths7303_platform_data *pdata = state-pdata;
+ u8 val, sel = 0;
+ int err, disable = 0;
if (!client)
return -EINVAL;
switch (mode) {
case THS7303_FILTER_MODE_1080P:
- val = (3 6);
- val |= (3 3);
+ sel = 0x3; /*1080p and SXGA/UXGA */
[PATCH 1/2] [media] s5p-tv: Include missing irqreturn.h header
Without this patch we get the following compilation errors: drivers/media/platform/s5p-tv/mixer.h:345:13: error: Expected ; at end of declaration drivers/media/platform/s5p-tv/mixer.h:345:13: error: got mxr_irq_handler Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/platform/s5p-tv/mixer.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/s5p-tv/mixer.h b/drivers/media/platform/s5p-tv/mixer.h index b671e20..04e6490 100644 --- a/drivers/media/platform/s5p-tv/mixer.h +++ b/drivers/media/platform/s5p-tv/mixer.h @@ -19,6 +19,7 @@ #endif #include linux/fb.h +#include linux/irqreturn.h #include linux/kernel.h #include linux/spinlock.h #include linux/wait.h -- 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
[PATCH 2/2] [media] s5p-tv: Include missing platform_device.h header
Without this patch we get the following build error: drivers/media/platform/s5p-tv/mixer_video.c: In function ‘find_and_register_subdev’: drivers/media/platform/s5p-tv/mixer_video.c:42:34: error: ‘platform_bus_type’ undeclared (first use in this function) Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/platform/s5p-tv/mixer_video.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/platform/s5p-tv/mixer_video.c b/drivers/media/platform/s5p-tv/mixer_video.c index c087b66..82142a2 100644 --- a/drivers/media/platform/s5p-tv/mixer_video.c +++ b/drivers/media/platform/s5p-tv/mixer_video.c @@ -19,6 +19,7 @@ #include linux/videodev2.h #include linux/mm.h #include linux/module.h +#include linux/platform_device.h #include linux/timer.h #include media/videobuf2-dma-contig.h -- 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
