Re: [PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector
Hi Laurent, On Wed, 26 Mar 2014 18:33:09 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That could work in your case, but I don't really like that. We need to describe the hardware topology, that might be the only point we all agree on. There are various hardware topologies we need to support with different levels of complexity, and several ways to describe them, also with a wide range of complexities and features. The more complex the hardware topology, the more complex its description needs to be, and the more complex the code that will parse the description and handle the hardware will be. I don't think there's any doubt here. But also, the simpler is the topology and the simpler should be its description. In your approach, the connections between endpoints are described in the components themselves, which makes hard for the DT maintainers to have a global understanding of the video subsystem. Having the topology described in the master device is clearer, even if it is complex. A given device can be integrated in a wide variety of hardware with different complexities. A driver can't thus always assume that the whole composite display device will match a given class of topologies. This is especially true for encoders and connectors, they can be hooked up directly at the output of a very simple display controller, or can be part of a very complex graph. Encoder and connector drivers can't assume much about how they will be integrated. I want to avoid a situation where using an HDMI encoder already supported in mainline with a different SoC will result in having to rewrite the HDMI encoder driver. The tda998x chips are simple enough for being used in many boards: one video input and one serial digital output. I don't see in which circumstance the driver should be rewritten. The story is a bit different for display controllers. While the hardware topology outside (and sometimes inside as well) of the SoC can vary, a display controller often approximately implies a given level of complexity. A cheap SoC with a simple display controller will likely not be used to drive a 4k display requiring 4 encoders running in parallel for instance. While I also want to avoid having to make significant changes to a display controller driver when using the SoC on a different board, I believe the requirement can be slightly relaxed here, and the display controller driver(s) can assume more about the hardware topology than the encoder drivers. I don't think that the display controllers or the encoders have to know about the topology. They have well-knwon specific functions and the way they are interconnected should not impact these functions. If that would be the case, they should offer a particular configuration interface to the master driver. I've asked myself whether we needed a single, one-size-fits-them-all DT representation of the hardware topology. The view of the world from an external encoder point of view must not depend on the SoC it is hooked up to (this would prevent using a single encoder driver with multiple SoCs), which calls for at least some form of standardization. The topology representation on the display controller side may vary from display controller to display controller, but I believe this would just result in code duplication and having to solve the same problem in multiple drivers. For those reasons I believe that the OF graph proposal to represent the display hardware topology would be a good choice. The bindings are flexible enough to represent both simple and complex hardware. Your OF graph proposal is rather complex, and it does not even indicate which way the data flows. Now, I don't want to force all display device drivers to implement complex code when they only need to support simple hardware and simple hardware topologies. Not only would that be rightfully rejected, I would be among the ones nack'ing that approach. My opinion is that this calls for the creation of helpers to handle common cases. Several (possibly many) display systems only need (or want) to support linear pipelines at their output(s), made of a single encoder and a single connector. There's no point in duplicating DT parsing or encoder/connector instantiation code in several drivers in that case where helpers could be reused. Several sets of helpers could support different kinds of topologies, with the driver author selecting a set of helpers depending on the expected hardware topology complexity. I don't like this 'helper' notion. See below. We also need to decide on who (as in which driver) will be responsible for binding all devices together. As DRM exposes a single device to userspace, there needs to be a single driver that will perform front line handling of the userspace API and delegate calls to the other drivers involved. I believe it would be logical for that
Re: [PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector
On Mon, 24 Mar 2014 23:39:01 +0100
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
Hi Jean-François,
Hi Laurent,
Thank you for the patch.
On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote:
The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.
This patch changes the driver to a normal DRM encoder/connector
thanks to the infrastructure for componentised subsystems.
I like the idea, but I'm not really happy with the implementation. Let me try
to explain why below.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/gpu/drm/i2c/tda998x_drv.c | 323 +++
1 file changed, 188 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c index fd6751c..1c25e40 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
[snip]
@@ -44,10 +45,14 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
- struct drm_encoder *encoder;
+ struct drm_encoder encoder;
+ struct drm_connector connector;
};
[snip]
-static int
-tda998x_probe(struct i2c_client *client, const struct i2c_device_id *id)
+static int tda_bind(struct device *dev, struct device *master, void *data)
{
+ struct drm_device *drm = data;
This is the part that bothers me. You're making two assumptions here, that
the
DRM driver will pass a struct drm_device pointer to the bind operation, and
that the I2C encoder driver can take control of DRM encoder and connector
creation. Although it could become problematic later, the first assumption
isn't too much of an issue for now. I'll thus focus on the second one.
The component framework isolate the encoder and DRM master drivers as far as
component creation and binding is concerned, but doesn't provide a way for
the
two drivers to communicate together (nor should it). You're solving this by
passing a pointer to the DRM device to the encoder bind operation, making the
encoder driver create a DRM encoder and connector, and relying on the DRM
core
to orchestrate CRTCs, encoders and connectors. You thus assume that the
encoder hardware should be represented by a DRM encoder object, and that its
output is connected to a connector that should be represented by a DRM
connector object. While this can work in your use case, that won't always
hold
true. Hardware encoders can be chained together, while DRM encoders can't.
The
DRM core has recently received support for bridge objects to overcome that
limitation. Depending on the hardware topology, a given hardware encoder
should be modeled as a DRM encoder or as a DRM bridge. That decision
shouldn't
be taken by the encoder driver but by the DRM master driver. The I2C encoder
driver thus shouldn't create the DRM encoder and DRM connector itself.
I believe the encoder/master communication problem should be solved
differently. Instead of passing a pointer to the DRM device to the encoder
driver and making the encoder driver control DRM encoder and connector
creation, the encoder driver should instead create an object not visible to
userspace that can be retrieved by the DRM master driver (possibly through
registration with the DRM core, or by going through drvdata in the encoder's
struct device). The DRM master could use that object to communicate with the
encoder, and would register the DRM encoder and DRM connector itself based on
hardware topology.
+ struct i2c_client *i2c_client = to_i2c_client(dev);
+ struct tda998x_priv *priv = i2c_get_clientdata(i2c_client);
+ struct drm_connector *connector = priv-connector;
+ struct drm_encoder *encoder = priv-encoder;
+ int ret;
+
+ if (!try_module_get(THIS_MODULE)) {
+ dev_err(dev, cannot get module %s\n, THIS_MODULE-name);
+ return -EINVAL;
+ }
+
+ ret = drm_connector_init(drm, connector,
+ connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
This is one example of the shortcomings I've explained above. An encoder
driver can't always know what connector type it is connected to. If I'm not
mistaken possible options here are DVII, DVID, HDMIA and HDMIB. It should be
up to the master driver to select the connector type based on its overall
view
of the hardware, or even to a connector driver that would be bound to a
connector DT node (as proposed in
https://www.mail-archive.com/devicetree@vger.kernel.org/msg16585.html).
[snip]
The tda998x, as a HDMI transmitter, has to deal with both video and
audio.
Whereas the hardware connection schemes are the same in both worlds,
the way they are translated to computer objects are very different:
- video
DRM card - CRTCs - encoders - (bridges
[PATCH v3] drm/i2c: tda998x: Deprecate nxp,tda998x in favour of nxp,tda9989
The tda998x driver accepts only 3 chips from the TDA998x family.
To avoid confusion with the other TDA998x chips, this patch changes
the driver compatible string to nxp,tda9989.
As the previous compatible string is not actually used in any DT,
no compatibility is offered.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
v3:
- fix the I2C ID (the OF compatible is not used for such drivers)
- define only one compatible (Sebastian Hesselbarth)
- change the subject (Sebastian Hesselbarth)
v2:
- change the subject to drm/i2c
This patch applies after
drm/i2c: tda998x: Fix lack of required reg in DT documentation
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 4 ++--
drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e9e4bce..9b41c7e 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -1,7 +1,7 @@
Device-Tree bindings for the NXP TDA998x HDMI transmitter
Required properties;
- - compatible: must be nxp,tda998x
+ - compatible: must be nxp,tda9989
- reg: I2C address
@@ -20,7 +20,7 @@ Optional properties:
Example:
tda998x: hdmi-encoder {
- compatible = nxp,tda998x;
+ compatible = nxp,tda9989;
reg = 0x70;
interrupt-parent = gpio0;
interrupts = 27 2;/* falling edge */
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 48af5ca..249ef84 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1367,14 +1367,14 @@ fail:
#ifdef CONFIG_OF
static const struct of_device_id tda998x_dt_ids[] = {
- { .compatible = nxp,tda998x, },
+ { .compatible = nxp,tda9989, },
{ }
};
MODULE_DEVICE_TABLE(of, tda998x_dt_ids);
#endif
static struct i2c_device_id tda998x_ids[] = {
- { tda998x, 0 },
+ { tda9989, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, tda998x_ids);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 1/6] drm/i2c: tda998x: Add the required port property
According to the media video interface, the video source and sink
ports must be identified by mutual phandles.
This patch adds the 'port' property of the tda998x (sink side).
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e3f3d65..10c5b5e 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -17,13 +17,22 @@ Optional properties:
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: 0x230145
+Required nodes:
+ - port: reference of the video source as described in media/video-interfaces
+
Example:
- tda998x: hdmi-encoder {
+ hdmi: hdmi-encoder {
compatible = nxp,tda19988;
reg = 0x70;
interrupt-parent = gpio0;
interrupts = 27 2;/* falling edge */
pinctrl-0 = pmx_camera;
pinctrl-names = default;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = lcd0_0;
+ };
+ };
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 0/6] drm/i2c: Move tda998x to a couple encoder/connector
The 'slave encoder' structure of the tda998x driver asks for glue between the DRM driver and the encoder/connector structures. Changing the tda998x driver to a simple encoder/connector simplifies the code of the tilcdc driver. This change is permitted by Russell's infrastructure for componentised subsystems. The proposed patch set does not include changes to the Armada DRM driver. These changes should already have been prepared by Russell King, as told in the message https://www.mail-archive.com/linux-media@vger.kernel.org/msg71202.html The tilcdc part of this patch set has not been tested. This patch set applies after the patchs: drm/i2c: tda998x: Fix lack of required reg in DT documentation drm/i2c: tda998x: Change the compatible strings - v2 - fix lack of call to component_bind_all() in tilcdc_drv.c - add tda998x configuration for non-DT systems Jean-Francois Moine (6): drm/i2c: tda998x: Add the required port property drm/i2c: tda998x: Move tda998x to a couple encoder/connector drm/tilcd: dts: Add the video output port drm/tilcdc: Change the interface with the tda998x driver drm/tilcd: dts: Remove unused slave description ARM: AM33XX: dts: Change the tda998x description .../devicetree/bindings/drm/i2c/tda998x.txt| 11 +- .../devicetree/bindings/drm/tilcdc/slave.txt | 18 - .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 14 + arch/arm/boot/dts/am335x-base0033.dts | 28 +- arch/arm/boot/dts/am335x-boneblack.dts | 21 +- drivers/gpu/drm/i2c/tda998x_drv.c | 323 +--- drivers/gpu/drm/tilcdc/Makefile| 1 - drivers/gpu/drm/tilcdc/tilcdc_drv.c| 85 - drivers/gpu/drm/tilcdc/tilcdc_slave.c | 406 - drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 -- 10 files changed, 315 insertions(+), 618 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 3/6] drm/tilcd: dts: Add the video output port
The connection between the video source and sink must follow
the media video interface.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..d0de848 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
- max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
+Optional nodes:
+
+ - port: reference of the video sink as described in media/video-interfaces.
+ This reference is required when the video sink is the TDA19988 HDMI
+ transmitter.
+
Example:
fb: fb@4830e000 {
@@ -27,3 +33,11 @@ Example:
interrupts = 36;
ti,hwmods = lcdc;
};
+
+ fb {
+ port {
+ lcd_0: endpoint@0 {
+ remote-endpoint = hdmi_0;
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 5/6] drm/tilcd: dts: Remove unused slave description
The tda998x being converted to a normal DRM encoder/connector,
there is no slave notion anymore.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/tilcdc/slave.txt | 18 --
1 file changed, 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be ti,tilcdc,slave.
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
- muxing properly for pins that connect to TFP410 device
-
-Example:
-
- hdmi {
- compatible = ti,tilcdc,slave;
- i2c = i2c0;
- pinctrl-names = default;
- pinctrl-0 = nxp_hdmi_bonelt_pins;
- };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 6/6] ARM: AM33XX: dts: Change the tda998x description
The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector and the tilcdc_slave glue being removed, the
declaration of the HDMI transmitter description must be changed in
the associated DTs.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
arch/arm/boot/dts/am335x-base0033.dts | 28 +++-
arch/arm/boot/dts/am335x-boneblack.dts | 21 -
2 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-base0033.dts
b/arch/arm/boot/dts/am335x-base0033.dts
index 72a9b3f..05f2b8f 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -14,15 +14,6 @@
model = IGEP COM AM335x on AQUILA Expansion;
compatible = isee,am335x-base0033, isee,am335x-igep0033,
ti,am33xx;
- hdmi {
- compatible = ti,tilcdc,slave;
- i2c = i2c0;
- pinctrl-names = default, off;
- pinctrl-0 = nxp_hdmi_pins;
- pinctrl-1 = nxp_hdmi_off_pins;
- status = okay;
- };
-
leds_base {
pinctrl-names = default;
pinctrl-0 = leds_base_pins;
@@ -85,6 +76,11 @@
lcdc {
status = okay;
+ port {
+ lcd_0: endpoint@0 {
+ remote-endpoint = hdmi_0;
+ };
+ };
};
i2c0 {
@@ -92,4 +88,18 @@
compatible = at,24c256;
reg = 0x50;
};
+ hdmi: hdmi-encoder {
+ compatible = nxp,tda19988;
+ reg = 0x70;
+
+ pinctrl-names = default, off;
+ pinctrl-0 = nxp_hdmi_pins;
+ pinctrl-1 = nxp_hdmi_off_pins;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = lcd_0;
+ };
+ };
+ };
};
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..b94d8bd 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -64,15 +64,26 @@
lcdc {
status = okay;
+ port {
+ lcd_0: endpoint@0 {
+ remote-endpoint = hdmi_0;
+ };
+ };
};
-/ {
- hdmi {
- compatible = ti,tilcdc,slave;
- i2c = i2c0;
+i2c0 {
+ hdmi: hdmi-encoder {
+ compatible = nxp,tda19988;
+ reg = 0x70;
+
pinctrl-names = default, off;
pinctrl-0 = nxp_hdmi_bonelt_pins;
pinctrl-1 = nxp_hdmi_bonelt_off_pins;
- status = okay;
+
+ port {
+ hdmi_0: endpoint@0 {
+ remote-endpoint = lcd_0;
+ };
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC v2 4/6] drm/tilcdc: Change the interface with the tda998x driver
The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector, the tilcdc_slave glue is not needed anymore.
This patch uses the infrastructure for componentised subsystems
for waiting to the tda998x full start and to give it the pointer
to the DRM device.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/gpu/drm/tilcdc/Makefile | 1 -
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 85 +--
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 406 --
drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 ---
4 files changed, 68 insertions(+), 450 deletions(-)
delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
- tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 171a820..dd6ebd3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -17,16 +17,16 @@
/* LCDC DRM driver, based on da8xx-fb */
+#include linux/component.h
+
#include tilcdc_drv.h
#include tilcdc_regs.h
#include tilcdc_tfp410.h
-#include tilcdc_slave.h
#include tilcdc_panel.h
#include drm_fb_helper.h
static LIST_HEAD(module_list);
-static bool slave_probing;
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +42,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(mod-list);
}
-void tilcdc_slave_probedefer(bool defered)
-{
- slave_probing = defered;
-}
-
static struct of_device_id tilcdc_of_match[];
static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -277,6 +272,10 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
platform_set_drvdata(pdev, dev);
+ /* initialize the subdevices */
+ ret = component_bind_all(pdev-dev, dev);
+ if (ret 0)
+ goto fail;
list_for_each_entry(mod, module_list, list) {
DBG(%s: preferred_bpp: %d, mod-name, mod-preferred_bpp);
@@ -577,6 +576,66 @@ static const struct dev_pm_ops tilcdc_pm_ops = {
* Platform driver:
*/
+/* component stuff */
+static int of_dev_node_match(struct device *dev, void *data)
+{
+ return dev-of_node == data;
+}
+
+static int tilcdc_add_components(struct device *master, struct master *m)
+{
+ struct device_node *np = master-of_node, *child;
+ int ret;
+
+ /* scan the video ports */
+ child = NULL;
+ for (;;) {
+ struct device_node *endpoint, *port, *i2c_node;
+
+ child = of_get_next_child(np, child);
+ if (!child)
+ break;
+ if (strcmp(child-name, port) != 0)
+ continue;
+
+ endpoint = of_get_next_child(child, NULL);
+ if (!endpoint) {
+ dev_err(master, tilcdc: no port endpoint\n);
+ return -EINVAL;
+ }
+ port = of_parse_phandle(endpoint, remote-endpoint, 0);
+ of_node_put(endpoint);
+ if (!port) {
+ dev_err(master, ticldc: no remote-endpoint\n);
+ return -EINVAL;
+ }
+ i2c_node = of_get_parent(of_get_parent(port));
+ of_node_put(port);
+ ret = component_master_add_child(m, of_dev_node_match,
+i2c_node);
+ of_node_put(i2c_node);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+static int tilcdc_bind(struct device *dev)
+{
+ return drm_platform_init(tilcdc_driver, to_platform_device(dev));
+}
+
+static void tilcdc_unbind(struct device *dev)
+{
+ drm_put_dev(dev_get_drvdata(dev));
+}
+
+static const struct component_master_ops tilcdc_comp_ops = {
+ .add_components = tilcdc_add_components,
+ .bind = tilcdc_bind,
+ .unbind = tilcdc_unbind,
+};
+
static int tilcdc_pdev_probe(struct platform_device *pdev)
{
/* bail out early if no DT data: */
@@ -584,18 +643,12 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
dev_err(pdev-dev, device-tree data is missing\n);
return -ENXIO;
}
-
- /* defer probing if slave is in deferred probing */
- if (slave_probing == true)
- return -EPROBE_DEFER;
-
- return drm_platform_init(tilcdc_driver, pdev);
+ return component_master_add(pdev-dev, tilcdc_comp_ops);
}
static int tilcdc_pdev_remove(struct
[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector
The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.
This patch changes the driver to a normal DRM encoder/connector
thanks to the infrastructure for componentised subsystems.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/gpu/drm/i2c/tda998x_drv.c | 323 ++
1 file changed, 188 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index fd6751c..1c25e40 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,11 +20,12 @@
#include linux/hdmi.h
#include linux/module.h
#include linux/irq.h
+#include linux/of_platform.h
+#include linux/component.h
#include sound/asoundef.h
#include drm/drmP.h
#include drm/drm_crtc_helper.h
-#include drm/drm_encoder_slave.h
#include drm/drm_edid.h
#include drm/i2c/tda998x.h
@@ -44,10 +45,14 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
- struct drm_encoder *encoder;
+ struct drm_encoder encoder;
+ struct drm_connector connector;
};
-#define to_tda998x_priv(x) ((struct tda998x_priv
*)to_encoder_slave(x)-slave_priv)
+#define connector_priv(e) \
+ container_of(connector, struct tda998x_priv, connector)
+#define encoder_priv(e) \
+ container_of(encoder, struct tda998x_priv, encoder)
/* The TDA9988 series of devices use a paged register scheme.. to simplify
* things we encode the page # in upper bits of the register #. To read/
@@ -559,9 +564,8 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
if ((flag2 INT_FLAGS_2_EDID_BLK_RD) priv-wq_edid_wait) {
priv-wq_edid_wait = 0;
wake_up(priv-wq_edid);
- } else if (cec != 0) { /* HPD change */
- if (priv-encoder priv-encoder-dev)
- drm_helper_hpd_irq_event(priv-encoder-dev);
+ } else if (cec != 0 priv-encoder.dev) { /* HPD change */
+ drm_helper_hpd_irq_event(priv-encoder.dev);
}
return IRQ_HANDLED;
}
@@ -731,9 +735,8 @@ tda998x_configure_audio(struct tda998x_priv *priv,
/* DRM encoder functions */
static void
-tda998x_encoder_set_config(struct drm_encoder *encoder, void *params)
+tda998x_encoder_set_config(struct tda998x_priv *priv, void *params)
{
- struct tda998x_priv *priv = to_tda998x_priv(encoder);
struct tda998x_encoder_params *p = params;
priv-vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(p-swap_a) |
@@ -755,7 +758,7 @@ tda998x_encoder_set_config(struct drm_encoder *encoder,
void *params)
static void
tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
{
- struct tda998x_priv *priv = to_tda998x_priv(encoder);
+ struct tda998x_priv *priv = encoder_priv(encoder);
/* we only care about on or off: */
if (mode != DRM_MODE_DPMS_ON)
@@ -786,18 +789,6 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
priv-dpms = mode;
}
-static void
-tda998x_encoder_save(struct drm_encoder *encoder)
-{
- DBG();
-}
-
-static void
-tda998x_encoder_restore(struct drm_encoder *encoder)
-{
- DBG();
-}
-
static bool
tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
@@ -806,11 +797,14 @@ tda998x_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
}
-static int
-tda998x_encoder_mode_valid(struct drm_encoder *encoder,
- struct drm_display_mode *mode)
+static void tda998x_encoder_prepare(struct drm_encoder *encoder)
{
- return MODE_OK;
+ tda998x_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
+}
+
+static void tda998x_encoder_commit(struct drm_encoder *encoder)
+{
+ tda998x_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
}
static void
@@ -818,7 +812,7 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
- struct tda998x_priv *priv = to_tda998x_priv(encoder);
+ struct tda998x_priv *priv = encoder_priv(encoder);
uint16_t ref_pix, ref_line, n_pix, n_line;
uint16_t hs_pix_s, hs_pix_e;
uint16_t vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
@@ -1006,10 +1000,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
}
static enum drm_connector_status
-tda998x_encoder_detect(struct drm_encoder *encoder,
- struct drm_connector *connector)
+tda998x_connector_detect(struct drm_connector *connector, bool force)
{
- struct tda998x_priv *priv = to_tda998x_priv(encoder);
+ struct tda998x_priv *priv = connector_priv(connector);
uint8_t val = cec_read(priv, REG_CEC_RXSHPDLEV);
return (val CEC_RXSHPDLEV_HPD) ? connector_status_connected :
@@ -1017,9 +1010,8
Re: [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
On Mon, 10 Feb 2014 13:12:33 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: I've NAK'd these patches already - I believe they're based on a mis-understanding of how this should be used. I believe Jean-Francois has only looked at the core, rather than looking at the imx-drm example it was posted with in an attempt to understand it. Omitting the component bind operations is absurd because it makes the component code completely pointless, since there is then no way to control the sequencing of driver initialisation - something which is one of the primary reasons for this code existing in the first place. I perfectly looked at your example and I use it now in my system. You did not see what could be done with your component code. For example, since november, I have not yet the clock probe_defer in the mainline (http://www.spinics.net/lists/arm-kernel/msg306072.html), so, there are 3 solutions: - hope the patch will be some day in the mainline and, today, reboot when the system does not start correctly, - insert a delay in the tda998x and kirkwood probe sequences (delay long enough to be sure the si5351 is started, or loop), - use your component work. In the last case, it is easy: - the si5351 driver calls component_add (with empty ops: it has no interest in the bind/unbind functions) when it is fully started (i.e. registered - that was the subject of my patch), - in the DRM driver, look for the si5351 as a clock in the DT (drm - encoder - clock), and add it to the awaited components (CRTCs, encoders..), - in the audio subsystem, look for the si5351 as an external clock in the DT (simple-card - CPU DAI - clock) and add it to the awaited components (CPU and CODEC DAIs - yes, the S/PDIF CODEC should also be a component with no bin/unbind ops). Then, when the si5351 is registered, both master components video and audio can safely run. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
On Fri, 7 Feb 2014 20:23:51 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: Here's my changes to the TDA998x driver to add support for the component helper. The TDA998x driver retains support for the old way so that drivers can be transitioned. For any one DRM card the transition to I rewrote the tda998x as a simple encoder+connector (i.e. not a slave_encoder) with your component helper, and the code is much clearer and simpler: the DRM driver has nothing to do except to know that the tda998x is a component and to set the possible_crtcs. AFAIK, only the tilcdc drm driver is using the tda998x as a slave_encoder. It does a (encoder+connector) conversion to (slave_encoder). Then, in your changes in the TDA998x, you do a (slave_encoder) translation to (encoder+connector). This seems rather complicated! I think it would be easier to use your component helper and rewrite (remove?) tilcdc_slave.c. And yes, I'm thinking that maybe moving compare_of() into the component support so that drivers can share this generic function may be a good idea. This function exists already in drivers/of/platform.c as of_dev_node_match(). It just needs to be exported. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, 7 Feb 2014 09:46:56 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote: I've chatted a bit with Hans Verkuil about this topic at fosdem and apparently both v4l and alsa have something like this already in their helper libraries. Adding more people as fyi in case they want to switch to the new driver core stuff from Russell. It's not ALSA, but ASoC which has this. Mark is already aware of this and will be looking at it from an ASoC perspective. Russell, I started to use your code (which works fine, thanks), and it avoids a lot of problems, especially, about probe_defer in a DT context. I was wondering if your componentised mechanism could be extended to the devices defined by DT. In the DT, when a device_node is a phandle, this means it is referenced by some other device(s), and these device(s) will not start until the phandle device is registered. Then, the idea is to do a component_add() for such phandle devices in device_add() (device_register). Pratically, - the component_add() call in device_register would not include any bind/unbind callback function, so, this should be tested in component_bind/unbind(), - component_add would not be called if the device being added already called component_add in its probe function. A simple flag in the struct device_node should solve this problem. What do you think about this? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 RFC 0/2] drivers/base: simplify simple DT-based components
This patch series tries to simplify the code of simple devices in case they are part of componentised subsystems, are declared in a DT, and are not using the component bin/unbind functions. Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops drivers/base: declare phandle DT nodes as components drivers/base/component.c | 21 +++-- drivers/base/core.c | 18 ++ include/linux/of.h | 2 ++ 3 files changed, 39 insertions(+), 2 deletions(-) -- 1.9.rc1 -- 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 RFC 1/2] drivers/base: permit base components to omit the bind/unbind ops
Some simple components don't need to do any specific action on
bind to / unbind from a master component.
This patch permits such components to omit the bind/unbind
operations.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index c53efe6..0a39d7a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -225,7 +225,8 @@ static void component_unbind(struct component *component,
{
WARN_ON(!component-bound);
- component-ops-unbind(component-dev, master-dev, data);
+ if (component-ops)
+ component-ops-unbind(component-dev, master-dev, data);
component-bound = false;
/* Release all resources claimed in the binding of this component */
@@ -274,7 +275,11 @@ static int component_bind(struct component *component,
struct master *master,
dev_dbg(master-dev, binding %s (ops %ps)\n,
dev_name(component-dev), component-ops);
- ret = component-ops-bind(component-dev, master-dev, data);
+ if (component-ops)
+ ret = component-ops-bind(component-dev, master-dev, data);
+ else
+ ret = 0;
+
if (!ret) {
component-bound = true;
--
1.9.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] drivers/base: declare phandle DT nodes as components
At system startup time, some devices depends on the availability of
some other devices before starting. The infrastructure for componentised
subsystems permits to handle this dependence, each driver defining
its own role.
This patch does an automatic creation of the lowest components in
case of DT. This permits simple devices to be part of complex
componentised subsystems without any specific code.
When created from DT, the device dependence is generally indicated by
phandle: a device which is pointed to by a phandle must be started
before the pointing device(s).
So, at device register time, the devices which are pointed to by a
phandle are declared as components, except when they declared
themselves as such in their probe function.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 12
drivers/base/core.c | 18 ++
include/linux/of.h | 2 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 0a39d7a..3cab26b 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/of.h
struct master {
struct list_head node;
@@ -336,6 +337,7 @@ EXPORT_SYMBOL_GPL(component_bind_all);
int component_add(struct device *dev, const struct component_ops *ops)
{
struct component *component;
+ struct device_node *np;
int ret;
component = kzalloc(sizeof(*component), GFP_KERNEL);
@@ -356,6 +358,11 @@ int component_add(struct device *dev, const struct
component_ops *ops)
kfree(component);
}
+
+ np = dev-of_node;
+ if (np)
+ np-_flags |= OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
return ret 0 ? ret : 0;
@@ -365,6 +372,7 @@ EXPORT_SYMBOL_GPL(component_add);
void component_del(struct device *dev, const struct component_ops *ops)
{
struct component *c, *component = NULL;
+ struct device_node *np;
mutex_lock(component_mutex);
list_for_each_entry(c, component_list, node)
@@ -377,6 +385,10 @@ void component_del(struct device *dev, const struct
component_ops *ops)
if (component component-master)
take_down_master(component-master);
+ np = dev-of_node;
+ if (np)
+ np-_flags = ~OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
WARN_ON(!component);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2b56717..0517b91 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -27,6 +27,7 @@
#include linux/pm_runtime.h
#include linux/netdevice.h
#include linux/sysfs.h
+#include linux/component.h
#include base.h
#include power/power.h
@@ -980,6 +981,7 @@ int device_add(struct device *dev)
struct device *parent = NULL;
struct kobject *kobj;
struct class_interface *class_intf;
+ struct device_node *np;
int error = -EINVAL;
dev = get_device(dev);
@@ -1088,6 +1090,15 @@ int device_add(struct device *dev)
class_intf-add_dev(dev, class_intf);
mutex_unlock(dev-class-p-mutex);
}
+
+ /* if DT-created device referenced by phandle, create a component */
+ np = dev-of_node;
+ if (np np-phandle
+ !(np-_flags OF_DEV_COMPONENT)) {
+ component_add(dev, NULL);
+ np-_flags |= OF_DEV_IMPLICIT_COMPONENT;
+ }
+
done:
put_device(dev);
return error;
@@ -1189,10 +1200,17 @@ void device_del(struct device *dev)
{
struct device *parent = dev-parent;
struct class_interface *class_intf;
+ struct device_node *np;
/* Notify clients of device removal. This call must come
* before dpm_sysfs_remove().
*/
+ np = dev-of_node;
+ if (np (np-_flags OF_DEV_COMPONENT)) {
+ component_del(dev, NULL);
+ np-_flags = ~OF_DEV_IMPLICIT_COMPONENT;
+ }
+
if (dev-bus)
blocking_notifier_call_chain(dev-bus-p-bus_notifier,
BUS_NOTIFY_DEL_DEVICE, dev);
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..40f1c34 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -59,6 +59,8 @@ struct device_node {
struct proc_dir_entry *pde;/* this node's proc directory */
struct kref kref;
unsigned long _flags;
+#define OF_DEV_COMPONENT 1
+#define OF_DEV_IMPLICIT_COMPONENT 2
void*data;
#if defined(CONFIG_SPARC)
const char *path_component_name;
--
1.9.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] *** SUBJECT HERE ***
*** BLURB HERE *** Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops drivers/base: declare phandle DT nodes as components drivers/base/component.c | 21 +++-- drivers/base/core.c | 18 ++ include/linux/of.h | 2 ++ 3 files changed, 39 insertions(+), 2 deletions(-) -- 1.9.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
Some simple components don't need to do any specific action on
bind to / unbind from a master component.
This patch permits such components to omit the bind/unbind
operations.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index c53efe6..0a39d7a 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -225,7 +225,8 @@ static void component_unbind(struct component *component,
{
WARN_ON(!component-bound);
- component-ops-unbind(component-dev, master-dev, data);
+ if (component-ops)
+ component-ops-unbind(component-dev, master-dev, data);
component-bound = false;
/* Release all resources claimed in the binding of this component */
@@ -274,7 +275,11 @@ static int component_bind(struct component *component,
struct master *master,
dev_dbg(master-dev, binding %s (ops %ps)\n,
dev_name(component-dev), component-ops);
- ret = component-ops-bind(component-dev, master-dev, data);
+ if (component-ops)
+ ret = component-ops-bind(component-dev, master-dev, data);
+ else
+ ret = 0;
+
if (!ret) {
component-bound = true;
--
1.9.rc1
--
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 RFC 2/2] drivers/base: declare phandle DT nodes as components
At system startup time, some devices depends on the availability of
some other devices before starting. The infrastructure for componentised
subsystems permits to handle this dependence, each driver defining
its own role.
This patch does an automatic creation of the lowest components in
case of DT. This permits simple devices to be part of complex
componentised subsystems without any specific code.
When created from DT, the device dependence is generally indicated by
phandle: a device which is pointed to by a phandle must be started
before the pointing device(s).
So, at device register time, the devices which are pointed to by a
phandle are declared as components, except when they declared
themselves as such in their probe function.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/base/component.c | 12
drivers/base/core.c | 18 ++
include/linux/of.h | 2 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 0a39d7a..3cab26b 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -17,6 +17,7 @@
#include linux/module.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/of.h
struct master {
struct list_head node;
@@ -336,6 +337,7 @@ EXPORT_SYMBOL_GPL(component_bind_all);
int component_add(struct device *dev, const struct component_ops *ops)
{
struct component *component;
+ struct device_node *np;
int ret;
component = kzalloc(sizeof(*component), GFP_KERNEL);
@@ -356,6 +358,11 @@ int component_add(struct device *dev, const struct
component_ops *ops)
kfree(component);
}
+
+ np = dev-of_node;
+ if (np)
+ np-_flags |= OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
return ret 0 ? ret : 0;
@@ -365,6 +372,7 @@ EXPORT_SYMBOL_GPL(component_add);
void component_del(struct device *dev, const struct component_ops *ops)
{
struct component *c, *component = NULL;
+ struct device_node *np;
mutex_lock(component_mutex);
list_for_each_entry(c, component_list, node)
@@ -377,6 +385,10 @@ void component_del(struct device *dev, const struct
component_ops *ops)
if (component component-master)
take_down_master(component-master);
+ np = dev-of_node;
+ if (np)
+ np-_flags = ~OF_DEV_COMPONENT;
+
mutex_unlock(component_mutex);
WARN_ON(!component);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2b56717..0517b91 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -27,6 +27,7 @@
#include linux/pm_runtime.h
#include linux/netdevice.h
#include linux/sysfs.h
+#include linux/component.h
#include base.h
#include power/power.h
@@ -980,6 +981,7 @@ int device_add(struct device *dev)
struct device *parent = NULL;
struct kobject *kobj;
struct class_interface *class_intf;
+ struct device_node *np;
int error = -EINVAL;
dev = get_device(dev);
@@ -1088,6 +1090,15 @@ int device_add(struct device *dev)
class_intf-add_dev(dev, class_intf);
mutex_unlock(dev-class-p-mutex);
}
+
+ /* if DT-created device referenced by phandle, create a component */
+ np = dev-of_node;
+ if (np np-phandle
+ !(np-_flags OF_DEV_COMPONENT)) {
+ component_add(dev, NULL);
+ np-_flags |= OF_DEV_IMPLICIT_COMPONENT;
+ }
+
done:
put_device(dev);
return error;
@@ -1189,10 +1200,17 @@ void device_del(struct device *dev)
{
struct device *parent = dev-parent;
struct class_interface *class_intf;
+ struct device_node *np;
/* Notify clients of device removal. This call must come
* before dpm_sysfs_remove().
*/
+ np = dev-of_node;
+ if (np (np-_flags OF_DEV_COMPONENT)) {
+ component_del(dev, NULL);
+ np-_flags = ~OF_DEV_IMPLICIT_COMPONENT;
+ }
+
if (dev-bus)
blocking_notifier_call_chain(dev-bus-p-bus_notifier,
BUS_NOTIFY_DEL_DEVICE, dev);
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..40f1c34 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -59,6 +59,8 @@ struct device_node {
struct proc_dir_entry *pde;/* this node's proc directory */
struct kref kref;
unsigned long _flags;
+#define OF_DEV_COMPONENT 1
+#define OF_DEV_IMPLICIT_COMPONENT 2
void*data;
#if defined(CONFIG_SPARC)
const char *path_component_name;
--
1.9.rc1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
On Fri, 7 Feb 2014 17:33:26 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote: This patch series tries to simplify the code of simple devices in case they are part of componentised subsystems, are declared in a DT, and are not using the component bin/unbind functions. I wonder - I said earlier today that this works absolutely fine without modification with DT, so why are you messing about with it adding DT support? This is totally the wrong approach. The idea is that this deals with /devices/ and /devices/ only. It groups up /devices/. It's up to the add_component callback to the master device to decide how to deal with that. Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops And this patch has me wondering if you even understand how to use this... The master bind/unbind callbacks are the ones which establish the card based context with the subsystem. Please, before buggering up this nicely designed implementation, please /first/ look at the imx-drm rework which was posted back in early January which illustrates how this is used in a DT context - which is something I've already pointed you at once today already. As I told in a previous mail, your code works fine in my DT-based Cubox. I am rewriting the TDA988x as a normal encoder/connector, and, yes, the bind/unbind functions are useful in this case. But you opened a door. In a DT context, you know that the probe_defer mechanism does not work correctly. Your work permits to solve delicate cases: your component_add tells exactly when a device is available, and the master bind callback is the green signal for the device waiting for its resources. Indeed, your system was not created for such a usage, but it works as it is (anyway, the component bind/unbind functions may be empty...). -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [media] gspca - topro: New subdriver for Topro webcams
On Thu, 30 Jan 2014 15:14:09 +0300
Dan Carpenter dan.carpen...@oracle.com wrote:
Hello Jean-François Moine,
The patch 8f12b1ab2fac: [media] gspca - topro: New subdriver for
Topro webcams from Sep 22, 2011, leads to the following
static checker warning:
drivers/media/usb/gspca/topro.c:4642
sd_pkt_scan() warn: check 'data[]' for negative offsets s32min
drivers/media/usb/gspca/topro.c
4632 data++;
Should there be an if (len 8) return; here?
4633 len--;
4634 if (*data == 0xff data[1] == 0xd8) {
4635 /*fixme: there may be information in the 4 high bits*/
4636 if ((data[6] 0x0f) != sd-quality)
4637 set_dqt(gspca_dev, data[6] 0x0f);
4638 gspca_frame_add(gspca_dev, FIRST_PACKET,
4639 sd-jpeg_hdr, JPEG_HDR_SZ);
4640 gspca_frame_add(gspca_dev, INTER_PACKET,
4641 data + 7, len - 7);
4642 } else if (data[len - 2] == 0xff data[len - 1] ==
0xd9) {
4643 gspca_frame_add(gspca_dev, LAST_PACKET,
4644 data, len);
4645 } else {
4646 gspca_frame_add(gspca_dev, INTER_PACKET,
4647 data, len);
4648 }
4649 return;
4650 }
4651
4652 switch (*data) {
4653 case 0x55:
4654 gspca_frame_add(gspca_dev, LAST_PACKET, data, 0);
4655
4656 if (len 8
^^^
The same as there is here.
4657 || data[1] != 0xff || data[2] != 0xd8
4658 || data[3] != 0xff || data[4] != 0xfe) {
4659
4660 /* Have only seen this with corrupt frames */
4661 gspca_dev-last_packet_type = DISCARD_PACKET;
4662 return;
4663 }
4664 if (data[7] != sd-quality)
4665 set_dqt(gspca_dev, data[7]);
4666 gspca_frame_add(gspca_dev, FIRST_PACKET,
4667 sd-jpeg_hdr, JPEG_HDR_SZ);
4668 gspca_frame_add(gspca_dev, INTER_PACKET,
4669 data + 8, len - 8);
4670 break;
4671 case 0xaa:
4672 gspca_dev-last_packet_type = DISCARD_PACKET;
4673 break;
4674 case 0xcc:
I suppose we could add a if (len 1) here as well.
4675 if (data[1] != 0xff || data[2] != 0xd8)
4676 gspca_frame_add(gspca_dev, INTER_PACKET,
4677 data + 1, len - 1);
4678 else
4679 gspca_dev-last_packet_type = DISCARD_PACKET;
4680 break;
4681 }
4682 }
AFAIR, there should be no bug because:
- for the BRIDGE_TP6810
- no, there shoud not be a if (len 8) return; at the place
you put it: the end of image may be indicated by just 0x5a,
0xff, 0xd9.
- when the first byte is 0x5a, there are always at least 3
bytes.
- when the 2nd and 3rd bytes are 0xff, 0xd8, there are always at
least 8 bytes. I never saw corrupt packets.
- for the BRIDGE_TP6800
- when the first byte is 0x55 (start of image), I saw some
corrupt packets with less than 8 bytes. So, the test is there.
- when the first byte is 0xcc, it is an intermediate packet, so
it always contains some data. I never saw such packets
reduced to less than 3 bytes.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] gspca - ov534: Fix the light frequency filter
On Mon, 26 Nov 2012 14:08:06 +0100
Antonio Ospite osp...@studenti.unina.it wrote:
For now I'd NAK the patch since it is a regression for users
with 50Hz power sources and it looks like it does not _always_ work for
60Hz either.
Should I remove it from patchwork as well?
As I have the webcam and can perform actual tests I'll coordinate with
Fabian to have more details about why light frequency filter is not
working for him with the current code, it works fine for me at 640x480,
even if I can see that its effect is weaker at 320x240.
I wonder how it could work. Look at the actual code:
val = val ? 0x9e : 0x00;
if (sd-sensor == SENSOR_OV767x) {
sccb_reg_write(gspca_dev, 0x2a, 0x00);
if (val)
val = 0x9d; /* insert dummy to 25fps for 50Hz */
}
sccb_reg_write(gspca_dev, 0x2b, val);
According to the ov7720/ov7221 documentation, the register 2b is:
2B EXHCL 00 RW Dummy Pixel Insert LSB
8 LSB for dummy pixel insert in horizontal direction
How could it act on the light frequency filter?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] gspca - ov534: Fix the light frequency filter
On Mon, 26 Nov 2012 18:12:41 +0100 Antonio Ospite osp...@studenti.unina.it wrote: BTW the documentation might also be wrong or inaccurate. The ov7670 documentation has exactly the same description of the register 0x2b, and I don't think that the manufacturer would greatly change the meaning of such low registers in so close sensors. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] gspca - ov534: Fix the light frequency filter
On Fri, 23 Nov 2012 18:09:09 +0100
Antonio Ospite osp...@studenti.unina.it wrote:
On Thu, 22 Nov 2012 12:46:52 +0100
[snip]
Jean-Francois Moine moin...@free.fr wrote:
This patch was done thanks to the documentation of the right
OmniVision sensors.
In the datasheet I have for ov772x, bit[6] of register 0x13 is described
as:
Bit[6]: AEC - Step size limit
0: Step size is limited to vertical blank
1: Unlimited step size
Right, but I don't use the bit 6, it is the bit 5:
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
which is described as:
Bit[5]: Banding filter ON/OFF
And the patch makes Light Frequency _NOT_ work with the PS3 eye (based
on ov772x).
What does the ov767x datasheet say?
Quite the same thing:
Bit[5]: Banding filter ON/OFF - In order to turn ON the banding
filter, BD50ST (0x9D) or BD60ST (0x9E) must be set to a
non-zero value.
0: OFF
1: ON
(the registers 9d and 9e are non zero for the ov767x in ov534.c)
Maybe we should use the new values only when
sd-sensor == SENSOR_OV767x
What sensor does Alexander's webcam use?
He has exactly the same webcam as yours: 1415:2000 (ps eye) with
sensor ov772x.
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
Tested-by: alexander calderon fabianp...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
drivers/media/usb/gspca/ov534.c: In function ‘setlightfreq’:
drivers/media/usb/gspca/ov534.c:1039:13: warning: unused variable ‘sd’
[-Wunused-variable]
Thanks.
Well, here is one of the last message I received from Alexander (in
fact, his first name is Fabian):
Thanks for all your help, it is very kind of you, I used the code below,the
60 Hz filter appear to work even at 100fps, but when I used 125 fps it
didnt work :( , i guess it is something of detection speed. If you have any
other idea I'll be very thankful.
Sincerely Fabian Calderon
So, how may we advance?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] gspca - ov534: Fix the light frequency filter
(fix lack of signature)
From: Jean-François Moine moin...@free.fr
The exchanges relative to the light frequency filter were adapted
from a description found in a ms-windows driver. It seems that the
registers were the ones of some other sensor.
This patch was done thanks to the documentation of the right
OmniVision sensors.
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
Tested-by: alexander calderon fabianp...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
- val = val ? 0x9e : 0x00;
- if (sd-sensor == SENSOR_OV767x) {
- sccb_reg_write(gspca_dev, 0x2a, 0x00);
- if (val)
- val = 0x9d; /* insert dummy to 25fps for 50Hz */
- }
- sccb_reg_write(gspca_dev, 0x2b, val);
+ if (!val)
+ sccb_reg_write(gspca_dev, 0x13, /* off */
+ sccb_reg_read(gspca_dev, 0x13) ~0x20);
+ else
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
}
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] gspca - ov534: Fix the light frequency filter.
From: Jean-François Moine moin...@free.fr
The exchanges relative to the light frequency filter were adapted
from a description found in a ms-windows driver. It seems that the
registers were the ones of some other sensor.
This patch was done thanks to the documentation of the right
OmniVision sensors.
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
- val = val ? 0x9e : 0x00;
- if (sd-sensor == SENSOR_OV767x) {
- sccb_reg_write(gspca_dev, 0x2a, 0x00);
- if (val)
- val = 0x9d; /* insert dummy to 25fps for 50Hz */
- }
- sccb_reg_write(gspca_dev, 0x2b, val);
+ if (!val)
+ sccb_reg_write(gspca_dev, 0x13, /* off */
+ sccb_reg_read(gspca_dev, 0x13) ~0x20);
+ else
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
}
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] gspca - stv06xx: Fix a regression with the bridge/sensor vv6410
From: Jean-François Moine moin...@free.fr
Setting the H and V flip controls at webcam connection time prevents
the webcam to work correctly.
This patch checks if the webcam is streaming before setting the flips.
It does not set the flips (nor other controls) at webcam start time.
Tested-by: Philippe ROUBACH philippe.roub...@free.fr
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/stv06xx/stv06xx_vv6410.c
+++ b/drivers/media/usb/gspca/stv06xx/stv06xx_vv6410.c
@@ -52,9 +52,13 @@
switch (ctrl-id) {
case V4L2_CID_HFLIP:
+ if (!gspca_dev-streaming)
+ return 0;
err = vv6410_set_hflip(gspca_dev, ctrl-val);
break;
case V4L2_CID_VFLIP:
+ if (!gspca_dev-streaming)
+ return 0;
err = vv6410_set_vflip(gspca_dev, ctrl-val);
break;
case V4L2_CID_GAIN:
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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: video: USB webcam fails since kernel 3.2
On Tue, 9 Oct 2012 15:54:46 -0700 Jonathan Nieder jrnie...@gmail.com wrote: Hi, In June, Martin-Éric Racine wrote: Since recent kernels, this ASUS W5F's built-in webcam fails to be detected. Gstreamer-based applications (Cheese, gstreamer-properties) immediately crash whenever trying to access the video device. [...] video_source:sr[3246]: segfault at 0 ip (null) sp ab36de1c error 14 in cheese[8048000+21000] In July, Martin-Éric Racine wrote: As far as I can tell, yes, the modules in Jean-François' tarball work as-is to fix the problem. [...] [ 11.834852] gspca_main: v2.15.18 registered [ 11.844262] gspca_main: vc032x-2.15.18 probing 0ac8:0321 [ 11.844682] gspca_vc032x: vc0321 check sensor header 2c [ 11.850304] gspca_vc032x: Sensor ID 3130 (0) [ 11.850309] gspca_vc032x: Find Sensor PO3130NC [ 11.851809] gspca_main: video0 created Backport would be needed against 3.2.21 as this is what Debian will (probably) release with. Sorry to have lost track of this. Do you know what patch fixed it? Does 3.5.y from experimental work? Curious, Jonathan Hi Jonathan, I tried to prepare a patch set for the vc032x, but testing with Martin-Éric stopped mid-july, so I have nothing to propose yet. I'm waiting for some other vc0321+po3130nc owner and continue the tests... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 10:02:27 +0300 Martin-Éric Racine martin-eric.rac...@iki.fi wrote: [snip] wget http://moinejf.free.fr/gspca-2.15.18.tar.gz tar -zxf gspca-2.15.18.tar.gz cd gspca-2.15.18 make $ LC_ALL=C make make -C /lib/modules/3.5.0-rc6+/build M=/home/perkelix/gspca-2.15.18/build modules make: *** /lib/modules/3.5.0-rc6+/build: No such file or directory. Stop. make: *** [modules] Error 2 You need the linux headers of your running kernel to compile the tarball. [snip] I don't recall Skype having required this in a long time. As I already said, until recently, the camera just worked. Good news! [snip] echo 0x1f /sys/module/gspca_main/parameters/debug then, unplug/replug the webcam, No can do; this is an internal webcam. No problem. As I want to know the sensor type, instead of cutting the kernel messages starting from the webcam probe, please, filter them by something like: dmesg | fgrep gspca gspca.txt Thanks. -- 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: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 13:21:55 +0300 Martin-Éric Racine martin-eric.rac...@iki.fi wrote: I installed them. That still doesn't fix it: $ LC_ALL=C make make -C /lib/modules/3.5.0-rc6+/build M=/home/perkelix/gspca-2.15.18/build modules make[1]: Entering directory `/usr/src/linux-headers-3.5.0-rc6+' /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile:39: /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile_32.cpu: No such file or directory make[1]: *** No rule to make target Strange. The file arch/x86/Makefile_32.cpu is in the linux 3.5.0 tree. It should have been forgotten in the Debian package. You may copy it from any other kernel source/header you have. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 14:14:24 +0300 Martin-Éric Racine martin-eric.rac...@iki.fi wrote: CC [M] /home/perkelix/gspca-2.15.18/build/ov534_9.o /home/perkelix/gspca-2.15.18/build/ov534_9.c: In function ‘sd_init’: /home/perkelix/gspca-2.15.18/build/ov534_9.c:1353:3: error: implicit declaration of function ‘err’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [/home/perkelix/gspca-2.15.18/build/ov534_9.o] Virhe 1 make[1]: *** [_module_/home/perkelix/gspca-2.15.18/build] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-3.5.0-rc6+' make: *** [modules] Error 2 Sorry, I did not compile yet with kernel = 3.4. So, please, edit the file build/ov534_9.c (and possibly other sources), changing the calls to 'err' to 'pr_err'. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 16:43:47 +0300 Martin-Éric Racine martin-eric.rac...@iki.fi wrote: Jean-Francois, can you perhaps make a patch against my latest tree for the po / PO3130 changes in your tarbal? Noted. Hopefully, the Debian kernel team can contribute to the backporting part, since it's needed for the upcoming stable release. I had many problems with the vc032x driver, and the source code is very different from the code in the official kernels. As I have no webcam, Martin-Éric, may I ask you to test the backport I will do? It will be done only in the vc032x driver, so you could keep the working gspca_vc032x.ko file you have and restore it between the tests. I still lack the sensor type of your webcam. May you send me the result of: dmesg | fgrep gspca I'll contact you directly (with copy to Hans de Goede) as soon as I will have something to propose. Thanks by advance. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: video: USB webcam fails since kernel 3.2
On Tue, 10 Jul 2012 15:56:08 +0300 Martin-Éric Racine martin-eric.rac...@iki.fi wrote: [snip] I hope that the above already provides some usable answers. Not a lot :( Well, I already saw these errors -71. One case was a cable problem. An other one occurred with skype only, while vlc worked correctly. So, it would be interesting to know if the (almost) last driver works. Then, you may try the gspca-2.15.18.tar.gz from my web site: wget http://moinejf.free.fr/gspca-2.15.18.tar.gz tar -zxf gspca-2.15.18.tar.gz cd gspca-2.15.18 make su make install reboot You may then try cheese. For skype, don't forget to force the use of the v4l library: export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so skype If the problem is still there, I'd be glad to get some traces. For that, as root, do: echo 0x1f /sys/module/gspca_main/parameters/debug then, unplug/replug the webcam, do some capture until the problem occurs, and send us the last kernel messages starting from the webcam probe. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: video: USB webcam fails since kernel 3.2
On Sun, 08 Jul 2012 19:58:08 +0200 Hans de Goede hdego...@redhat.com wrote: Hmm, this is then likely caused by the new isoc bandwidth negotiation code in 3.2, unfortunately the vc032x driver is one of the few gspca drivers for which I don't have a cam to test with. Can you try to build your own kernel from source? Hi Martin-Éric, Instead of re-building the gspca driver from a kernel source, you may try the gspca test tarball from my web site http://moinejf.free.fr/gspca-2.15.18.tar.gz It contains most of the bug fixes, including the one about the bandwidth problem. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] gspca - ov534/ov534_9: Fix sccd_read/write errors
The ov534 bridge is too slow to handle the sensor accesses
requested by fast hosts giving 'sccb_reg_write failed'.
A small delay fixes the problem.
Signed-off-by: Jean-François Moine moin...@free.fr
---
drivers/media/video/gspca/ov534.c |1 +
drivers/media/video/gspca/ov534_9.c |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/media/video/gspca/ov534.c
b/drivers/media/video/gspca/ov534.c
index b5acb1e..d5a7873 100644
--- a/drivers/media/video/gspca/ov534.c
+++ b/drivers/media/video/gspca/ov534.c
@@ -851,6 +851,7 @@ static int sccb_check_status(struct gspca_dev *gspca_dev)
int i;
for (i = 0; i 5; i++) {
+ msleep(10);
data = ov534_reg_read(gspca_dev, OV534_REG_STATUS);
switch (data) {
diff --git a/drivers/media/video/gspca/ov534_9.c
b/drivers/media/video/gspca/ov534_9.c
index e6601b8..0120f94 100644
--- a/drivers/media/video/gspca/ov534_9.c
+++ b/drivers/media/video/gspca/ov534_9.c
@@ -1008,6 +1008,7 @@ static int sccb_check_status(struct gspca_dev *gspca_dev)
int i;
for (i = 0; i 5; i++) {
+ msleep(10);
data = reg_r(gspca_dev, OV534_REG_STATUS);
switch (data) {
--
1.7.10
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] gspca - sonixj: Fix bad values of webcam 0458:7025
The webcam 0458:7025 (Eye911Q) has:
- an inverted power pin,
- a sensor mi0360b which cannot be probed.
Signed-off-by: Jean-François Moine moin...@free.fr
---
drivers/media/video/gspca/sonixj.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/sonixj.c
b/drivers/media/video/gspca/sonixj.c
index 4d1696d..f38faa9 100644
--- a/drivers/media/video/gspca/sonixj.c
+++ b/drivers/media/video/gspca/sonixj.c
@@ -3120,7 +3120,7 @@ static const struct sd_desc sd_desc = {
| (SENSOR_ ## sensor 8) \
| (flags)
static const struct usb_device_id device_table[] = {
- {USB_DEVICE(0x0458, 0x7025), BS(SN9C120, MI0360)},
+ {USB_DEVICE(0x0458, 0x7025), BSF(SN9C120, MI0360B, F_PDN_INV)},
{USB_DEVICE(0x0458, 0x702e), BS(SN9C120, OV7660)},
{USB_DEVICE(0x045e, 0x00f5), BSF(SN9C105, OV7660, F_PDN_INV)},
{USB_DEVICE(0x045e, 0x00f7), BSF(SN9C105, OV7660, F_PDN_INV)},
--
1.7.10
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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
gspca maintenance handover
Hi Mauro, I was glad and proud to work for 4 years in the Linux media team, but, now, I am a bit weary of webcams! I proposed to Hans de Goede to take the maintenance of gspca. He perfectly knows the code and does a good work. The driver will be in safe hands. Anyway, I will not fully give up. I will stay in the list and help if any problem. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] gspca: Maintainer change
Hans de Goede accepted to be the new gspca maintainer. Signed-off-by: Jean-François Moine moin...@free.fr --- MAINTAINERS |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f175f44..aaa63da 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3061,8 +3061,7 @@ S:Maintained F: drivers/media/video/gspca/t613.c GSPCA USB WEBCAM DRIVER -M: Jean-Francois Moine moin...@free.fr -W: http://moinejf.free.fr +M: Hans de Goede hdego...@redhat.com L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git S: Maintained -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] gspca: kinect cleanup, ov534 port to control framework
On Wed, 16 May 2012 23:42:43 +0200 Antonio Ospite osp...@studenti.unina.it wrote: The second patch removes the dependency between auto gain and auto white balance, I'd like to hear Jean-Francois on this, the webcam (the ov772x sensor) is able to set the two parameters independently and the user can see the difference of either, is there a reason why we were preventing the user from doing so before? Hi Antonio, I added this dependency by the git commit 2d19a2c1186d86e3 on Thu, 12 Nov 2009 (the original patch was done under mercurial). Looking in my archives, I retrieved this mail I have sent to you, Max Thrun, kaswy, baptiste_lemarie, Martin Drake and Jim Paris: On Thu, 12 Nov 2009 13:24:43 +0100 I wrote: On Thu, 12 Nov 2009 11:13:32 +0100 Antonio Ospite osp...@studenti.unina.it wrote: On Wed, 11 Nov 2009 19:13:51 -0500 Max Thrun bear2...@gmail.com wrote: *I get a weird effect, something like a mosaic effect caused by a picture shift, at such high frame rates (also at 640x480@60), I need to verify if it is my usb host which is weak.* [snip] Maybe the End Of Frame detection logic is still imperfect, but I have to admit I haven't looked at it lately. You are heading to face/object tracking, aren't you? Very interesting. When adding the ov965x, I removed the check of the image size. May you try to set it back? (sorry, I have no patch - the check must be done at 2 places, just before adding the LAST_PACKET - the 2nd is enclosed in #if 0) * * Brightness control in guvcview doesn't seem to work.* Confirmed. Easy fix though: [snip] Thanks, please send patches, they are so easy to create from Mercurial that I don't think you have many excuses for not doing so :) Thanks also from me. I already did and uploaded the fix. * * AWB doesn't have any effect?* I notice its effect if i start uvcview, enable auto gain, then enable awb. If there is a strict dependency between these two settings, shouldn't the driver enforce it? [snip] It should! This asks for a change in the main gspca. I will try to do it quickly. Otherwise, you are right, the ov7670 and ov7729 datasheets do not talk about a possible AGC and AWB dependency... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How fix driver for this USB camera (MT9T031 sensor and Cypress FX2LP USB bridge)
On Wed, 16 May 2012 22:14:48 + (UTC) Simon Gustafsson sim...@simong.se wrote: 2) Where should I begin? My gut feeling is to go for media/video/gspca/ov519.c, since it has the code for talking to the USB bridge chip (BRIDGE_OVFX2), and Hi Simon, The FX2 is a processor, and, in ov519, used as a bridge, it has been programmed by OmniVision for their sensors. It is quite sure that its firmware is different in your webcam. To know more, you should examine USB traces done with some other driver (ms-windows - the scripts I use to translate these traces for gspca are in my web site)... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: gspca zc3xx - JPEG quality / frame overflow
On Sun, 06 May 2012 20:17:08 +0200 Hans de Goede hdego...@redhat.com wrote: - as it is (read the register 11 every 100 ms), the work queue is usefull when there is no polling of the snapshot button, because the frame overflow is reported as the bit 0 in the forth byte (data[3]) of the interrupt messages. Interesting, so if the interrupt is enabled, then as soon as an overflow happens, we get notified through the interrupt data? That may be an alternative to the worker thread, although the current solution does work rather well, so I wonder if we should meddle with it. Hi Hans, Indeed, your solution works, but it does double polling, and the actual worker thread asks for a USB exchange each 100 ms. When using only the interrupt message, there is no overhead. Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [RFCv1 PATCH 1/7] gspca: allow subdrivers to use the control framework.
On Sat, 05 May 2012 16:59:30 +0200 Hans de Goede hdego...@redhat.com wrote: Unless there is another good reason for doing the probing in sd_init I prefer to move it to sd_config. Sensor probing does more then just sensor probing, it also configures things like the i2c clockrate, and if the bus between bridge and sensor is spi / i2c or 3-wire, or whatever ... After a suspend resume all bets are of wrt bridge state, so we prefer to always do a full re-init as we do on initial probe, so that we (hopefully) will put the bridge back in a sane state. I think moving the probing from init to config is a bad idea, the chance that we will get regressions (after a suspend/resume) from this are too big IMHO. Moving the sensor probing to sd_config is normally safe because the init sequences which are sent actually after probing do all the re-initialization job. An easy way to know it in zc3xx is to force the sensor via the module parameter. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [RFCv1 PATCH 1/7] gspca: allow subdrivers to use the control framework.
On Sat, 05 May 2012 17:05:28 +0200 Hans de Goede hdego...@redhat.com wrote: Now I see that we are doing exactly that in for example vidioc_g_jpegcomp in gspca.c, so we should stop doing that. We can make vidioc_g/s_jpegcomp only do the usb locking if gspca_dev-vdev.ctrl_handler == NULL, and once all sub drivers are converted simply remove it. Actually I'm thinking about making the jpegqual control part of the gspca_dev struct itself and move all handling of vidioc_g/s_jpegcomp out of the sub drivers and into the core. Here is an updated version of this patch implementing this approach for vidioc_g/s_jpegcomp. We may need to do something similar in other places, although I cannot think of any such places atm, As the JPEG parameters have been redefined as standard controls, and as there should be only a very few applications which use it, I think the vidioc_g/s_jpegcomp code could be fully removed. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
gspca zc3xx - JPEG quality / frame overflow
Hi Hans, I quickly looked at your patches about the changes for the JPEG quality, and I have some remarks. Indeed, as I don't have any zc3xx webcam nor a lot of documentation about the zc3xx bridge, my information come only from USB trace analysis, and I am not sure there are fully valid. - the register 08 always have values 0..3 (bits 0 and 1). I never saw the bits 2 or 3 set when the frame transfer regulation is active. - when frame overflows occur or disappear, the register 07 is always updated before the register 08. There are bug fixes about the setting of the registers 07 and 08 in my gspca test tarball 2.15.17. - as it is (read the register 11 every 100 ms), the work queue is usefull when there is no polling of the snapshot button, because the frame overflow is reported as the bit 0 in the forth byte (data[3]) of the interrupt messages. In fact, in the traces I have, only the webcams which don't do button polling by interrupt messages have to read the register 11. Why only when the sensor is hv7131r or pas202b? I don't know. But with gspca, the polling is always active when CONFIG_INPUT is defined. Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] gspca: passing wrong length parameter to reg_w()
On Wed, 2 May 2012 09:15:25 +0300
Dan Carpenter dan.carpen...@oracle.com wrote:
This looks like a cut an paste error. This is a two byte array but we
use 8 as a length parameter.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
This is a static checker fix. I don't own the hardware.
diff --git a/drivers/media/video/gspca/conex.c
b/drivers/media/video/gspca/conex.c
index ea17b5d..f39fee0 100644
--- a/drivers/media/video/gspca/conex.c
+++ b/drivers/media/video/gspca/conex.c
@@ -306,7 +306,7 @@ static void cx_sensor(struct gspca_dev*gspca_dev)
reg_w(gspca_dev, 0x0020, reg20, 8);
reg_w(gspca_dev, 0x0028, reg28, 8);
- reg_w(gspca_dev, 0x0010, reg10, 8);
+ reg_w(gspca_dev, 0x0010, reg10, 2);
reg_w_val(gspca_dev, 0x0092, 0x03);
switch (gspca_dev-cam.cam_mode[(int) gspca_dev-curr_mode].priv) {
@@ -326,7 +326,7 @@ static void cx_sensor(struct gspca_dev*gspca_dev)
}
reg_w(gspca_dev, 0x007b, reg7b, 6);
reg_w_val(gspca_dev, 0x00f8, 0x00);
- reg_w(gspca_dev, 0x0010, reg10, 8);
+ reg_w(gspca_dev, 0x0010, reg10, 2);
reg_w_val(gspca_dev, 0x0098, 0x41);
for (i = 0; i 11; i++) {
if (i == 3 || i == 5 || i == 8)
Hi Dan,
Thanks for the patch. The bug is very very old (6 years, at least -
neither have I such a webcam).
Maybe the fix could have been
reg_w(gspca_dev, 0x0010, reg10, sizeof reg10);
but it is OK for me.
Acked-by: Jean-Francois Moine http://moinejf.free.fr
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.4] gspca for_v3.4
The following changes since commit 976a87b9ce3172065e21f0d136353a01df06d0d6: [media] gspca - sn9c20x: Change the exposure setting of Omnivision sensors (2012-04-09 14:22:52 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.4 for you to fetch changes up to 3f46715c09b017bfdfa8c0f5ea284d42a9c213a2: gspca - sonixj: Fix a zero divide in isoc interrupt (2012-05-02 09:05:18 +0200) Jean-François Moine (1): gspca - sonixj: Fix a zero divide in isoc interrupt drivers/media/video/gspca/sonixj.c |8 1 file changed, 4 insertions(+), 4 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: gspca V4L2_CID_EXPOSURE_AUTO and VIDIOC_G/S/TRY_EXT_CTRLS
On Wed, 18 Apr 2012 15:37:20 +0200 Antonio Ospite osp...@studenti.unina.it wrote: I noticed that AEC (Automatic Exposure Control, or V4L2_CID_EXPOSURE_AUTO) does not work in the ov534 gspca driver, either from guvcview or qv4l2. [snip] So in ov534, but I think in m5602 too, V4L2_CID_EXPOSURE_AUTO does not work from guvcview, qv4l2, or v4l2-ctrl, for instance the latter fails with the message: error 25 getting ext_ctrl Auto Exposure I tried adding an hackish implementation of vidioc_g_ext_ctrls and vidioc_s_ext_ctrls to gspca, and with these V4L2_CID_EXPOSURE_AUTO seems to work, but I need to learn more about this kind of controls before I can propose a decent implementation for mainline inclusion myself, so if anyone wants to anticipate me I'd be glad to test :) Unrelated, but maybe worth mentioning is that V4L2_CID_EXPOSURE_AUTO is of type MENU, while some drivers are treating it as a boolean, I think I can fix this one if needed. Hi Antonio, Yes, V4L2_CID_EXPOSURE_AUTO is of class V4L2_CTRL_CLASS_CAMERA, and, as the associated menu shows, it is not suitable for webcams. In the webcam world, the autoexposure is often the same as the autogain: in the knee algorithm (http://81.209.78.62:8080/docs/LowLightOptimization.html - also look at gspca/sonixb.c), both exposure and gain are concerned. The cases where a user wants only autoexposure (fixed gain) or autogain (fixed exposure) are rare. If you want people to be able to do that, you should add a new webcam control, V4L2_CID_AUTOEXPOSURE, and also add it to each driver which implements the knee algorithm, and handle the three cases, autogain only, autoexposure only and knee. Then, looking about your implementation of vidioc_s_ext_ctrls, I found it was a bit simple: setting many controls is atomic, i.e., if any error occurs at some point, the previous controls should be reset to their original values. Same about vidioc_g_ext_ctrls: the mutex must be taken only once for the values do not change. You also do not check if the controls are in a same control class. Anyway, are these ioctl's needed? Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 3/3] [media] gspca - main: implement vidioc_g_ext_ctrls and vidioc_s_ext_ctrls
On Fri, 27 Apr 2012 10:20:23 +0200 Hans Verkuil hverk...@xs4all.nl wrote: I might have some time (no guarantees yet) to help with this. It would certainly be interesting to add support for the control framework in the gspca core. Hmm, perhaps that's a job for the weekend... Hi Hans, I hope you will not do it! The way gspca treats the controls is static, quick and very small. The controls in the subdrivers ask only for the declaration of the controls and functions to send the values to the webcams. Actually, not all subdrivers have been converted to the new gspca control handling, but, when done, it will save more memory. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
Hi Hans, On Wed, 25 Apr 2012 16:19:57 +0200 Hans de Goede hdego...@redhat.com wrote: You say that the marker cannot be in the range 0..31 (index 0..7), but I have never seen a value lower than 68 (index 17). If you change register 0x80 in bank/page 1 to 42 on pac7311 or larger then circa 100 on pac7302, you will get markers with bit 8 set. When this happens you will initially get markers 0xa0 - 0xa4 ... 0xbc and the stream tends to stabilize on 0xbc. Likewise if you remove the artificial limiting of the pac7302 to 15 fps from the driver you will get markers 0x44 - 0x48 ... 0x7c. The images look a lot better with bit 8 set, so I plan to run some tests wrt what framerates can safely handle that (it uses more bandwidth) and set bit 8 on lower framerates. I carefully looked at the ms-windows pac7302 traces I have. The register 1-80 stays always in the range 0d..11, except sometimes 19 at start time. In these traces, the images with marker 44 (dec 68) look really better with all 08's as the quantization table. [snip] Yeah short of someone disassembling and reverse-engineering the windows driver we will probably never figure out the exact correct tables. Well, I got the SPC230NC.SYS of the ms-windows pac7302 driver, but it is not easy to disassemble because it has no symbol table. But, inside, I found this tables just before the Huffman table: - 0006C888 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006C908 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006C988 08 08 08 08 08 08 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 - 0006CA08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20 - 0006CA88 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CB08 08 0b 0b 0b 0b 0b 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 40 40 40 40 40 40 40 40 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CB88 11 12 12 18 15 18 2f 1a 1a 2f 63 42 38 42 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CC08 10 0b 0c 0e 0c 0b 10 0e 0d 0e 12 11 10 13 18 28 1a 18 16 16 18 31 23 25 1d 28 3a 33 3d 3c 39 33 38 37 40 48 5c 4e 40 44 57 45 37 38 50 6D 51 57 5F 62 67 68 67 3E 4D 71 78 70 64 78 5C 65 67 63 Don't they look like quantization tables? (the table 0006CB08 is quite the same the flat table you tried!) BTW, I don't think the exposure and gain controls use the right registers as they are coded in the actual gspca pac7302 subdriver. The ms-windows driver uses the registers (3-80 / 3-03), (3-05 / 3-04), (3-12) and (1-80) for autogain/exposure. The gspca test tarball of my web site includes a new AGC using these registers, but it does not work well. Maybe you could tell me what is wrong with it... Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
On Mon, 23 Apr 2012 23:34:05 +0200
Hans de Goede hdego...@redhat.com wrote:
Thanks for your work on this! I've just spend almost 4 days wrestling
which the Pixart JPEG decompression code to try to better understand
these cams, and I have learned quite a bit and eventually came up
with a different approach.
But your effort is appreciated! After spending so much time on this
myself, I can imagine that it took you quite some time to come up
with your solution.
Attach is a 4 patch patchset which I plan to push to v4l-utils
tomorrow (after running some more tests in daylight). I'll also try
to do some kernel patches tomorrow to match...
Hi Hans,
I tried your patch, but I am not happy with the images I have (pac7302).
You say that the marker cannot be in the range 0..31 (index 0..7), but
I have never seen a value lower than 68 (index 17).
This last marker value (68) is the default when the images have no big
contrasts. With such images / blocks, the standard JPEG quantization
table does not work well. It seems that, for this value, the table
should be full of either 7 or 8 (8 gives a higher contrast).
Here is the sequence which works better (around line 1420 of tinyjpeg.c):
-8--
/* And another special Pixart feature, the DC quantization
factor is fixed! */
qt[0] = 7; // 8 gives a higher contrast
// special case for 68
if (marker == 68) {
for (i = 1; i 64; i++)
qt[i] = 7; // also works with 8
} else {
for (i = 1; i 64; i++) {
j = (standard_quantization[0][i] * comp + 50) / 100;
qt[i] = (j 255) ? j : 255;
}
}
build_quantization_table(priv-Q_tables[0], qt);
-8--
About the other marker values, it seems also that the quantization
tables are not optimal: some blocks are either too much (small
contrasted lines) or not enough (big pixels) decompressed. As you know,
a finer adjustment would ask for a long test time, so, I think we can
live with your code.
Best regards.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
In PJPG blocks, a marker gives the quantization tables to use for image
decoding. This patch dynamically updates the luminance table when the
marker changes.
Note that the values of this table have been guessed from a small
number of images and that they may not work fine in some situations,
but, in most cases, the images are better.
Signed-off-by: Jean-François Moine moin...@free.fr
diff --git a/lib/libv4lconvert/tinyjpeg-internal.h
b/lib/libv4lconvert/tinyjpeg-internal.h
index 702a2a2..4041251 100644
--- a/lib/libv4lconvert/tinyjpeg-internal.h
+++ b/lib/libv4lconvert/tinyjpeg-internal.h
@@ -103,6 +103,7 @@ struct jdec_private {
#if SANITY_CHECK
unsigned int current_cid; /* For planar JPEG */
#endif
+ unsigned char marker; /* for PJPG (Pixart JPEG) */
/* Temp space used after the IDCT to store each components */
uint8_t Y[64 * 4], Cr[64], Cb[64];
diff --git a/lib/libv4lconvert/tinyjpeg.c b/lib/libv4lconvert/tinyjpeg.c
index 2c2d4af..d986a45 100644
--- a/lib/libv4lconvert/tinyjpeg.c
+++ b/lib/libv4lconvert/tinyjpeg.c
@@ -1376,6 +1376,8 @@ static void decode_MCU_2x1_3planes(struct jdec_private
*priv)
IDCT(priv-component_infos[cCr], priv-Cr, 8);
}
+static void build_quantization_table(float *qtable, const unsigned char
*ref_table);
+
static void pixart_decode_MCU_2x1_3planes(struct jdec_private *priv)
{
unsigned char marker;
@@ -1384,10 +1386,8 @@ static void pixart_decode_MCU_2x1_3planes(struct
jdec_private *priv)
/* I think the marker indicates which quantization table to use, iow
a Pixart JPEG may have a different quantization table per MCU, most
MCU's have 0x44 as marker for which our special Pixart quantization
- tables are correct. Unfortunately with a 7302 some blocks also have
0x48,
- and sometimes even other values. As 0x48 is quite common too, we
really
- need to find out the correct table for that, as currently the blocks
- with a 0x48 marker look wrong. During normal operation the marker
stays
+ tables are correct. [jfm: snip]
+ During normal operation the marker stays
within the range below, if it gets out of this range we're most
likely
decoding garbage */
if (marker 0x20 || marker 0x7f) {
@@ -1396,6 +1396,53 @@ static void pixart_decode_MCU_2x1_3planes(struct
jdec_private *priv)
(unsigned int)marker);
longjmp(priv-jump_state, -EIO);
}
+
+ /* rebuild the Y quantization table when the marker changes */
+ if (marker != priv-marker) {
+ unsigned char quant_new[64];
+ int i, j;
+ /*
+* table to rebuild the Y quantization table
+* index 1 = marker / 4
+* index 2 = 4 end indexes in the quantization table
+* values = 0x08, 0x10, 0x20, 0x40, 0x63
+* jfm: The values have been guessed from 4 images, so,
+* better values may be found...
+*/
+ static const unsigned char q_tb[12][4] = {
+ { 64, 64, 64, 64 }, /* 68 */
+ { 8, 32, 64, 64 },
+ { 1, 16, 50, 64 },
+ { 1, 16, 30, 60 }, /* 80 */
+ { 1, 8, 16, 32 },
+ { 1, 4, 16, 31 },
+ { 1, 3, 16, 30 },
+ { 1, 2, 16, 21 },
+ { 1, 1, 16, 18 }, /* 100 */
+ { 1, 1, 16, 17 },
+ { 1, 1, 16, 16 },
+ { 1, 1, 15, 15 },
+ };
+
+ priv-marker = marker;
+ j = marker - 68;
+ if (j 0)
+ j = 0;
+ j = 2;
+ if (j sizeof q_tb / sizeof q_tb[0])
+ j = sizeof q_tb / sizeof q_tb[0] - 1;
+ for (i = 0; i q_tb[j][0]; i++)
+ quant_new[i] = 0x08;
+ for (; i q_tb[j][1]; i++)
+ quant_new[i] = 0x10;
+ for (; i q_tb[j][2]; i++)
+ quant_new[i] = 0x20;
+ for (; i q_tb[j][3]; i++)
+ quant_new[i] = 0x40;
+ for (; i 64; i++)
+ quant_new[i] = 0x63;
+ build_quantization_table(priv-Q_tables[0], quant_new);
+ }
skip_nbits(priv-reservoir, priv-nbits_in_reservoir, priv-stream, 8);
// Y
@@ -1948,6 +1995,7 @@ static int parse_JFIF(struct jdec_private *priv, const
unsigned char *stream)
if (!priv-default_huffman_table_initialized) {
build_quantization_table(priv-Q_tables[0],
pixart_quantization[0]);
[PATCH] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
In PJPG blocks, a marker gives the quantization tables to use for image
decoding. This patch dynamically updates the luminance table when the
marker changes.
Note that the values of this table have been guessed from a small
number of images and that they may not work fine in some situations,
but, in most cases, the images are better rendered.
Signed-off-by: Jean-François Moine moin...@free.fr
diff --git a/lib/libv4lconvert/tinyjpeg-internal.h
b/lib/libv4lconvert/tinyjpeg-internal.h
index 702a2a2..4041251 100644
--- a/lib/libv4lconvert/tinyjpeg-internal.h
+++ b/lib/libv4lconvert/tinyjpeg-internal.h
@@ -103,6 +103,7 @@ struct jdec_private {
#if SANITY_CHECK
unsigned int current_cid; /* For planar JPEG */
#endif
+ unsigned char marker; /* for PJPG (Pixart JPEG) */
/* Temp space used after the IDCT to store each components */
uint8_t Y[64 * 4], Cr[64], Cb[64];
diff --git a/lib/libv4lconvert/tinyjpeg.c b/lib/libv4lconvert/tinyjpeg.c
index 2c2d4af..d986a45 100644
--- a/lib/libv4lconvert/tinyjpeg.c
+++ b/lib/libv4lconvert/tinyjpeg.c
@@ -1376,6 +1376,8 @@ static void decode_MCU_2x1_3planes(struct jdec_private
*priv)
IDCT(priv-component_infos[cCr], priv-Cr, 8);
}
+static void build_quantization_table(float *qtable, const unsigned char
*ref_table);
+
static void pixart_decode_MCU_2x1_3planes(struct jdec_private *priv)
{
unsigned char marker;
@@ -1384,10 +1386,8 @@ static void pixart_decode_MCU_2x1_3planes(struct
jdec_private *priv)
/* I think the marker indicates which quantization table to use, iow
a Pixart JPEG may have a different quantization table per MCU, most
MCU's have 0x44 as marker for which our special Pixart quantization
- tables are correct. Unfortunately with a 7302 some blocks also have
0x48,
- and sometimes even other values. As 0x48 is quite common too, we
really
- need to find out the correct table for that, as currently the blocks
- with a 0x48 marker look wrong. During normal operation the marker
stays
+ tables are correct. [jfm: snip]
+ During normal operation the marker stays
within the range below, if it gets out of this range we're most
likely
decoding garbage */
if (marker 0x20 || marker 0x7f) {
@@ -1396,6 +1396,53 @@ static void pixart_decode_MCU_2x1_3planes(struct
jdec_private *priv)
(unsigned int)marker);
longjmp(priv-jump_state, -EIO);
}
+
+ /* rebuild the Y quantization table when the marker changes */
+ if (marker != priv-marker) {
+ unsigned char quant_new[64];
+ int i, j;
+ /*
+* table to rebuild the Y quantization table
+* index 1 = marker / 4
+* index 2 = 4 end indexes in the quantization table
+* values = 0x08, 0x10, 0x20, 0x40, 0x63
+* jfm: The values have been guessed from 4 images, so,
+* better values may be found...
+*/
+ static const unsigned char q_tb[12][4] = {
+ { 6, 28, 43, 64 }, /* 68 */
+ { 6, 24, 40, 60 },
+ { 4, 18, 30, 55 },
+ { 2, 10, 20, 50 }, /* 80 */
+ { 1, 6, 15, 46 },
+ { 1, 4, 15, 37 },
+ { 1, 3, 15, 30 },
+ { 1, 2, 15, 21 },
+ { 1, 1, 15, 18 }, /* 100 */
+ { 1, 1, 15, 16 },
+ { 1, 1, 15, 15 },
+ { 1, 1, 10, 10 },
+ };
+
+ priv-marker = marker;
+ j = marker - 68;
+ if (j 0)
+ j = 0;
+ j = 2;
+ if (j sizeof q_tb / sizeof q_tb[0])
+ j = sizeof q_tb / sizeof q_tb[0] - 1;
+ for (i = 0; i q_tb[j][0]; i++)
+ quant_new[i] = 0x08;
+ for (; i q_tb[j][1]; i++)
+ quant_new[i] = 0x10;
+ for (; i q_tb[j][2]; i++)
+ quant_new[i] = 0x20;
+ for (; i q_tb[j][3]; i++)
+ quant_new[i] = 0x40;
+ for (; i 64; i++)
+ quant_new[i] = 0x63;
+ build_quantization_table(priv-Q_tables[0], quant_new);
+ }
skip_nbits(priv-reservoir, priv-nbits_in_reservoir, priv-stream, 8);
// Y
@@ -1948,6 +1995,7 @@ static int parse_JFIF(struct jdec_private *priv, const
unsigned char *stream)
if (!priv-default_huffman_table_initialized) {
build_quantization_table(priv-Q_tables[0],
pixart_quantization[0]);
Re: Startup delay needed for a Sonix camera
On Thu, 29 Mar 2012 09:16:59 +0200 Rafał Rzepecki divided.m...@gmail.com wrote: Actually after some more research I've found that b4b01071379 has fixed it. (Jean-François says in the commit message This problem was introduced by commit 0e4d413af1a9d and its exact effects are unknown. So I guess they are known now.) Good news. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.4] gspca for_v3.4
The following changes since commit f92c97c8bd77992ff8bd6ef29a23dc82dca799cb: [media] update CARDLIST.em28xx (2012-03-19 23:12:02 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.4 for you to fetch changes up to 9aadae9dfed054929f80c9f2a7e8b35b195f0b2a: gspca - sn9c20x: Change the exposure setting of Omnivision sensors (2012-03-24 13:33:42 +0100) Jean-François Moine (7): gspca - ov519: Add more information about probe problems gspca - sn9c20x: Change the number of the sensor mt9vprb gspca - sn9c20x: Add the sensor mt9vprb to the sensor ident table gspca - sn9c20x: Define more tables as constant gspca - sn9c20x: Set the i2c interface speed gspca - sn9c20x: Don't do sensor update before the capture is started gspca - sn9c20x: Change the exposure setting of Omnivision sensors drivers/media/video/gspca/ov519.c | 10 ++-- drivers/media/video/gspca/sn9c20x.c | 97 ++ 2 files changed, 68 insertions(+), 39 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] tinyjpeg: Better luminance quantization table for Pixart JPEG
An other luminance quantization table gives a better quality to the
Pixart images created by the webcams handled by the gspca drivers
pac7302 and pac7311 (pixel format 'PJPG').
Tests have been done with 5 different pac7302 webcams. The marker was
always 0x44.
Signed-off-by: Jean-François Moine moin...@free.fr
diff --git a/lib/libv4lconvert/tinyjpeg.c b/lib/libv4lconvert/tinyjpeg.c
index e308f63..687e69c 100644
--- a/lib/libv4lconvert/tinyjpeg.c
+++ b/lib/libv4lconvert/tinyjpeg.c
@@ -206,14 +206,14 @@ static const unsigned char val_ac_chrominance[] = {
};
const unsigned char pixart_quantization[][64] = { {
- 0x07, 0x07, 0x08, 0x0a, 0x09, 0x07, 0x0d, 0x0b,
- 0x0c, 0x0d, 0x11, 0x10, 0x0f, 0x12, 0x17, 0x27,
- 0x1a, 0x18, 0x16, 0x16, 0x18, 0x31, 0x23, 0x25,
- 0x1d, 0x28, 0x3a, 0x33, 0x3d, 0x3c, 0x39, 0x33,
- 0x38, 0x37, 0x40, 0x48, 0x5c, 0x4e, 0x40, 0x44,
- 0x57, 0x45, 0x37, 0x38, 0x50, 0x6d, 0x51, 0x57,
- 0x5f, 0x62, 0x67, 0x68, 0x67, 0x3e, 0x4d, 0x71,
- 0x79, 0x70, 0x64, 0x78, 0x5c, 0x65, 0x67, 0x63,
+ 0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x10, 0x10,
+ 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10,
+ 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10, 0x10,
+ 0x10, 0x10, 0x10, 0x10, 0x20, 0x20, 0x20, 0x20,
+ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
+ 0x20, 0x20, 0x20, 0x40, 0x40, 0x40, 0x40, 0x40,
+ 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40,
+ 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40,
},
{
0x11, 0x12, 0x12, 0x18, 0x15, 0x18, 0x2f, 0x1a,
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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: [Q] v4l buffer format inside isoc
On Tue, 20 Mar 2012 21:05:13 -0300 Ezequiel García elezegar...@gmail.com wrote: I'm a little lost while writing a driver for an easycap device (saa7113 capture device). I have my isoc handler, and the isoc urb flying OK. I also have the videobuf2 queue setup (or at least I think so), and I understand I need to call vb2_buffer_done() with a filled buffer. What I DON'T understand is how should I fill such buffer? I mean, what *format* comes inside the isoc buffer? Should I look at saa7113 datasheet? Should I base in em28xx? I'm sorry to ask such a generic question. Perhaps, someone cares enough to give me a hint. Hi Ezequiel, The saa7113 chip is (also?) handled by the gspca spca506 subdriver which may be a base for your device. In the gspca test tarball (see my site), I merged the spca506 code into the spca505 for a webcam which may also do analog video capture. The webcam works, but the analog video capture has never been tested. Also, the gspca_main - subdriver interface for vidioc_s_input and vidioc_s_std is not very clean. So, you might include your device in this new spca505 subdriver, forgetting about urb, isoc, videobuf.., and just concentrating on the device management (image format, video controls, USB exchanges..). I am ready to cleanup and extend the gspca subdriver interface to handle any specific need. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.4] gspca for_v3.4
Hi Mauro, This set includes the patch http://patchwork.linuxtv.org/patch/9494. The following changes since commit 632fba4d012458fd5fedc678fb9b0f8bc59ceda2: [media] cx25821: Add a card definition for No brand cards that have: subvendor = 0x subdevice = 0x (2012-03-08 12:42:28 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.4 for you to fetch changes up to 898b0fd6218c7012a1b73e3bf7a7c60fd578c0a6: gspca - sn9c20x: Cleanup source (2012-03-19 08:55:16 +0100) Jean-François Moine (12): gspca - zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support gspca - zc3xx: Lack of register 08 value for sensor cs2102k gspca - sn9c20x: Fix loss of frame start gspca - sn9c20x: Use the new video control mechanism gspca - sn9c20x: Propagate USB errors to higher level gspca - sn9c20x: Add a delay after Omnivision sensor reset gspca - sn9c20x: Add the JPEG compression quality control gspca - sn9c20x: Optimize the code of write sequences gspca - sn9c20x: Greater delay in case of sensor no response gspca - sn9c20x: Add automatic JPEG compression mechanism gspca - sn9c20x: Simplify register write for capture start/stop gspca - sn9c20x: Cleanup source Jose Alberto Reguero (1): gspca - ov534_9: Add brightness to OmniVision 5621 sensor drivers/media/video/gspca/ov534_9.c | 49 ++- drivers/media/video/gspca/sn9c20x.c | 1138 --- drivers/media/video/gspca/zc3xx.c | 47 ++- 3 files changed, 582 insertions(+), 652 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam succumbs to glare in Linux
On Fri, 16 Mar 2012 08:53:51 +1100 Xavion xavio...@gmail.com wrote: As you can probably gather from the attached screenshots, I'm attempting to use my SN9C201 webcam for home security. The problem is that it succumbs to external glare during the middle hours of sunny days when used in Linux. The same problem doesn't occur in Windows, probably since the software automatically adjusts to the current lighting conditions. These screenshots were taken only five minutes apart and the sunlight intensity didn't change much in-between. No amount of adjusting the webcam's settings (via V4L2-UCP) seemed to make any significant difference. For this reason, I'm guessing that there's at least one other adjustable setting that the GSPCA driver isn't tapping into yet. [snip] Hi Xavion, It seems that the exposure is not set correctly. May you try the patch below? (to be applied to the gspca test version 2.15.7 - the exposure may be too low at init time, set it to 800) --- build/sn9c20x.c~ +++ build/sn9c20x.c @@ -1650,10 +1650,9 @@ case SENSOR_OV7670: case SENSOR_OV9655: case SENSOR_OV9650: - exp[0] |= (3 4); - exp[2] = 0x2d; - exp[3] = expo; - exp[4] = expo 8; + exp[0] |= (2 4); + exp[2] = 0x10; /* AECH */ + exp[3] = expo * 255 / 0x1780; break; case SENSOR_MT9M001: case SENSOR_MT9V112: -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.4] gspca for_v3.4
On Tue, 28 Feb 2012 12:15:43 +0100
Sylwester Nawrocki s.nawro...@samsung.com wrote:
I checked the changes in zc3xx.c, and I have made many commits. So, it
would be simpler if you would remove your patch. I could give you a
merged one once the media tree would be updated.
OK, if it's easier please carry the patch in your tree. Otherwise, let me
handle it after our pull request are included in the media tree.
Hi Sylwester,
Here is the merge of your patch (origin media_tree staging/for_v3.4).
As I have an other patch to do to the driver, I may add it to my
changes once you have acked it (I have no webcam to test it).
Best regards.
diff --git a/drivers/media/video/gspca/zc3xx.c
b/drivers/media/video/gspca/zc3xx.c
index c10bdb4..7bbdf83 100644
--- a/drivers/media/video/gspca/zc3xx.c
+++ b/drivers/media/video/gspca/zc3xx.c
@@ -44,6 +44,7 @@ enum e_ctrl {
AUTOGAIN,
LIGHTFREQ,
SHARPNESS,
+ QUALITY,
NCTRLS /* number of controls */
};
@@ -99,6 +100,7 @@ static void setexposure(struct gspca_dev *gspca_dev);
static int sd_setautogain(struct gspca_dev *gspca_dev, __s32 val);
static void setlightfreq(struct gspca_dev *gspca_dev);
static void setsharpness(struct gspca_dev *gspca_dev);
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val);
static const struct ctrl sd_ctrls[NCTRLS] = {
[BRIGHTNESS] = {
@@ -186,6 +188,18 @@ static const struct ctrl sd_ctrls[NCTRLS] = {
},
.set_control = setsharpness
},
+[QUALITY] = {
+ {
+ .id = V4L2_CID_JPEG_COMPRESSION_QUALITY,
+ .type= V4L2_CTRL_TYPE_INTEGER,
+ .name= Compression Quality,
+ .minimum = 40,
+ .maximum = 70,
+ .step= 1,
+ .default_value = 70 /* updated in sd_init() */
+ },
+ .set = sd_setquality
+ },
};
static const struct v4l2_pix_format vga_mode[] = {
@@ -6151,6 +6165,7 @@ static void transfer_update(struct work_struct *work)
|| !gspca_dev-present
|| !gspca_dev-streaming)
goto err;
+ sd-ctrls[QUALITY].val = jpeg_qual[sd-reg08];
jpeg_set_qual(sd-jpeg_hdr,
jpeg_qual[sd-reg08]);
}
@@ -6717,13 +6732,20 @@ static int sd_init(struct gspca_dev *gspca_dev)
sd-ctrls[GAMMA].def = gamma[sd-sensor];
sd-reg08 = reg08_tb[sd-sensor];
+ sd-ctrls[QUALITY].def = jpeg_qual[sd-reg08];
+ sd-ctrls[QUALITY].min = jpeg_qual[0];
+ sd-ctrls[QUALITY].max = jpeg_qual[ARRAY_SIZE(jpeg_qual) - 1];
switch (sd-sensor) {
case SENSOR_HV7131R:
+ gspca_dev-ctrl_dis = (1 QUALITY);
break;
case SENSOR_OV7630C:
gspca_dev-ctrl_dis = (1 LIGHTFREQ) | (1 EXPOSURE);
break;
+ case SENSOR_PAS202B:
+ gspca_dev-ctrl_dis = (1 QUALITY) | (1 EXPOSURE);
+ break;
default:
gspca_dev-ctrl_dis = (1 EXPOSURE);
break;
@@ -7003,24 +7025,33 @@ static int sd_querymenu(struct gspca_dev *gspca_dev,
return -EINVAL;
}
-static int sd_set_jcomp(struct gspca_dev *gspca_dev,
- struct v4l2_jpegcompression *jcomp)
+static int sd_setquality(struct gspca_dev *gspca_dev, __s32 val)
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
for (i = 0; i ARRAY_SIZE(jpeg_qual) - 1; i++) {
- if (jcomp-quality = jpeg_qual[i])
+ if (val = jpeg_qual[i])
break;
}
if (i 0
i == sd-reg08
- jcomp-quality jpeg_qual[sd-reg08])
+ val jpeg_qual[sd-reg08])
i--;
sd-reg08 = i;
- jcomp-quality = jpeg_qual[i];
+ sd-ctrls[QUALITY].val = jpeg_qual[i];
if (gspca_dev-streaming)
- jpeg_set_qual(sd-jpeg_hdr, jcomp-quality);
+ jpeg_set_qual(sd-jpeg_hdr, sd-ctrls[QUALITY].val);
+ return gspca_dev-usb_err;
+}
+
+static int sd_set_jcomp(struct gspca_dev *gspca_dev,
+ struct v4l2_jpegcompression *jcomp)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ sd_setquality(gspca_dev, jcomp-quality);
+ jcomp-quality = sd-ctrls[QUALITY].val;
return gspca_dev-usb_err;
}
@@ -7030,7 +7061,7 @@ static int sd_get_jcomp(struct gspca_dev *gspca_dev,
struct sd *sd = (struct sd *) gspca_dev;
memset(jcomp, 0, sizeof *jcomp);
- jcomp-quality = jpeg_qual[sd-reg08];
+ jcomp-quality = sd-ctrls[QUALITY].val;
jcomp-jpeg_markers = V4L2_JPEG_MARKER_DHT
| V4L2_JPEG_MARKER_DQT;
return 0;
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Wed, 7 Mar 2012 09:59:28 +1100 Xavion xavio...@gmail.com wrote: root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 ... Hmm, error -18 is EXDEV, which according to Documentation/usb/error-codes.txt is: -EXDEV ISO transfer only partially completed (only set in iso_frame_desc[n].status, not urb-status) I've seen those before, and I think we should simply ignore them rather then log an error for them. Jean-Francois, what do you think? I'll let you guys decide what to do about this, but remember that I'm here to help if you need more testing done. If you want my opinion, I'd be leaning towards trying to prevent any errors that appear regularly. Hi, It seems that the webcams handled by the driver sn9c20x work the same as the ones handled by sonixj. In this last driver, I adjust the JPEG compression to avoid the errors USB FIFO full, and I think that these errors also raise the URB error -18 with the sn9c20x. I will need some time to put a same code into the sn9c20x, then I'd be glad to have it tested. There was an other problem in the driver sonixj: the end of frame marker was not always at the right place. Xavion, as you have ms-windows, may you do some USB traces with this system? I need a capture sequence of about 15 seconds (not more) with big luminosity changes. This isn't even the proper SXGA resolution, which is supposed to be 1280x1024. The Sonix website claims that their SN9C201 webcam can provide up to a 1.3 MP (SXGA) video size! Do you happen to know of any inexpensive webcams that are capable of true SXGA in Linux? `-- lsusb | grep Cam Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV7660) The sensor ov7660 can do VGA only (640x480). Otherwise, I uploaded a new gspca test version (2.15.3) with the JPEG compression control (default 80%). May you try it? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [bug?] ov519 fails to handle Hercules Deluxe webcam
On Sun, 4 Mar 2012 18:38:01 -0600 Jonathan Nieder jrnie...@gmail.com wrote: Hi, Skippy le Grand Gourou wrote[1]: Hercules Deluxe USB webcam won't work, see the end of the kernel log. [...] [521041.808976] gspca: probing 05a9:4519 [521042.469094] ov519: I2C synced in 3 attempt(s) [521042.469097] ov519: starting OV7xx0 configuration [521042.469793] ov519: Unknown image sensor version: 2 [521042.469795] ov519: Failed to configure OV7xx0 [521042.469797] ov519: OV519 Config failed [521042.469807] ov519: probe of 3-1.4:1.0 failed with error -16 [521042.469884] gspca: probing 05a9:4519 [521467.885255] usbcore: deregistering interface driver ov519 [521467.885278] ov519: deregistered [521467.900288] gspca: main deregistered [521809.376462] dialog[12612]: segfault at 0 ip b77c6125 sp bf8861b0 error 4 in libncursesw.so.5.7[b77b5000+43000] [524303.418813] usb 3-1.3: USB disconnect, address 9 [...] [528511.174900] usb 3-1.4: USB disconnect, address 10 [528513.420812] usb 3-1.4: new full speed USB device using ehci_hcd and address 13 [528513.515013] usb 3-1.4: New USB device found, idVendor=05a9, idProduct=4519 [528513.515018] usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [528513.515021] usb 3-1.4: Product: USB Camera [528513.515023] usb 3-1.4: Manufacturer: OmniVision Technologies, Inc. [528513.515116] usb 3-1.4: configuration #1 chosen from 1 choice [528513.524620] Linux video capture interface: v2.00 [528513.526783] gspca: main v2.7.0 registered [528513.527299] gspca: probing 05a9:4519 [528514.190995] ov519: I2C synced in 3 attempt(s) [528514.190998] ov519: starting OV7xx0 configuration [528514.192570] ov519: Sensor is an OV7610 [528514.417110] ov519: probe of 3-1.4:1.0 failed with error -5 [528514.417139] usbcore: registered new interface driver ov519 [528514.417143] ov519: registered [...] 00:1a.0 USB Controller [0c03]: Intel Corporation Cougar Point USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. Device [1043:844d] [...] Bus 001 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 012: ID 9e88:9e8f Bus 003 Device 013: ID 05a9:4519 OmniVision Technologies, Inc. Webcam Classic Bus 003 Device 005: ID 04a9:221c Canon, Inc. CanoScan LiDE 60 Bus 003 Device 006: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver [...] Kernel is Debian 2.6.32-41, which is closely based on stable 2.6.32.54. I don't see any obvious potential fixes in the diff relative to linux-next. Known problem? Any hints for tracking this down? Thanks, Jonathan [1] http://bugs.debian.org/662246 Hi Skippy and Jonathan, The git commit b877a9a7fb0 (gspca - ov519: Fix sensor detection problems) may have fix this problem. To be sure, try the gspca test version from my web site. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [bug?] ov519 fails to handle Hercules Deluxe webcam
On Mon, 5 Mar 2012 03:34:30 -0600 Jonathan Nieder jrnie...@gmail.com wrote: To be sure, try the gspca test version from my web site. Skippy, assuming that works (and I expect it would), could you try the attached patch against 2.6.32.y? It works like this: 0. Prerequisites: apt-get install git build-essential 1. Get the kernel, if you don't already have it: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git [snip] This asks for a lot of job. With the gspca tarball (423Kb), you just need the linux-headers. And it permits further debugging... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Mon, 05 Mar 2012 09:33:18 +0100 Hans de Goede hdego...@redhat.com wrote: I guess that motion is using the JPG compressed frames rather then the i420 like special format these cameras also support, and it looks like we don't reserve enoug space to buffer these frames. To fix this we need to enlarge the size we reserve per frame in the sn9c20x driver, edit sn9c20x.c and search for vga_mode, in that table you will find a factor 4 / 8 (its in there 3 times), change all 3 occurences to 5 / 8 and try again, then 6 / 8, etc. Normally I would be suspicious about SOF / EOF detection when we need such a factor, but the timestamps in your log exactly match 30 fps, so that seems to be fine. And in my experience with the USB bandwidth stuff the sn9c20x does seem to compress less then other JPG cams, so it makes sense that it needs bigger buffers to store the frames too. Hi Hans, The JPEG compression quality of the sn9c20x is 95%. That's why the frames are so big. Then, if the quality is not settable, I wonder why to use the JPEG format. BTW, I wonder also about the SN9C20X_I420: this format asks for a buffer greater than the native image. So, as these webcams are USB 2.0, shouldn't it be simpler to have only Bayer in the driver? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Mon, 5 Mar 2012 08:58:30 +1100 Xavion xavio...@gmail.com wrote: I can confirm that GSPCA v2.15.1 removes the bad pixels when I use Cheese or VLC. However, I'm sorry to report that the Motion problems unfortunately still remain. Is there something else I must do to overcome the below errors? I'm happy to keep testing newer GSPCA versions for you until we get this fixed. Hi again, I looked at the driver again, and thanks to Hans, I found you could easily lower the JPEG compression quality and stop buffer overflow. At line 2093 of build/sn9c20x.c (gspca test), there is: sd-quality = 95; Changing '95' to '80' should be enough. I will add this parameter as a video control as soon as it will be standard. Then you could adjust it with an external program as v4l2ucp. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Sun, 4 Mar 2012 11:25:19 +1100 Xavion xavio...@gmail.com wrote: Thanks for letting me know that this problem will be fixed in Linux v3.3. It could be several weeks before my distribution releases that kernel. Dropping back to Linux v3.1 isn't an option, as my NVIDIA driver requires Linux v3.2. Can the fix for this problem also be applied to Linux v3.2.x manually? If so, please email me the corresponding patch file and I'll test it here. Hi, You may take the gspca test version from my site: it is smaller. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.4] gspca for_v3.4
On Mon, 27 Feb 2012 21:01:21 +0100 Sylwester Nawrocki snj...@gmail.com wrote: This patch will conflict with patch: gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support from my recent pull request http://patchwork.linuxtv.org/patch/10022/ How should we proceed with that ? Do you want me to remove the above patch from my pull request, or would you rebase your change set on top of mine ? Hi Sylwester, Sorry for the problem, I thought your patch was already in the media tree. I checked the changes in zc3xx.c, and I have made many commits. So, it would be simpler if you would remove your patch. I could give you a merged one once the media tree would be updated. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.4] gspca for_v3.4
The following changes since commit a3db60bcf7671cc011ab4f848cbc40ff7ab52c1e: [media] xc5000: declare firmware configuration structures as static const (2012-02-14 17:22:46 -0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.4 for you to fetch changes up to 1b9ace2d5769c1676c96a6dc70ea84d2dea17140: gspca - zc3xx: Set the exposure at start of hv7131r (2012-02-27 12:49:49 +0100) Jean-François Moine (13): gspca - pac7302: Add new webcam 06f8:301b gspca - pac7302: Cleanup source gspca - pac7302: Simplify the function pkt_scan gspca - pac7302: Use the new video control mechanism gspca - pac7302: Do autogain setting work gspca - sonixj: Remove the jpeg control gspca - sonixj: Add exposure, gain and auto exposure for po2030n gspca - zc3xx: Adjust the JPEG decompression tables gspca - zc3xx: Do automatic transfer control for hv7131r and pas202b gspca - zc3xx: Remove the low level traces gspca - zc3xx: Cleanup source gspca - zc3xx: Fix bad sensor values when changing autogain gspca - zc3xx: Set the exposure at start of hv7131r Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/pac7302.c | 583 ++- drivers/media/video/gspca/sonixj.c | 185 +--- drivers/media/video/gspca/zc3xx.c | 295 -- 4 files changed, 511 insertions(+), 553 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] libv4lconvert: Add new rotated_90 webcam 06f8:301b
The webcam Hercules Link is handled by the driver gspca pac7302.
Signed-off-by: Jean-François Moine moin...@free.fr
---
lib/libv4lconvert/control/libv4lcontrol.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/libv4lconvert/control/libv4lcontrol.c
b/lib/libv4lconvert/control/libv4lcontrol.c
index 1788811..d10c958 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -191,6 +191,8 @@ static const struct v4lcontrol_flags_info
v4lcontrol_flags[] = {
V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
{ 0x06f8, 0x3009, 0,NULL, NULL,
V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
+ { 0x06f8, 0x301b, 0,NULL, NULL,
+ V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
{ 0x145f, 0x013c, 0,NULL, NULL,
V4LCONTROL_ROTATED_90_JPEG | V4LCONTROL_WANTS_WB, 1500 },
/* Pac7311 based devices */
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v4 3/3] gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
On Sat, 21 Jan 2012 15:45:42 +0100 Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: is this patch looking OK or you, or would you have any further remarks ? I'd like to add it to a pull request in coming week, together with remaining patches in this series plus a patch for some SoC JPEG codec driver. Please let me know if there is anything that could be changed/improved. Hi Sylwester, The patch is OK for me. Acked-by: Jean-Francois Moine moin...@free.fr Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 3/4] gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
On Fri, 6 Jan 2012 19:14:41 +0100 Sylwester Nawrocki snj...@gmail.com wrote: The JPEG compression quality value can currently be read using the VIDIOC_G_JPEGCOMP ioctl. As the quality field of struct v4l2_jpgecomp is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY control, so after the deprecation period VIDIOC_G_JPEGCOMP ioctl handler can be removed, leaving the control the only user interface for retrieving the compression quality. [snip] This patch works, but, to follow the general control mechanism in gspca, it should be better to remove the variable 'quality' of 'struct sd' and to replace all 'sd-quality' by 'sd-ctrls[QUALITY].val'. Then, initialization sd-quality = QUALITY_DEF; in sd_config() is no more useful, and there is no need to have a getjpegqual() function, the control descriptor for QUALITY having just: .set_control = setjpegqual -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 4/4] gspca: zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
On Fri, 6 Jan 2012 19:14:42 +0100 Sylwester Nawrocki snj...@gmail.com wrote: The JPEG compression quality control is currently done by means of the VIDIOC_S/G_JPEGCOMP ioctls. As the quality field of struct v4l2_jpgecomp is being deprecated, we add the V4L2_CID_JPEG_COMPRESSION_QUALITY control, so after the deprecation period VIDIOC_S/G_JPEGCOMP ioctl handlers can be removed, leaving the control the only user interface for compression quality configuration. This patch works, but it may be simplified. Instead of a '.set' pointer, the control descriptor for QUALITY may contain a '.set_control' pointing to a function which just does jpeg_set_qual(sd-jpeg_hdr, sd-ctrls[QUALITY].val); this function being also be called from the obsoleted function sd_setquality(). Also, in sd_config, there is no need to initialize the variable sd-ctrls[QUALITY].val. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 3/4] gspca: sonixj: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support
On Sat, 14 Jan 2012 18:42:20 +0100 Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: Thank you for reviewing the patches. I wasn't sure I fully understood the locking, hence I left the 'quality' field in 'struct sd' not removed. I've modified both subdrivers according to your suggestions. I would have one question before I send the corrected patches though. Unlike zc3xx, the configured quality value in sonixj driver changes dynamically, i.e. it drifts away in few seconds from whatever value the user sets. This makes me wonder if .set_control operation should be implemented for the QUALITY control, and whether to leave V4L2_CTRL_FLAG_READ_ONLY control flag or not. There seem to be not much value in setting such control for the user, but maybe it's different for other devices covered by the sonixj driver. Setting the JPEG quality in sonixj has been removed when automatic quality adjustment has been added (git commit b96cfc33e7). At this time, I let the JPEG get function, but it could have been removed as well: I don't think the users are interested by this quality, and the applications may find it looking at the quantization tables of the images. Otherwise, letting the users/applications to set this quality is dangerous: if the quality is too high, the images cannot be fully transmitted because their size is too big for the USB 1.1 channel. So, IMO, you should let the sonixj as it is, and I will remove the get_jepgcomp. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.3] gspca for_v3.3
Hi Mauro, This set includes the patch http://patchwork.linuxtv.org/patch/8858. Most of these patches concern regression fixes and should be backported to the kernel 3.2. The following changes since commit 1e73fa5d56333230854ae9460579eb2fcee8af02: [media] stb6100: Properly retrieve symbol rate (2011-12-31 17:26:23 -0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.3 Hans de Goede (8): gspca - main: rename build_ep_tb to build_isoc_ep_tb gspca - main: Correct use of interval in bandwidth calculation gspca - main: Take numerator into account in fps calculations gspca: Check dev-actconfig rather than dev-config gspca - main: Avoid clobbering all bandwidth when mic in webcam gspca - main: isoc mode devices are never low speed gspca: Add a need_max_bandwidth flag to sd_desc gscpa - sn9c20x: Add sd_isoc_init ensuring enough bw when i420 fmt Jean-François Moine (1): gspca - main: Change the bandwidth estimation of isochronous transfer. Jose Alberto Reguero (1): gspca - ov534_9: New sensor ov5621 and webcam 05a9:1550 Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/gspca.c | 70 + drivers/media/video/gspca/gspca.h |3 + drivers/media/video/gspca/nw80x.c |1 + drivers/media/video/gspca/ov534_9.c | 141 ++- drivers/media/video/gspca/sn9c20x.c | 38 +++ drivers/media/video/gspca/spca561.c |1 + drivers/media/video/gspca/stv06xx/stv06xx.c |4 +- drivers/media/video/gspca/xirlink_cit.c |4 +- 9 files changed, 236 insertions(+), 27 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 for 3.2 URGENT] gspca: Fix bulk mode cameras no longer working (regression fix)
On Thu, 29 Dec 2011 21:36:42 +0100 Hans de Goede hdego...@redhat.com wrote: The new iso bandwidth calculation code accidentally has broken support for bulk mode cameras. This has broken the following drivers: finepix, jeilinj, ovfx2, ov534, ov534_9, se401, sq905, sq905c, sq930x, stv0680, vicam. Thix patch fixes this. Fix tested with: se401, sq905, sq905c, stv0680 vicam cams. Hi Hans, Sorry for I should not be fully awoken yet, but I don't understand the problem from your fix. The patch just sets the altsetting to the highest one for bulk transfer. Does this mean that, in this case, the altsetting table created by build_ep_tb is wrong and the highest altsetting cannot selected? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.3] gspca patches and new jl2005bcd driver
On Fri, 30 Dec 2011 10:29:56 +0100 Hans de Goede hdego...@redhat.com wrote: [snip] The following changes since commit 1a5cd29631a6b75e49e6ad8a770ab9d69cda0fa2: [media] tda10021: Add support for DVB-C Annex C (2011-12-20 14:01:08 -0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.3 [snip] Theodore Kilgore (1): gspca: add jl2005bcd sub driver [snip] I have noticed some problems with the patch 2346c78dff71b003f: - there should be no change in gspca.h (addition of two empty lines) - there is no documentation about the new pixel format 'JL20' - in jl2005bcd.c, the macro 'err' is used instead of 'pr_err' (there are also spaces at end of line, but this is less important..) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.3] gspca patches and new jl2005bcd driver
On Fri, 30 Dec 2011 11:56:38 +0100 Hans de Goede hdego...@redhat.com wrote: I took it as is from Theodore, I guess we should do a separate cleanup patch on top to preserve the history / authorship. Since I'm busy testing the new isoc bandwidth stuff today, could you perhaps do a cleanup patch for this? Yes, but the first step is to remove this patch from the pull request, and only you may do it (it is only 3 git commands and an email - otherwise, it has no sense to add two empty lines in a patch and to remove them in an other one!). -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: zc3xx webcam crashes on in-focus pictures
On Sun, 11 Dec 2011 12:59:39 +0100 Johannes Bauer dfnsonfsdu...@gmx.de wrote: [snip] I have a Logitech Labtec webcam: Bus 001 Device 012: ID 046d:08a2 Logitech, Inc. Labtec Webcam Pro Which I use with the zc3xx driver on a 2.6.34 Linux: usb 1-3.2: new full speed USB device using ehci_hcd and address 12 gspca: probing 046d:08a2 zc3xx: probe sensor - 000e zc3xx: Find Sensor PAS202B input: zc3xx as /devices/pci:00/:00:1a.7/usb1/1-3/1-3.2/input/input7 gspca: video0 created gspca: found int in endpoint: 0x82, buffer_len=8, interval=10 gspca: probing 046d:08a2 gspca: probing 046d:08a2 I'm using mplayer for playback. This works nicely for the most part. However, as soon as I get things in focus (or make images of things that have sharp edges), the driver chokes -- mplayer just displays v4l2: select timeout And no more frames appear. As soon as I put the pictures back out of focus, frames are updated again. [snip] Hi Joe, Your problem seems to be tied to the JPEG compression. It should have been fixed in June, for the kernel 3.1.x (commit 93604b0fdde32). If you cannot update your kernel, you may try the gspca test version from my web page (see below). Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.3] gspca for_v3.3
The following changes since commit 36d36b884c745c507d9b3f60eb42925749f7d758: [media] tm6000: Warning cleanup (2011-11-28 21:58:54 -0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.3 Jean-François Moine (6): gspca: Remove the useless variable 'reverse_alts' gspca: Remove the useless variable 'nbalt' gspca - sonixj: Bad sensor mode at start time. gspca - sonixj: Change color control for sensor po2030n gspca - topro: Lower the frame rate in 640x480 for the tp6800 gspca - zc3xx: Bad initialization of zc305/gc0303 drivers/media/video/gspca/benq.c|7 ++- drivers/media/video/gspca/gl860/gl860.c |1 - drivers/media/video/gspca/gspca.c |3 +- drivers/media/video/gspca/gspca.h |2 - drivers/media/video/gspca/konica.c |3 - drivers/media/video/gspca/mars.c|1 - drivers/media/video/gspca/nw80x.c |1 - drivers/media/video/gspca/ov519.c |1 - drivers/media/video/gspca/se401.c | 10 +++- drivers/media/video/gspca/sonixj.c | 18 +++-- drivers/media/video/gspca/spca561.c |1 - drivers/media/video/gspca/topro.c |2 +- drivers/media/video/gspca/xirlink_cit.c |2 - drivers/media/video/gspca/zc3xx.c | 117 +-- 14 files changed, 78 insertions(+), 91 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] JPEG encoders control class
On Mon, 28 Nov 2011 19:48:28 +0100 Luca Risolia luca.riso...@studio.unibo.it wrote: Note that et61x251 and sn9c102 are going to be deprecated and removed at some time in the future (gspca will support these devices). Has this been discussed yet? Also, last time I tried the gspca driver with a number of V4L2-compliant applications, it did not support at all or work well for all the sn9c1xx-based devices I have here, which are both controllers and sensors the manufacturer sent to me when developing the driver with their collaboration. I also don't understand why the gspca driver has been accepted in the mainline kernel in the first place, despite the fact the sn9c1xx has been present in the kernel since long time and already supported many devices at the time the gspca was submitted. Maybe it's better to remove the duplicate code form the gspca driver and add the different parts (if any) to the sn9c1xx. Hi Luca, Removing the sn9c102 is on the way for a long time. I think we were just waiting for a message from you! Why is gspca in the kernel? Because of its design: all the system / v4l2 interface are in the main driver, while the subdrivers only deal with the specific device exchanges. This simplifies development and maintenance. At the beginning, the gspca did not handle the sn9c102 webcams (but some Sonix based webcams were already handled only by gspca). From time to time, there were users saying that their webcams did not work correctly with the sn9c102, and that they worked better with gspca. So, we moved their IDs to gspca. Now, the sonixjb and sonixj subdrivers handle many more sensors than the sn9c102 with less problems. Indeed, there are still problems, but, as I have only 3 webcams (none with Sonix chips), I must wait for user reports and fix them. As you have some Sonix based webcams, and as you had contact with the manufacturers, you should easily find if there are wrong sequences in the gspca subdrivers and/or what could be done for a better support. This would help... Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Cleanup proposal for media/gspca
On Wed, 16 Nov 2011 15:19:04 -0300
Ezequiel García elezegar...@gmail.com wrote:
In 'media/video/gspca/gspca.c' I really hated this cast (maybe because
I am too dumb to understand it):
gspca_dev = (struct gspca_dev *) video_devdata(file);
wich is only legal because a struct video_device is the first member
of gspca_dev. IMHO, this is 'unnecesary obfuscation'.
The thing is the driver is surely working fine and there is no good
reasong for the change.
Is it ok to submit a patchset to change this? Something like this:
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 881e04c..5d962ce 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1304,9 +1306,11 @@ static void gspca_release(struct video_device *vfd)
static int dev_open(struct file *file)
{
struct gspca_dev *gspca_dev;
+ struct video_device *vdev;
PDEBUG(D_STREAM, [%s] open, current-comm);
- gspca_dev = (struct gspca_dev *) video_devdata(file);
+ vdev = video_devdata(file);
+ gspca_dev = video_get_drvdata(vdev);
if (!gspca_dev-present)
Hi Ezequiel,
You are right, the cast is not a good way (and there are a lot of them
in the gspca subdrivers), but your patch does not work because the
'private_data' of the device is not initialized (there is no call to
video_set_drvdata).
So, a possible cleanup could be:
- gspca_dev = (struct gspca_dev *) video_devdata(file);
+ gspca_dev = container_of(video_devdata(file), struct gspca_dev, vdev);
Is it OK for you?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.2] gspca for_v3.2
Hi Mauro, This set includes the patches: http://patchwork.linuxtv.org/patch/7358 http://patchwork.linuxtv.org/patch/114 Cheers. The following changes since commit e553000a14ead0e265a8aa4d241c7b3221e233e3: [media] sr030pc30: Remove empty s_stream op (2011-09-21 12:48:45 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.2 Frank Schaefer (1): gspca - sn9c20x: Fix status LED device 0c45:62b3. Jean-François Moine (10): gspca - benq: Remove the useless function sd_isoc_init gspca - main: Use a better altsetting for image transfer gspca - main: Handle the xHCI error on usb_set_interface() gspca - topro: New subdriver for Topro webcams gspca - spca1528: Increase the status waiting time gspca - spca1528: Add some comments and update copyright gspca - spca1528: Change the JPEG quality of the images gspca - spca1528: Don't force the USB transfer alternate setting gspca - main: Version change to 2.14.0 gspca - main: Display the subdriver name and version at probe time Wolfram Sang (1): gspca - zc3xx: New webcam 03f0:1b07 HP Premium Starter Cam Documentation/video4linux/gspca.txt |3 + drivers/media/video/gspca/Kconfig| 10 + drivers/media/video/gspca/Makefile |2 + drivers/media/video/gspca/benq.c | 15 - drivers/media/video/gspca/gspca.c| 225 ++- drivers/media/video/gspca/sn9c20x.c |2 +- drivers/media/video/gspca/spca1528.c | 26 +- drivers/media/video/gspca/topro.c| 4989 ++ drivers/media/video/gspca/zc3xx.c|1 + 9 files changed, 5180 insertions(+), 93 deletions(-) create mode 100644 drivers/media/video/gspca/topro.c -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Question about USB interface index restriction in gspca
On Mon, 19 Sep 2011 22:13:12 +0200 Frank Schäfer fschaefer@googlemail.com wrote: So, if your webcam is in the 99.99% which use the interface 0, use gspca_dev_probe(), otherwise, YOU know the right interface, so, call gspca_dev_probe2(). Isn't it also possible that we don't know the right interface and it is not interface 0 ? ;-) I hope that the interface does not change each time you unplug/replug the webcam :), but if different webcams with a same device ID may use different interfaces, you should have to develop specific code in the subdriver... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Question about USB interface index restriction in gspca
On Thu, 15 Sep 2011 23:46:57 +0200 Frank Schäfer fschaefer@googlemail.com wrote: For webcam devices, the interface class is meaningful only when set to USB_CLASS_VIDEO (UVC). Otherwise, I saw many different values. Does that mean that there are devices out in the wild that report for example USB_CLASS_WIRELESS_CONTROLLER for the video interface ??? For video on a particular interface, the subdriver must call the function gspca_dev_probe2() as this is done in spca1528 and xirlink_cit. Hmm, sure, that would work... But wouldn't it be better to improve the interface check and merge the two probing functions ? The subdrivers can decide which interfaces are (not) probed and the gspca core does plausability checks (e.g. bulk/isoc endpoint ? usb class ?). Generally, the first interface is the video device, and the function gspca_dev_probe() works well enough. The function gspca_dev_probe2() is used by only 2 subdrivers and the way to find the correct interface is not easy. For example, the webcam 047d:5003 (subdriver spca1528) has 3 interfaces (class vendor specific). The 1st one has only one altsetting with only one interrupt endpoint, the 2nd one has 8 altsettings, each with only one isochronous endpoint, and the last one has one altsetting with 3 endpoints (bulk in, bulk out and interrupt). At the first glance, it is easy to know the right interface, but writing generic code to handle such webcams seems rather complicated. So, if your webcam is in the 99.99% which use the interface 0, use gspca_dev_probe(), otherwise, YOU know the right interface, so, call gspca_dev_probe2(). Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Question about USB interface index restriction in gspca
On Tue, 13 Sep 2011 21:14:28 +0200 Frank Schäfer fschaefer@googlemail.com wrote: I have a question about the following code in gspca.c: in function gspca_dev_probe(...): ... /* the USB video interface must be the first one */ if (dev-config-desc.bNumInterfaces != 1 intf-cur_altsetting-desc.bInterfaceNumber != 0) return -ENODEV; ... Is there a special reason for not allowing devices with USB interface index 0 for video ? I'm experimenting with a device that has the video interface at index 3 and two audio interfaces at index 0 and 1 (index two is missing !). And the follow-up question: can we assume that all device handled by the gspca-driver have vendor specific video interfaces ? Then we could change the code to ... /* the USB video interface must be of class vendor */ if (intf-cur_altsetting-desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC) return -ENODEV; ... Hi Frank, For webcam devices, the interface class is meaningful only when set to USB_CLASS_VIDEO (UVC). Otherwise, I saw many different values. For video on a particular interface, the subdriver must call the function gspca_dev_probe2() as this is done in spca1528 and xirlink_cit. Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] gspca/zc3xx: add usb_id for HP Premium Starter Cam
On Fri, 9 Sep 2011 11:33:15 +0200 Wolfram Sang w.s...@pengutronix.de wrote: On Sat, Jul 02, 2011 at 02:02:00PM +0200, Wolfram Sang wrote: Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Jean-Francois Moine moin...@free.fr --- Ping. I can't find it in the git-repos on linuxtv.org? Hi Wolfram, I asked to pull your patch in linux 3.1 on Sun, 3 Jul 2011: http://www.spinics.net/lists/linux-media/msg34914.html but, it seems that only the patches relative to ov519 and jeilinj have been applied (the patch for sn9c20x has been lost too). Hi Mauro, I removed Wolfram's and Franck's patches from my repository. Have you still these patches or must I resubmit them (and the 2 other pending request)? Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: spca1528 device (Device 015: ID 04fc:1528 Sunplus Technology)..libv4l2: error turning on stream: Timer expired issue
On Sun, 04 Sep 2011 15:39:30 -0400 Mauricio Henriquez buhochil...@gmail.com wrote: Recently I'm trying to make work a Sunplus crappy mini HD USB camera, lsusb list this info related to the device: Picture Transfer Protocol (PIMA 15470) Bus 001 Device 015: ID 04fc:1528 Sunplus Technology Co., Ltd idVendor 0x04fc Sunplus Technology Co., Ltd idProduct 0x1528 bcdDevice1.00 iManufacturer 1 Sunplus Co Ltd iProduct2 General Image Devic iSerial 0 ... Using the gspca-2.13.6 on my Fed12 (2.6.31.6-166.fc12.i686.PAE kernel), the device is listed as /dev/video1 and no error doing a dmesg...but trying to make it work, let say with xawtv, I get: [snip] Hi Mauricio, The problem seems tied to the alternate setting. It must be the #3 while the lastest versions of gspca compute a best one. May you apply the following patch to gspca-2.13.6? --8-- --- build/spca1528.c.orig 2011-09-05 08:41:54.0 +0200 +++ build/spca1528.c2011-09-05 08:53:51.0 +0200 @@ -307,8 +307,6 @@ sd-color = COLOR_DEF; sd-sharpness = SHARPNESS_DEF; - gspca_dev-nbalt = 4; /* use alternate setting 3 */ - return 0; } @@ -349,6 +347,9 @@ reg_r(gspca_dev, 0x25, 0x0004, 1); reg_wb(gspca_dev, 0x27, 0x, 0x, 0x06); reg_r(gspca_dev, 0x27, 0x, 1); + + gspca_dev-alt = 4; /* use alternate setting 3 */ + return gspca_dev-usb_err; } --8-- (Theodore, this webcam may work in mass storage mode with ID 04fc:0171. In webcam mode with ID 04fc:1528, it offers 3 interfaces: interface 0 contains only an interrupt endpoint, interface 1 is the webcam with only isochronous endpoints and interface 2 contains bulk in, bulk out and interrupt in endpoints - I don't know how to use the interfaces 0 and 2, but sure the interface 2 could be used to access the camera images) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: spca1528 device (Device 015: ID 04fc:1528 Sunplus Technology)..libv4l2: error turning on stream: Timer expired issue
On Mon, 05 Sep 2011 11:33:49 -0400 Mauricio Henriquez buhochil...@gmail.com wrote: Thanks Jean, yeap I apply the patch, but still the same kind of messages about timeout sing xawtv or svv: OK Mauricio. So, I need more information. May you set the gspca debug level to 0x0f echo 0x0f /sys/module/gspca_main/parameters/debug run 'svv' and send me the kernel messages starting from the last gspca open? Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.2] [media] Fix wrong register mask in gspca/sonixj.c
On Mon, 29 Aug 2011 09:57:26 -0700 (PDT) Luiz Ramos lramos.p...@yahoo.com.br wrote: Mauro: To be fair, this patch itself isn't sufficient to solve the problem described in the text provided. One other patch is necessary to get this goal accomplished, named, one published in this same thread in 2011-07-18. This later fix is now embedded in a wider patch provided by Jean-François Moine in 2011-08-10. I'd suggest to change the text below, if possible, mentioning only something like fix wrong register masking. Hi Mauro, Sorry, I did not notice the automatic commit report. I submitted Luiz's patch and the darkness fix in 2 git patch requests on Wed, 10 Aug for 3.1 and on Fri, 12 Aug for 3.2: gspca - sonixj: Fix wrong register mask for sensor om6802 gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 06/14] [media] cx18: Use current logging styles
On Sat, 27 Aug 2011 09:42:32 -0700 Joe Perches j...@perches.com wrote: Andy, I fully understand how this stuff works. You apparently don't (yet). Look at include/linux/printk.h #ifndef pr_fmt #define pr_fmt(fmt) fmt #endif A default empty define is used when one is not specified before printk.h is included. kernel.h includes printk.h Hi Joe, Yes, but, what if pr_fmt is redefined in some driver specific include by: #undef pr_fmt #define pr_fmt(fmt) KBUILD_MODNAME : fmt (in gspca.h for example) ? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 14/14] [media] gspca: Use current logging styles
On Sun, 21 Aug 2011 15:56:57 -0700 Joe Perches j...@perches.com wrote: Add pr_fmt. Convert usb style logging macros to pr_level. Remove now unused old usb style logging macros. Hi Joe, Sorry, but I do not see the advantages of your patch. For gspca, the source files are bigger, and the only visible change is the display of the real module name instead of the name defined by hand (this change may have been done just in gspca.h). Also, I think that defining 'pr_fmt' in each source file is not a good idea... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 14/14] [media] gspca: Use current logging styles
On Mon, 22 Aug 2011 08:20:28 -0700 Joe Perches j...@perches.com wrote: The primary current advantage is style standardization both in code and dmesg output. Future changes to printk.h will reduce object sizes by centralizing the prefix to a singleton and emitting it only in pr_level. Hi Joe, OK, I did not see that you started such changes a long time ago! Thanks and good luck! Acked-by: Jean-Francois Moine moin...@free.fr -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: Image and webcam freeze on Ubuntu with Logitech QuickCam Communicate STX
On Thu, 18 Aug 2011 12:31:51 +0200 Damien Cassou damien.cas...@gmail.com wrote: my Logitech QuickCam Communicate STX works perfectly well for a few minutes when I use it. However, after that the image is frozen and I can't make it work again until I reboot the system (before rebooting, the webcam has a blue color indicating it is working even though I can't get anything displayed). What can I do? A way to avoid rebooting would be a very welcomed workaround. Details below: - because of this bug I compiled the driver manually to see if the bug was fixed. I compiled it from gspca-2.13.6.tar.gz - ubuntu 11.04, all updates installed - dmesg displays a lot of the following line: gspca: ISOC data error: [0] len=0, status=-18 - lsusb returns: Bus 003 Device 002: ID 046d:08ad Logitech, Inc. QuickCam Communicate STX Hi Damien, I need more information. May you send me the kernel messages starting from the webcam connection up to the first ISOC data errors? Please, use the gspca 2.13.6 and set the debug level to 0x0f: echo 0x0f /sys/module/gspca_main/parameters/debug (then, unplug / replug the webcam) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.2] gspca for_v3.2
The following changes since commit 9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e: [media] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028 (2011-08-06 09:52:47 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.2 Jean-François Moine (15): gspca - ov519: Fix LED inversion of some ov519 webcams gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 gspca - jeilinj: Cleanup code gspca - sonixj: Adjust the contrast control gspca - sonixj: Increase the exposure for sensor soi768 gspca - sonixj: Cleanup source and remove useless instructions gspca - benq: Remove the useless function sd_isoc_init gspca - kinect: Remove the gspca_debug definition gspca - ov534_9: Use the new control mechanism gspca - ov534_9: New sensor ov9712 and new webcam 05a9:8065 gspca - main: Fix the isochronous transfer interval gspca - main: Better values for V4L2_FMT_FLAG_COMPRESSED gspca - main: Use a better altsetting for image transfer gspca - main: Handle the xHCI error on usb_set_interface() gspca - tp6800: New subdriver for Topro webcams Luiz Carlos Ramos (1): gspca - sonixj: Fix wrong register mask for sensor om6802 Documentation/video4linux/gspca.txt |3 + drivers/media/video/gspca/Kconfig |9 + drivers/media/video/gspca/Makefile |2 + drivers/media/video/gspca/benq.c| 15 - drivers/media/video/gspca/gspca.c | 234 ++- drivers/media/video/gspca/jeilinj.c | 10 +- drivers/media/video/gspca/kinect.c |5 - drivers/media/video/gspca/ov519.c | 22 +- drivers/media/video/gspca/ov534_9.c | 504 ++-- drivers/media/video/gspca/sonixj.c | 29 +- drivers/media/video/gspca/tp6800.c | 4989 +++ 11 files changed, 5430 insertions(+), 392 deletions(-) create mode 100644 drivers/media/video/gspca/tp6800.c -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.1] gspca for_v3.1
The following changes since commit 46540f7ac646ada7f22912ea7ea9b761ff5c4718: [media] ir-mce_kbd-decoder: include module.h for its facilities (2011-07-29 12:52:23 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.1 Jean-François Moine (2): gspca - ov519: Fix LED inversion of some ov519 webcams gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 Luiz Carlos Ramos (1): gspca - sonixj: Fix wrong register mask for sensor om6802 drivers/media/video/gspca/ov519.c | 22 ++ drivers/media/video/gspca/sonixj.c |6 +- 2 files changed, 15 insertions(+), 13 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [Workshop-2011] Media Subsystem Workshop 2011
On Thu, 04 Aug 2011 09:40:18 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: What we need for this is a simple API (new v4l ioctl's I guess) for the stillcam mode of these dual mode cameras (stillcam + webcam). So that the webcam drivers can grow code to also allow access to the stored pictures, which were taken in standalone (iow not connected to usb) stillcam mode. This API does not need to be terribly complex. AFAIK all of the currently supported dual cam cameras don't have filenames only picture numbers, so the API could consist of a simple, get highest picture nr, is picture X present (some slots may contain deleted pictures), get picture X, delete picture X, delete all API. That sounds to work. I would map it on a way close to the controls API (or like the DVB FE_[GET|SET]_PROPERTY API), as this would make easier to expand it in the future, if we start to see webcams with file names or other things like that. I did not follow all the thread, but I was wondering about an other solution: what about offering both USB mass storage and webcam accesses? When a dual-mode webcam is plugged in, the driver creates two devices, the video device /dev/videox and the volume /dev/sdx. When the webcam is opened, the volume cannot be mounted. When the volume is mounted, the webcam cannot be opened. There is no need for a specific API. As Mauro said: For those, we may eventually need some sort of locking between the USB storage and V4L. That's all. By where am I wrong? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] Fix wrong register mask in gspca/sonixj.c
On Thu, 21 Jul 2011 03:43:13 -0700 (PDT) Luiz Ramos lramos.p...@yahoo.com.br wrote: Now my doubts. Unless I misunderstood something, it seems these are the our assumptions regarding reg01 and reg17: - reg01 bit 6 is set when bridge runs at 48 MHz; if reset, 24 MHz - reg17 bits 0..4 is a mask for dividing a sensor clock of 48 MHz, so - if reg17 = x | 01 then clock = 48 MHz - if reg17 = x | 02 then clock = 24 MHz - if reg17 = x | 04 then clock = 12 MHz Putting some printk at the code version 2.13.3, the values of these registers at the last command are: - at 640x480 ... reg01 = 0x66 reg17 = 0x64 - at 320x240/160x120 ... reg01 = 0x26 reg17 = 0x61 So, at 640x480 the bridge would be running at 48 MHz and the sensor at 12 MHz. At lower resolutions the bridge would be running at 24 MHz and the sensor at 48 MHz. It seems that this is not what we'd like to do. From the documentation, the register 17 contains a divide factor of the bridge clock (the sensor has no clock). So: - reg01 = 0x66 reg17 = 0x64 -- bridge 48 MHz sensor 12 MHz - reg01 = 0x26 reg17 = 0x61 -- bridge 24 MHz sensor 24 MHz I made some experiences, and noticed that: - making reg17 = 0x62 (sensor clock at 24 MHz) and reg01 = 0x26 (bridge clock at 24 MHz) at 320x240 and lower makes it work again. I think this reaches the goal of having both clocks at 24 MHz, but at 10 fps In fact, bridge 24 MHz and sensor 12 MHz. This seems the best configuration. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] Fix wrong register mask in gspca/sonixj.c
On Mon, 18 Jul 2011 18:39:14 -0700 (PDT) Luiz Ramos lramos.p...@yahoo.com.br wrote: [snip] I noticed that in 640x480 the device worked fine, but in 320x240 and 160x120 it didn't (I mean: the image is dark). Or'ing reg17 with 0x04 in line 2535 (as it's currently done for VGA) is sufficient to make the webcam work again. The change could be like that: [snip] However, the frame rates get limited to 10 fps. Without that change, and in 320x240 and 160x120, they reach 20 fps (of darkness). I can't see what or'ing that register means, and what's the relationship between this and the webcam darkness. It seems that these bits control some kind of clock; this can be read in the program comments. One other argument in favour of this assumption is the fact that the frame rate changes accordingly to the value of these bits. But I can't see how this relates to exposure. For my purposes, I'll stay with that change; it's sufficient for my purposes. If you know what I did, please advise me. :-) Hi Luiz, You changed the sensor clock from 24MHz to 12MHz. The clocks of the sensor and the bridge may have different values. In 640x480, the bridge clock is 48MHz (reg01) and the sensor clock is 12MHz (reg17: clock / 4). Previously, in 320x240, the bridge clock was 48MHz and the sensor clock 24 MHz (reg17: clock / 2). I think that the sensor clock must stay the same for a same frame rate. So, what about changing the bridge clock only, i.e. bridge clock 24MHZ (reg01) and sensor clock 24MHz (reg17: clock / 1)? That's what I coded in the last gspca test version (2.13.3) which is available in my web site (see below). May you try it? Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] Fix wrong register mask in gspca/sonixj.c
On Thu, 14 Jul 2011 19:08:39 -0700 (PDT) Luiz Ramos luizzra...@yahoo.com.br wrote: Signed-off-by: Luiz Carlos Ramos lramos.prof at yahoo.com.br --- a/drivers/media/video/gspca/sonixj.c2011-07-14 13:14:41.0 -0300 +++ b/drivers/media/video/gspca/sonixj.c2011-07-14 13:22:26.0 -0300 @@ -2386,7 +2386,7 @@ static int sd_start(struct gspca_dev *gs reg_w1(gspca_dev, 0x01, 0x22); msleep(100); reg01 = SCL_SEL_OD | S_PDN_INV; - reg17 = MCK_SIZE_MASK; + reg17 = ~MCK_SIZE_MASK; /* that is, reset bits 4..0 */ reg17 |= 0x04; /* clock / 4 */ break; } Acked-by: Jean-François Moine moin...@free.fr Luiz, may you get and try the last gspca tarball from my web site? (you will have to redo your patch, because I have not yet uploaded it) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] Fix wrong register mask in gspca/sonixj.c
On Fri, 15 Jul 2011 02:57:43 -0700 (PDT) Luiz Ramos lramos.p...@yahoo.com.br wrote: Ok, I'm now grabbing this tarball: http://moinejf.free.fr/gspca-2.13.2.tar.gz. The site also features a (some) git repository(ies) but I understood you mean the test version, is it right? Yes. The tarball is simpler to compile and install. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.0] gspca for_v3.0
The following changes since commit 215c52702775556f4caf5872cc84fa8810e6fc7d: [media] V4L/videobuf2-memops: use pr_debug for debug messages (2011-06-01 18:20:34 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.0 Jean-François Moine (2): gspca - ov519: Fix sensor detection problems gspca - ov519: Fix a LED inversion drivers/media/video/gspca/ov519.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
