Re: [PATCH] [media] adv7180: free an interrupt on failure paths in init_device()
On 03/14/2014 10:04 PM, Alexey Khoroshilov wrote: There is request_irq() in init_device(), but the interrupt is not removed on failure paths. The patch adds proper error handling. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru Hi, Thanks for the patch. It's actually worse than that. request_irq should not be called in init_device() since init_device() is also called on resume(). The request_irq call should be moved to probe() and be called after init device. I've recently made some modifications to this part of the driver (switched to threaded IRQs), so make sure you generate the patch against the media/master tree. Thanks, - Lars --- drivers/media/i2c/adv7180.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c index d7d99f1c69e4..e462392ba043 100644 --- a/drivers/media/i2c/adv7180.c +++ b/drivers/media/i2c/adv7180.c @@ -541,40 +541,44 @@ static int init_device(struct i2c_client *client, struct adv7180_state *state) ret = i2c_smbus_write_byte_data(client, ADV7180_ADI_CTRL_REG, ADV7180_ADI_CTRL_IRQ_SPACE); if (ret 0) - return ret; + goto err; /* config the Interrupt pin to be active low */ ret = i2c_smbus_write_byte_data(client, ADV7180_ICONF1_ADI, ADV7180_ICONF1_ACTIVE_LOW | ADV7180_ICONF1_PSYNC_ONLY); if (ret 0) - return ret; + goto err; ret = i2c_smbus_write_byte_data(client, ADV7180_IMR1_ADI, 0); if (ret 0) - return ret; + goto err; ret = i2c_smbus_write_byte_data(client, ADV7180_IMR2_ADI, 0); if (ret 0) - return ret; + goto err; /* enable AD change interrupts interrupts */ ret = i2c_smbus_write_byte_data(client, ADV7180_IMR3_ADI, ADV7180_IRQ3_AD_CHANGE); if (ret 0) - return ret; + goto err; ret = i2c_smbus_write_byte_data(client, ADV7180_IMR4_ADI, 0); if (ret 0) - return ret; + goto err; ret = i2c_smbus_write_byte_data(client, ADV7180_ADI_CTRL_REG, 0); if (ret 0) - return ret; + goto err; } return 0; + +err: + free_irq(state-irq, state); + return ret; } static int adv7180_probe(struct i2c_client *client, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Fri, 21 Mar 2014 00:26:12 +0100, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Thursday 20 March 2014 23:12:50 Grant Likely wrote: On Thu, 20 Mar 2014 19:52:53 +0100, Laurent Pinchart wrote: Then we might not be talking about the same thing. I'm talking about DT bindings to represent the topology of the device, not how drivers are wired together. Possibly. I'm certainly confused now. You brought up the component helpers in drivers/base/component.c, so I thought working out dependencies is part of the purpose of this binding. Everything I've heard so far has given me the impression that the graph binding is tied up with knowing when all of the devices exist. The two are related, you're of course right about that. We're not really moving forward here. Part of our disagreement comes in my opinion from having different requirements and different views of the problem, caused by experiences with different kind of devices. This is much easier to solve by sitting around the same table than discussing on mailing lists. I would propose a meeting at the ELC but that's still a bit far away and would delay progress by more than one month, which is probably not acceptable. I can reply to the e-mail where I've drawn one use case I have to deal with to detail my needs if that can help. Alternatively the UK isn't that far away and I could jump in a train if you can provide tea for the discussion :-) I'm game for that, but it is a long train ride. I'm up in Aberdeen which is 8 hours from London by train. Also, I'm travelling next week to California (Collaboration summit), so it will have to be in 2 weeks time. Why don't we instead try a Google Hangout or a phone call today. Anywhere between 11:30 and 14:00 GMT would work for me. I'd offer to provide the tea, but I haven't quite perfected transporter technology yet. g. -- 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 6/8] leds: Add support for max77693 mfd flash cell
On 03/20/2014 04:34 PM, Lee Jones wrote:
On Thu, 20 Mar 2014, Jacek Anaszewski wrote:
This patch adds led-flash support to Maxim max77693 chipset.
Device can be exposed to user space through LED subsystem
sysfs interface or through V4L2 subdevice when the support
for Multimedia Framework is enabled. Device supports up to
two leds which can work in flash and torch mode. Leds can
be triggered externally or by software.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: SangYoung Son hello@smasung.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/leds/Kconfig |9 +
drivers/leds/Makefile|1 +
drivers/leds/leds-max77693.c | 768 ++
drivers/mfd/max77693.c | 21 +-
include/linux/mfd/max77693.h | 32 ++
5 files changed, 825 insertions(+), 6 deletions(-)
create mode 100644 drivers/leds/leds-max77693.c
[...]
diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
index c5535f0..6fa92d3 100644
--- a/drivers/mfd/max77693.c
+++ b/drivers/mfd/max77693.c
@@ -41,12 +41,21 @@
#define I2C_ADDR_MUIC (0x4A 1)
#define I2C_ADDR_HAPTIC (0x90 1)
-static const struct mfd_cell max77693_devs[] = {
- { .name = max77693-pmic, },
- { .name = max77693-charger, },
- { .name = max77693-flash, },
- { .name = max77693-muic, },
- { .name = max77693-haptic, },
+enum mfd_devs_idx {
+ IDX_PMIC,
+ IDX_CHARGER,
+ IDX_LED,
+ IDX_MUIC,
+ IDX_HAPTIC,
+};
+
+static struct mfd_cell max77693_devs[] = {
+ [IDX_PMIC] = { .name = max77693-pmic, },
+ [IDX_CHARGER] = { .name = max77693-charger, },
+ [IDX_LED] = { .name = max77693-led,
+ .of_compatible = maxim,max77693-led},
+ [IDX_MUIC] = { .name = max77693-muic, },
+ [IDX_HAPTIC]= { .name = max77693-haptic, },
};
What is the purpose of this change?
Introducing mfd_devs_idx itself is a cosmetic change, which
actually could be avoided. Initialization of the of_compatible field
is required for the led driver to get matched properly. And as I've
just realized also max77693-flash name should be preserved.
I will fix this in the next version of the patch.
Thanks,
Jacek Anaszewski
--
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 1/8] leds: Add sysfs and kernel internal API for flash LEDs
On 03/20/2014 04:28 PM, Richard Purdie wrote: On Thu, 2014-03-20 at 15:51 +0100, Jacek Anaszewski wrote: Some LED devices support two operation modes - torch and flash. This patch provides support for flash LED devices in the LED subsystem by introducing new sysfs attributes and kernel internal interface. The attributes being introduced are: flash_mode, flash_timeout, max_flash_timeout, flash_fault and hw_triggered. The modifications aim to be compatible with V4L2 framework requirements related to the flash devices management. The design assumes that V4L2 driver can take of the LED class device control and communicate with it through the kernel internal interface. The LED sysfs interface is made unavailable then. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net --- drivers/leds/led-class.c| 216 +-- drivers/leds/led-core.c | 124 +++-- drivers/leds/led-triggers.c | 17 +++- drivers/leds/leds.h |9 ++ include/linux/leds.h| 136 +++ 5 files changed, 486 insertions(+), 16 deletions(-) It seems rather sad to have to insert that amount of code into the core LED files for something which only a small number of LEDs actually use. This will increase the footprint of the core LED code significantly. Is it not possible to add this as a module/extension to the LED core rather than completely entangling them? OK, I'll try to decouple it. Thanks, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] MFC cleanup of reqbuf, streamon, open and close
This patch series contain some fixes and cleanups done to the s5p-mfc decoder in reqbuf, streamon and open/close commands. These patches are present in the ChromeOS tree and just rebased onto the media-tree and tested. Pawel Osciak (3): [media] s5p-mfc: Fixes for decode REQBUFS. [media] s5p-mfc: Extract open/close MFC instance commands. [media] s5p-mfc: Don't allocate codec buffers on STREAMON. drivers/media/platform/s5p-mfc/s5p_mfc.c | 29 +--- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 62 +++ drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h |3 + drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 216 - drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 18 +-- 5 files changed, 182 insertions(+), 146 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] s5p-mfc: Extract open/close MFC instance commands.
From: Pawel Osciak posc...@chromium.org
This is in preparation for a new flow to fix issues with streamon, which
should not be allocating buffer memory.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 19 +---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 61 +
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h |3 ++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 28 +++-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 18 ++--
5 files changed, 74 insertions(+), 55 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index d636789..04030f5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -872,24 +872,7 @@ static int s5p_mfc_release(struct file *file)
* return instance and free resources */
if (ctx-inst_no != MFC_NO_INSTANCE_SET) {
mfc_debug(2, Has to free instance\n);
- ctx-state = MFCINST_RETURN_INST;
- set_work_bit_irqsave(ctx);
- s5p_mfc_clean_ctx_int_flags(ctx);
- s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
- /* Wait until instance is returned or timeout occurred */
- if (s5p_mfc_wait_for_done_ctx
- (ctx, S5P_MFC_R2H_CMD_CLOSE_INSTANCE_RET, 0)) {
- s5p_mfc_clock_off();
- mfc_err(Err returning instance\n);
- }
- mfc_debug(2, After free instance\n);
- /* Free resources */
- s5p_mfc_hw_call(dev-mfc_ops, release_codec_buffers, ctx);
- s5p_mfc_hw_call(dev-mfc_ops, release_instance_buffer, ctx);
- if (ctx-type == MFCINST_DECODER)
- s5p_mfc_hw_call(dev-mfc_ops, release_dec_desc_buffer,
- ctx);
-
+ s5p_mfc_close_mfc_inst(dev, ctx);
ctx-inst_no = MFC_NO_INSTANCE_SET;
}
/* hardware locking scheme */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index ba1d302..ccbfcb3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -402,3 +402,64 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev)
return 0;
}
+int s5p_mfc_open_mfc_inst(struct s5p_mfc_dev *dev, struct s5p_mfc_ctx *ctx)
+{
+ int ret = 0;
+
+ ret = s5p_mfc_hw_call(dev-mfc_ops, alloc_instance_buffer, ctx);
+ if (ret) {
+ mfc_err(Failed allocating instance buffer\n);
+ goto err;
+ }
+
+ if (ctx-type == MFCINST_DECODER) {
+ ret = s5p_mfc_hw_call(dev-mfc_ops,
+ alloc_dec_temp_buffers, ctx);
+ if (ret) {
+ mfc_err(Failed allocating temporary buffers\n);
+ goto err_free_inst_buf;
+ }
+ }
+
+ set_work_bit_irqsave(ctx);
+ s5p_mfc_clean_ctx_int_flags(ctx);
+ s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
+ if (s5p_mfc_wait_for_done_ctx(ctx,
+ S5P_MFC_R2H_CMD_OPEN_INSTANCE_RET, 0)) {
+ /* Error or timeout */
+ mfc_err(Error getting instance from hardware\n);
+ ret = -EIO;
+ goto err_free_desc_buf;
+ }
+
+ mfc_debug(2, Got instance number: %d\n, ctx-inst_no);
+ return ret;
+
+err_free_desc_buf:
+ if (ctx-type == MFCINST_DECODER)
+ s5p_mfc_hw_call(dev-mfc_ops, release_dec_desc_buffer, ctx);
+err_free_inst_buf:
+ s5p_mfc_hw_call(dev-mfc_ops, release_instance_buffer, ctx);
+err:
+ return ret;
+}
+
+void s5p_mfc_close_mfc_inst(struct s5p_mfc_dev *dev, struct s5p_mfc_ctx *ctx)
+{
+ ctx-state = MFCINST_RETURN_INST;
+ set_work_bit_irqsave(ctx);
+ s5p_mfc_clean_ctx_int_flags(ctx);
+ s5p_mfc_hw_call(dev-mfc_ops, try_run, dev);
+ /* Wait until instance is returned or timeout occurred */
+ if (s5p_mfc_wait_for_done_ctx(ctx,
+ S5P_MFC_R2H_CMD_CLOSE_INSTANCE_RET, 0))
+ mfc_err(Err returning instance\n);
+
+ /* Free resources */
+ s5p_mfc_hw_call(dev-mfc_ops, release_codec_buffers, ctx);
+ s5p_mfc_hw_call(dev-mfc_ops, release_instance_buffer, ctx);
+ if (ctx-type == MFCINST_DECODER)
+ s5p_mfc_hw_call(dev-mfc_ops, release_dec_desc_buffer, ctx);
+
+ ctx-state = MFCINST_FREE;
+}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
index 6a9b6f8..8e5df04 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
@@ -28,4 +28,7 @@ int s5p_mfc_wakeup(struct s5p_mfc_dev *dev);
int
Re: [PATCH/RFC 6/8] leds: Add support for max77693 mfd flash cell
This patch adds led-flash support to Maxim max77693 chipset.
Device can be exposed to user space through LED subsystem
sysfs interface or through V4L2 subdevice when the support
for Multimedia Framework is enabled. Device supports up to
two leds which can work in flash and torch mode. Leds can
be triggered externally or by software.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: SangYoung Son hello@smasung.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/leds/Kconfig |9 +
drivers/leds/Makefile|1 +
drivers/leds/leds-max77693.c | 768
++
drivers/mfd/max77693.c | 21 +-
include/linux/mfd/max77693.h | 32 ++
5 files changed, 825 insertions(+), 6 deletions(-)
create mode 100644 drivers/leds/leds-max77693.c
[...]
-static const struct mfd_cell max77693_devs[] = {
- { .name = max77693-pmic, },
- { .name = max77693-charger, },
- { .name = max77693-flash, },
- { .name = max77693-muic, },
- { .name = max77693-haptic, },
+enum mfd_devs_idx {
+ IDX_PMIC,
+ IDX_CHARGER,
+ IDX_LED,
+ IDX_MUIC,
+ IDX_HAPTIC,
+};
+
+static struct mfd_cell max77693_devs[] = {
+ [IDX_PMIC] = { .name = max77693-pmic, },
+ [IDX_CHARGER] = { .name = max77693-charger, },
+ [IDX_LED] = { .name = max77693-led,
+ .of_compatible = maxim,max77693-led},
+ [IDX_MUIC] = { .name = max77693-muic, },
+ [IDX_HAPTIC]= { .name = max77693-haptic, },
};
What is the purpose of this change?
Introducing mfd_devs_idx itself is a cosmetic change, which
actually could be avoided. Initialization of the of_compatible field
is required for the led driver to get matched properly. And as I've
just realized also max77693-flash name should be preserved.
I will fix this in the next version of the patch.
I'm happy with the addition of any .of_compatible strings, however
please leave out the IDXs in your next version(s).
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On 03/20/2014 06:23 PM, Grant Likely wrote: On Tue, 11 Mar 2014 14:16:37 +0100, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote: So depending on the use case, the endpoints would point to opposite direction from the encoder's point of view. And if I gathered Grant's opinion correctly (correct me if I'm wrong), he thinks things should be explicit, i.e. the bindings for, say, an encoder should state that the encoder's output endpoint _must_ contain a remote-endpoint property, whereas the encoder's input endpoint _must not_ contain a remote-endpoint property. Actually my understand was that DT links would have the same direction as the data flow. There would be no ambiguity in that case as the direction of the data flow is known. What happens for bidirectional data flows still need to be discussed though. And if we want to use the of-graph bindings to describe graphs without a data flow, a decision will need to be taken there too. On further thinking, I would say linkage direction should be in the direction that would be considered the dependency order... I'm going to soften my position though. I think the generic pattern should still recommend unidirection links in direction of device dependency, but I am not sure what you mean by 'device dependency' but I am sure it will not be difficult to present problematic cases, maybe circular dependencies, two-way dependencies, etc. The only problem of unidirectional links from programming point of view is that destination port/interface should be exposed using some framework and driver of source link should grab it using the same framework, using port/endpoint node for identification. In case of bi-directional links the same process should happen but DT do not dictates who should expose and who grabs. So from programming point of view it should be easy to handle unidirectional links regardless of the direction. So I guess the best is to use data flow direction as it seems to be the most natural. I'm okay with allowing the bidirection option if the helper functions are modified to validate the target endpoint. I think it needs to test for the following: - Make sure the endpoint either: - does not have a backlink, or - the backlink points back to the origin node - If the target is an endpoint node, then make sure the parent doesn't have a link of any kind - If the target is a port node, make sure it doesn't have any endpoint children nodes at all. I think link validation can be done at dts compile time. Regards Andrzej g. -- 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 RFC v2 0/6] drm/i2c: Move tda998x to a couple encoder/connector
On Fri, Mar 21, 2014 at 11:27:45AM +0100, Jean-Francois Moine wrote: The 'slave encoder' structure of the tda998x driver asks for glue between the DRM driver and the encoder/connector structures. Given how close we are to the coming merge window, that the discussion about the of-graph bindings is still going on without concensus being reached, and that this driver is not in staging, this needs to be delayed until the following merge window when hopefully we have a clearer picture about the DT side of this. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Fri, 21 Mar 2014 11:44:24 +0100, Andrzej Hajda a.ha...@samsung.com wrote: On 03/20/2014 06:23 PM, Grant Likely wrote: On Tue, 11 Mar 2014 14:16:37 +0100, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote: So depending on the use case, the endpoints would point to opposite direction from the encoder's point of view. And if I gathered Grant's opinion correctly (correct me if I'm wrong), he thinks things should be explicit, i.e. the bindings for, say, an encoder should state that the encoder's output endpoint _must_ contain a remote-endpoint property, whereas the encoder's input endpoint _must not_ contain a remote-endpoint property. Actually my understand was that DT links would have the same direction as the data flow. There would be no ambiguity in that case as the direction of the data flow is known. What happens for bidirectional data flows still need to be discussed though. And if we want to use the of-graph bindings to describe graphs without a data flow, a decision will need to be taken there too. On further thinking, I would say linkage direction should be in the direction that would be considered the dependency order... I'm going to soften my position though. I think the generic pattern should still recommend unidirection links in direction of device dependency, but I am not sure what you mean by 'device dependency' but I am sure it will not be difficult to present problematic cases, maybe circular dependencies, two-way dependencies, etc. My understanding has been that the link data would be used determine when the controller driver can be brought up and active. Certainly both sides of a link need to be 'live' before the link can be used. The kernel must have a way to resolve the question of who starts first?, whether it be the situation of the consumer starts before the producer, or the situation of two components need to start before the controller driver can start. That is the dependency chain I'm talking about. The only problem of unidirectional links from programming point of view is that destination port/interface should be exposed using some framework and driver of source link should grab it using the same framework, using port/endpoint node for identification. In case of bi-directional links the same process should happen but DT do not dictates who should expose and who grabs. So from programming point of view it should be easy to handle unidirectional links regardless of the direction. So I guess the best is to use data flow direction as it seems to be the most natural. right. I'm okay with allowing the bidirection option if the helper functions are modified to validate the target endpoint. I think it needs to test for the following: - Make sure the endpoint either: - does not have a backlink, or - the backlink points back to the origin node - If the target is an endpoint node, then make sure the parent doesn't have a link of any kind - If the target is a port node, make sure it doesn't have any endpoint children nodes at all. I think link validation can be done at dts compile time. I'm firm on the opinion that the checking must also happen at runtime. The biggest part of my objection has been how easy it would be to get a linkage out of sync, and dtc is not necessarily the last tool to touch the dtb before the kernel gets booted. I want the kernel to flat out reject any linkage that is improperly formed. g. Regards Andrzej g. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On 20/03/14 19:01, Grant Likely wrote: I think depending on a generic graph walk is where I have the biggest concern about the design. I don't think it is a good idea for the master device to try a generic walk over the graph looking for other devices that might be components because it cannot know whether or not further links are relevant, or even if other endpoint nodes in the target hierarchy actually conform to the graph binding in the same way. Consider the example of a system with two video controllers (one embedded and one discrete), a display mux, and a panel. The display controller depends on the mux, and the mux depends on the panel. It would be entirely reasonable to start up the display subsystem with the embedded controller without the discrete adapter being available, but the way the current graph pattern is proposed there is no dependency information between the devices. For some reason I don't understand this master and dependency way of thinking. I just can't twist my brain to it, please help me =). With the setup you describe above, why does the video controller depend on the mux, and why it is the master? Why the DMA engine does not depend on the embedded video controller, and why is the DMA engine not the master? With the setup above, what are we really interested in? It's the display, right? We want to have the display working, with resolution and video timings that work for the display. The mux and the display controllers are just necessary evils to make the display work. The display depends on the mux to provide it a video stream. The mux depends on the two video controllers to provide the mux two video streams. The video controllers depend (possibly) on SoC's DMA, or PCI bus to provide them video data. And if we consider the same setup as above, but the mux has two exclusive outputs, it again works fine with the dependency I described. If you want to enable panel 1, you'll depend on mux and video controllers, but not on panel 2. So you can leave the panel 2 driver out and things still work ok. But note that I don't think this dependency has strict relation to the DT graph representation, see below. I really do think the dependency direction needs to be explicit so that a driver knows whether or not a given link is relevant for it to start, I think that comes implicitly from the driver, it doesn't need to be described in the DT. If a device has an input port, and the device is configured to use that input port, the device depends on whatever is on the other side of the input port. The device driver must know that. Somehow a device driver needs to find if the driver behind its input ports are ready. It could use the links in DT directly, if they are supplied in that direction, or it could rely on someone else parsing the DT, and exposing the information via some API. I think it's simpler for the SW to follow the links directly, but that would mean having the links in the opposite direction than the data flow, which feels a bit odd to me. and there must be driver know that knows how to interpret the target node. A device that is a master needs to know which links are dependencies, and which are not. Well, again, I may not quite understand what the master means here. But for me, the display is the master of the pipeline. The driver for the display is the one that has to decide what kind of video signal is acceptable, how the signal must be enabled, and disabled, etc. When someone (the master's master =) tells the panel to enable itself, the panel needs to use an API to configure and enable its input ports. The devices on the other end of the input ports then configure and enable their inputs. And so on. Anyway, I do think this is more of a SW organization topic than how we should describe the hardware. As I see it, the parent-child relationships in the DT describe the control paths and the graph describes the data paths. Having the data paths described in the direction of data flow (or double-linked in case of bi-dir link) sounds logical to me, but I think the inverse could work fine too. But using some kind of CPU centric direction doesn't sound very usable, it makes no sense for cases with peripheral-to-peripheral links, and the control bus already describes the CPU centric direction in cases where there exists a clear CPU-to-peripheral direction. I'm not even talking about the bi-directional link issue. This issue remains regardless of whether or not bidirectional links are used. I would solve it in one of the following two ways: 1) Make masters only look at one level of dependency. Make the component driver responsible for checking /its/ dependencies. If its dependencies aren't yet met, then don't register the component as ready. We could probably make the drivers/base/component code allow components to pull in additional components as required. This approach shouldn't even require a change to the binding and eliminates any need for
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On 21/03/14 13:47, Grant Likely wrote: I'm firm on the opinion that the checking must also happen at runtime. The biggest part of my objection has been how easy it would be to get a linkage out of sync, and dtc is not necessarily the last tool to touch the dtb before the kernel gets booted. I want the kernel to flat out reject any linkage that is improperly formed. Isn't it trivial to verify it with the current v4l2 bindings? And endpoint must have a 'remote-endpoint' property, and the endpoint on the other end must have similar property, pointing in the first endpoint. Anything else is an error. I agree that it's easier to write bad links in the dts with double-linking than with single-linking, but it's still trivial to verify it in the kernel. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote: However, we (as in the V4L2 community, and me personally) would have appreciated to be CC'ed on the proposal. As you might know we already had a solution for this problem, albeit V4L2-specific, in drivers/media/v4l2- core/v4l2-async.c. There's a lot of people who would have liked to be on the Cc, but there's two problems: 1. the Cc list would be too big for mailing lists to accept the message, and 2. finding everyone who should be on the Cc list is quite an impossible task. The topic is particularly hot given that a similar solution was also proposed as part of the now defunct (or at least hibernating) common display framework. Yes, I am aware of CDF. However, the annoying thing is that it's another case of the bigger picture not being looked at - which is that we don't need yet another subsystem specific solution to a problem which is not subsystem specific. The fact of the matter is that /anyone/ has the opportunity to come up with a generic solution to this problem, and no one did... instead, more solutions were generated - the proof is we solved this in CDF with a CDF specific solution. :p If I had replied to this mail thread without sleeping on it first I might not have known better and have got half-paranoid, wondereding whether there had been a deliberate attempt to fast-track this API before the V4L2 developers noticed. To be perfectly clear, there is *NO* implicit or explicit such accusation here, as I know better. What would have happened is that CDF would have been raised, and there would be a big long discussion with no real resolution. The problem would not have been solved (even partially). We'd be sitting here right now still without any kind of solution that anyone can use. Instead, what we have right now is the opportunity for people to start making use of this and solving the real problems they have with driver initialisation. For example, the IPU on iMX locks up after a number of mode changes, and it's useful to be able to unload the driver, poke about in the hardware, and reload it. Without this problem fixed, that's impossible without rebooting the kernel, because removing the driver oopses the kernel due to the broken work-arounds that it has to do - and it has to do those because this problem has not been solved, despite it being known about for /years/. Accordingly, I would like to comment on the component API, despite the fact that it has been merged in mainline already. The first thing that I believe is missing is documentation. Do you have any pending patch for that, either as kerneldoc or as a text file for Documentation/ ? As I've read the code to understand it I might have missed so design goals, so please bear with the stupid questions that may follow. There's lots of things in the kernel which you just have to read the code for - and this is one of them at the moment. :) (Another is PM domains...) What I know is that this will not satisfy all your requirements - I don't want it to initially satisfy everyone's requirements, because that's just far too big a job, but it satisfies the common problem that most people are suffering from and have already implemented many badly written driver specific solutions. In other words - this is designed to _improve_ the current situation where we have lots of buggy implementions trying to work around this problem, factor that code out, and fix up those problems. Briefly, the idea is: - there is a master device - lots of these subsystems doing this already have that, whether that be ALSA or DRM based stuff. - then there are the individual component devices and their drivers. Subsystems like ALSA and DRM are not component based subsystems. These subsystems have two states - either they're initialised and the entire card system is known about, or they're not initialised. There is no possibility of a piecemeal approach, where they partially come up and additional stuff gets added later. With DRM, that's especially true because of how the userspace API works - to change that probably means changing stuff all the way through things like the X server and its xrandr application interface. This is probably the reason why David said at KS that DRM isn't going to do the hotplugging of components. The master device has a privileged position - it gets to make the decision about which component devices are relevant to it, and when the card system is fully known. As far as DT goes, we've had a long discussion about this approach in the past, and we've accepted this approach - we have the sound node which doesn't actually refer to any hardware block, it's a node which describes how the hardware blocks are connected together, which gets translated into a platform device. When a master device gets added, it gets added to the list of master devices, and then it's asked whether all the components that it needs are present. Since we
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Hi Grant, On Friday 21 March 2014 08:15:34 Grant Likely wrote: On Fri, 21 Mar 2014 00:26:12 +0100, Laurent Pinchart wrote: On Thursday 20 March 2014 23:12:50 Grant Likely wrote: On Thu, 20 Mar 2014 19:52:53 +0100, Laurent Pinchart wrote: Then we might not be talking about the same thing. I'm talking about DT bindings to represent the topology of the device, not how drivers are wired together. Possibly. I'm certainly confused now. You brought up the component helpers in drivers/base/component.c, so I thought working out dependencies is part of the purpose of this binding. Everything I've heard so far has given me the impression that the graph binding is tied up with knowing when all of the devices exist. The two are related, you're of course right about that. We're not really moving forward here. Part of our disagreement comes in my opinion from having different requirements and different views of the problem, caused by experiences with different kind of devices. This is much easier to solve by sitting around the same table than discussing on mailing lists. I would propose a meeting at the ELC but that's still a bit far away and would delay progress by more than one month, which is probably not acceptable. I can reply to the e-mail where I've drawn one use case I have to deal with to detail my needs if that can help. Alternatively the UK isn't that far away and I could jump in a train if you can provide tea for the discussion :-) I'm game for that, but it is a long train ride. I'm up in Aberdeen which is 8 hours from London by train. Also, I'm travelling next week to California (Collaboration summit), so it will have to be in 2 weeks time. Why don't we instead try a Google Hangout or a phone call today. Anywhere between 11:30 and 14:00 GMT would work for me. I'd offer to provide the tea, but I haven't quite perfected transporter technology yet. That would work for me, but not today I'm afraid. Will you already be in California on Monday ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] media mini-summit on May, 2 in San Jose
Devin and myself will be in San Jose all week, although we do have existing plans for May 2nd. If we can fit the mini-summit in then we will, or we'll catch up with individual people during the conference itself. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com On Wed, Mar 19, 2014 at 3:02 PM, Mauro Carvalho Chehab m.che...@samsung.com wrote: As discussed on our IRC #v4l channels, most of the core developers will be in San Jose - CA - USA for the Embedded Linux Conference. There are several subjects that we've been discussing those days that require a face to face meeting. So, We'll be doing a media mini-summit on May, 2 (Friday) at Marriott San Jose. Eventually, we may also schedule some BoFs during the week, if needed. In order to properly organize the event, I need the name of the developers interested on joining us, plus the themes proposed for discussions. As usual, we'll be using the media-works...@linuxtv.org ML for specific discussions about that, so the ones interested on participate are requested to subscribe it. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Fri, Mar 21, 2014 at 12:44 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Grant, On Friday 21 March 2014 08:15:34 Grant Likely wrote: Why don't we instead try a Google Hangout or a phone call today. Anywhere between 11:30 and 14:00 GMT would work for me. I'd offer to provide the tea, but I haven't quite perfected transporter technology yet. That would work for me, but not today I'm afraid. Will you already be in California on Monday ? Yes. Let's try the week after. g. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
On 21/03/14 00:32, Laurent Pinchart wrote: The OF graph bindings documentation could just specify the ports node as optional and mandate individual device bindings to specify it as mandatory or forbidden (possibly with a default behaviour to avoid making all device bindings too verbose). Isn't it so that if the device has one port, it can always do without 'ports', but if it has multiple ports, it always has to use 'ports' so that #address-cells and #size-cells can be defined? If so, there's nothing left for the individual device bindings to decide. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
On 21/03/14 14:37, Tomi Valkeinen wrote: On 21/03/14 00:32, Laurent Pinchart wrote: The OF graph bindings documentation could just specify the ports node as optional and mandate individual device bindings to specify it as mandatory or forbidden (possibly with a default behaviour to avoid making all device bindings too verbose). Isn't it so that if the device has one port, it can always do without 'ports', but if it has multiple ports, it always has to use 'ports' so that #address-cells and #size-cells can be defined? If so, there's nothing left for the individual device bindings to decide. Wouldn't it make the bindings even more verbose ? Letting the individual device bindings to decide sounds more sensible to me. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
Hi Tomi, On Friday 21 March 2014 15:37:17 Tomi Valkeinen wrote: On 21/03/14 00:32, Laurent Pinchart wrote: The OF graph bindings documentation could just specify the ports node as optional and mandate individual device bindings to specify it as mandatory or forbidden (possibly with a default behaviour to avoid making all device bindings too verbose). Isn't it so that if the device has one port, it can always do without 'ports', but if it has multiple ports, it always has to use 'ports' so that #address-cells and #size-cells can be defined? You can put the #address-cells and #size-cells property in the device node directly without requiring a ports subnode. If so, there's nothing left for the individual device bindings to decide. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
On 21/03/14 16:13, Laurent Pinchart wrote: Hi Tomi, On Friday 21 March 2014 15:37:17 Tomi Valkeinen wrote: On 21/03/14 00:32, Laurent Pinchart wrote: The OF graph bindings documentation could just specify the ports node as optional and mandate individual device bindings to specify it as mandatory or forbidden (possibly with a default behaviour to avoid making all device bindings too verbose). Isn't it so that if the device has one port, it can always do without 'ports', but if it has multiple ports, it always has to use 'ports' so that #address-cells and #size-cells can be defined? You can put the #address-cells and #size-cells property in the device node directly without requiring a ports subnode. Ah, right. So 'ports' is only needed when the device node has other children nodes than the ports and those nodes need different #address-cells and #size-cells than the ports. In that case it sounds fine to leave it for the driver bindings to decide. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
Hi Tomi, On Friday 21 March 2014 16:22:52 Tomi Valkeinen wrote: On 21/03/14 16:13, Laurent Pinchart wrote: On Friday 21 March 2014 15:37:17 Tomi Valkeinen wrote: On 21/03/14 00:32, Laurent Pinchart wrote: The OF graph bindings documentation could just specify the ports node as optional and mandate individual device bindings to specify it as mandatory or forbidden (possibly with a default behaviour to avoid making all device bindings too verbose). Isn't it so that if the device has one port, it can always do without 'ports', but if it has multiple ports, it always has to use 'ports' so that #address-cells and #size-cells can be defined? You can put the #address-cells and #size-cells property in the device node directly without requiring a ports subnode. Ah, right. So 'ports' is only needed when the device node has other children nodes than the ports and those nodes need different #address-cells and #size-cells than the ports. I would rephrase that as the ports node being required only in that case. It can also be useful to cleanly group ports together when the device node has other unrelated children, even though no technical requirement exist (yet ?) in that case. In that case it sounds fine to leave it for the driver bindings to decide. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
On Fri, 21 Mar 2014 14:16:20 +0200, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 21/03/14 13:47, Grant Likely wrote: I'm firm on the opinion that the checking must also happen at runtime. The biggest part of my objection has been how easy it would be to get a linkage out of sync, and dtc is not necessarily the last tool to touch the dtb before the kernel gets booted. I want the kernel to flat out reject any linkage that is improperly formed. Isn't it trivial to verify it with the current v4l2 bindings? And endpoint must have a 'remote-endpoint' property, and the endpoint on the other end must have similar property, pointing in the first endpoint. Anything else is an error. I agree that it's easier to write bad links in the dts with double-linking than with single-linking, but it's still trivial to verify it in the kernel. Right, which is exactly what I'm asking for. g. -- 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
xc2038/3028 firmware
Hi, are there any reasons why the xc2028/3028 firmware files are not included in the linux-firmware tree ? The xc5000 firmware is already there, so it seems Xceive|has nothing against| redistribution of their firmware... ?! Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xc2038/3028 firmware
Hi Frank, I specifically asked for and received permission from Xceive/CrestaTech to make the xc5000 firmware freely redistributable. They were unwilling to entertain that though for the xc2028/3028 as they considered it a long deprecated product. In order to include firmware blobs in linux-firmware, there needs to be an actual license legally permitting redistribution - we don't have that for the 2028/3028. In general CrestaTech have been extremely cooperative with the Linux community, especially in recent years. However in this case they just couldn't justify the effort to do the paperwork for a chip that they stopped shipping years ago. Devin On Fri, Mar 21, 2014 at 1:25 PM, Frank Schäfer fschaefer@googlemail.com wrote: Hi, are there any reasons why the xc2028/3028 firmware files are not included in the linux-firmware tree ? The xc5000 firmware is already there, so it seems Xceive|has nothing against| redistribution of their firmware... ?! Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xc2038/3028 firmware
Em Fri, 21 Mar 2014 18:23:13 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Hi, are there any reasons why the xc2028/3028 firmware files are not included in the linux-firmware tree ? The xc5000 firmware is already there, so it seems Xceive|has nothing against| redistribution of their firmware... ?! They explicitly granted redistribution rights to xc5000 firmware, but they never gave for xc2028/3028. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-apps build failure
On 03/11/2014 12:39 AM, Jonathan McCrohan wrote: Hi Oliver, On Thu, 06 Feb 2014 09:25:14 +0100, Quentin Glidic wrote: Hello, When building dvb-apps from the Mercurial repository, you hit the following error: install: cannot stat 'atsc/*': No such file or directory Can you test it now? I removed the install section from the makefile and pushed it upstream. It worked on my outdated virtual machine, so it should be good now. Sorry for the delay, was hoping one of the dvb-apps maintainers would pick it up ... Olliver In the latest changeset (http://linuxtv.org/hg/dvb-apps/rev/d40083fff895) scan files were deleted from the repository but not their install rule. Could someone please remove the bottom part of util/scan/Makefile (from line 31, http://linuxtv.org/hg/dvb-apps/file/d40083fff895/util/scan/Makefile#l31) to fix this issue? Ping on Quentin's behalf. I'd like to upload a new version of dvb-apps to Debian, but the build is currently broken after your recent patch. Would you be able to take a look? Thanks, Jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: em28xx-video - change em28xx_scaler_set() to use em28xx_reg_len()
Change em28xx_scaler_set() to use em28xx_reg_len() to get register
lengths for EM28XX_R30_HSCALELOW and EM28XX_R32_VSCALELOW registers,
instead of hard-coding the length. Moved em28xx_reg_len() definition
for it to be visible to em28xx_scaler_set().
Signed-off-by: Shuah Khan shuah...@samsung.com
---
drivers/media/usb/em28xx/em28xx-video.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 19af6b3..f8a91de 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -272,6 +272,18 @@ static void em28xx_capture_area_set(struct em28xx *dev, u8
hstart, u8 vstart,
}
}
+static int em28xx_reg_len(int reg)
+{
+ switch (reg) {
+ case EM28XX_R40_AC97LSB:
+ case EM28XX_R30_HSCALELOW:
+ case EM28XX_R32_VSCALELOW:
+ return 2;
+ default:
+ return 1;
+ }
+}
+
static int em28xx_scaler_set(struct em28xx *dev, u16 h, u16 v)
{
u8 mode;
@@ -284,11 +296,13 @@ static int em28xx_scaler_set(struct em28xx *dev, u16 h,
u16 v)
buf[0] = h;
buf[1] = h 8;
- em28xx_write_regs(dev, EM28XX_R30_HSCALELOW, (char *)buf, 2);
+ em28xx_write_regs(dev, EM28XX_R30_HSCALELOW, (char *)buf,
+ em28xx_reg_len(EM28XX_R30_HSCALELOW));
buf[0] = v;
buf[1] = v 8;
- em28xx_write_regs(dev, EM28XX_R32_VSCALELOW, (char *)buf, 2);
+ em28xx_write_regs(dev, EM28XX_R32_VSCALELOW, (char *)buf,
+ em28xx_reg_len(EM28XX_R32_VSCALELOW));
/* it seems that both H and V scalers must be active
to work correctly */
mode = (h || v) ? 0x30 : 0x00;
@@ -1583,17 +1597,6 @@ static int vidioc_g_chip_info(struct file *file, void
*priv,
return 0;
}
-static int em28xx_reg_len(int reg)
-{
- switch (reg) {
- case EM28XX_R40_AC97LSB:
- case EM28XX_R30_HSCALELOW:
- case EM28XX_R32_VSCALELOW:
- return 2;
- default:
- return 1;
- }
-}
static int vidioc_g_register(struct file *file, void *priv,
struct v4l2_dbg_register *reg)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Mar 22 04:00:13 CET 2014 git branch: test git hash: ed97a6fe5308e5982d118a25f0697b791af5ec50 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
