Re: [PATCH 45/47] adv7604: Add DT support
On 02/05/14 17:42, Laurent Pinchart wrote:
Parse the device tree node to populate platform data.
Cc: devicet...@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../devicetree/bindings/media/i2c/adv7604.txt | 56
drivers/media/i2c/adv7604.c| 101
++---
2 files changed, 143 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7604.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
new file mode 100644
index 000..0845c50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -0,0 +1,56 @@
+* Analog Devices ADV7604/11 video decoder with HDMI receiver
+
+The ADV7604 and ADV7611 are multiformat video decoders with an integrated
HDMI
+receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input,
+and the ADV7611 has one HDMI input and no analog input.
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+- adi,adv7604 for the ADV7604
+- adi,adv7611 for the ADV7611
+
+ - reg: I2C slave address
+
+ - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
+detection pins, one per HDMI input. The active flag indicates the GPIO
+level that enables hot-plug detection.
+
+Optional Properties:
+
+ - reset-gpios: Reference to the GPIO connected to the device's reset pin.
+
+ - adi,default-input: Index of the input to be configured as default. Valid
+values are 0..5 for the ADV7604 and 0 for the ADV7611.
+
+ - adi,disable-power-down: Boolean property. When set forces the device to
+ignore the power-down pin. The property is valid for the ADV7604 only as
+the ADV7611 has no power-down pin.
+
+ - adi,disable-cable-reset: Boolean property. When set disables the HDMI
+receiver automatic reset when the HDMI cable is unplugged.
+
+Example:
+
+ hdmi_receiver@4c {
+ compatible = adi,adv7611;
+ reg = 0x4c;
+
+ reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
+ hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
+
+ adi,default-input = 0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ };
+ port@1 {
+ reg = 1;
+ hdmi_in: endpoint {
+ remote-endpoint = ccdc_in;
+ };
+ };
+ };
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e586c1c..cd8a2dc 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -32,6 +32,7 @@
#include linux/i2c.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/slab.h
#include linux/v4l2-dv-timings.h
#include linux/videodev2.h
@@ -2641,13 +2642,83 @@ static const struct adv7604_chip_info
adv7604_chip_info[] = {
},
};
+static struct i2c_device_id adv7604_i2c_id[] = {
+ { adv7604, (kernel_ulong_t)adv7604_chip_info[ADV7604] },
+ { adv7611, (kernel_ulong_t)adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
+
+static struct of_device_id adv7604_of_id[] = {
+ { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
+ { .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adv7604_of_id);
+
+static int adv7604_parse_dt(struct adv7604_state *state)
Put this under #ifdef CONFIG_OF. It fails to compile if CONFIG_OF is not set
(as it is in my case since this driver is used with a PCIe card).
Regards,
Hans
+{
+ struct device_node *np;
+ unsigned int i;
+ int ret;
+
+ np = state-i2c_clients[ADV7604_PAGE_IO]-dev.of_node;
+ state-info = of_match_node(adv7604_of_id, np)-data;
+
+ state-pdata.disable_pwrdnb =
+ of_property_read_bool(np, adi,disable-power-down);
+ state-pdata.disable_cable_det_rst =
+ of_property_read_bool(np, adi,disable-cable-reset);
+
+ ret = of_property_read_u32(np, adi,default-input,
+state-pdata.default_input);
+ if (ret 0)
+ state-pdata.default_input = -1;
+
+ for (i = 0; i state-info-num_dv_ports; ++i) {
+ enum of_gpio_flags flags;
+
+ state-pdata.hpd_gpio[i] =
+ of_get_named_gpio_flags(np, hpd-gpios, i, flags);
+ if (IS_ERR_VALUE(state-pdata.hpd_gpio[i]))
+ continue;
+
+ state-pdata.hpd_gpio_low[i] = flags == OF_GPIO_ACTIVE_LOW;
+ }
+
+ /* Disable the interrupt for now as no DT-based board uses it. */
+ state-pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED;
+
Re: [PATCH 43/47] adv7604: Control hot-plug detect through a GPIO
On 02/05/14 17:42, Laurent Pinchart wrote:
Replace the ADV7604-specific hotplug notifier with a GPIO to control the
HPD pin directly instead of going through the bridge driver.
Hmm, that's not going to work for me. I don't have a GPIO pin here, instead
it is a bit in a register that I have to set.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 47
+
include/media/adv7604.h | 5 -
2 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 369cb1e..2f38071 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -28,6 +28,7 @@
*/
#include linux/delay.h
+#include linux/gpio.h
#include linux/i2c.h
#include linux/kernel.h
#include linux/module.h
@@ -608,6 +609,23 @@ static inline int edid_write_block(struct v4l2_subdev
*sd,
return err;
}
+static void adv7604_set_hpd(struct adv7604_state *state, unsigned int hpd)
+{
+ unsigned int i;
+
+ for (i = 0; i state-info-num_dv_ports; ++i) {
+ unsigned int enable = hpd BIT(i);
+
+ if (IS_ERR_VALUE(state-pdata.hpd_gpio[i]))
IS_ERR_VALUE: that's normally used for pointers, not integers. I would
much prefer something simple like 'bool hpd_use_gpio[4]'.
Regards,
Hans
+ continue;
+
+ if (state-pdata.hpd_gpio_low[i])
+ enable = !enable;
+
+ gpio_set_value_cansleep(state-pdata.hpd_gpio[i], enable);
+ }
+}
+
static void adv7604_delayed_work_enable_hotplug(struct work_struct *work)
{
struct delayed_work *dwork = to_delayed_work(work);
@@ -617,7 +635,7 @@ static void adv7604_delayed_work_enable_hotplug(struct
work_struct *work)
v4l2_dbg(2, debug, sd, %s: enable hotplug\n, __func__);
- v4l2_subdev_notify(sd, ADV7604_HOTPLUG, (void *)state-edid.present);
+ adv7604_set_hpd(state, state-edid.present);
}
static inline int hdmi_read(struct v4l2_subdev *sd, u8 reg)
@@ -2022,7 +2040,6 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edi
struct adv7604_state *state = to_state(sd);
const struct adv7604_chip_info *info = state-info;
int spa_loc;
- int tmp = 0;
int err;
int i;
@@ -2033,7 +2050,7 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edi
if (edid-blocks == 0) {
/* Disable hotplug and I2C access to EDID RAM from DDC port */
state-edid.present = ~(1 edid-pad);
- v4l2_subdev_notify(sd, ADV7604_HOTPLUG, (void
*)state-edid.present);
+ adv7604_set_hpd(state, state-edid.present);
rep_write_clr_set(sd, info-edid_enable_reg, 0x0f,
state-edid.present);
/* Fall back to a 16:9 aspect ratio */
@@ -2059,7 +2076,7 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edi
/* Disable hotplug and I2C access to EDID RAM from DDC port */
cancel_delayed_work_sync(state-delayed_work_enable_hotplug);
- v4l2_subdev_notify(sd, ADV7604_HOTPLUG, (void *)tmp);
+ adv7604_set_hpd(state, 0);
rep_write_clr_set(sd, info-edid_enable_reg, 0x0f, 0x00);
spa_loc = get_edid_spa_location(edid-edid);
@@ -2655,6 +2672,28 @@ static int adv7604_probe(struct i2c_client *client,
return -ENODEV;
}
state-pdata = *pdata;
+
+ /* Request GPIOs. */
+ for (i = 0; i state-info-num_dv_ports; ++i) {
+ char name[5];
+
+ if (IS_ERR_VALUE(state-pdata.hpd_gpio[i]))
+ continue;
+
+ sprintf(name, hpd%u, i);
+ err = devm_gpio_request_one(client-dev,
+ state-pdata.hpd_gpio[i],
+ state-pdata.hpd_gpio_low[i] ?
+ GPIOF_OUT_INIT_HIGH :
+ GPIOF_OUT_INIT_LOW,
+ name);
+ if (err 0) {
+ v4l_err(client, Failed to request HPD %u GPIO (%u)\n,
+ i, state-pdata.hpd_gpio[i]);
+ return err;
+ }
+ }
+
state-timings = cea640x480;
state-format = adv7604_format_info(state, V4L2_MBUS_FMT_YUYV8_2X8);
diff --git a/include/media/adv7604.h b/include/media/adv7604.h
index 4da678c..dddb0cb 100644
--- a/include/media/adv7604.h
+++ b/include/media/adv7604.h
@@ -90,6 +90,10 @@ struct adv7604_platform_data {
/* DIS_CABLE_DET_RST: 1 if the 5V pins are unused and unconnected */
unsigned disable_cable_det_rst:1;
+ /* Hot-Plug Detect control GPIOs */
+ int hpd_gpio[4];
+ bool hpd_gpio_low[4];
+
/* Analog
Re: [PATCH 35/47] adv7604: Add sink pads
On 02/05/14 17:42, Laurent Pinchart wrote:
The ADV7604 has sink pads for its HDMI and analog inputs. Report them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 71
-
include/media/adv7604.h | 14 -
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 05e7e1a..da32ce9 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -97,13 +97,25 @@ struct adv7604_chip_info {
*
**
*/
+enum adv7604_pad {
+ ADV7604_PAD_HDMI_PORT_A = 0,
+ ADV7604_PAD_HDMI_PORT_B = 1,
+ ADV7604_PAD_HDMI_PORT_C = 2,
+ ADV7604_PAD_HDMI_PORT_D = 3,
+ ADV7604_PAD_VGA_RGB = 4,
+ ADV7604_PAD_VGA_COMP = 5,
+ /* The source pad is either 1 (ADV7611) or 6 (ADV7604) */
How about making this explicit:
ADV7604_PAD_SOURCE = 6,
ADV7611_PAD_SOURCE = 1,
+ ADV7604_PAD_MAX = 7,
+};
Wouldn't it make more sense to have this in the header? I would really
like to use the symbolic names for these pads in my bridge driver.
Regards,
Hans
+
struct adv7604_state {
const struct adv7604_chip_info *info;
struct adv7604_platform_data pdata;
struct v4l2_subdev sd;
- struct media_pad pad;
+ struct media_pad pads[ADV7604_PAD_MAX];
+ unsigned int source_pad;
struct v4l2_ctrl_handler hdl;
- enum adv7604_input_port selected_input;
+ enum adv7604_pad selected_input;
struct v4l2_dv_timings timings;
struct {
u8 edid[256];
@@ -775,18 +787,18 @@ static inline bool is_analog_input(struct v4l2_subdev
*sd)
{
struct adv7604_state *state = to_state(sd);
- return state-selected_input == ADV7604_INPUT_VGA_RGB ||
-state-selected_input == ADV7604_INPUT_VGA_COMP;
+ return state-selected_input == ADV7604_PAD_VGA_RGB ||
+state-selected_input == ADV7604_PAD_VGA_COMP;
}
static inline bool is_digital_input(struct v4l2_subdev *sd)
{
struct adv7604_state *state = to_state(sd);
- return state-selected_input == ADV7604_INPUT_HDMI_PORT_A ||
-state-selected_input == ADV7604_INPUT_HDMI_PORT_B ||
-state-selected_input == ADV7604_INPUT_HDMI_PORT_C ||
-state-selected_input == ADV7604_INPUT_HDMI_PORT_D;
+ return state-selected_input == ADV7604_PAD_HDMI_PORT_A ||
+state-selected_input == ADV7604_PAD_HDMI_PORT_B ||
+state-selected_input == ADV7604_PAD_HDMI_PORT_C ||
+state-selected_input == ADV7604_PAD_HDMI_PORT_D;
}
/* --- */
@@ -1066,14 +1078,14 @@ static void set_rgb_quantization_range(struct
v4l2_subdev *sd)
switch (state-rgb_quantization_range) {
case V4L2_DV_RGB_RANGE_AUTO:
- if (state-selected_input == ADV7604_INPUT_VGA_RGB) {
+ if (state-selected_input == ADV7604_PAD_VGA_RGB) {
/* Receiving analog RGB signal
* Set RGB full range (0-255) */
io_write_and_or(sd, 0x02, 0x0f, 0x10);
break;
}
- if (state-selected_input == ADV7604_INPUT_VGA_COMP) {
+ if (state-selected_input == ADV7604_PAD_VGA_COMP) {
/* Receiving analog YPbPr signal
* Set automode */
io_write_and_or(sd, 0x02, 0x0f, 0xf0);
@@ -1106,7 +1118,7 @@ static void set_rgb_quantization_range(struct
v4l2_subdev *sd)
}
break;
case V4L2_DV_RGB_RANGE_LIMITED:
- if (state-selected_input == ADV7604_INPUT_VGA_COMP) {
+ if (state-selected_input == ADV7604_PAD_VGA_COMP) {
/* YCrCb limited range (16-235) */
io_write_and_or(sd, 0x02, 0x0f, 0x20);
break;
@@ -1117,7 +1129,7 @@ static void set_rgb_quantization_range(struct
v4l2_subdev *sd)
break;
case V4L2_DV_RGB_RANGE_FULL:
- if (state-selected_input == ADV7604_INPUT_VGA_COMP) {
+ if (state-selected_input == ADV7604_PAD_VGA_COMP) {
/* YCrCb full range (0-255) */
io_write_and_or(sd, 0x02, 0x0f, 0x60);
break;
@@ -1806,7 +1818,7 @@ static int adv7604_get_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edi
struct adv7604_state *state = to_state(sd);
u8 *data = NULL;
- if (edid-pad ADV7604_EDID_PORT_D)
+ if (edid-pad ADV7604_PAD_HDMI_PORT_D)
return -EINVAL;
if (edid-blocks == 0)
return -EINVAL;
@@ -1823,10 +1835,10 @@ static int adv7604_get_edid(struct
[PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag
Commit d632dfefd36f ([media] v4l: omap4iss: Add support for OMAP4 camera interface - Build system) added a Kconfig entry for VIDEO_OMAP4_DEBUG. But nothing uses that symbol. This entry was apparently copied from a similar entry for OMAP 3 Camera debug messages. The OMAP 3 entry is used to set the DEBUG compiler flag, which enables calls of dev_dbg(). So add a Makefile line to do that for omap4iss too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) v1 was called [media] v4l: omap4iss: Remove VIDEO_OMAP4_DEBUG. This versions implements Laurent's alternative (which is much better). 1) Still untested. drivers/staging/media/omap4iss/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/media/omap4iss/Makefile b/drivers/staging/media/omap4iss/Makefile index a716ce9..f46c6bd 100644 --- a/drivers/staging/media/omap4iss/Makefile +++ b/drivers/staging/media/omap4iss/Makefile @@ -1,5 +1,7 @@ # Makefile for OMAP4 ISS driver +ccflags-$(CONFIG_VIDEO_OMAP4_DEBUG) += -DDEBUG + omap4-iss-objs += \ iss.o iss_csi2.o iss_csiphy.o iss_ipipeif.o iss_ipipe.o iss_resizer.o iss_video.o -- 1.8.5.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Philipp Zabel philipp.za...@gmail.com
This patch moves the parsing helpers used to parse connected graphs
in the device tree, like the video interface bindings documented in
Documentation/devicetree/bindings/media/video-interfaces.txt, from
drivers/media/v4l2-core to drivers/of.
This allows to reuse the same parser code from outside the V4L2 framework,
most importantly from display drivers. There have been patches that duplicate
the code (and I am going to send one of my own), such as
http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
and others that parse the same binding in a different way:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
I think that all common video interface parsing helpers should be moved to a
single place, outside of the specific subsystems, so that it can be reused
by all drivers.
I moved v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
and v4l2_of_get_remote_port_parent. They are renamed to
of_graph_get_next_endpoint, of_graph_get_remote_port, and
of_graph_get_remote_port_parent, respectively.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/Kconfig | 1 +
drivers/media/v4l2-core/v4l2-of.c | 117 -
drivers/of/Kconfig| 3 +
drivers/of/Makefile | 1 +
drivers/of/of_graph.c | 133 ++
include/linux/of_graph.h | 23 +++
include/media/v4l2-of.h | 16 ++---
7 files changed, 167 insertions(+), 127 deletions(-)
create mode 100644 drivers/of/of_graph.c
create mode 100644 include/linux/of_graph.h
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 1d0758a..882faeb 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -96,6 +96,7 @@ config VIDEO_DEV
tristate
depends on MEDIA_SUPPORT
depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT ||
MEDIA_RADIO_SUPPORT
+ select OF_GRAPH if OF
default y
config VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 42e3e8a..f919db3 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -152,120 +152,3 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
return 0;
}
EXPORT_SYMBOL(v4l2_of_parse_endpoint);
-
-/**
- * v4l2_of_get_next_endpoint() - get next endpoint node
- * @parent: pointer to the parent device node
- * @prev: previous endpoint node, or NULL to get first
- *
- * Return: An 'endpoint' node pointer with refcount incremented. Refcount
- * of the passed @prev node is not decremented, the caller have to use
- * of_node_put() on it when done.
- */
-struct device_node *v4l2_of_get_next_endpoint(const struct device_node *parent,
- struct device_node *prev)
-{
- struct device_node *endpoint;
- struct device_node *port = NULL;
-
- if (!parent)
- return NULL;
-
- if (!prev) {
- struct device_node *node;
- /*
-* It's the first call, we have to find a port subnode
-* within this node or within an optional 'ports' node.
-*/
- node = of_get_child_by_name(parent, ports);
- if (node)
- parent = node;
-
- port = of_get_child_by_name(parent, port);
-
- if (port) {
- /* Found a port, get an endpoint. */
- endpoint = of_get_next_child(port, NULL);
- of_node_put(port);
- } else {
- endpoint = NULL;
- }
-
- if (!endpoint)
- pr_err(%s(): no endpoint nodes specified for %s\n,
- __func__, parent-full_name);
- of_node_put(node);
- } else {
- port = of_get_parent(prev);
- if (!port)
- /* Hm, has someone given us the root node ?... */
- return NULL;
-
- /* Avoid dropping prev node refcount to 0. */
- of_node_get(prev);
- endpoint = of_get_next_child(port, prev);
- if (endpoint) {
- of_node_put(port);
- return endpoint;
- }
-
- /* No more endpoints under this port, try the next one. */
- do {
- port = of_get_next_child(parent, port);
- if (!port)
- return NULL;
- } while (of_node_cmp(port-name, port));
-
- /* Pick up the first endpoint in this port. */
- endpoint = of_get_next_child(port, NULL);
- of_node_put(port);
- }
-
- return endpoint;
-}
-EXPORT_SYMBOL(v4l2_of_get_next_endpoint);
-
Re: [PATCH 35/47] adv7604: Add sink pads
Hi Hans,
On Tuesday 11 February 2014 11:19:32 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
The ADV7604 has sink pads for its HDMI and analog inputs. Report them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 71 +---
include/media/adv7604.h | 14 -
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 05e7e1a..da32ce9 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -97,13 +97,25 @@ struct adv7604_chip_info {
**
*/
+enum adv7604_pad {
+ ADV7604_PAD_HDMI_PORT_A = 0,
+ ADV7604_PAD_HDMI_PORT_B = 1,
+ ADV7604_PAD_HDMI_PORT_C = 2,
+ ADV7604_PAD_HDMI_PORT_D = 3,
+ ADV7604_PAD_VGA_RGB = 4,
+ ADV7604_PAD_VGA_COMP = 5,
+ /* The source pad is either 1 (ADV7611) or 6 (ADV7604) */
How about making this explicit:
ADV7604_PAD_SOURCE = 6,
ADV7611_PAD_SOURCE = 1,
I can do that, but those two constants won't be used in the driver as they
computed dynamically.
+ ADV7604_PAD_MAX = 7,
+};
Wouldn't it make more sense to have this in the header? I would really
like to use the symbolic names for these pads in my bridge driver.
That would add a dependency on the adv7604 driver to the bridge driver, isn't
the whole point of subdevs to avoid such dependencies ?
--
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 43/47] adv7604: Control hot-plug detect through a GPIO
Hi Hans,
On Tuesday 11 February 2014 11:09:31 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
Replace the ADV7604-specific hotplug notifier with a GPIO to control the
HPD pin directly instead of going through the bridge driver.
Hmm, that's not going to work for me. I don't have a GPIO pin here, instead
it is a bit in a register that I have to set.
But that bit controls a GPIO, doesn't it ? In that case it should be exposed
as a GPIO controller.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 47
include/media/adv7604.h | 5 -
2 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 369cb1e..2f38071 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -28,6 +28,7 @@
*/
#include linux/delay.h
+#include linux/gpio.h
#include linux/i2c.h
#include linux/kernel.h
#include linux/module.h
@@ -608,6 +609,23 @@ static inline int edid_write_block(struct v4l2_subdev
*sd,
return err;
}
+static void adv7604_set_hpd(struct adv7604_state *state, unsigned int
hpd)
+{
+ unsigned int i;
+
+ for (i = 0; i state-info-num_dv_ports; ++i) {
+ unsigned int enable = hpd BIT(i);
+
+ if (IS_ERR_VALUE(state-pdata.hpd_gpio[i]))
IS_ERR_VALUE: that's normally used for pointers, not integers. I would
much prefer something simple like 'bool hpd_use_gpio[4]'.
I've reworked this to use the gpiod_* API, I'll post v2 when the whole set
will be reviewed.
+ continue;
+
+ if (state-pdata.hpd_gpio_low[i])
+ enable = !enable;
+
+ gpio_set_value_cansleep(state-pdata.hpd_gpio[i], enable);
+ }
+}
+
static void adv7604_delayed_work_enable_hotplug(struct work_struct *work)
{
struct delayed_work *dwork = to_delayed_work(work);
@@ -617,7 +635,7 @@ static void adv7604_delayed_work_enable_hotplug(struct
work_struct *work)
v4l2_dbg(2, debug, sd, %s: enable hotplug\n, __func__);
- v4l2_subdev_notify(sd, ADV7604_HOTPLUG, (void *)state-
edid.present);
+ adv7604_set_hpd(state, state-edid.present);
}
static inline int hdmi_read(struct v4l2_subdev *sd, u8 reg)
@@ -2022,7 +2040,6 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edi
struct adv7604_state *state = to_state(sd);
const struct adv7604_chip_info *info = state-info;
int spa_loc;
- int tmp = 0;
int err;
int i;
@@ -2033,7 +2050,7 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edi
if (edid-blocks == 0) {
/* Disable hotplug and I2C access to EDID RAM from DDC port */
state-edid.present = ~(1 edid-pad);
- v4l2_subdev_notify(sd, ADV7604_HOTPLUG, (void *)state-
edid.present);
+ adv7604_set_hpd(state, state-edid.present);
rep_write_clr_set(sd, info-edid_enable_reg, 0x0f,
state-edid.present);
/* Fall back to a 16:9 aspect ratio */
@@ -2059,7 +2076,7 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_subdev_edid *edi
/* Disable hotplug and I2C access to EDID RAM from DDC port */
cancel_delayed_work_sync(state-delayed_work_enable_hotplug);
- v4l2_subdev_notify(sd, ADV7604_HOTPLUG, (void *)tmp);
+ adv7604_set_hpd(state, 0);
rep_write_clr_set(sd, info-edid_enable_reg, 0x0f, 0x00);
spa_loc = get_edid_spa_location(edid-edid);
@@ -2655,6 +2672,28 @@ static int adv7604_probe(struct i2c_client *client,
return -ENODEV;
}
state-pdata = *pdata;
+
+ /* Request GPIOs. */
+ for (i = 0; i state-info-num_dv_ports; ++i) {
+ char name[5];
+
+ if (IS_ERR_VALUE(state-pdata.hpd_gpio[i]))
+ continue;
+
+ sprintf(name, hpd%u, i);
+ err = devm_gpio_request_one(client-dev,
+ state-pdata.hpd_gpio[i],
+ state-pdata.hpd_gpio_low[i] ?
+ GPIOF_OUT_INIT_HIGH :
+ GPIOF_OUT_INIT_LOW,
+ name);
+ if (err 0) {
+ v4l_err(client, Failed to request HPD %u GPIO (%u)\n,
+ i, state-pdata.hpd_gpio[i]);
+ return err;
+ }
+ }
+
state-timings = cea640x480;
state-format = adv7604_format_info(state, V4L2_MBUS_FMT_YUYV8_2X8);
diff --git a/include/media/adv7604.h b/include/media/adv7604.h
index 4da678c..dddb0cb 100644
--- a/include/media/adv7604.h
+++ b/include/media/adv7604.h
@@ -90,6 +90,10 @@ struct
Re: [PATCH 45/47] adv7604: Add DT support
Hi Hans,
On Tuesday 11 February 2014 10:23:03 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
Parse the device tree node to populate platform data.
Cc: devicet...@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../devicetree/bindings/media/i2c/adv7604.txt | 56
drivers/media/i2c/adv7604.c| 101 ++--
2 files changed, 143 insertions(+), 14 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/i2c/adv7604.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt new file mode
100644
index 000..0845c50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -0,0 +1,56 @@
+* Analog Devices ADV7604/11 video decoder with HDMI receiver
+
+The ADV7604 and ADV7611 are multiformat video decoders with an integrated
HDMI +receiver. The ADV7604 has four multiplexed HDMI inputs and one
analog input, +and the ADV7611 has one HDMI input and no analog input.
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+- adi,adv7604 for the ADV7604
+- adi,adv7611 for the ADV7611
+
+ - reg: I2C slave address
+
+ - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
+detection pins, one per HDMI input. The active flag indicates the
GPIO
+level that enables hot-plug detection.
+
+Optional Properties:
+
+ - reset-gpios: Reference to the GPIO connected to the device's reset
pin. +
+ - adi,default-input: Index of the input to be configured as default.
Valid +values are 0..5 for the ADV7604 and 0 for the ADV7611.
+
+ - adi,disable-power-down: Boolean property. When set forces the device
to +ignore the power-down pin. The property is valid for the ADV7604
only as +the ADV7611 has no power-down pin.
+
+ - adi,disable-cable-reset: Boolean property. When set disables the HDMI
+receiver automatic reset when the HDMI cable is unplugged.
+
+Example:
+
+ hdmi_receiver@4c {
+ compatible = adi,adv7611;
+ reg = 0x4c;
+
+ reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
+ hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
+
+ adi,default-input = 0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ };
+ port@1 {
+ reg = 1;
+ hdmi_in: endpoint {
+ remote-endpoint = ccdc_in;
+ };
+ };
+ };
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e586c1c..cd8a2dc 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -32,6 +32,7 @@
#include linux/i2c.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/slab.h
#include linux/v4l2-dv-timings.h
#include linux/videodev2.h
@@ -2641,13 +2642,83 @@ static const struct adv7604_chip_info
adv7604_chip_info[] = {
},
};
+static struct i2c_device_id adv7604_i2c_id[] = {
+ { adv7604, (kernel_ulong_t)adv7604_chip_info[ADV7604] },
+ { adv7611, (kernel_ulong_t)adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
+
+static struct of_device_id adv7604_of_id[] = {
+ { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
+ { .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adv7604_of_id);
+
+static int adv7604_parse_dt(struct adv7604_state *state)
Put this under #ifdef CONFIG_OF.
#ifdef CONFIG_OF has been discouraged. I'll add an IS_ENABLED(CONFIG_OF) to
condition the call of adv7604_parse_dt() and let the compiler optimize the
function out, but I've been recommended to fix compilation errors instead of
using conditional compilation.
It fails to compile if CONFIG_OF is not set (as it is in my case since this
driver is used with a PCIe card).
What's the compilation failure ?
+{
+ struct device_node *np;
+ unsigned int i;
+ int ret;
+
+ np = state-i2c_clients[ADV7604_PAGE_IO]-dev.of_node;
+ state-info = of_match_node(adv7604_of_id, np)-data;
+
+ state-pdata.disable_pwrdnb =
+ of_property_read_bool(np, adi,disable-power-down);
+ state-pdata.disable_cable_det_rst =
+ of_property_read_bool(np, adi,disable-cable-reset);
+
+ ret = of_property_read_u32(np, adi,default-input,
+ state-pdata.default_input);
+ if (ret 0)
+ state-pdata.default_input = -1;
+
+ for (i = 0; i state-info-num_dv_ports; ++i) {
+ enum of_gpio_flags flags;
+
+
Re: [PATCH 35/47] adv7604: Add sink pads
On 02/11/14 13:00, Laurent Pinchart wrote:
Hi Hans,
On Tuesday 11 February 2014 11:19:32 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
The ADV7604 has sink pads for its HDMI and analog inputs. Report them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 71 +---
include/media/adv7604.h | 14 -
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 05e7e1a..da32ce9 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -97,13 +97,25 @@ struct adv7604_chip_info {
**
*/
+enum adv7604_pad {
+ ADV7604_PAD_HDMI_PORT_A = 0,
+ ADV7604_PAD_HDMI_PORT_B = 1,
+ ADV7604_PAD_HDMI_PORT_C = 2,
+ ADV7604_PAD_HDMI_PORT_D = 3,
+ ADV7604_PAD_VGA_RGB = 4,
+ ADV7604_PAD_VGA_COMP = 5,
+ /* The source pad is either 1 (ADV7611) or 6 (ADV7604) */
How about making this explicit:
ADV7604_PAD_SOURCE = 6,
ADV7611_PAD_SOURCE = 1,
I can do that, but those two constants won't be used in the driver as they
computed dynamically.
+ ADV7604_PAD_MAX = 7,
+};
Wouldn't it make more sense to have this in the header? I would really
like to use the symbolic names for these pads in my bridge driver.
That would add a dependency on the adv7604 driver to the bridge driver, isn't
the whole point of subdevs to avoid such dependencies ?
The bridge driver has to know about the adv7604, not the other way around.
E.g. in my bridge driver I have to match v4l2 inputs to pads, both for
S_EDID and for s_routing, so it needs to know which pad number to use.
Also, for calling set_fmt, BTW. There I need to specify the source pad,
which is also why I would like to have a symbolic name for it as suggested
above.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 45/47] adv7604: Add DT support
On 02/11/14 13:08, Laurent Pinchart wrote:
Hi Hans,
On Tuesday 11 February 2014 10:23:03 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
Parse the device tree node to populate platform data.
Cc: devicet...@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../devicetree/bindings/media/i2c/adv7604.txt | 56
drivers/media/i2c/adv7604.c| 101 ++--
2 files changed, 143 insertions(+), 14 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/i2c/adv7604.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt new file mode
100644
index 000..0845c50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -0,0 +1,56 @@
+* Analog Devices ADV7604/11 video decoder with HDMI receiver
+
+The ADV7604 and ADV7611 are multiformat video decoders with an integrated
HDMI +receiver. The ADV7604 has four multiplexed HDMI inputs and one
analog input, +and the ADV7611 has one HDMI input and no analog input.
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+- adi,adv7604 for the ADV7604
+- adi,adv7611 for the ADV7611
+
+ - reg: I2C slave address
+
+ - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
+detection pins, one per HDMI input. The active flag indicates the
GPIO
+level that enables hot-plug detection.
+
+Optional Properties:
+
+ - reset-gpios: Reference to the GPIO connected to the device's reset
pin. +
+ - adi,default-input: Index of the input to be configured as default.
Valid +values are 0..5 for the ADV7604 and 0 for the ADV7611.
+
+ - adi,disable-power-down: Boolean property. When set forces the device
to +ignore the power-down pin. The property is valid for the ADV7604
only as +the ADV7611 has no power-down pin.
+
+ - adi,disable-cable-reset: Boolean property. When set disables the HDMI
+receiver automatic reset when the HDMI cable is unplugged.
+
+Example:
+
+ hdmi_receiver@4c {
+ compatible = adi,adv7611;
+ reg = 0x4c;
+
+ reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
+ hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
+
+ adi,default-input = 0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ };
+ port@1 {
+ reg = 1;
+ hdmi_in: endpoint {
+ remote-endpoint = ccdc_in;
+ };
+ };
+ };
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e586c1c..cd8a2dc 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -32,6 +32,7 @@
#include linux/i2c.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/slab.h
#include linux/v4l2-dv-timings.h
#include linux/videodev2.h
@@ -2641,13 +2642,83 @@ static const struct adv7604_chip_info
adv7604_chip_info[] = {
},
};
+static struct i2c_device_id adv7604_i2c_id[] = {
+ { adv7604, (kernel_ulong_t)adv7604_chip_info[ADV7604] },
+ { adv7611, (kernel_ulong_t)adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
+
+static struct of_device_id adv7604_of_id[] = {
+ { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
+ { .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adv7604_of_id);
+
+static int adv7604_parse_dt(struct adv7604_state *state)
Put this under #ifdef CONFIG_OF.
#ifdef CONFIG_OF has been discouraged. I'll add an IS_ENABLED(CONFIG_OF) to
condition the call of adv7604_parse_dt() and let the compiler optimize the
function out, but I've been recommended to fix compilation errors instead of
using conditional compilation.
It fails to compile if CONFIG_OF is not set (as it is in my case since this
driver is used with a PCIe card).
What's the compilation failure ?
drivers/media/i2c/adv7604.c: In function ‘adv7604_parse_dt’:
drivers/media/i2c/adv7604.c:2671:48: warning: dereferencing ‘void *’ pointer
[enabled by default]
state-info = of_match_node(adv7604_of_id, np)-data;
^
drivers/media/i2c/adv7604.c:2671:48: error: request for member ‘data’ in
something not a structure or union
make[3]: *** [drivers/media/i2c/adv7604.o] Error 1
+{
+ struct device_node *np;
+ unsigned int i;
+ int ret;
+
+ np = state-i2c_clients[ADV7604_PAGE_IO]-dev.of_node;
+ state-info = of_match_node(adv7604_of_id, np)-data;
+
+ state-pdata.disable_pwrdnb =
+ of_property_read_bool(np, adi,disable-power-down);
+ state-pdata.disable_cable_det_rst =
+
Re: [PATCH 45/47] adv7604: Add DT support
On 02/11/2014 01:14 PM, Hans Verkuil wrote:
On 02/11/14 13:08, Laurent Pinchart wrote:
Hi Hans,
On Tuesday 11 February 2014 10:23:03 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
Parse the device tree node to populate platform data.
Cc: devicet...@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../devicetree/bindings/media/i2c/adv7604.txt | 56
drivers/media/i2c/adv7604.c| 101 ++--
2 files changed, 143 insertions(+), 14 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/i2c/adv7604.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt new file mode
100644
index 000..0845c50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -0,0 +1,56 @@
+* Analog Devices ADV7604/11 video decoder with HDMI receiver
+
+The ADV7604 and ADV7611 are multiformat video decoders with an integrated
HDMI +receiver. The ADV7604 has four multiplexed HDMI inputs and one
analog input, +and the ADV7611 has one HDMI input and no analog input.
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+- adi,adv7604 for the ADV7604
+- adi,adv7611 for the ADV7611
+
+ - reg: I2C slave address
+
+ - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
+detection pins, one per HDMI input. The active flag indicates the
GPIO
+level that enables hot-plug detection.
+
+Optional Properties:
+
+ - reset-gpios: Reference to the GPIO connected to the device's reset
pin. +
+ - adi,default-input: Index of the input to be configured as default.
Valid +values are 0..5 for the ADV7604 and 0 for the ADV7611.
+
+ - adi,disable-power-down: Boolean property. When set forces the device
to +ignore the power-down pin. The property is valid for the ADV7604
only as +the ADV7611 has no power-down pin.
+
+ - adi,disable-cable-reset: Boolean property. When set disables the HDMI
+receiver automatic reset when the HDMI cable is unplugged.
+
+Example:
+
+ hdmi_receiver@4c {
+ compatible = adi,adv7611;
+ reg = 0x4c;
+
+ reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
+ hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
+
+ adi,default-input = 0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+ };
+ port@1 {
+ reg = 1;
+ hdmi_in: endpoint {
+ remote-endpoint = ccdc_in;
+ };
+ };
+ };
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e586c1c..cd8a2dc 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -32,6 +32,7 @@
#include linux/i2c.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/slab.h
#include linux/v4l2-dv-timings.h
#include linux/videodev2.h
@@ -2641,13 +2642,83 @@ static const struct adv7604_chip_info
adv7604_chip_info[] = {
},
};
+static struct i2c_device_id adv7604_i2c_id[] = {
+ { adv7604, (kernel_ulong_t)adv7604_chip_info[ADV7604] },
+ { adv7611, (kernel_ulong_t)adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
+
+static struct of_device_id adv7604_of_id[] = {
+ { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
+ { .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adv7604_of_id);
+
+static int adv7604_parse_dt(struct adv7604_state *state)
Put this under #ifdef CONFIG_OF.
#ifdef CONFIG_OF has been discouraged. I'll add an IS_ENABLED(CONFIG_OF) to
condition the call of adv7604_parse_dt() and let the compiler optimize the
function out, but I've been recommended to fix compilation errors instead of
using conditional compilation.
It fails to compile if CONFIG_OF is not set (as it is in my case since this
driver is used with a PCIe card).
What's the compilation failure ?
drivers/media/i2c/adv7604.c: In function ‘adv7604_parse_dt’:
drivers/media/i2c/adv7604.c:2671:48: warning: dereferencing ‘void *’ pointer
[enabled by default]
state-info = of_match_node(adv7604_of_id, np)-data;
^
drivers/media/i2c/adv7604.c:2671:48: error: request for member ‘data’ in
something not a structure or union
make[3]: *** [drivers/media/i2c/adv7604.o] Error 1
That looks like a bug in the stubbed out version of of_match_node(). It
should be a inline function with a return type, rather than a macro.
- Lars
--
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
Re: [PATCH 35/47] adv7604: Add sink pads
Hi Hans,
On Tuesday 11 February 2014 13:07:51 Hans Verkuil wrote:
On 02/11/14 13:00, Laurent Pinchart wrote:
On Tuesday 11 February 2014 11:19:32 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
The ADV7604 has sink pads for its HDMI and analog inputs. Report them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 71 --
include/media/adv7604.h | 14 -
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 05e7e1a..da32ce9 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -97,13 +97,25 @@ struct adv7604_chip_info {
**
*/
+enum adv7604_pad {
+ ADV7604_PAD_HDMI_PORT_A = 0,
+ ADV7604_PAD_HDMI_PORT_B = 1,
+ ADV7604_PAD_HDMI_PORT_C = 2,
+ ADV7604_PAD_HDMI_PORT_D = 3,
+ ADV7604_PAD_VGA_RGB = 4,
+ ADV7604_PAD_VGA_COMP = 5,
+ /* The source pad is either 1 (ADV7611) or 6 (ADV7604) */
How about making this explicit:
ADV7604_PAD_SOURCE = 6,
ADV7611_PAD_SOURCE = 1,
I can do that, but those two constants won't be used in the driver as they
computed dynamically.
+ ADV7604_PAD_MAX = 7,
+};
Wouldn't it make more sense to have this in the header? I would really
like to use the symbolic names for these pads in my bridge driver.
That would add a dependency on the adv7604 driver to the bridge driver,
isn't the whole point of subdevs to avoid such dependencies ?
The bridge driver has to know about the adv7604, not the other way around.
E.g. in my bridge driver I have to match v4l2 inputs to pads, both for
S_EDID and for s_routing, so it needs to know which pad number to use.
Is that information that you want to pass to the bridge driver through
platform data, or do you want to hardcode it in the bridge driver itself ? In
the latter case the bridge driver would become specific to the adv7604. It
might be fine in your case if your bridge is specific to your board anyway
(FPGAs come to mind), but it lacks genericity.
Also, for calling set_fmt, BTW. There I need to specify the source pad,
which is also why I would like to have a symbolic name for it as suggested
above.
--
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 35/47] adv7604: Add sink pads
On 02/11/14 13:23, Laurent Pinchart wrote:
Hi Hans,
On Tuesday 11 February 2014 13:07:51 Hans Verkuil wrote:
On 02/11/14 13:00, Laurent Pinchart wrote:
On Tuesday 11 February 2014 11:19:32 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
The ADV7604 has sink pads for its HDMI and analog inputs. Report them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 71 --
include/media/adv7604.h | 14 -
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 05e7e1a..da32ce9 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -97,13 +97,25 @@ struct adv7604_chip_info {
**
*/
+enum adv7604_pad {
+ ADV7604_PAD_HDMI_PORT_A = 0,
+ ADV7604_PAD_HDMI_PORT_B = 1,
+ ADV7604_PAD_HDMI_PORT_C = 2,
+ ADV7604_PAD_HDMI_PORT_D = 3,
+ ADV7604_PAD_VGA_RGB = 4,
+ ADV7604_PAD_VGA_COMP = 5,
+ /* The source pad is either 1 (ADV7611) or 6 (ADV7604) */
How about making this explicit:
ADV7604_PAD_SOURCE = 6,
ADV7611_PAD_SOURCE = 1,
I can do that, but those two constants won't be used in the driver as they
computed dynamically.
+ ADV7604_PAD_MAX = 7,
+};
Wouldn't it make more sense to have this in the header? I would really
like to use the symbolic names for these pads in my bridge driver.
That would add a dependency on the adv7604 driver to the bridge driver,
isn't the whole point of subdevs to avoid such dependencies ?
The bridge driver has to know about the adv7604, not the other way around.
E.g. in my bridge driver I have to match v4l2 inputs to pads, both for
S_EDID and for s_routing, so it needs to know which pad number to use.
Is that information that you want to pass to the bridge driver through
platform data, or do you want to hardcode it in the bridge driver itself ? In
the latter case the bridge driver would become specific to the adv7604. It
might be fine in your case if your bridge is specific to your board anyway
(FPGAs come to mind), but it lacks genericity.
Hardcoded. It's just like any PCI driver: the PCI ID determines what the
board is and based on that you set everything up. And if there are multiple
variations of the board you use card structures to define such things.
The only place where you can put that information is in the bridge driver.
Regards,
Hans
Also, for calling set_fmt, BTW. There I need to specify the source pad,
which is also why I would like to have a symbolic name for it as suggested
above.
--
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 45/47] adv7604: Add DT support
Hi Lars,
On Tuesday 11 February 2014 13:21:56 Lars-Peter Clausen wrote:
On 02/11/2014 01:14 PM, Hans Verkuil wrote:
On 02/11/14 13:08, Laurent Pinchart wrote:
On Tuesday 11 February 2014 10:23:03 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
Parse the device tree node to populate platform data.
Cc: devicet...@vger.kernel.org
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../devicetree/bindings/media/i2c/adv7604.txt | 56
drivers/media/i2c/adv7604.c| 101 ++--
2 files changed, 143 insertions(+), 14 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/i2c/adv7604.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt new file mode
100644
index 000..0845c50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -0,0 +1,56 @@
+* Analog Devices ADV7604/11 video decoder with HDMI receiver
+
+The ADV7604 and ADV7611 are multiformat video decoders with an
integrated
HDMI +receiver. The ADV7604 has four multiplexed HDMI inputs and one
analog input, +and the ADV7611 has one HDMI input and no analog input.
+
+Required Properties:
+
+ - compatible: Must contain one of the following
+- adi,adv7604 for the ADV7604
+- adi,adv7611 for the ADV7611
+
+ - reg: I2C slave address
+
+ - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
+detection pins, one per HDMI input. The active flag indicates the
GPIO
+level that enables hot-plug detection.
+
+Optional Properties:
+
+ - reset-gpios: Reference to the GPIO connected to the device's reset
pin. +
+ - adi,default-input: Index of the input to be configured as default.
Valid +values are 0..5 for the ADV7604 and 0 for the ADV7611.
+
+ - adi,disable-power-down: Boolean property. When set forces the
device
to +ignore the power-down pin. The property is valid for the
ADV7604
only as +the ADV7611 has no power-down pin.
+
+ - adi,disable-cable-reset: Boolean property. When set disables the
HDMI
+receiver automatic reset when the HDMI cable is unplugged.
+
+Example:
+
+hdmi_receiver@4c {
+compatible = adi,adv7611;
+reg = 0x4c;
+
+reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
+hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
+
+adi,default-input = 0;
+
+#address-cells = 1;
+#size-cells = 0;
+
+port@0 {
+reg = 0;
+};
+port@1 {
+reg = 1;
+hdmi_in: endpoint {
+remote-endpoint = ccdc_in;
+};
+};
+};
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e586c1c..cd8a2dc 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -32,6 +32,7 @@
#include linux/i2c.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/slab.h
#include linux/v4l2-dv-timings.h
#include linux/videodev2.h
@@ -2641,13 +2642,83 @@ static const struct adv7604_chip_info
adv7604_chip_info[] = {
},
};
+static struct i2c_device_id adv7604_i2c_id[] = {
+{ adv7604, (kernel_ulong_t)adv7604_chip_info[ADV7604] },
+{ adv7611, (kernel_ulong_t)adv7604_chip_info[ADV7611] },
+{ }
+};
+MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
+
+static struct of_device_id adv7604_of_id[] = {
+{ .compatible = adi,adv7604, .data =
adv7604_chip_info[ADV7604] },
+{ .compatible = adi,adv7611, .data =
adv7604_chip_info[ADV7611] },
+{ }
+};
+MODULE_DEVICE_TABLE(of, adv7604_of_id);
+
+static int adv7604_parse_dt(struct adv7604_state *state)
Put this under #ifdef CONFIG_OF.
#ifdef CONFIG_OF has been discouraged. I'll add an IS_ENABLED(CONFIG_OF)
to condition the call of adv7604_parse_dt() and let the compiler optimize
the function out, but I've been recommended to fix compilation errors
instead of using conditional compilation.
It fails to compile if CONFIG_OF is not set (as it is in my case since
this driver is used with a PCIe card).
What's the compilation failure ?
drivers/media/i2c/adv7604.c: In function ‘adv7604_parse_dt’:
drivers/media/i2c/adv7604.c:2671:48: warning: dereferencing ‘void *’
pointer [enabled by default]
state-info = of_match_node(adv7604_of_id, np)-data;
drivers/media/i2c/adv7604.c:2671:48: error: request for member ‘data’ in
something not a structure or union make[3]: ***
[drivers/media/i2c/adv7604.o] Error 1
Re: [PATCH 35/47] adv7604: Add sink pads
Hi Hans,
On Tuesday 11 February 2014 13:24:03 Hans Verkuil wrote:
On 02/11/14 13:23, Laurent Pinchart wrote:
On Tuesday 11 February 2014 13:07:51 Hans Verkuil wrote:
On 02/11/14 13:00, Laurent Pinchart wrote:
On Tuesday 11 February 2014 11:19:32 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
The ADV7604 has sink pads for its HDMI and analog inputs. Report them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 71 ++-
include/media/adv7604.h | 14 -
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 05e7e1a..da32ce9 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -97,13 +97,25 @@ struct adv7604_chip_info {
*/
+enum adv7604_pad {
+ ADV7604_PAD_HDMI_PORT_A = 0,
+ ADV7604_PAD_HDMI_PORT_B = 1,
+ ADV7604_PAD_HDMI_PORT_C = 2,
+ ADV7604_PAD_HDMI_PORT_D = 3,
+ ADV7604_PAD_VGA_RGB = 4,
+ ADV7604_PAD_VGA_COMP = 5,
+ /* The source pad is either 1 (ADV7611) or 6 (ADV7604) */
How about making this explicit:
ADV7604_PAD_SOURCE = 6,
ADV7611_PAD_SOURCE = 1,
I can do that, but those two constants won't be used in the driver as
they
computed dynamically.
+ ADV7604_PAD_MAX = 7,
+};
Wouldn't it make more sense to have this in the header? I would really
like to use the symbolic names for these pads in my bridge driver.
That would add a dependency on the adv7604 driver to the bridge driver,
isn't the whole point of subdevs to avoid such dependencies ?
The bridge driver has to know about the adv7604, not the other way
around.
E.g. in my bridge driver I have to match v4l2 inputs to pads, both for
S_EDID and for s_routing, so it needs to know which pad number to use.
Is that information that you want to pass to the bridge driver through
platform data, or do you want to hardcode it in the bridge driver itself ?
In the latter case the bridge driver would become specific to the
adv7604. It might be fine in your case if your bridge is specific to your
board anyway (FPGAs come to mind), but it lacks genericity.
Hardcoded. It's just like any PCI driver: the PCI ID determines what the
board is and based on that you set everything up. And if there are multiple
variations of the board you use card structures to define such things.
The only place where you can put that information is in the bridge driver.
Or in DT I suppose ;-) It could be argued that the bridge driver could/should
discover pad numbers somehow dynamically, but there's no harm in moving the
enum to the header, so I'll do that.
Also, for calling set_fmt, BTW. There I need to specify the source pad,
which is also why I would like to have a symbolic name for it as
suggested
above.
--
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 35/47] adv7604: Add sink pads
On 02/11/14 13:32, Laurent Pinchart wrote:
Hi Hans,
On Tuesday 11 February 2014 13:24:03 Hans Verkuil wrote:
On 02/11/14 13:23, Laurent Pinchart wrote:
On Tuesday 11 February 2014 13:07:51 Hans Verkuil wrote:
On 02/11/14 13:00, Laurent Pinchart wrote:
On Tuesday 11 February 2014 11:19:32 Hans Verkuil wrote:
On 02/05/14 17:42, Laurent Pinchart wrote:
The ADV7604 has sink pads for its HDMI and analog inputs. Report them.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/i2c/adv7604.c | 71 ++-
include/media/adv7604.h | 14 -
2 files changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 05e7e1a..da32ce9 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -97,13 +97,25 @@ struct adv7604_chip_info {
*/
+enum adv7604_pad {
+ ADV7604_PAD_HDMI_PORT_A = 0,
+ ADV7604_PAD_HDMI_PORT_B = 1,
+ ADV7604_PAD_HDMI_PORT_C = 2,
+ ADV7604_PAD_HDMI_PORT_D = 3,
+ ADV7604_PAD_VGA_RGB = 4,
+ ADV7604_PAD_VGA_COMP = 5,
+ /* The source pad is either 1 (ADV7611) or 6 (ADV7604) */
How about making this explicit:
ADV7604_PAD_SOURCE = 6,
ADV7611_PAD_SOURCE = 1,
I can do that, but those two constants won't be used in the driver as
they
computed dynamically.
+ ADV7604_PAD_MAX = 7,
+};
Wouldn't it make more sense to have this in the header? I would really
like to use the symbolic names for these pads in my bridge driver.
That would add a dependency on the adv7604 driver to the bridge driver,
isn't the whole point of subdevs to avoid such dependencies ?
The bridge driver has to know about the adv7604, not the other way
around.
E.g. in my bridge driver I have to match v4l2 inputs to pads, both for
S_EDID and for s_routing, so it needs to know which pad number to use.
Is that information that you want to pass to the bridge driver through
platform data, or do you want to hardcode it in the bridge driver itself ?
In the latter case the bridge driver would become specific to the
adv7604. It might be fine in your case if your bridge is specific to your
board anyway (FPGAs come to mind), but it lacks genericity.
Hardcoded. It's just like any PCI driver: the PCI ID determines what the
board is and based on that you set everything up. And if there are multiple
variations of the board you use card structures to define such things.
The only place where you can put that information is in the bridge driver.
Or in DT I suppose ;-)
Well, there is no DT. So there's that.
It could be argued that the bridge driver could/should
discover pad numbers somehow dynamically, but there's no harm in moving the
enum to the header, so I'll do that.
Thanks.
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag
Hi Paul, Thank you for the patch. On Tuesday 11 February 2014 12:17:01 Paul Bolle wrote: Commit d632dfefd36f ([media] v4l: omap4iss: Add support for OMAP4 camera interface - Build system) added a Kconfig entry for VIDEO_OMAP4_DEBUG. But nothing uses that symbol. This entry was apparently copied from a similar entry for OMAP 3 Camera debug messages. The OMAP 3 entry is used to set the DEBUG compiler flag, which enables calls of dev_dbg(). So add a Makefile line to do that for omap4iss too. Signed-off-by: Paul Bolle pebo...@tiscali.nl Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and applied to my tree. --- 0) v1 was called [media] v4l: omap4iss: Remove VIDEO_OMAP4_DEBUG. This versions implements Laurent's alternative (which is much better). Thanks :-) 1) Still untested. drivers/staging/media/omap4iss/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/media/omap4iss/Makefile b/drivers/staging/media/omap4iss/Makefile index a716ce9..f46c6bd 100644 --- a/drivers/staging/media/omap4iss/Makefile +++ b/drivers/staging/media/omap4iss/Makefile @@ -1,5 +1,7 @@ # Makefile for OMAP4 ISS driver +ccflags-$(CONFIG_VIDEO_OMAP4_DEBUG) += -DDEBUG + omap4-iss-objs += \ iss.o iss_csi2.o iss_csiphy.o iss_ipipeif.o iss_ipipe.o iss_resizer.o iss_video.o -- 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: [kconfig] update: results of some syntactical checks
Mauro, On Sat, 2013-11-02 at 17:40 -0200, Mauro Carvalho Chehab wrote: Em Sat, 02 Nov 2013 20:20:54 +0100 Paul Bolle pebo...@tiscali.nl escreveu: On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote: drivers/media/common/siano/Kconfig:21-26 config SMS_SIANO_DEBUGFS bool Enable debugfs for smsdvb depends on SMS_SIANO_MDTV depends on DEBUG_FS depends on SMS_USB_DRV depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV The last line adds the dependency CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV. This expression does not look sound as those two symbols are not declared anywhere. So, the two strings CONFIG_SMS_USB_DRV and CONFIG_SMS_SDIO_DRV are compared, yielding always 'n'. As a result, SMS_SIANO_DEBUGFS will never be enabled. [...] The Kconfig logic here is that it should depends on !SMS_SDIO_DRV or SMS_USB_DRV = SMS_SDIO_DRV. I remember I made a patch like that while testing some things with this driver, but it seems that I forgot to push. I might have it somewhere on my test machine. This line is still present in v3.14-rc2. Did you ever find that patch on your test machine? Paul Bolle -- 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: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)
On Wed, Feb 05, 2014 at 01:16:53PM +, Robert Longbottom wrote:
On 28 Jan 2014, at 02:02 AM, Daniel Glöckner daniel...@gmx.net wrote:
When we cycle through all combinations in one minute, there are about
a hundred PCI cycles per combination left for the chip to be granted
access to the bus. I expect most of the pins to provide a priority
or weighting value for each BT878A, so there should be many combinations
that do something.
How difficult is it for me to do this? And is it obvious when it works?
I have an old pc that I can put the card in that doesn't matter. And given
I can't get the card to work in windows or Linux its not much use to me as
it is, so if it breaks then so be it.
I've not done any Linux driver development, but I'm happy enough compiling
stuff for the most part.
Try the attached program. It must be linked with -lrt. It will set all 24
GPIOs of that one chip to output. The output file contains one nibble
per GPIO combination with each bit representing one of the BT878.
In my tests with a single BT878 the 10us delay sometimes was not enough
for the RISC PC to advance. It should be enough to recognize a pattern,
though.
Daniel
DMA from userspace... I feel dirty...
#include unistd.h
#include fcntl.h
#include sys/mman.h
#include stdlib.h
#include stdio.h
#include stdint.h
#include signal.h
#include time.h
#include sched.h
#include string.h
#include limits.h
#include dirent.h
#ifndef MAP_32BIT
#if defined(__x86_64__) || defined(__i386__)
#define MAP_32BIT 0x40
#else
#define MAP_32BIT 0
#endif
#endif
#define BT848_RISC_JUMP (0x07 28)
static char path[PATH_MAX] = /sys/bus/pci/devices/, *fname;
static long get_attr(const char *attr)
{
char name[80], buf[20] = {0};
int fd;
strcpy(fname, attr);
fd = open(path, O_RDONLY);
if (fd == -1) {
perror(open);
return -1;
}
read(fd, buf, sizeof(buf) - 1);
close(fd);
return strtol(buf, NULL, 0);
}
static int find_card(void)
{
int i = strlen(path), j, n = 0;
DIR *d = opendir(path), *d2;
struct dirent *e;
char *busdev, lastgood[PATH_MAX];
if (!d)
return 0;
while ((e = readdir(d))) {
if (e-d_name[0] == '.')
continue;
strcpy(path + i, e-d_name);
strcat(path, /);
fname = path + strlen(path);
if (get_attr(vendor) != 0x3388)
continue;
if (get_attr(device) != 0x0021)
continue;
strcpy(fname, pci_bus);
d2 = opendir(path);
if (!d2)
continue;
while (e = readdir(d2)) {
if (e-d_name[0] == '.')
continue;
strcpy(path + i, e-d_name);
break;
}
closedir(d2);
if (!e)
continue;
fname = path + strlen(path) + 6;
for (j = 0xC; j = 0xF; j++) {
sprintf(fname - 6, :%02x.0/, j);
if (access(path, F_OK))
break;
if (get_attr(vendor) != 0x109e)
break;
if (get_attr(device) != 0x036e)
break;
}
if (j 0x10)
continue;
fname[0] = 0;
strcpy(lastgood, path);
n++;
}
closedir(d);
if (!n)
fputs(card not found\n, stderr);
else if (n 1)
fputs(multiple cards found, can't decide which to test\n,
stderr);
else {
strcpy(path, lastgood);
fname = path + strlen(path);
strcpy(fname, resource0);
fname -= 4;
}
return n == 1;
}
static void *get_page(uint32_t *phys)
{
long l = sysconf(_SC_PAGESIZE);
void *m;
int fd;
uintptr_t v;
uint64_t p;
m = mmap(NULL, l, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT|MAP_LOCKED, -1, 0);
if (m == MAP_FAILED)
return NULL;
v = (uintptr_t)m;
if (v % l)
return NULL;
v /= l;
fd = open(/proc/self/pagemap, O_RDONLY);
if (fd == -1)
return NULL;
if (pread(fd, p, sizeof(p), v * sizeof(p)) != sizeof(p))
return NULL;
close(fd);
if ((p 62) != 2)
return NULL;
p = (p ((1LL 55) - 1)) ((p 55) 0x3f);
if (p 32)
return NULL;
*phys = p;
return m;
}
static unsigned int loops;
static void
Re: Upstreaming SAA716x driver to the media_tree
Hi, Any update on this? Thanks, Luis On Wed, Jan 22, 2014 at 3:26 PM, Manu Abraham abraham.m...@gmail.com wrote: On Wed, Jan 22, 2014 at 3:29 AM, Steven Toth st...@kernellabs.com wrote: On Mon, Jan 13, 2014 at 10:35 PM, Manu Abraham abraham.m...@gmail.com wrote: On Tue, Jan 14, 2014 at 12:20 AM, Steven Toth st...@kernellabs.com wrote: Manu, do you see any inconvenience in sending your driver to the linux_media tree? I'm available to place some effort on this task. I can push the 716x driver and whatever additional changes that I have later on this weekend, if that's okay with you. I never saw a push. Spliiting and cleaning up the patches took up more time than expected. Please wait a few days. Any news on this? I just pushed out a large chunk of the changes. There are a few dependencies that need to be resolved with the rebased tree. -- 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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel p.za...@pengutronix.de wrote:
From: Philipp Zabel philipp.za...@gmail.com
This patch moves the parsing helpers used to parse connected graphs
in the device tree, like the video interface bindings documented in
Documentation/devicetree/bindings/media/video-interfaces.txt, from
drivers/media/v4l2-core to drivers/of.
This is the opposite direction things have been moving...
This allows to reuse the same parser code from outside the V4L2 framework,
most importantly from display drivers. There have been patches that duplicate
the code (and I am going to send one of my own), such as
http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
and others that parse the same binding in a different way:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
I think that all common video interface parsing helpers should be moved to a
single place, outside of the specific subsystems, so that it can be reused
by all drivers.
Perhaps that should be done rather than moving to drivers/of now and
then again to somewhere else.
I moved v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
and v4l2_of_get_remote_port_parent. They are renamed to
of_graph_get_next_endpoint, of_graph_get_remote_port, and
of_graph_get_remote_port_parent, respectively.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/Kconfig | 1 +
drivers/media/v4l2-core/v4l2-of.c | 117 -
drivers/of/Kconfig| 3 +
drivers/of/Makefile | 1 +
drivers/of/of_graph.c | 133
++
include/linux/of_graph.h | 23 +++
include/media/v4l2-of.h | 16 ++---
7 files changed, 167 insertions(+), 127 deletions(-)
create mode 100644 drivers/of/of_graph.c
create mode 100644 include/linux/of_graph.h
[snip]
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 541cea4..404a493 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -17,6 +17,7 @@
#include linux/list.h
#include linux/types.h
#include linux/errno.h
+#include linux/of_graph.h
#include media/v4l2-mediabus.h
@@ -72,11 +73,6 @@ struct v4l2_of_endpoint {
#ifdef CONFIG_OF
int v4l2_of_parse_endpoint(const struct device_node *node,
struct v4l2_of_endpoint *endpoint);
-struct device_node *v4l2_of_get_next_endpoint(const struct device_node
*parent,
- struct device_node *previous);
-struct device_node *v4l2_of_get_remote_port_parent(
- const struct device_node *node);
-struct device_node *v4l2_of_get_remote_port(const struct device_node *node);
#else /* CONFIG_OF */
static inline int v4l2_of_parse_endpoint(const struct device_node *node,
@@ -85,25 +81,25 @@ static inline int v4l2_of_parse_endpoint(const struct
device_node *node,
return -ENOSYS;
}
+#endif /* CONFIG_OF */
+
static inline struct device_node *v4l2_of_get_next_endpoint(
const struct device_node *parent,
struct device_node *previous)
{
- return NULL;
+ return of_graph_get_next_endpoint(parent, previous);
Won't this break for !OF?
Rob
--
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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote: On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel p.za...@pengutronix.de wrote: This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. There have been patches that duplicate the code (and I am going to send one of my own), such as http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html and others that parse the same binding in a different way: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html I think that all common video interface parsing helpers should be moved to a single place, outside of the specific subsystems, so that it can be reused by all drivers. Perhaps that should be done rather than moving to drivers/of now and then again to somewhere else. Do you have a better suggestion where it should move to? drivers/gpu/drm - no, because v4l2 wants to use it drivers/media/video - no, because DRM drivers want to use it drivers/video - no, because v4l2 and drm drivers want to use it Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it into drivers/of ? -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- 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
OMAP3 ISP capabilities
Hello Laurent, some quick question about the OMAP3 ISP pipeline capabilities: (1) can the OMAP3 ISP CCDC output concurrently to memory AND the resizer in YUV mode? I think the answer is no due to hardware limitation (2) in RAW mode, I think it should be possible to connect pad 1 of the OMAP3 ISP CCDC to CCDC output and pad 2 to the ISP preview and subsequently to the resizer? so two stream can be read concurrently from video2 and video6? (3) it should be possible to use the ISP resizer input / output (memory-to-memory) independently; it there any example code doing this? thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) -- 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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Hi Russell, On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote: On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote: On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote: This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. There have been patches that duplicate the code (and I am going to send one of my own), such as http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html and others that parse the same binding in a different way: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html I think that all common video interface parsing helpers should be moved to a single place, outside of the specific subsystems, so that it can be reused by all drivers. Perhaps that should be done rather than moving to drivers/of now and then again to somewhere else. Do you have a better suggestion where it should move to? drivers/gpu/drm - no, because v4l2 wants to use it drivers/media/video - no, because DRM drivers want to use it drivers/video - no, because v4l2 and drm drivers want to use it Just pointing out a missing location (which might be rejected due to similar concerns), there's also drivers/media, which isn't V4L-specific. Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it into drivers/of ? -- 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: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Hi Rob,
Am Dienstag, den 11.02.2014, 07:56 -0600 schrieb Rob Herring:
On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel p.za...@pengutronix.de wrote:
From: Philipp Zabel philipp.za...@gmail.com
This patch moves the parsing helpers used to parse connected graphs
in the device tree, like the video interface bindings documented in
Documentation/devicetree/bindings/media/video-interfaces.txt, from
drivers/media/v4l2-core to drivers/of.
This is the opposite direction things have been moving...
I understand subsystem specific functionality is moving from drivers/of
into the subsystems. In this case three subsystems all could benefit
from the same set of parsing functions, so it is not clear to me where
if not drivers/of would be the correct place for this code.
This allows to reuse the same parser code from outside the V4L2 framework,
most importantly from display drivers. There have been patches that
duplicate
the code (and I am going to send one of my own), such as
http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
and others that parse the same binding in a different way:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
I think that all common video interface parsing helpers should be moved to a
single place, outside of the specific subsystems, so that it can be reused
by all drivers.
Perhaps that should be done rather than moving to drivers/of now and
then again to somewhere else.
I moved v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
and v4l2_of_get_remote_port_parent. They are renamed to
of_graph_get_next_endpoint, of_graph_get_remote_port, and
of_graph_get_remote_port_parent, respectively.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/Kconfig | 1 +
drivers/media/v4l2-core/v4l2-of.c | 117 -
drivers/of/Kconfig| 3 +
drivers/of/Makefile | 1 +
drivers/of/of_graph.c | 133
++
include/linux/of_graph.h | 23 +++
include/media/v4l2-of.h | 16 ++---
7 files changed, 167 insertions(+), 127 deletions(-)
create mode 100644 drivers/of/of_graph.c
create mode 100644 include/linux/of_graph.h
[snip]
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 541cea4..404a493 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -17,6 +17,7 @@
#include linux/list.h
#include linux/types.h
#include linux/errno.h
+#include linux/of_graph.h
#include media/v4l2-mediabus.h
@@ -72,11 +73,6 @@ struct v4l2_of_endpoint {
#ifdef CONFIG_OF
int v4l2_of_parse_endpoint(const struct device_node *node,
struct v4l2_of_endpoint *endpoint);
-struct device_node *v4l2_of_get_next_endpoint(const struct device_node
*parent,
- struct device_node *previous);
-struct device_node *v4l2_of_get_remote_port_parent(
- const struct device_node *node);
-struct device_node *v4l2_of_get_remote_port(const struct device_node
*node);
#else /* CONFIG_OF */
static inline int v4l2_of_parse_endpoint(const struct device_node *node,
@@ -85,25 +81,25 @@ static inline int v4l2_of_parse_endpoint(const struct
device_node *node,
return -ENOSYS;
}
+#endif /* CONFIG_OF */
+
static inline struct device_node *v4l2_of_get_next_endpoint(
const struct device_node *parent,
struct device_node *previous)
{
- return NULL;
+ return of_graph_get_next_endpoint(parent, previous);
Won't this break for !OF?
It will. The of_graph_* functions should get their own stubs for that
case.
regards
Philipp
--
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
OMAP3 ISP capabilities (fwd)
Hello, trying (3) below and hitting [ 6241.536071] WARNING: at drivers/media/v4l2-core/v4l2-subdev.c:424 v4l2_subdev_link_validate_get_format+0x90/0xa8() [ 6241.573150] Driver bug! Wrong media entity type 65536, entity OMAP3 ISP resizer input [ 6241.595153] [c0011cdc] (unwind_backtrace+0x0/0xe0) from [c002ed28] (warn_slowpath_common+0x4c/0x64) [ 6241.605651] [c002ed28] (warn_slowpath_common+0x4c/0x64) from [c002edc0] (warn_slowpath_fmt+0x2c/0x3c) [ 6241.615997] [c002edc0] (warn_slowpath_fmt+0x2c/0x3c) from [c027e2e4] (v4l2_subdev_link_validate_get_format+0x90/0xa8) [ 6241.632751] [c027e2e4] (v4l2_subdev_link_validate_get_format+0x90/0xa8) from [c027e314] (v4l2_subdev_link_validate+0x18) [ 6241.645324] [c027e314] (v4l2_subdev_link_validate+0x18/0xac) from [c0272954] (media_entity_pipeline_start+0xc8/0x170) [ 6241.657012] [c0272954] (media_entity_pipeline_start+0xc8/0x170) from [c0285820] (isp_video_streamon+0xa4/0x314) [ 6241.672027] [c0285820] (isp_video_streamon+0xa4/0x314) from [c02748ec] (v4l_streamon+0x18/0x1c) [ 6241.681884] [c02748ec] (v4l_streamon+0x18/0x1c) from [c02779c0] (__video_do_ioctl+0x1c4/0x2e4) [ 6241.691558] [c02779c0] (__video_do_ioctl+0x1c4/0x2e4) from [c0277d84] (video_usercopy+0x2a4/0x3e0) [ 6241.701507] [c0277d84] (video_usercopy+0x2a4/0x3e0) from [c02730e0] (v4l2_ioctl+0x6c/0x110) [ 6241.715240] [c02730e0] (v4l2_ioctl+0x6c/0x110) from [c00c36ec] (do_vfs_ioctl+0x548/0x5b8) [ 6241.724792] [c00c36ec] (do_vfs_ioctl+0x548/0x5b8) from [c00c3794] (sys_ioctl+0x38/0x54) [ 6241.733795] [c00c3794] (sys_ioctl+0x38/0x54) from [c000d420] (ret_fast_syscall+0x0/0x30) [ 6241.743438] ---[ end trace 3ce601d6bddf2d7e ]--- pipeline is media-ctl -r media-ctl -l 'OMAP3 ISP resizer input:0-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -V 'OMAP3 ISP resizer:0 [YUYV2X8 640x480]' media-ctl -V 'OMAP3 ISP resizer:1 [YUYV2X8 320x240]' I'm opening /dev/video5 and /dev/video6, do S_FMT on both as VIDEO_OUTPUT and VIDEO_CAPTURE, respectively, configure buffers and then STREAMON -- bang! regards, p. -- Peter Meerwald +43-664-218 (mobile) -- Forwarded message -- Date: Tue, 11 Feb 2014 15:54:00 +0100 (CET) From: Peter Meerwald pme...@pmeerw.net To: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: linux-media@vger.kernel.org, linux-o...@vger.kernel.org Subject: OMAP3 ISP capabilities Hello Laurent, some quick question about the OMAP3 ISP pipeline capabilities: (1) can the OMAP3 ISP CCDC output concurrently to memory AND the resizer in YUV mode? I think the answer is no due to hardware limitation (2) in RAW mode, I think it should be possible to connect pad 1 of the OMAP3 ISP CCDC to CCDC output and pad 2 to the ISP preview and subsequently to the resizer? so two stream can be read concurrently from video2 and video6? (3) it should be possible to use the ISP resizer input / output (memory-to-memory) independently; it there any example code doing this? thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) -- 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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Am Dienstag, den 11.02.2014, 16:23 +0100 schrieb Laurent Pinchart: Hi Russell, On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote: On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote: On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote: This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. There have been patches that duplicate the code (and I am going to send one of my own), such as http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html and others that parse the same binding in a different way: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html I think that all common video interface parsing helpers should be moved to a single place, outside of the specific subsystems, so that it can be reused by all drivers. Perhaps that should be done rather than moving to drivers/of now and then again to somewhere else. Do you have a better suggestion where it should move to? drivers/gpu/drm - no, because v4l2 wants to use it drivers/media/video - no, because DRM drivers want to use it drivers/video - no, because v4l2 and drm drivers want to use it Just pointing out a missing location (which might be rejected due to similar concerns), there's also drivers/media, which isn't V4L-specific. Since drivers/Makefile has media/ in obj-y, moving the graph helpers to drivers/media should technically work. Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it into drivers/of ? include/media/of_graph.h, drivers/media/of_graph.c? regards Philipp -- 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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Tue, Feb 11, 2014 at 8:52 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote: On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel p.za...@pengutronix.de wrote: This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. There have been patches that duplicate the code (and I am going to send one of my own), such as http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html and others that parse the same binding in a different way: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html I think that all common video interface parsing helpers should be moved to a single place, outside of the specific subsystems, so that it can be reused by all drivers. Perhaps that should be done rather than moving to drivers/of now and then again to somewhere else. Do you have a better suggestion where it should move to? No. drivers/gpu/drm - no, because v4l2 wants to use it drivers/media/video - no, because DRM drivers want to use it drivers/video - no, because v4l2 and drm drivers want to use it I don't believe it exists currently, so it would need to be created. Perhaps adding a layer of directory to combine these. This patch alone is not enough to really justify that, but if there's a lot more shared code possible then it would be the right direction. Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it into drivers/of ? I assume you weren't serious, but no for /of-graph. If a better place can't be found/made, I'll take it. Rob -- 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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
(adding Guennadi to Cc)
On 11/02/14 17:36, Philipp Zabel wrote:
Am Dienstag, den 11.02.2014, 16:23 +0100 schrieb Laurent Pinchart:
Hi Russell,
On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote:
On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote:
On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote:
This allows to reuse the same parser code from outside the V4L2
framework, most importantly from display drivers. There have been
patches that duplicate the code (and I am going to send one of my own),
such as
http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
and others that parse the same binding in a different way:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
I think that all common video interface parsing helpers should be moved
to a single place, outside of the specific subsystems, so that it can
be reused by all drivers.
Perhaps that should be done rather than moving to drivers/of now and
then again to somewhere else.
Do you have a better suggestion where it should move to?
drivers/gpu/drm - no, because v4l2 wants to use it
drivers/media/video - no, because DRM drivers want to use it
drivers/video - no, because v4l2 and drm drivers want to use it
Just pointing out a missing location (which might be rejected due to similar
concerns), there's also drivers/media, which isn't V4L-specific.
Since drivers/Makefile has media/ in obj-y, moving the graph helpers to
drivers/media should technically work.
Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it
into drivers/of ?
include/media/of_graph.h,
drivers/media/of_graph.c?
drivers/media sounds like a good alternative to me.
I would just remove also v4l2_of_{parse/get}* and update the users
to call of_graph_* directly, there should not be many of them.
--
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: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Hi Philipp, On Tuesday 11 February 2014 17:36:57 Philipp Zabel wrote: Am Dienstag, den 11.02.2014, 16:23 +0100 schrieb Laurent Pinchart: On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote: On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote: On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote: This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. There have been patches that duplicate the code (and I am going to send one of my own), such as http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.h tml and others that parse the same binding in a different way: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.ht ml I think that all common video interface parsing helpers should be moved to a single place, outside of the specific subsystems, so that it can be reused by all drivers. Perhaps that should be done rather than moving to drivers/of now and then again to somewhere else. Do you have a better suggestion where it should move to? drivers/gpu/drm - no, because v4l2 wants to use it drivers/media/video - no, because DRM drivers want to use it drivers/video - no, because v4l2 and drm drivers want to use it Just pointing out a missing location (which might be rejected due to similar concerns), there's also drivers/media, which isn't V4L-specific. Since drivers/Makefile has media/ in obj-y, moving the graph helpers to drivers/media should technically work. Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it into drivers/of ? include/media/of_graph.h, drivers/media/of_graph.c? I'm personally fine with that. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: soc-camera: support deferred probing of clients and OF cameras
On Mon, Feb 10, 2014 at 10:37 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Bryan,
On Mon, 10 Feb 2014, Bryan Wu wrote:
On Sun, Feb 9, 2014 at 2:20 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Bryan,
Thanks for reiterating this patch!
Sure, my pleasure. I basically assembled your patches together and
change them to use latest V4L2 soc_camera API.
On Fri, 7 Feb 2014, Bryan Wu wrote:
[snip]
@@ -67,6 +81,8 @@ struct soc_camera_async_client {
static int soc_camera_video_start(struct soc_camera_device *icd);
static int video_dev_create(struct soc_camera_device *icd);
+static void soc_camera_of_i2c_info(struct device_node *node,
+ struct soc_camera_of_client *sofc);
If you have to resubmit this patch, plase, make sure the second line of
the above declaration is aligned af usual - under the first character
_after_ the opening bracket.
No problem, I will update this.
Hmmm, something weird on my side. I did put the second line starting
under the first character after the opening bracket. But in git show
and git format-patch I got this
---
static int soc_camera_video_start(struct soc_camera_device *icd);
static int video_dev_create(struct soc_camera_device *icd);
+static void soc_camera_of_i2c_info(struct device_node *node,
+ struct soc_camera_of_client *sofc);
---
But I think that's what you want, right?
Don't know - now aöö TABs above are replaced with spaces, so, cannot say.
[snip]
+{
+ struct soc_camera_of_client *sofc;
+ struct soc_camera_desc *sdesc;
I'm really grateful, that you decided to use my original patch and
preserve my authorship! But then, I think, it'd be also better to avoid
unnecessary changes to it. What was wrong with allocation of *sofc in the
definition line?
Oh, this is really I want to bring up. It's a very subtle bug here.
If we use local variable sofc instead of zalloc, fields of sofc have
undetermined None NULL value.
No. If you initialise some members of a struct in its definition line, the
rest will be initialised to 0 / NULL. I.e. in
struct foo y = {.x = 1,};
all other fields of y will be initialised to 0.
I see, but original one is soc_camera_link which is simple in this
case. right now we move to soc_camera_desc. I think following line is
not very straight forward in a local function.
struct soc_camera_desc sdesc = { .host_desc = { .host_wait = true,},};
What about
a) struct soc_camera_desc sdesc and use memset to all 0.
b) use kzalloc() and kfree() in this function.
I think b) is more straight forward and easy to understand.
Thanks,
-Bryan
--
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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Em Tue, 11 Feb 2014 18:22:34 +0100
Sylwester Nawrocki s.nawro...@samsung.com escreveu:
(adding Guennadi to Cc)
On 11/02/14 17:36, Philipp Zabel wrote:
Am Dienstag, den 11.02.2014, 16:23 +0100 schrieb Laurent Pinchart:
Hi Russell,
On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote:
On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote:
On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote:
This allows to reuse the same parser code from outside the V4L2
framework, most importantly from display drivers. There have been
patches that duplicate the code (and I am going to send one of my own),
such as
http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
and others that parse the same binding in a different way:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
I think that all common video interface parsing helpers should be moved
to a single place, outside of the specific subsystems, so that it can
be reused by all drivers.
Perhaps that should be done rather than moving to drivers/of now and
then again to somewhere else.
Do you have a better suggestion where it should move to?
drivers/gpu/drm - no, because v4l2 wants to use it
drivers/media/video - no, because DRM drivers want to use it
drivers/video - no, because v4l2 and drm drivers want to use it
Just pointing out a missing location (which might be rejected due to
similar
concerns), there's also drivers/media, which isn't V4L-specific.
Since drivers/Makefile has media/ in obj-y, moving the graph helpers to
drivers/media should technically work.
Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it
into drivers/of ?
include/media/of_graph.h,
drivers/media/of_graph.c?
drivers/media sounds like a good alternative to me.
From my side, I'm ok with putting them at drivers/media. You may add my
acked-by
for such change:
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
I would just remove also v4l2_of_{parse/get}* and update the users
to call of_graph_* directly, there should not be many of them.
--
Thanks,
Sylwester
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] af9035: Add remaining it913x dual ids to af9035.
Moikka Malcolm!
Thanks for the patch serie.
You removed all IDs from it913x driver. There is possibility to just
remove / comment out:
MODULE_DEVICE_TABLE(usb, it913x_id_table);
which prevents loading that driver automatically, but leaves possibility
to load it manually if user wants to fallback. I am fine either way you
decide to do it, just a propose.
regards
Antti
On 09.02.2014 15:04, Malcolm Priestley wrote:
As follow on to patch
af9035: Move it913x single devices to af9035
and patch 1.
SNR is reported as db/10 values.
All dual ids are added to af9035 and it913x driver disabled.
it913x/it913x-fe removal patches to follow.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/usb/dvb-usb-v2/af9035.c | 8
drivers/media/usb/dvb-usb-v2/it913x.c | 5 +
2 files changed, 13 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 4f682ad..49e8360 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -1552,6 +1552,14 @@ static const struct usb_device_id af9035_id_table[] = {
af9035_props, Avermedia A835B(4835), RC_MAP_IT913X_V2) },
{ DVB_USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_H335,
af9035_props, Avermedia H335, RC_MAP_IT913X_V2) },
+ { DVB_USB_DEVICE(USB_VID_KWORLD_2, USB_PID_KWORLD_UB499_2T_T09,
+ af9035_props, Kworld UB499-2T T09, RC_MAP_IT913X_V1) },
+ { DVB_USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV22_IT9137,
+ af9035_props, Sveon STV22 Dual DVB-T HDTV,
+ RC_MAP_IT913X_V1) },
+ { DVB_USB_DEVICE(USB_VID_KWORLD_2, USB_PID_CTVDIGDUAL_V2,
+ af9035_props, Digital Dual TV Receiver CTVDIGDUAL_V2,
+ RC_MAP_IT913X_V1) },
/* XXX: that same ID [0ccd:0099] is used by af9015 driver too */
{ DVB_USB_DEVICE(USB_VID_TERRATEC, 0x0099,
af9035_props, TerraTec Cinergy T Stick Dual RC (rev. 2),
NULL) },
diff --git a/drivers/media/usb/dvb-usb-v2/it913x.c
b/drivers/media/usb/dvb-usb-v2/it913x.c
index 78bf8fd..39488f8 100644
--- a/drivers/media/usb/dvb-usb-v2/it913x.c
+++ b/drivers/media/usb/dvb-usb-v2/it913x.c
@@ -781,6 +781,8 @@ static const struct usb_device_id it913x_id_table[] = {
{} /* Terminating entry */
};
+#if 0
+
MODULE_DEVICE_TABLE(usb, it913x_id_table);
static struct usb_driver it913x_driver = {
@@ -792,8 +794,11 @@ static struct usb_driver it913x_driver = {
.id_table = it913x_id_table,
};
+
module_usb_driver(it913x_driver);
+#endif
+
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
MODULE_VERSION(1.33);
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/3] ir-rc5-sz: Add ir encoding support
On 10 February 2014 22:50, James Hogan james.ho...@imgtec.com wrote: I suspect it needs some more space at the end too, to be sure that no more bits afterwards are accepted. I'm sorry but I'm not sure I completely understood what you meant here. For RC-5-SZ the entire scancode gets encoded and nothing more. Do you mean that the encoder should append some ir silence to the end result to make sure the ir sample has ended? Yeh something like that. Certainly the raw decoders I've looked at expect a certain amount of space at the end to avoid decoding part of a longer protocol (it's in the pulse distance helper as the trailer space timing). Similarly the IMG hardware decoder has register fields for the free-time to require at the end of the message. In fact it becomes a bit awkward for the raw IR driver for the IMG hardware which uses edge interrupts, as it has to have a timeout to emit a final repeat event after 150ms of inactivity, in order for the raw decoders to accept it (unless you hold the button down in which case the repeat code edges result in the long space). Ok, I understand now. I suppose I can append some IR silence to the encoded result. The trailer space timing seems like a good way to do it. I'll create new version of my patches sometime later. Are you working on the wakeup protocol selector sysfs interface? -Antti -- 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: Upstreaming SAA716x driver to the media_tree
On Tue, Feb 11, 2014 at 7:14 PM, Luis Alves lja...@gmail.com wrote: Hi, Any update on this? I need to address the issues Mauro pointed out, prior to the merge. Will address the issues during the next week. Have been a bit busy restoring the system at my end after a crash. Regards, Manu -- 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 2/2] af9035: Add remaining it913x dual ids to af9035.
On Tue, 2014-02-11 at 19:42 +0200, Antti Palosaari wrote: Moikka Malcolm! Thanks for the patch serie. You removed all IDs from it913x driver. There is possibility to just remove / comment out: MODULE_DEVICE_TABLE(usb, it913x_id_table); which prevents loading that driver automatically, but leaves possibility to load it manually if user wants to fallback. I am fine either way you decide to do it, just a propose. Hi Antti I am going post a patches to remove it. The only reason why an user would want to fall back is the use dvb-usb-it9137-01.fw firmware with USB_VID_KWORLD_2. I left the USB_VID_KWORLD_2 ids in the driver. I haven't found any issues with dvb-usb-it9135-01.fw USB_VID_KWORLD_2 users could have trouble updating older kernels via media_build. Perhaps there should be a warning message in af9035 that users need to change firmware. Regards Malcolm -- 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 2/2] af9035: Add remaining it913x dual ids to af9035.
On 11.02.2014 22:32, Malcolm Priestley wrote: On Tue, 2014-02-11 at 19:42 +0200, Antti Palosaari wrote: Moikka Malcolm! Thanks for the patch serie. You removed all IDs from it913x driver. There is possibility to just remove / comment out: MODULE_DEVICE_TABLE(usb, it913x_id_table); which prevents loading that driver automatically, but leaves possibility to load it manually if user wants to fallback. I am fine either way you decide to do it, just a propose. Hi Antti I am going post a patches to remove it. The only reason why an user would want to fall back is the use dvb-usb-it9137-01.fw firmware with USB_VID_KWORLD_2. I left the USB_VID_KWORLD_2 ids in the driver. I haven't found any issues with dvb-usb-it9135-01.fw USB_VID_KWORLD_2 users could have trouble updating older kernels via media_build. Perhaps there should be a warning message in af9035 that users need to change firmware. Is that KẂorld device dual model (I guess yes, because of it9137)? Is it version 1 (AX) or version 2 (BX) chip? If it is dual with version 1 chips, it is similar than that: http://blog.palosaari.fi/2013/06/naked-hardware-9-terratec-cinergy-t.html I suspect firmware is same for both it9135 or it9137 and only difference between chips is pins to connect slave demodulator. Maybe difference is just firmware version and it is likely older (as I extracted one it9135 ver. 1 fw from latest windows driver). Have to check that. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH: Added device (0ccd:00b4) to DVB_USB_RTL28XXU media driver
Hi all,
I've got the following DAB USB stick that also works fine with the
DVB_USB_RTL28XXU
driver after I added its USB ID:
--- snip ---
user@box:~ lsusb -d 0ccd:00b4
Bus 001 Device 009: ID 0ccd:00b4 TerraTec Electronic GmbH
--- snap ---
I tried it on a recent openSUSE 13.1 with this kernel/architecture
--- snip ---
user@box:~ uname -a
Linux box 3.11.10-7-desktop #1 SMP PREEMPT Mon Feb 3 09:41:24 UTC 2014 (750023e)
x86_64 x86_64 x86_64 GNU/Linux
--- snap ---
The patches itself are trivial:
--- ./drivers/media/dvb-core/dvb-usb-ids.h.orig 2014-02-09 22:36:35.266625484
+0100
+++ ./drivers/media/dvb-core/dvb-usb-ids.h 2014-02-09 22:38:00.128199957
+0100
@@ -256,6 +256,7 @@
#define USB_PID_TERRATEC_T50x10a1
#define USB_PID_NOXON_DAB_STICK0x00b3
#define USB_PID_NOXON_DAB_STICK_REV2 0x00e0
+#define USB_PID_NOXON_DAB_STICK_REV3 0x00b4
#define USB_PID_PINNACLE_EXPRESSCARD_320CX 0x022e
#define USB_PID_PINNACLE_PCTV2000E 0x022c
#define USB_PID_PINNACLE_PCTV_DVB_T_FLASH 0x0228
--- ./drivers/media/usb/dvb-usb-v2/rtl28xxu.c.orig 2014-02-03
10:41:24.0
+0100
+++ ./drivers/media/usb/dvb-usb-v2/rtl28xxu.c 2014-02-09 22:37:53.464154845
+0100
@@ -1362,6 +1362,8 @@ static const struct usb_device_id rtl28x
rtl2832u_props, TerraTec NOXON DAB Stick, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV2,
rtl2832u_props, TerraTec NOXON DAB Stick (rev 2), NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV3,
+ rtl2832u_props, TerraTec NOXON DAB Stick (rev 3), NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
HTH -- Till
--
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: Added device (0ccd:00b4) to DVB_USB_RTL28XXU media driver
Moikka Till!
Thanks for the 'patch' :)
I am not sure how I should handle that as the code itself is valid, but
patch is not as it should.
If you could make a proper patch, using git commit git format-patch,
it will be nice. But as I understand it could be quite much of learning
many things, I am willing to take that and apply half manually. I still
need you signed-off-by tag as documented [1]. Please reply with
signed-off-by or even better if you could make formally correct patch.
[1] https://www.kernel.org/doc/Documentation/SubmittingPatches
regards
Antti
On 11.02.2014 22:27, Till Dörges wrote:
Hi all,
I've got the following DAB USB stick that also works fine with the
DVB_USB_RTL28XXU
driver after I added its USB ID:
--- snip ---
user@box:~ lsusb -d 0ccd:00b4
Bus 001 Device 009: ID 0ccd:00b4 TerraTec Electronic GmbH
--- snap ---
I tried it on a recent openSUSE 13.1 with this kernel/architecture
--- snip ---
user@box:~ uname -a
Linux box 3.11.10-7-desktop #1 SMP PREEMPT Mon Feb 3 09:41:24 UTC 2014 (750023e)
x86_64 x86_64 x86_64 GNU/Linux
--- snap ---
The patches itself are trivial:
--- ./drivers/media/dvb-core/dvb-usb-ids.h.orig 2014-02-09 22:36:35.266625484
+0100
+++ ./drivers/media/dvb-core/dvb-usb-ids.h 2014-02-09 22:38:00.128199957
+0100
@@ -256,6 +256,7 @@
#define USB_PID_TERRATEC_T50x10a1
#define USB_PID_NOXON_DAB_STICK0x00b3
#define USB_PID_NOXON_DAB_STICK_REV2 0x00e0
+#define USB_PID_NOXON_DAB_STICK_REV3 0x00b4
#define USB_PID_PINNACLE_EXPRESSCARD_320CX 0x022e
#define USB_PID_PINNACLE_PCTV2000E 0x022c
#define USB_PID_PINNACLE_PCTV_DVB_T_FLASH 0x0228
--- ./drivers/media/usb/dvb-usb-v2/rtl28xxu.c.orig 2014-02-03
10:41:24.0
+0100
+++ ./drivers/media/usb/dvb-usb-v2/rtl28xxu.c 2014-02-09 22:37:53.464154845
+0100
@@ -1362,6 +1362,8 @@ static const struct usb_device_id rtl28x
rtl2832u_props, TerraTec NOXON DAB Stick, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV2,
rtl2832u_props, TerraTec NOXON DAB Stick (rev 2), NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV3,
+ rtl2832u_props, TerraTec NOXON DAB Stick (rev 3), NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
HTH -- Till
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: soc-camera: support deferred probing of clients and OF cameras
On Tue, 11 Feb 2014, Bryan Wu wrote:
On Mon, Feb 10, 2014 at 10:37 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Bryan,
On Mon, 10 Feb 2014, Bryan Wu wrote:
On Sun, Feb 9, 2014 at 2:20 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Bryan,
Thanks for reiterating this patch!
Sure, my pleasure. I basically assembled your patches together and
change them to use latest V4L2 soc_camera API.
On Fri, 7 Feb 2014, Bryan Wu wrote:
[snip]
@@ -67,6 +81,8 @@ struct soc_camera_async_client {
static int soc_camera_video_start(struct soc_camera_device *icd);
static int video_dev_create(struct soc_camera_device *icd);
+static void soc_camera_of_i2c_info(struct device_node *node,
+ struct soc_camera_of_client *sofc);
If you have to resubmit this patch, plase, make sure the second line of
the above declaration is aligned af usual - under the first character
_after_ the opening bracket.
No problem, I will update this.
Hmmm, something weird on my side. I did put the second line starting
under the first character after the opening bracket. But in git show
and git format-patch I got this
---
static int soc_camera_video_start(struct soc_camera_device *icd);
static int video_dev_create(struct soc_camera_device *icd);
+static void soc_camera_of_i2c_info(struct device_node *node,
+ struct soc_camera_of_client *sofc);
---
But I think that's what you want, right?
Don't know - now aöö TABs above are replaced with spaces, so, cannot say.
[snip]
+{
+ struct soc_camera_of_client *sofc;
+ struct soc_camera_desc *sdesc;
I'm really grateful, that you decided to use my original patch and
preserve my authorship! But then, I think, it'd be also better to avoid
unnecessary changes to it. What was wrong with allocation of *sofc in the
definition line?
Oh, this is really I want to bring up. It's a very subtle bug here.
If we use local variable sofc instead of zalloc, fields of sofc have
undetermined None NULL value.
No. If you initialise some members of a struct in its definition line, the
rest will be initialised to 0 / NULL. I.e. in
struct foo y = {.x = 1,};
all other fields of y will be initialised to 0.
I see, but original one is soc_camera_link which is simple in this
case. right now we move to soc_camera_desc. I think following line is
not very straight forward in a local function.
struct soc_camera_desc sdesc = { .host_desc = { .host_wait = true,},};
I usually do
struct soc_camera_desc sdesc = {.host_desc.host_wait = true,};
What about a) struct soc_camera_desc sdesc and use memset to all 0. b)
use kzalloc() and kfree() in this function.
I think b) is more straight forward and easy to understand.
With error handling for a failed kzalloc() - don't think so.
Thanks
Guennadi
Thanks,
-Bryan
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Wed, 12 Feb 2014, Mauro Carvalho Chehab wrote:
Em Tue, 11 Feb 2014 18:22:34 +0100
Sylwester Nawrocki s.nawro...@samsung.com escreveu:
(adding Guennadi to Cc)
On 11/02/14 17:36, Philipp Zabel wrote:
Am Dienstag, den 11.02.2014, 16:23 +0100 schrieb Laurent Pinchart:
Hi Russell,
On Tuesday 11 February 2014 14:52:48 Russell King - ARM Linux wrote:
On Tue, Feb 11, 2014 at 07:56:33AM -0600, Rob Herring wrote:
On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel wrote:
This allows to reuse the same parser code from outside the V4L2
framework, most importantly from display drivers. There have been
patches that duplicate the code (and I am going to send one of my
own),
such as
http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
and others that parse the same binding in a different way:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
I think that all common video interface parsing helpers should be
moved
to a single place, outside of the specific subsystems, so that it can
be reused by all drivers.
Perhaps that should be done rather than moving to drivers/of now and
then again to somewhere else.
Do you have a better suggestion where it should move to?
drivers/gpu/drm - no, because v4l2 wants to use it
drivers/media/video - no, because DRM drivers want to use it
drivers/video - no, because v4l2 and drm drivers want to use it
Just pointing out a missing location (which might be rejected due to
similar
concerns), there's also drivers/media, which isn't V4L-specific.
Since drivers/Makefile has media/ in obj-y, moving the graph helpers to
drivers/media should technically work.
Maybe drivers/of-graph/ ? Or maybe it's just as good a place to move it
into drivers/of ?
include/media/of_graph.h,
drivers/media/of_graph.c?
drivers/media sounds like a good alternative to me.
From my side, I'm ok with putting them at drivers/media. You may add my
acked-by
for such change:
Acked-by: Mauro Carvalho Chehab m.che...@samsung.com
Cannot see any problems with this
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
I would just remove also v4l2_of_{parse/get}* and update the users
to call of_graph_* directly, there should not be many of them.
--
Thanks,
Sylwester
--
Cheers,
Mauro
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/media
From: Philipp Zabel philipp.za...@gmail.com This patch moves the parsing helpers used to parse connected graphs in the device tree, like the video interface bindings documented in Documentation/devicetree/bindings/media/video-interfaces.txt, from drivers/media/v4l2-core to drivers/media. This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. The functions v4l2_of_get_next_endpoint, v4l2_of_get_remote_port, and v4l2_of_get_remote_port_parent are moved. They are renamed to of_graph_get_next_endpoint, of_graph_get_remote_port, and of_graph_get_remote_port_parent, respectively. Since there are not that many current users, switch all of them to the new functions right away. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Mauro Carvalho Chehab m.che...@samsung.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Changes since v1: - Moved to drivers/media instead of drives/of - Removed v4l2_of_get_ functions and changed all users in one step - Keep providing stubs for !OF case --- drivers/media/Kconfig | 4 + drivers/media/Makefile| 2 + drivers/media/i2c/adv7343.c | 4 +- drivers/media/i2c/mt9p031.c | 4 +- drivers/media/i2c/s5k5baf.c | 3 +- drivers/media/i2c/tvp514x.c | 3 +- drivers/media/i2c/tvp7002.c | 3 +- drivers/media/of_graph.c | 133 ++ drivers/media/platform/exynos4-is/fimc-is.c | 6 +- drivers/media/platform/exynos4-is/media-dev.c | 3 +- drivers/media/platform/exynos4-is/mipi-csis.c | 3 +- drivers/media/v4l2-core/v4l2-of.c | 117 -- include/media/of_graph.h | 46 + include/media/v4l2-of.h | 24 - 14 files changed, 202 insertions(+), 153 deletions(-) create mode 100644 drivers/media/of_graph.c create mode 100644 include/media/of_graph.h diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 1d0758a..7681026 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -96,6 +96,7 @@ config VIDEO_DEV tristate depends on MEDIA_SUPPORT depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT + select OF_GRAPH if OF default y config VIDEO_V4L2_SUBDEV_API @@ -203,3 +204,6 @@ source drivers/media/tuners/Kconfig source drivers/media/dvb-frontends/Kconfig endif # MEDIA_SUPPORT + +config OF_GRAPH +bool diff --git a/drivers/media/Makefile b/drivers/media/Makefile index 620f275..ff980bd 100644 --- a/drivers/media/Makefile +++ b/drivers/media/Makefile @@ -18,6 +18,8 @@ ifeq ($(CONFIG_MEDIA_CONTROLLER),y) obj-$(CONFIG_MEDIA_SUPPORT) += media.o endif +obj-$(CONFIG_OF_GRAPH) += of_graph.o + obj-$(CONFIG_VIDEO_DEV) += v4l2-core/ obj-$(CONFIG_DVB_CORE) += dvb-core/ diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c index d4e15a6..74a1507 100644 --- a/drivers/media/i2c/adv7343.c +++ b/drivers/media/i2c/adv7343.c @@ -28,10 +28,10 @@ #include linux/of.h #include media/adv7343.h +#include media/of_graph.h #include media/v4l2-async.h #include media/v4l2-device.h #include media/v4l2-ctrls.h -#include media/v4l2-of.h #include adv7343_regs.h @@ -410,7 +410,7 @@ adv7343_get_pdata(struct i2c_client *client) if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node) return client-dev.platform_data; - np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL); + np = of_graph_get_next_endpoint(client-dev.of_node, NULL); if (!np) return NULL; diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c index e5ddf47..60f36dc 100644 --- a/drivers/media/i2c/mt9p031.c +++ b/drivers/media/i2c/mt9p031.c @@ -27,9 +27,9 @@ #include linux/videodev2.h #include media/mt9p031.h +#include media/of_graph.h #include media/v4l2-ctrls.h #include media/v4l2-device.h -#include media/v4l2-of.h #include media/v4l2-subdev.h #include aptina-pll.h @@ -943,7 +943,7 @@ mt9p031_get_pdata(struct i2c_client *client) if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node) return client-dev.platform_data; - np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL); + np = of_graph_get_next_endpoint(client-dev.of_node, NULL); if (!np) return NULL; diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c index 77e10e0..06261ee 100644 --- a/drivers/media/i2c/s5k5baf.c +++ b/drivers/media/i2c/s5k5baf.c @@ -25,6 +25,7 @@ #include linux/slab.h #include media/media-entity.h +#include media/of_graph.h #include media/v4l2-ctrls.h #include media/v4l2-device.h #include media/v4l2-subdev.h @@ -1855,7 +1856,7 @@ static int s5k5baf_parse_device_node(struct s5k5baf *state, struct device *dev) if
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Hi Sylwester,
On Tue, Feb 11, 2014 at 06:22:34PM +0100, Sylwester Nawrocki wrote:
drivers/media sounds like a good alternative to me.
I would just remove also v4l2_of_{parse/get}* and update the users
to call of_graph_* directly, there should not be many of them.
For now I'd like to skip v4l2_of_parse_endpoint. The others can just be
copied verbatim, but this one also depends on struct 4l2_of_endpoint,
struct v4l2_of_bus_*, and media/v4l2-mediabus.h.
regards
Philipp
--
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] of: move graph helpers from drivers/media/v4l2-core to drivers/media
Em Tue, 11 Feb 2014 22:41:45 +0100 Philipp Zabel p.za...@pengutronix.de escreveu: From: Philipp Zabel philipp.za...@gmail.com This patch moves the parsing helpers used to parse connected graphs in the device tree, like the video interface bindings documented in Documentation/devicetree/bindings/media/video-interfaces.txt, from drivers/media/v4l2-core to drivers/media. This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. The functions v4l2_of_get_next_endpoint, v4l2_of_get_remote_port, and v4l2_of_get_remote_port_parent are moved. They are renamed to of_graph_get_next_endpoint, of_graph_get_remote_port, and of_graph_get_remote_port_parent, respectively. Since there are not that many current users, switch all of them to the new functions right away. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Mauro Carvalho Chehab m.che...@samsung.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Changes since v1: - Moved to drivers/media instead of drives/of - Removed v4l2_of_get_ functions and changed all users in one step - Keep providing stubs for !OF case --- drivers/media/Kconfig | 4 + drivers/media/Makefile| 2 + drivers/media/i2c/adv7343.c | 4 +- drivers/media/i2c/mt9p031.c | 4 +- drivers/media/i2c/s5k5baf.c | 3 +- drivers/media/i2c/tvp514x.c | 3 +- drivers/media/i2c/tvp7002.c | 3 +- drivers/media/of_graph.c | 133 ++ drivers/media/platform/exynos4-is/fimc-is.c | 6 +- drivers/media/platform/exynos4-is/media-dev.c | 3 +- drivers/media/platform/exynos4-is/mipi-csis.c | 3 +- drivers/media/v4l2-core/v4l2-of.c | 117 -- include/media/of_graph.h | 46 + include/media/v4l2-of.h | 24 - 14 files changed, 202 insertions(+), 153 deletions(-) create mode 100644 drivers/media/of_graph.c create mode 100644 include/media/of_graph.h diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 1d0758a..7681026 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -96,6 +96,7 @@ config VIDEO_DEV tristate depends on MEDIA_SUPPORT depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT + select OF_GRAPH if OF default y config VIDEO_V4L2_SUBDEV_API @@ -203,3 +204,6 @@ source drivers/media/tuners/Kconfig source drivers/media/dvb-frontends/Kconfig endif # MEDIA_SUPPORT + +config OF_GRAPH +bool diff --git a/drivers/media/Makefile b/drivers/media/Makefile index 620f275..ff980bd 100644 --- a/drivers/media/Makefile +++ b/drivers/media/Makefile @@ -18,6 +18,8 @@ ifeq ($(CONFIG_MEDIA_CONTROLLER),y) obj-$(CONFIG_MEDIA_SUPPORT) += media.o endif +obj-$(CONFIG_OF_GRAPH) += of_graph.o + obj-$(CONFIG_VIDEO_DEV) += v4l2-core/ obj-$(CONFIG_DVB_CORE) += dvb-core/ diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c index d4e15a6..74a1507 100644 --- a/drivers/media/i2c/adv7343.c +++ b/drivers/media/i2c/adv7343.c @@ -28,10 +28,10 @@ #include linux/of.h #include media/adv7343.h +#include media/of_graph.h #include media/v4l2-async.h #include media/v4l2-device.h #include media/v4l2-ctrls.h -#include media/v4l2-of.h #include adv7343_regs.h @@ -410,7 +410,7 @@ adv7343_get_pdata(struct i2c_client *client) if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node) return client-dev.platform_data; - np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL); + np = of_graph_get_next_endpoint(client-dev.of_node, NULL); if (!np) return NULL; diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c index e5ddf47..60f36dc 100644 --- a/drivers/media/i2c/mt9p031.c +++ b/drivers/media/i2c/mt9p031.c @@ -27,9 +27,9 @@ #include linux/videodev2.h #include media/mt9p031.h +#include media/of_graph.h #include media/v4l2-ctrls.h #include media/v4l2-device.h -#include media/v4l2-of.h #include media/v4l2-subdev.h #include aptina-pll.h @@ -943,7 +943,7 @@ mt9p031_get_pdata(struct i2c_client *client) if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node) return client-dev.platform_data; - np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL); + np = of_graph_get_next_endpoint(client-dev.of_node, NULL); if (!np) return NULL; diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c index 77e10e0..06261ee 100644 --- a/drivers/media/i2c/s5k5baf.c +++ b/drivers/media/i2c/s5k5baf.c @@ -25,6 +25,7 @@ #include linux/slab.h #include media/media-entity.h +#include media/of_graph.h #include
Re: [PATCH 2/2] af9035: Add remaining it913x dual ids to af9035.
On Tue, 2014-02-11 at 22:41 +0200, Antti Palosaari wrote: On 11.02.2014 22:32, Malcolm Priestley wrote: On Tue, 2014-02-11 at 19:42 +0200, Antti Palosaari wrote: Moikka Malcolm! Thanks for the patch serie. You removed all IDs from it913x driver. There is possibility to just remove / comment out: MODULE_DEVICE_TABLE(usb, it913x_id_table); which prevents loading that driver automatically, but leaves possibility to load it manually if user wants to fallback. I am fine either way you decide to do it, just a propose. Hi Antti I am going post a patches to remove it. The only reason why an user would want to fall back is the use dvb-usb-it9137-01.fw firmware with USB_VID_KWORLD_2. I left the USB_VID_KWORLD_2 ids in the driver. I haven't found any issues with dvb-usb-it9135-01.fw USB_VID_KWORLD_2 users could have trouble updating older kernels via media_build. Perhaps there should be a warning message in af9035 that users need to change firmware. Is that KẂorld device dual model (I guess yes, because of it9137)? Is it version 1 (AX) or version 2 (BX) chip? Both apparently exist, but the firmware is the same. The main difference registers in the firmwares dvb-usb-it9137-01.fw --clk enable 0xd81a -- tuner_it91x_priv.h...set_it9137_template dvb-usb-it9135-01.fw --clk enable 0xcfff -- tuner_it91x_priv.h...set_it9135_template dvb-usb-it9135-02.fw --clk enable 0xcfff -- tuner_it91x_priv.h...set_it9135_template As far as It can tell all the latest firmwares are based on set_it9135_template. On the KWorld the second device is another it9137 and has an eeprom 24c02 fitted. So dropping the dvb-usb-it9137-01.fw firmware is fine. Regards Malcolm -- 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: soc-camera: support deferred probing of clients and OF cameras
On Tue, Feb 11, 2014 at 12:53 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
On Tue, 11 Feb 2014, Bryan Wu wrote:
On Mon, Feb 10, 2014 at 10:37 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Bryan,
On Mon, 10 Feb 2014, Bryan Wu wrote:
On Sun, Feb 9, 2014 at 2:20 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Bryan,
Thanks for reiterating this patch!
Sure, my pleasure. I basically assembled your patches together and
change them to use latest V4L2 soc_camera API.
On Fri, 7 Feb 2014, Bryan Wu wrote:
[snip]
@@ -67,6 +81,8 @@ struct soc_camera_async_client {
static int soc_camera_video_start(struct soc_camera_device *icd);
static int video_dev_create(struct soc_camera_device *icd);
+static void soc_camera_of_i2c_info(struct device_node *node,
+ struct soc_camera_of_client *sofc);
If you have to resubmit this patch, plase, make sure the second line of
the above declaration is aligned af usual - under the first character
_after_ the opening bracket.
No problem, I will update this.
Hmmm, something weird on my side. I did put the second line starting
under the first character after the opening bracket. But in git show
and git format-patch I got this
---
static int soc_camera_video_start(struct soc_camera_device *icd);
static int video_dev_create(struct soc_camera_device *icd);
+static void soc_camera_of_i2c_info(struct device_node *node,
+ struct soc_camera_of_client *sofc);
---
But I think that's what you want, right?
Don't know - now aöö TABs above are replaced with spaces, so, cannot say.
[snip]
+{
+ struct soc_camera_of_client *sofc;
+ struct soc_camera_desc *sdesc;
I'm really grateful, that you decided to use my original patch and
preserve my authorship! But then, I think, it'd be also better to avoid
unnecessary changes to it. What was wrong with allocation of *sofc in
the
definition line?
Oh, this is really I want to bring up. It's a very subtle bug here.
If we use local variable sofc instead of zalloc, fields of sofc have
undetermined None NULL value.
No. If you initialise some members of a struct in its definition line, the
rest will be initialised to 0 / NULL. I.e. in
struct foo y = {.x = 1,};
all other fields of y will be initialised to 0.
I see, but original one is soc_camera_link which is simple in this
case. right now we move to soc_camera_desc. I think following line is
not very straight forward in a local function.
struct soc_camera_desc sdesc = { .host_desc = { .host_wait = true,},};
I usually do
struct soc_camera_desc sdesc = {.host_desc.host_wait = true,};
What about a) struct soc_camera_desc sdesc and use memset to all 0. b)
use kzalloc() and kfree() in this function.
I think b) is more straight forward and easy to understand.
With error handling for a failed kzalloc() - don't think so.
OK deal. I will update this.
More questions here:
1. Why do we need a notifier for soc_camera_pdrv_probe()?
I think we can call platform_device_register() which will finish call
the soc_camera_pdrv_probe() and before we start to call.
icd = platform_get_drvdata(sofc-pdev);
I removed those bus notifier code, it works fine on my platform for probing.
2. How to use v4l2-async API properly?
I think basically we need to call
v4l2_async_notifier_register(ici-v4l2_dev, sofc-notifier);
And move the code in soc_camera_i2c_notify() into
.bound/.unbind/.complete call function.
I just treat the scan_async_group() as an example.
Thanks,
-Bryan
--
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] s2255drv: upgrade to videobuf2
Hi Dean,
On 02/12/2014 12:05 AM, Dean Anderson wrote:
The output of v4l2-compliance looks fine. The warnings can be ignored
for this patch.
Can you update to the latest v4l2-compliance that I just pushed this morning?
I added support for the streaming I/O ioctls (use the -s option and make sure
that you have a valid video signal).
That will be very useful.
Regards,
Hans
./v4l2-compliance :
Driver Info:
Driver name : s2255
Card type : s2255
Bus info : usb-:00:1a.7-3.6
Driver version: 3.13.0
Capabilities : 0x8401
Video Capture
Streaming
Device Capabilities
Device Caps : 0x0401
Video Capture
Streaming
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK
Input ioctls:
test VIDIOC_G/S_TUNER: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Control ioctls:
test VIDIOC_QUERYCTRL/MENU: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
warn: v4l2-test-controls.cpp(753): The VIDIOC_G_JPEGCOMP ioctl
is
deprecated!
warn: v4l2-test-controls.cpp(770): The VIDIOC_S_JPEGCOMP ioctl
is
deprecated!
test VIDIOC_G/S_JPEGCOMP: OK
Standard Controls: 7 Private Controls: 1
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
warn: v4l2-test-formats.cpp(598): TRY_FMT cannot handle an
invalid
pixelformat.
warn: v4l2-test-formats.cpp(599): This may or may not be a
problem.
For more information see:
warn: v4l2-test-formats.cpp(600):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
test VIDIOC_TRY_FMT: OK
warn: v4l2-test-formats.cpp(785): S_FMT cannot handle an
invalid
pixelformat.
warn: v4l2-test-formats.cpp(786): This may or may not be a
problem.
For more information see:
warn: v4l2-test-formats.cpp(787):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
warn: v4l2-test-buffers.cpp(335): VIDIOC_CREATE_BUFS not
supported
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
Total: 36, Succeeded: 36, Failed: 0, Warnings: 9
On 2014-02-11 16:56, Dean Anderson wrote:
Upgrade to videobuf2 libraries.
Signed-off-by: Dean Anderson linux-...@sensoray.com
---
drivers/media/usb/s2255/s2255drv.c | 507
+++-
1 file changed, 148 insertions(+), 359 deletions(-)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index e0663ce..3f0d1a6 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -45,14 +45,14 @@
#include linux/mm.h
#include linux/vmalloc.h
#include linux/usb.h
-#include media/videobuf-vmalloc.h
+#include media/videobuf2-vmalloc.h
#include media/v4l2-common.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
#include media/v4l2-event.h
-#define S2255_VERSION 1.24.1
+#define S2255_VERSION 1.25.1
#define FIRMWARE_FILE_NAME f2255usb.bin
/* default JPEG quality */
@@ -229,8 +229,6 @@ struct s2255_vc {
struct v4l2_captureparm cap_parm;
int cur_frame;
int last_frame;
-
-int b_acquire;
/*
Re: [PATCH] s2255drv: upgrade to videobuf2
The output of v4l2-compliance looks fine. The warnings can be ignored
for this patch.
./v4l2-compliance :
Driver Info:
Driver name : s2255
Card type : s2255
Bus info : usb-:00:1a.7-3.6
Driver version: 3.13.0
Capabilities : 0x8401
Video Capture
Streaming
Device Capabilities
Device Caps : 0x0401
Video Capture
Streaming
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK
Input ioctls:
test VIDIOC_G/S_TUNER: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Control ioctls:
test VIDIOC_QUERYCTRL/MENU: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
warn: v4l2-test-controls.cpp(753): The VIDIOC_G_JPEGCOMP ioctl is
deprecated!
warn: v4l2-test-controls.cpp(770): The VIDIOC_S_JPEGCOMP ioctl is
deprecated!
test VIDIOC_G/S_JPEGCOMP: OK
Standard Controls: 7 Private Controls: 1
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
warn: v4l2-test-formats.cpp(598): TRY_FMT cannot handle an invalid
pixelformat.
warn: v4l2-test-formats.cpp(599): This may or may not be a problem.
For more information see:
warn: v4l2-test-formats.cpp(600):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
test VIDIOC_TRY_FMT: OK
warn: v4l2-test-formats.cpp(785): S_FMT cannot handle an invalid
pixelformat.
warn: v4l2-test-formats.cpp(786): This may or may not be a problem.
For more information see:
warn: v4l2-test-formats.cpp(787):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
warn: v4l2-test-buffers.cpp(335): VIDIOC_CREATE_BUFS not
supported
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
Total: 36, Succeeded: 36, Failed: 0, Warnings: 9
On 2014-02-11 16:56, Dean Anderson wrote:
Upgrade to videobuf2 libraries.
Signed-off-by: Dean Anderson linux-...@sensoray.com
---
drivers/media/usb/s2255/s2255drv.c | 507
+++-
1 file changed, 148 insertions(+), 359 deletions(-)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index e0663ce..3f0d1a6 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -45,14 +45,14 @@
#include linux/mm.h
#include linux/vmalloc.h
#include linux/usb.h
-#include media/videobuf-vmalloc.h
+#include media/videobuf2-vmalloc.h
#include media/v4l2-common.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
#include media/v4l2-event.h
-#define S2255_VERSION 1.24.1
+#define S2255_VERSION 1.25.1
#define FIRMWARE_FILE_NAME f2255usb.bin
/* default JPEG quality */
@@ -229,8 +229,6 @@ struct s2255_vc {
struct v4l2_captureparm cap_parm;
int cur_frame;
int last_frame;
-
- int b_acquire;
/* allocated image size */
unsigned long req_image_size;
/* received packet size */
@@ -249,8 +247,12 @@ struct s2255_vc {
int vidstatus_ready;
unsigned intwidth;
unsigned intheight;
+ enum v4l2_field field;
const struct s2255_fmt *fmt;
int idx; /* channel number on device, 0-3 */
+ struct vb2_queue vb_vidq;
Re: [RFC PATCH 2/3] ir-rc5-sz: Add ir encoding support
On Tuesday 11 February 2014 20:14:19 Antti Seppälä wrote:
On 10 February 2014 22:50, James Hogan james.ho...@imgtec.com wrote:
I suspect it needs some more space at the end too, to be sure that no
more bits afterwards are accepted.
I'm sorry but I'm not sure I completely understood what you meant
here. For RC-5-SZ the entire scancode gets encoded and nothing more.
Do you mean that the encoder should append some ir silence to the end
result to make sure the ir sample has ended?
Yeh something like that. Certainly the raw decoders I've looked at expect
a
certain amount of space at the end to avoid decoding part of a longer
protocol (it's in the pulse distance helper as the trailer space timing).
Similarly the IMG hardware decoder has register fields for the free-time
to require at the end of the message.
In fact it becomes a bit awkward for the raw IR driver for the IMG
hardware
which uses edge interrupts, as it has to have a timeout to emit a final
repeat event after 150ms of inactivity, in order for the raw decoders to
accept it (unless you hold the button down in which case the repeat code
edges result in the long space).
Ok, I understand now.
I suppose I can append some IR silence to the encoded result. The
trailer space timing seems like a good way to do it. I'll create new
version of my patches sometime later.
Are you working on the wakeup protocol selector sysfs interface?
I gave it a try yesterday, but it's a bit of a work in progress at the moment.
It's also a bit more effort for img-ir to work properly with it, so I'd
probably just limit the allowed wakeup protocols to the enabled normal
protocol at first in img-ir.
Here's what I have (hopefully kmail won't corrupt it), feel free to take and
improve/fix it. I'm not keen on the invasiveness of the
allowed_protos/enabled_protocols change (which isn't complete), but it
should probably be abstracted at some point anyway.
Cheers
James
diff --git a/Documentation/ABI/testing/sysfs-class-rc
b/Documentation/ABI/testing/sysfs-class-rc
index c0e1d14..1e4ecc8 100644
--- a/Documentation/ABI/testing/sysfs-class-rc
+++ b/Documentation/ABI/testing/sysfs-class-rc
@@ -61,6 +61,25 @@ Description:
an error.
This value may be reset to 0 if the current protocol is altered.
+What: /sys/class/rc/rcN/wakeup_protocol
+Date: Feb 2014
+KernelVersion: 3.15
+Contact: Mauro Carvalho Chehab m.che...@samsung.com
+Description:
+ Reading this file returns a list of available protocols to use
+ for the wakeup filter, something like:
+ rc5 rc6 nec jvc [sony]
+ The enabled wakeup protocol is shown in [] brackets.
+ Writing +proto will add a protocol to the list of enabled
+ wakeup protocols.
+ Writing -proto will remove a protocol from the list of enabled
+ wakeup protocols.
+ Writing proto will use proto for wakeup events.
+ Writing none will disable wakeup.
+ Write fails with EINVAL if more than one protocol would be
+ enabled, an unknown protocol name is used, or if wakeup is not
+ supported by the hardware.
+
What: /sys/class/rc/rcN/wakeup_filter
Date: Jan 2014
KernelVersion: 3.15
@@ -74,7 +93,7 @@ Description:
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.
- This value may be reset to 0 if the current protocol is altered.
+ This value may be reset to 0 if the wakeup protocol is altered.
What: /sys/class/rc/rcN/wakeup_filter_mask
Date: Jan 2014
@@ -89,4 +108,4 @@ Description:
scancodes which match the filter will wake the system from e.g.
suspend to RAM or power off.
Otherwise the write will fail with an error.
- This value may be reset to 0 if the current protocol is altered.
+ This value may be reset to 0 if the wakeup protocol is altered.
diff --git a/drivers/media/rc/ir-jvc-decoder.c
b/drivers/media/rc/ir-jvc-decoder.c
index 3948138..7fb9467 100644
--- a/drivers/media/rc/ir-jvc-decoder.c
+++ b/drivers/media/rc/ir-jvc-decoder.c
@@ -47,7 +47,7 @@ static int ir_jvc_decode(struct rc_dev *dev, struct
ir_raw_event ev)
{
struct jvc_dec *data = dev-raw-jvc;
- if (!(dev-enabled_protocols RC_BIT_JVC))
+ if (!(dev-enabled_protocols[RC_FILTER_NORMAL] RC_BIT_JVC))
return 0;
if (!is_timing_event(ev)) {
diff --git a/drivers/media/rc/ir-mce_kbd-decoder.c
b/drivers/media/rc/ir-mce_kbd-decoder.c
index 9f3c9b5..bc93e11 100644
--- a/drivers/media/rc/ir-mce_kbd-decoder.c
+++ b/drivers/media/rc/ir-mce_kbd-decoder.c
@@ -216,7 +216,7 @@ static int
Re: [PATCH 3/4] em28xx-i2c: do not map -ENXIO errors to -ENODEV for empty i2c transfers
On 09.02.2014 20:34, Frank Schäfer wrote: Am 04.02.2014 19:47, schrieb Mauro Carvalho Chehab: Em Sun, 19 Jan 2014 22:48:36 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Commit e63b009d6e changed the error codes i2c ACK errors from -ENODEV to -ENXIO. But it also introduced a line that maps -ENXIO back to -ENODEV in case of empty i2c messages, which makes no sense, because 1.) an ACK error is an ACK error no matter what the i2c message content is 2.) -ENXIO is perfectly suited for probing, too I don't agree with this patch. 0-byte messages are only usin during device probe. ??? The error handling is inconsistent for no good reason. The old code always returned -ENODEV. Then you came to the conclusion that -ENODEV isn't good and we both agreed that -ENXIO is appropriate. But then you decided to keep -ENODEV for 0-Byte messages only. Why ? According to the i2c error code description, -ENXIO and -ENODEV are both suited for probing. AFAICS there are zero reasons for returning different error codes in case of the same i2c ack error. So please, either -ENODEV or -ENXIO instead of such inconsistencies. 3.) we are loosing the ability to distinguish USB device disconnects Huh? Maybe (like me) you didn't notice that before. This is probably the most cogent argument for changing -ENODEV to -ENXIO for i2c ack errors in case of USB devices. ;-) I looked the I2C spec and there seems to be *not* restriction I2C message len, nor any mention zero len is not valid. If that is the case, adapter should just do the zero len xfer if requested and return success if it is success (slave answers). If adapter does not support zero len messages it should return EOPNOTSUPP according to kernel i2c fault codes document. I think em28xx supports, so that is not case here. I think Frank is correct. I2C spec is here: http://www.nxp.com/documents/user_manual/UM10204.pdf Hope this helps. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s2255drv: upgrade to videobuf2
Upgrade to videobuf2 libraries.
Signed-off-by: Dean Anderson linux-...@sensoray.com
---
drivers/media/usb/s2255/s2255drv.c | 507 +++-
1 file changed, 148 insertions(+), 359 deletions(-)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index e0663ce..3f0d1a6 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -45,14 +45,14 @@
#include linux/mm.h
#include linux/vmalloc.h
#include linux/usb.h
-#include media/videobuf-vmalloc.h
+#include media/videobuf2-vmalloc.h
#include media/v4l2-common.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-ctrls.h
#include media/v4l2-event.h
-#define S2255_VERSION 1.24.1
+#define S2255_VERSION 1.25.1
#define FIRMWARE_FILE_NAME f2255usb.bin
/* default JPEG quality */
@@ -229,8 +229,6 @@ struct s2255_vc {
struct v4l2_captureparm cap_parm;
int cur_frame;
int last_frame;
-
- int b_acquire;
/* allocated image size */
unsigned long req_image_size;
/* received packet size */
@@ -249,8 +247,12 @@ struct s2255_vc {
int vidstatus_ready;
unsigned intwidth;
unsigned intheight;
+ enum v4l2_field field;
const struct s2255_fmt *fmt;
int idx; /* channel number on device, 0-3 */
+ struct vb2_queue vb_vidq;
+ struct mutex vb_lock; /* streaming lock */
+ spinlock_t qlock;
};
@@ -270,7 +272,6 @@ struct s2255_dev {
u32 cc; /* current channel */
int frame_ready;
int chn_ready;
- spinlock_t slock;
/* dsp firmware version (f2255usb.bin) */
int dsp_fw_ver;
u16 pid; /* product id */
@@ -292,16 +293,10 @@ struct s2255_fmt {
/* buffer for one video frame */
struct s2255_buffer {
/* common v4l buffer stuff -- must be first */
- struct videobuf_buffer vb;
+ struct vb2_buffer vb;
+ struct list_head list;
};
-struct s2255_fh {
- /* this must be the first field in this struct */
- struct v4l2_fh fh;
- struct videobuf_queue vb_vidq;
- struct s2255_vc *vc;
- int resources;
-};
/* current cypress EEPROM firmware version */
#define S2255_CUR_USB_FWVER((3 8) | 12)
@@ -569,21 +564,20 @@ static int s2255_got_frame(struct s2255_vc *vc, int
jpgsize)
struct s2255_dev *dev = to_s2255_dev(vc-vdev.v4l2_dev);
unsigned long flags = 0;
int rc = 0;
- spin_lock_irqsave(dev-slock, flags);
+ spin_lock_irqsave(vc-qlock, flags);
if (list_empty(vc-buf_list)) {
dprintk(dev, 1, No active queue to serve\n);
rc = -1;
goto unlock;
}
buf = list_entry(vc-buf_list.next,
-struct s2255_buffer, vb.queue);
- list_del(buf-vb.queue);
- v4l2_get_timestamp(buf-vb.ts);
+struct s2255_buffer, list);
+ list_del(buf-list);
+ v4l2_get_timestamp(buf-vb.v4l2_buf.timestamp);
s2255_fillbuff(vc, buf, jpgsize);
- wake_up(buf-vb.done);
- dprintk(dev, 2, %s: [buf/i] [%p/%d]\n, __func__, buf, buf-vb.i);
+ dprintk(dev, 2, %s: [buf] [%p]\n, __func__, buf);
unlock:
- spin_unlock_irqrestore(dev-slock, flags);
+ spin_unlock_irqrestore(vc-qlock, flags);
return rc;
}
@@ -615,7 +609,7 @@ static void s2255_fillbuff(struct s2255_vc *vc,
{
int pos = 0;
const char *tmpbuf;
- char *vbuf = videobuf_to_vmalloc(buf-vb);
+ char *vbuf = vb2_plane_vaddr(buf-vb, 0);
unsigned long last_frame;
struct s2255_dev *dev = vc-dev;
@@ -629,21 +623,21 @@ static void s2255_fillbuff(struct s2255_vc *vc,
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
planar422p_to_yuv_packed((const unsigned char *)tmpbuf,
-vbuf, buf-vb.width,
-buf-vb.height,
+vbuf, vc-width,
+vc-height,
vc-fmt-fourcc);
break;
case V4L2_PIX_FMT_GREY:
- memcpy(vbuf, tmpbuf, buf-vb.width * buf-vb.height);
+ memcpy(vbuf, tmpbuf, vc-width * vc-height);
break;
case V4L2_PIX_FMT_JPEG:
case V4L2_PIX_FMT_MJPEG:
- buf-vb.size = jpgsize;
- memcpy(vbuf, tmpbuf, buf-vb.size);
+
Re: PATCH: Added device (0ccd:00b4) to DVB_USB_RTL28XXU media driver
Hi Antti,
thanks for the quick response.
Am 11.02.2014 21:53, schrieb Antti Palosaari:
Thanks for the 'patch' :)
I am not sure how I should handle that as the code itself is valid, but patch
is not
as it should.
If you could make a proper patch, using git commit git format-patch, it
will be
nice. But as I understand it could be quite much of learning many things, I am
willing to take that and apply half manually. I still need you signed-off-by
tag as
documented [1]. Please reply with signed-off-by or even better if you could
make
formally correct patch.
[1] https://www.kernel.org/doc/Documentation/SubmittingPatches
I actually read that document before, but apparently I missed the git part (and
I
don't have a git checkout of the kernel sources). So if you can help me out,
that's
greatly appreciated. :-)
Signed-off-by: Till Dörges t...@doerges.net
Thanks -- Till
On 11.02.2014 22:27, Till Dörges wrote:
Hi all,
I've got the following DAB USB stick that also works fine with the
DVB_USB_RTL28XXU
driver after I added its USB ID:
--- snip ---
user@box:~ lsusb -d 0ccd:00b4
Bus 001 Device 009: ID 0ccd:00b4 TerraTec Electronic GmbH
--- snap ---
I tried it on a recent openSUSE 13.1 with this kernel/architecture
--- snip ---
user@box:~ uname -a
Linux box 3.11.10-7-desktop #1 SMP PREEMPT Mon Feb 3 09:41:24 UTC 2014
(750023e)
x86_64 x86_64 x86_64 GNU/Linux
--- snap ---
The patches itself are trivial:
--- ./drivers/media/dvb-core/dvb-usb-ids.h.orig 2014-02-09
22:36:35.266625484 +0100
+++ ./drivers/media/dvb-core/dvb-usb-ids.h 2014-02-09
22:38:00.128199957 +0100
@@ -256,6 +256,7 @@
#define USB_PID_TERRATEC_T50x10a1
#define USB_PID_NOXON_DAB_STICK0x00b3
#define USB_PID_NOXON_DAB_STICK_REV2 0x00e0
+#define USB_PID_NOXON_DAB_STICK_REV3 0x00b4
#define USB_PID_PINNACLE_EXPRESSCARD_320CX 0x022e
#define USB_PID_PINNACLE_PCTV2000E 0x022c
#define USB_PID_PINNACLE_PCTV_DVB_T_FLASH 0x0228
--- ./drivers/media/usb/dvb-usb-v2/rtl28xxu.c.orig 2014-02-03
10:41:24.0
+0100
+++ ./drivers/media/usb/dvb-usb-v2/rtl28xxu.c 2014-02-09
22:37:53.464154845 +0100
@@ -1362,6 +1362,8 @@ static const struct usb_device_id rtl28x
rtl2832u_props, TerraTec NOXON DAB Stick, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV2,
rtl2832u_props, TerraTec NOXON DAB Stick (rev 2), NULL)
},
+ { DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV3,
+ rtl2832u_props, TerraTec NOXON DAB Stick (rev 3), NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
HTH -- Till
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Feb 12 04:00:18 CET 2014 git branch: test git hash: 37e59f876bc710d67a30b660826a5e83e07101ce gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-6.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-rc1-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/media
Hi, On 11/02/14 23:41, Philipp Zabel wrote: From: Philipp Zabel philipp.za...@gmail.com This patch moves the parsing helpers used to parse connected graphs in the device tree, like the video interface bindings documented in Documentation/devicetree/bindings/media/video-interfaces.txt, from drivers/media/v4l2-core to drivers/media. This allows to reuse the same parser code from outside the V4L2 framework, most importantly from display drivers. The functions v4l2_of_get_next_endpoint, v4l2_of_get_remote_port, and v4l2_of_get_remote_port_parent are moved. They are renamed to of_graph_get_next_endpoint, of_graph_get_remote_port, and of_graph_get_remote_port_parent, respectively. Since there are not that many current users, switch all of them to the new functions right away. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Mauro Carvalho Chehab m.che...@samsung.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de I don't think the graphs or the parsing code has anything video specific. It could well be used for anything, whenever there's need to describe connections between devices which are not handled by the normal child-parent relationships. So the code could well reside in some generic place, in my opinion. Also, I have no problem with having it in drivers/media, but drivers/video should work also. We already have other, generic, video related things there like hdmi infoframes and display timings. And last, it's fine to move the funcs as-is in the first place, but I think they should be improved a bit before non-v4l2 users use them. There are a couple of things I tried to accomplish with the omapdss specific versions in https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html: - Iterating ports and endpoints separately. If a node has multiple ports, I would think that the driver needs to know which port and endpoint combination is the current one during iteration. It's not enough to just get the endpoint. - Simplify cases when there's just one port and one endpoint, in which case the port node can be omitted from the DT data. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFCv2 PATCH 00/10] vb2: fixes, balancing callbacks
Is anyone planning to review this? I could really use some more eyeballs looking at this! Regards, Hans On 02/06/2014 12:02 PM, Hans Verkuil wrote: This patch series is v2 of the previous series: http://www.spinics.net/lists/linux-media/msg72166.html Patches 1-6 are unchanged, 7-10 are new. This patch series fixes a series of bugs in vb2. Recently I have been converting the saa7134 driver to vb2 and as part of that work I discovered that the op calls were not properly balanced, which caused saa7134 to fail. Based on that I did more debugging and I found lots of different issues with vb2 when it comes to balancing ops. This patch series fixes them. Many thanks to Pawel Osciak for a good brainstorm session. Patch 1 adds debugging code to check for unbalanced calls. I used this when testing since without this it is very hard to verify correctness. It is currently turned on when CONFIG_VIDEO_ADV_DEBUG is set, but perhaps this should be placed under a vb2 specific debug option? The next patch changes the buf_finish return type to void. It must not fail, and you can't do anything useful if it does anyway. Note that I really would like to do the same for stop_streaming. The stop_streaming error is currently ignored, and there are some drivers that can actually return an error (waiting for an interruptible mutex for example). Opinions are welcome. Patch 3 just improves some comments. Patches 4 and 5 fix several unbalanced ops. Patch 6 fixes a regression (must go to 3.14!). Patch 7 just renames queue_count to owned_by_drv_count. The old name suggests the number of buffers in the queue_list, but that's not what it is. Since the next patch will actually add a real count for the number of buffers in the queue_list I decided to just rename this, thus freeing up the name 'queue_count'. Patch 8 fixes a bug in the handling of start_streaming: before that op is called any prequeued buffers are handed over to the driver. But if start_streaming returns an error, then those buffers are not reclaimed. Since start_streaming failed, q-streaming is 0, so stop_streaming isn't called either. There are two reasons for an error in start_streaming: either a real error when setting up the DMA engine occurred or there were not enough buffers queued for the DMA engine to start (start_streaming returns -ENOBUFS in that case). It makes sense to require that drivers return queued buffers back to vb2 in case of an error, but not if they also have to do that in case of insufficient buffers. So this patch replaces the -ENOBUFS mechanism by a vb2_queue field that tells vb2 what the minimum number of buffers is. Now if start_streaming returns an error the vb2 core will check if there are still buffers owned by the driver and if so produce a warning and reclaim those buffers. The same is done when the vb2_queue is freed. This ensures that the prepare/finish memops are correctly called and the state of all the buffers is consistent. Patch 9 fixes vivi for this start_streaming issue. Note that there are many drivers that do not clean up properly in case of an error during start_streaming. The final patch attempts to fix another issue: I noticed that in the few drivers that implement VIDIOC_CREATE_BUFS the v4l2_format is just used as-is, i.e. no checks are done whether the contents of the struct makes sense or not. This patch adds a number of sanity check to see if the buffer size related values make sense. I have been testing these vb2 changes with vivi (vmalloc based) and an out-of-tree PCI driver (dma-sg based), with the mmap/userptr and read/write streaming modes. I hope to test this also for a dma-contig based driver. I have no way of testing with dmabuf, though. Does anyone know of a simple way to obtain dmabufs from somewhere so they can be passed to a v4l driver? It would be great to add a --stream-dmabuf option for v4l2-ctl. I have to admit that I was a bit disappointed by all these vb2 issues... 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 -- 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
[REVIEWv2 PATCH 35/34] DocBook media: clarify how the matrix maps to the grid.
(This patch is an addition to the Add support for complex controls, use in solo/go7007 patch series) Make it explicit that matrix element (0, 0) maps to the top-left cell of the grid. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/controls.xml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 5f3e138..4749216 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -5102,7 +5102,8 @@ description of this control class./entry /row rowentry spanname=descrSets the motion detection thresholds for each cell in the grid. To be used with the constantV4L2_DETECT_MD_MODE_THRESHOLD_GRID/constant - motion detection mode./entry + motion detection mode. Matrix element (0, 0) represents the cell at the top-left of the + grid./entry /row row entry spanname=idconstantV4L2_CID_DETECT_MD_REGION_GRID/constantnbsp;/entry @@ -5110,7 +5111,8 @@ description of this control class./entry /row rowentry spanname=descrSets the motion detection region value for each cell in the grid. To be used with the constantV4L2_DETECT_MD_MODE_REGION_GRID/constant - motion detection mode./entry + motion detection mode. Matrix element (0, 0) represents the cell at the top-left of the + grid./entry /row /tbody /tgroup -- 1.8.5.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
