Re: [PATCH] em28xx: ignore isoc DVB USB endpoints with wMaxPacketSize = 0 bytes for all alt settings
On Wed, 27 Mar 2013 21:07:41 +0100 Frank Schäfer fschaefer@googlemail.com wrote: Some devices without DVB support (such as the Terratec Grabby and Easycap DC-60) provide isochronous DVB USB endpoints with wMaxPacketSize set to 0 bytes for all alt settings. Ignore these endpoints and avoid registering a DVB device node and loading the DVB driver extension. Signed-off-by: Frank Schäfer fschaefer@googlemail.com Cc: sta...@kernel.org Tested-by: Timo Teräs timo.te...@iki.fi Fixes the false DVB detection on my Terratec Grabby. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.10] hdpvr: driver overhaul
Hi Mauro, This pull request overhauls the hdpvr driver. It's identical to my earlier posted patch series: http://www.mail-archive.com/linux-media@vger.kernel.org/msg60040.html except for being rebased to the latest master. It's been tested thoroughly on my hdpvr and with a video generator to test all the video formats. I've taken care to preserve the current VIDIOC_G_FMT behavior since MythTV relies on that. See the last patch for more information on that topic. Leonid, because of the MythTV behavior your patch (http://patchwork.linuxtv.org/patch/17567/) can't be applied. The way out would be for someone to add support to MythTV for VIDIOC_QUERY_DV_TIMINGS as the preferred method of detecting if a signal is present on the HDPVR, and once that it in place this legacy hack can be removed from this driver. Regards, Hans The following changes since commit 004e45d736bfe62159bd4dc1549eff414bd27496: [media] tuner-core: handle errors when getting signal strength/afc (2013-03-25 15:10:43 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git hdpvr for you to fetch changes up to 6cb9721190d98e654e1b5ac467565ce7784ed2da: hdpvr: add dv_timings support. (2013-03-28 09:16:36 +0100) Hans Verkuil (11): videodev2.h: fix incorrect V4L2_DV_FL_HALF_LINE bitmask. v4l2-dv-timings.h: add 480i59.94 and 576i50 CEA-861-E timings. hdpvr: convert to the control framework. hdpvr: remove hdpvr_fh and just use v4l2_fh. hdpvr: add prio and control event support. hdpvr: support device_caps in querycap. hdpvr: small fixes hdpvr: register the video node at the end of probe. hdpvr: recognize firmware version 0x1e. hdpvr: add g/querystd, remove deprecated current_norm. hdpvr: add dv_timings support. drivers/media/usb/hdpvr/hdpvr-core.c | 14 +- drivers/media/usb/hdpvr/hdpvr-video.c | 918 +--- drivers/media/usb/hdpvr/hdpvr.h | 19 +- include/uapi/linux/v4l2-dv-timings.h | 18 ++ include/uapi/linux/videodev2.h|2 +- 5 files changed, 473 insertions(+), 498 deletions(-) -- To unsubscribe from this list: send the line unsubscribe 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] [media] add Aptina mt9m114 HD digital image sensor driver
This driver support parallel data output mode and
QVGA/VGA/WVGA/720P resolution. You can select YCbCr and RGB565
output format.
What host bridge do you use this driver with ?
I only tested with blackfin.
+ */
[snip]
+struct mt9m114_reg {
+ u16 reg;
+ u32 val;
+ int width;
+};
+
+enum {
+ MT9M114_QVGA,
+ MT9M114_VGA,
+ MT9M114_WVGA,
+ MT9M114_720P,
+};
This is the part I don't like. Instead of hardcoding 4 different resolutions
and using large register address/value tables, you should compute the register
values from the image size requested by the user.
In fact we get this table with the Aptina development tool. So we only support
fixed resolutions. If we compute each register value, it only makes
the code more complex.
--
To unsubscribe from this list: send the line unsubscribe 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] davinci: vpif: add pm_runtime support
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Add pm_runtime support to the TI Davinci VPIF driver.
Along side this patch replaces clk_get() with devm_clk_get()
to simplify the error handling.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c
index 28638a8..7d14625 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -25,6 +25,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/err.h
+#include linux/pm_runtime.h
#include linux/v4l2-dv-timings.h
#include mach/hardware.h
@@ -44,7 +45,6 @@ static struct resource*res;
spinlock_t vpif_lock;
void __iomem *vpif_base;
-struct clk *vpif_clk;
/**
* ch_params: video standard configuration parameters for vpif
@@ -421,6 +421,7 @@ EXPORT_SYMBOL(vpif_channel_getfid);
static int vpif_probe(struct platform_device *pdev)
{
+ struct clk *vpif_clk;
int status = 0;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -439,12 +440,17 @@ static int vpif_probe(struct platform_device *pdev)
goto fail;
}
- vpif_clk = clk_get(pdev-dev, vpif);
+ vpif_clk = devm_clk_get(pdev-dev, vpif);
if (IS_ERR(vpif_clk)) {
status = PTR_ERR(vpif_clk);
goto clk_fail;
}
- clk_prepare_enable(vpif_clk);
+ clk_put(vpif_clk);
+
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_resume(pdev-dev);
+
+ pm_runtime_get(pdev-dev);
spin_lock_init(vpif_lock);
dev_info(pdev-dev, vpif probe success\n);
@@ -459,11 +465,6 @@ fail:
static int vpif_remove(struct platform_device *pdev)
{
- if (vpif_clk) {
- clk_disable_unprepare(vpif_clk);
- clk_put(vpif_clk);
- }
-
iounmap(vpif_base);
release_mem_region(res-start, res_len);
return 0;
@@ -472,13 +473,13 @@ static int vpif_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int vpif_suspend(struct device *dev)
{
- clk_disable_unprepare(vpif_clk);
+ pm_runtime_put(dev);
return 0;
}
static int vpif_resume(struct device *dev)
{
- clk_prepare_enable(vpif_clk);
+ pm_runtime_get(dev);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Grabby hwrev 2
On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. - Timo -- To unsubscribe from this list: send the line unsubscribe 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] davinci: vpif: add pm_runtime support
Hi Prabhakar,
Thanks for the patch.
On Thursday 28 March 2013 14:20:32 Prabhakar lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Add pm_runtime support to the TI Davinci VPIF driver.
Along side this patch replaces clk_get() with devm_clk_get()
to simplify the error handling.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c index 28638a8..7d14625 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -25,6 +25,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/err.h
+#include linux/pm_runtime.h
#include linux/v4l2-dv-timings.h
#include mach/hardware.h
@@ -44,7 +45,6 @@ static struct resource *res;
spinlock_t vpif_lock;
void __iomem *vpif_base;
-struct clk *vpif_clk;
/**
* ch_params: video standard configuration parameters for vpif
@@ -421,6 +421,7 @@ EXPORT_SYMBOL(vpif_channel_getfid);
static int vpif_probe(struct platform_device *pdev)
{
+ struct clk *vpif_clk;
int status = 0;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -439,12 +440,17 @@ static int vpif_probe(struct platform_device *pdev)
goto fail;
}
- vpif_clk = clk_get(pdev-dev, vpif);
+ vpif_clk = devm_clk_get(pdev-dev, vpif);
if (IS_ERR(vpif_clk)) {
status = PTR_ERR(vpif_clk);
goto clk_fail;
}
- clk_prepare_enable(vpif_clk);
+ clk_put(vpif_clk);
Why do you need to call clk_put() here ?
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_resume(pdev-dev);
+
+ pm_runtime_get(pdev-dev);
Does runtime PM automatically handle your clock ? If so can't you remove clock
handling from the driver completely ?
spin_lock_init(vpif_lock);
dev_info(pdev-dev, vpif probe success\n);
@@ -459,11 +465,6 @@ fail:
static int vpif_remove(struct platform_device *pdev)
{
- if (vpif_clk) {
- clk_disable_unprepare(vpif_clk);
- clk_put(vpif_clk);
- }
-
iounmap(vpif_base);
release_mem_region(res-start, res_len);
return 0;
@@ -472,13 +473,13 @@ static int vpif_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int vpif_suspend(struct device *dev)
{
- clk_disable_unprepare(vpif_clk);
+ pm_runtime_put(dev);
return 0;
}
static int vpif_resume(struct device *dev)
{
- clk_prepare_enable(vpif_clk);
+ pm_runtime_get(dev);
return 0;
}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] [media] add Aptina mt9m114 HD digital image sensor driver
Hi Scott,
On Thursday 28 March 2013 16:29:30 Scott Jiang wrote:
This driver support parallel data output mode and
QVGA/VGA/WVGA/720P resolution. You can select YCbCr and RGB565
output format.
What host bridge do you use this driver with ?
I only tested with blackfin.
+ */
[snip]
+struct mt9m114_reg {
+ u16 reg;
+ u32 val;
+ int width;
+};
+
+enum {
+ MT9M114_QVGA,
+ MT9M114_VGA,
+ MT9M114_WVGA,
+ MT9M114_720P,
+};
This is the part I don't like. Instead of hardcoding 4 different
resolutions and using large register address/value tables, you should
compute the register values from the image size requested by the user.
In fact we get this table with the Aptina development tool. So we only
support fixed resolutions. If we compute each register value, it only makes
the code more complex.
But it also makes the code more useful, as the user won't be limited to the 4
resolutions above.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Get resolution of image capture device?
Hi, there are several documents and examples out there tha helped me a lot with v4l2 and image capturing, but one question is still unanswered: How can I check which (maximum) native resolutions a device supports? Is there a possibility to query image width and height from a device? 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: [PATCH] davinci: vpif: add pm_runtime support
Hi Laurent,
Thanks for the quick review!
On Thu, Mar 28, 2013 at 2:39 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
Thanks for the patch.
On Thursday 28 March 2013 14:20:32 Prabhakar lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Add pm_runtime support to the TI Davinci VPIF driver.
Along side this patch replaces clk_get() with devm_clk_get()
to simplify the error handling.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c index 28638a8..7d14625 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -25,6 +25,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/err.h
+#include linux/pm_runtime.h
#include linux/v4l2-dv-timings.h
#include mach/hardware.h
@@ -44,7 +45,6 @@ static struct resource *res;
spinlock_t vpif_lock;
void __iomem *vpif_base;
-struct clk *vpif_clk;
/**
* ch_params: video standard configuration parameters for vpif
@@ -421,6 +421,7 @@ EXPORT_SYMBOL(vpif_channel_getfid);
static int vpif_probe(struct platform_device *pdev)
{
+ struct clk *vpif_clk;
int status = 0;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -439,12 +440,17 @@ static int vpif_probe(struct platform_device *pdev)
goto fail;
}
- vpif_clk = clk_get(pdev-dev, vpif);
+ vpif_clk = devm_clk_get(pdev-dev, vpif);
if (IS_ERR(vpif_clk)) {
status = PTR_ERR(vpif_clk);
goto clk_fail;
}
- clk_prepare_enable(vpif_clk);
+ clk_put(vpif_clk);
Why do you need to call clk_put() here ?
The above check is to see if the clock is provided, once done
we free it using clk_put().
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_resume(pdev-dev);
+
+ pm_runtime_get(pdev-dev);
Does runtime PM automatically handle your clock ? If so can't you remove clock
handling from the driver completely ?
Yes pm runtime take care of enabling/disabling the clocks
so that we don't have to do it in drivers. I believe clock
handling is removed with this patch, with just devm_clk_get() remaining ;)
Regards,
--Prabhakar
spin_lock_init(vpif_lock);
dev_info(pdev-dev, vpif probe success\n);
@@ -459,11 +465,6 @@ fail:
static int vpif_remove(struct platform_device *pdev)
{
- if (vpif_clk) {
- clk_disable_unprepare(vpif_clk);
- clk_put(vpif_clk);
- }
-
iounmap(vpif_base);
release_mem_region(res-start, res_len);
return 0;
@@ -472,13 +473,13 @@ static int vpif_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int vpif_suspend(struct device *dev)
{
- clk_disable_unprepare(vpif_clk);
+ pm_runtime_put(dev);
return 0;
}
static int vpif_resume(struct device *dev)
{
- clk_prepare_enable(vpif_clk);
+ pm_runtime_get(dev);
return 0;
}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] davinci: vpif: add pm_runtime support
Hi Prabhakar,
On Thursday 28 March 2013 15:36:11 Prabhakar Lad wrote:
On Thu, Mar 28, 2013 at 2:39 PM, Laurent Pinchart wrote:
On Thursday 28 March 2013 14:20:32 Prabhakar lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Add pm_runtime support to the TI Davinci VPIF driver.
Along side this patch replaces clk_get() with devm_clk_get()
to simplify the error handling.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c index 28638a8..7d14625 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
[snip]
@@ -439,12 +440,17 @@ static int vpif_probe(struct platform_device *pdev)
goto fail;
}
- vpif_clk = clk_get(pdev-dev, vpif);
+ vpif_clk = devm_clk_get(pdev-dev, vpif);
if (IS_ERR(vpif_clk)) {
status = PTR_ERR(vpif_clk);
goto clk_fail;
}
- clk_prepare_enable(vpif_clk);
+ clk_put(vpif_clk);
Why do you need to call clk_put() here ?
The above check is to see if the clock is provided, once done
we free it using clk_put().
In that case you shouldn't use devm_clk_get(), otherwise clk_put() will be
called again automatically at remove() time.
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_resume(pdev-dev);
+
+ pm_runtime_get(pdev-dev);
Does runtime PM automatically handle your clock ? If so can't you remove
clock handling from the driver completely ?
Yes pm runtime take care of enabling/disabling the clocks
so that we don't have to do it in drivers. I believe clock
handling is removed with this patch, with just devm_clk_get() remaining ;)
When is the clk_get() call expected to fail ? If the clock is provided by the
SoC and always available, can't the check be removed completely ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] davinci: vpif: add pm_runtime support
Hi Laurent,
On Thu, Mar 28, 2013 at 3:40 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
On Thursday 28 March 2013 15:36:11 Prabhakar Lad wrote:
On Thu, Mar 28, 2013 at 2:39 PM, Laurent Pinchart wrote:
On Thursday 28 March 2013 14:20:32 Prabhakar lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Add pm_runtime support to the TI Davinci VPIF driver.
Along side this patch replaces clk_get() with devm_clk_get()
to simplify the error handling.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c index 28638a8..7d14625 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
[snip]
@@ -439,12 +440,17 @@ static int vpif_probe(struct platform_device *pdev)
goto fail;
}
- vpif_clk = clk_get(pdev-dev, vpif);
+ vpif_clk = devm_clk_get(pdev-dev, vpif);
if (IS_ERR(vpif_clk)) {
status = PTR_ERR(vpif_clk);
goto clk_fail;
}
- clk_prepare_enable(vpif_clk);
+ clk_put(vpif_clk);
Why do you need to call clk_put() here ?
The above check is to see if the clock is provided, once done
we free it using clk_put().
In that case you shouldn't use devm_clk_get(), otherwise clk_put() will be
called again automatically at remove() time.
Yes agreed it should be clk_get() only.
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_resume(pdev-dev);
+
+ pm_runtime_get(pdev-dev);
Does runtime PM automatically handle your clock ? If so can't you remove
clock handling from the driver completely ?
Yes pm runtime take care of enabling/disabling the clocks
so that we don't have to do it in drivers. I believe clock
handling is removed with this patch, with just devm_clk_get() remaining ;)
When is the clk_get() call expected to fail ? If the clock is provided by the
SoC and always available, can't the check be removed completely ?
Yes I agree with you it can be removed completely assuming the clock
is always available from the Soc.
But may be I need feedback from others Hans/Sekhar what do you suggest ?
Regards,
--Prabhakar
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] uvcvideo: Return -EINVAL when setting a menu control to an invalid value
-ERANGE is the right error code when the value is outside of the menu range, but -EINVAL must be reported for invalid values inside the range. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/usb/uvc/uvc_ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index 61e28de..a2f4501 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1487,7 +1487,7 @@ int uvc_ctrl_set(struct uvc_video_chain *chain, step = mapping-get(mapping, UVC_GET_RES, uvc_ctrl_data(ctrl, UVC_CTRL_DATA_RES)); if (!(step value)) - return -ERANGE; + return -EINVAL; } break; -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvcvideo: Return -EINVAL when setting a menu control to an invalid value
On Thu March 28 2013 12:10:56 Laurent Pinchart wrote: -ERANGE is the right error code when the value is outside of the menu range, but -EINVAL must be reported for invalid values inside the range. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans --- drivers/media/usb/uvc/uvc_ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c index 61e28de..a2f4501 100644 --- a/drivers/media/usb/uvc/uvc_ctrl.c +++ b/drivers/media/usb/uvc/uvc_ctrl.c @@ -1487,7 +1487,7 @@ int uvc_ctrl_set(struct uvc_video_chain *chain, step = mapping-get(mapping, UVC_GET_RES, uvc_ctrl_data(ctrl, UVC_CTRL_DATA_RES)); if (!(step value)) - return -ERANGE; + return -EINVAL; } break; -- To unsubscribe from this list: send the line unsubscribe 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] uvcvideo: Disable USB autosuspend for Creative Live! Cam Optia AF
The camera fails to start video streaming after having been autosuspend.
Add a new quirk to selectively disable autosuspend for devices that
don't support it.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/usb/uvc/uvc_driver.c | 14 +-
drivers/media/usb/uvc/uvcvideo.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
I've tried to set the reset resume quirk for this device in the USB core but
the camera still failed to start video streaming after having been
autosuspended. Regardless of whether the reset resume quirk was set, it would
respond to control messages but wouldn't send video data.
This solution below is a hack, but I'm not sure what else I can try. Crazy
ideas are welcome.
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 5dbefa6..99e2de0 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1913,8 +1913,11 @@ static int uvc_probe(struct usb_interface *intf,
supported.\n, ret);
}
+ if (!(dev-quirks UVC_QUIRK_DISABLE_AUTOSUSPEND))
+ usb_enable_autosuspend(udev);
+
uvc_trace(UVC_TRACE_PROBE, UVC device initialized.\n);
- usb_enable_autosuspend(udev);
+
return 0;
error:
@@ -2061,6 +2064,15 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_PROBE_MINMAX },
+ /* Creative Live! Cam Optia AF */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x041e,
+ .idProduct= 0x4058,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_DISABLE_AUTOSUSPEND },
/* Genius eFace 2025 */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index af505fd..9cd584a 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -137,6 +137,7 @@
#define UVC_QUIRK_FIX_BANDWIDTH0x0080
#define UVC_QUIRK_PROBE_DEF0x0100
#define UVC_QUIRK_RESTRICT_FRAME_RATE 0x0200
+#define UVC_QUIRK_DISABLE_AUTOSUSPEND 0x0400
/* Format flags */
#define UVC_FMT_FLAG_COMPRESSED0x0001
--
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
[GIT PULL FOR v3.10] uvcvideo fix
Hi Mauro, The following changes since commit 004e45d736bfe62159bd4dc1549eff414bd27496: [media] tuner-core: handle errors when getting signal strength/afc (2013-03-25 15:10:43 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next for you to fetch changes up to a5104bfc835d4e8a9420f558a2a7b1a8da30f5a6: uvcvideo: Return -EINVAL when setting a menu control to an invalid value (2013-03-28 12:53:48 +0100) Laurent Pinchart (1): uvcvideo: Return -EINVAL when setting a menu control to an invalid value drivers/media/usb/uvc/uvc_ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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: Terratec Grabby hwrev 2
Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. - Timo -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Grabby hwrev 2
On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. Smells to me that they replaced the saa7113 with cheaper clone that does not support the ID string. Sounds like the same issue as: http://www.spinics.net/lists/linux-media/msg57926.html Additionally noted that something is not initialized right: With PAL signal: - there's some junk pixel in beginning of each line (looks like pixes from previous lines end), sync issue? - some junk lines at the end - distorted colors when white and black change between pixels With NTSC signal: - unable to get a lock, and the whole picture looks garbled On the W7 driver, I don't get any of the above mentioned problems. I looked at the saa7113 register init sequence, and copied that over to linux saa7113 init, but that did not remove the problems. There were only few changes. - Timo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] hdpvr: driver overhaul
On Thu March 28 2013 09:27:53 Hans Verkuil wrote: Hi Mauro, This pull request overhauls the hdpvr driver. It's identical to my earlier posted patch series: http://www.mail-archive.com/linux-media@vger.kernel.org/msg60040.html except for being rebased to the latest master. It's been tested thoroughly on my hdpvr and with a video generator to test all the video formats. I've taken care to preserve the current VIDIOC_G_FMT behavior since MythTV relies on that. See the last patch for more information on that topic. Leonid, because of the MythTV behavior your patch (http://patchwork.linuxtv.org/patch/17567/) can't be applied. The way out would be for someone to add support to MythTV for VIDIOC_QUERY_DV_TIMINGS as the preferred method of detecting if a signal is present on the HDPVR, and once that it in place this legacy hack can be removed from this driver. Regards, Hans Nacked-by: Hans Verkuil hans.verk...@cisco.com Leonid found some issues that I want to address first. Regards, Hans The following changes since commit 004e45d736bfe62159bd4dc1549eff414bd27496: [media] tuner-core: handle errors when getting signal strength/afc (2013-03-25 15:10:43 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git hdpvr for you to fetch changes up to 6cb9721190d98e654e1b5ac467565ce7784ed2da: hdpvr: add dv_timings support. (2013-03-28 09:16:36 +0100) Hans Verkuil (11): videodev2.h: fix incorrect V4L2_DV_FL_HALF_LINE bitmask. v4l2-dv-timings.h: add 480i59.94 and 576i50 CEA-861-E timings. hdpvr: convert to the control framework. hdpvr: remove hdpvr_fh and just use v4l2_fh. hdpvr: add prio and control event support. hdpvr: support device_caps in querycap. hdpvr: small fixes hdpvr: register the video node at the end of probe. hdpvr: recognize firmware version 0x1e. hdpvr: add g/querystd, remove deprecated current_norm. hdpvr: add dv_timings support. drivers/media/usb/hdpvr/hdpvr-core.c | 14 +- drivers/media/usb/hdpvr/hdpvr-video.c | 918 +--- drivers/media/usb/hdpvr/hdpvr.h | 19 +- include/uapi/linux/v4l2-dv-timings.h | 18 ++ include/uapi/linux/videodev2.h|2 +- 5 files changed, 473 insertions(+), 498 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] uvcvideo: Disable USB autosuspend for Creative Live! Cam Optia AF
On Thu, 28 Mar 2013, Laurent Pinchart wrote: The camera fails to start video streaming after having been autosuspend. Add a new quirk to selectively disable autosuspend for devices that don't support it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/usb/uvc/uvc_driver.c | 14 +- drivers/media/usb/uvc/uvcvideo.h | 1 + 2 files changed, 14 insertions(+), 1 deletion(-) I've tried to set the reset resume quirk for this device in the USB core but the camera still failed to start video streaming after having been autosuspended. Regardless of whether the reset resume quirk was set, it would respond to control messages but wouldn't send video data. Presumably the camera won't work after a system suspend, either. This solution below is a hack, but I'm not sure what else I can try. Crazy ideas are welcome. It's not a hack; it's a normal use for a quirk flag. Of course, if you can figure out what's wrong with the camera and see how to fix it, that would be best. How does the camera perform on a Windows system after being put to sleep and then woken up? Alan Stern -- To unsubscribe from this list: send the line unsubscribe 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: Terratec Grabby hwrev 2
On Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras timo.te...@iki.fi wrote: On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. Smells to me that they replaced the saa7113 with cheaper clone that does not support the ID string. Sounds like the same issue as: http://www.spinics.net/lists/linux-media/msg57926.html Additionally noted that something is not initialized right: With PAL signal: - there's some junk pixel in beginning of each line (looks like pixes from previous lines end), sync issue? - some junk lines at the end - distorted colors when white and black change between pixels Still have not figured out this one. Could be probably related to the saa7113 differences. With NTSC signal: - unable to get a lock, and the whole picture looks garbled NTSC started working after I removed all the saa711x writes to following registers: R_14_ANAL_ADC_COMPAT_CNTL R_15_VGATE_START_FID_CHG R_16_VGATE_STOP R_17_MISC_VGATE_CONF_AND_MSB - Timo -- To unsubscribe from this list: send the line unsubscribe 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: Terratec Grabby hwrev 2
Em Thu, 28 Mar 2013 15:35:56 +0200 Timo Teras timo.te...@iki.fi escreveu: On Thu, 28 Mar 2013 09:40:52 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 28 Mar 2013 10:52:01 +0200 Timo Teras timo.te...@iki.fi escreveu: On Wed, 27 Mar 2013 16:10:49 +0200 Timo Teras timo.te...@iki.fi wrote: On Tue, 26 Mar 2013 10:20:56 +0200 Timo Teras timo.te...@iki.fi wrote: I did manage to get decent traces with USBlyzer evaluation version. Nothing _that_ exciting there. Though, there's quite a bit of differences on certain register writes. I tried copying the changed parts, but did not really help. Turning on saa7115 debug gave: saa7115 1-0025: chip found @ 0x4a (ID 000) does not match a known saa711x chip. Well, I just made saa7115.c ignore this ID check, and defeault to saa7113 which is apparently the chip used. And now it looks like things start to work a lot better. Weird that the saa7113 chip is missing the ID string. Will continue testing. That could happen if saa7113 is behind some I2C bridge and when saa7113 is not found when the detection code is called. Smells to me that they replaced the saa7113 with cheaper clone that does not support the ID string. Well, I suspect that you'll need to open the box and see what's there. Are you sure that you've initiated the needed GPIO settings before start writing data to it? Sounds like the same issue as: http://www.spinics.net/lists/linux-media/msg57926.html Additionally noted that something is not initialized right: With PAL signal: - there's some junk pixel in beginning of each line (looks like pixes from previous lines end), sync issue? - some junk lines at the end - distorted colors when white and black change between pixels With NTSC signal: - unable to get a lock, and the whole picture looks garbled The driver supports several chipset variants, by reading the ID data from it. If the autodetection code didn't work, it may be sending commands to the wrong variation. Also, if this is a clone, it may require some different setups for it to work, either at saa711x driver or less likely at em28xx. On the W7 driver, I don't get any of the above mentioned problems. I looked at the saa7113 register init sequence, and copied that over to linux saa7113 init, but that did not remove the problems. There were only few changes. So, maybe it does a different crop setup at em28xx. - Timo -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Mar 28 19:00:21 CET 2013 git branch: test git hash: 004e45d736bfe62159bd4dc1549eff414bd27496 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS 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: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Problems with Hauppauge Nova TD Dual Tuner USB Stick and Mythtv, no problems in Windows!
I'm posting this on both the Mythtv dev and Linux Media lists as I'm not sure where the problem sits, my inclination is it's probably in myth's tuning and I'll explaing why shortly. I recently built a system for a friend of mine, using Fedora 18 x64. Clean build on a DFI Mini ITX P55-T36 system with a decent sized hard disk and 4GB of memory..plenty to run a mythTV backend. The tuners were Hauppauge Nova TD Dual Tuner USB Sticks, USB reference 2040:9580 IIRC. His place has a masthead antenna and no matter what I did I could not get these things to tune properly. LNA On, LNA Off, Rooftop Antenna, Mini Antenna supplied with Stick, Attenuators in and out, I've messed around with every variation for about 3 weeks now and been unable to get a proper signal on all the muxes no matter what I do. He's in East London on the border of the City near Aldgate. His internal antenna feed to the TV is perfect but I cannot get it behave using Linux no matter what configuration I try. In desperation I finally tried something different today, took in another hard disk and did a clean build of Windows 7 Ultimate x64, didn't touch anything else, installed the latest Hauppauge drivers from their website and used Win7Ult own Media for TV software.every channel tuned in straight away no problem, except some borderline signal issues with the Film4 mux. Now this got me thinking back to when I first plugged the USB stick in to a Mint Live CD, I tested it using either VLC or Kaffeine (I honest can't rmember which) and I could get tuning on pretty much all the channels straight away. As the device isn't supported properly in Myth/Linux I had to compile the V4L drivers, I'm running Fedora 18 x64 Kernel 3.8.4-202 and V4L compiled last night, using Mythtv from the RPMFusion repos so 26.0.7--18. If anyone can suggest anything I'm receptive to try it but honestly I think something is broken in either the mythtv tuning code or the interaction between the tuners and the V4L drivers. If anyone wants specific info let me know what you need. Tony -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] gspca: remove obsolete Kconfig macros
The et61x251 driver was removed in v3.5. Remove the last references to
its Kconfig macro now.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, as usual.
drivers/media/usb/gspca/etoms.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/usb/gspca/etoms.c b/drivers/media/usb/gspca/etoms.c
index 38f68e1..f165581 100644
--- a/drivers/media/usb/gspca/etoms.c
+++ b/drivers/media/usb/gspca/etoms.c
@@ -768,9 +768,7 @@ static const struct sd_desc sd_desc = {
/* -- module initialisation -- */
static const struct usb_device_id device_table[] = {
{USB_DEVICE(0x102c, 0x6151), .driver_info = SENSOR_PAS106},
-#if !defined CONFIG_USB_ET61X251 !defined CONFIG_USB_ET61X251_MODULE
{USB_DEVICE(0x102c, 0x6251), .driver_info = SENSOR_TAS5130CXX},
-#endif
{}
};
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe 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 01/12] exynos-fimc-is: Adding device tree nodes
Hi Arun, On 03/28/2013 06:10 AM, Arun Kumar K wrote: On Wed, Mar 27, 2013 at 7:17 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 03/27/2013 05:31 AM, Arun Kumar K wrote: On Wed, Mar 27, 2013 at 4:21 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: On 03/26/2013 01:17 PM, Arun Kumar K wrote: [...] Only issue is with the context sharing. Right now you can see that the fimc-is context is shared between all the subdevs. As all of them are part of the same driver, it is possible. If sensor is made as an independent i2c device, a separate probe will be called for it. For ISP sensor subdev to work independently, it needs to call the fimc_is_pipeline_* calls for FW initialization and other configurations for which it needs the fimc-is main context. Now there is a workaround here by calling a get_context() macro in sensor's probe to get the fimc-is context. This will cause the same context to be shared and updated by 2 drivers though both are part of fimc-is. Is this acceptable? Or am I missing some other simple solution of implementing it in a better way? OK, thanks for the explanation. I can think of at least one possible way to get hold of the fimc-is context in the subdev. For instance, in subdev's .registered callback you get a pointer to struct v4l2_device, which is normally embedded in a top level driver's private data. Then with container_of() you could get hold of required data at the fimc-is driver. But as per current implementation, it is not the fimc-is driver that is registering the ISP subdevs. It will be registered from the media controller driver. So fimc-is context cannot be obtained by just using container_of(). I guess best option would be to have a function to get the IS slave interface driver context at the sensor subdev exported by the IS driver module, as you suggested previously. You still could obtain the fimc-is object from the media device private data structure, since the media device has normally a list of its all entities in one form or the other. But the sensor would need to know details of the media device, which makes it a bit pointless. Nevertheless, my main concern is the DT binding. Sharing the sensor subdev driver might not be that important at the moment, we are talking about 300..500 lines of code per ISP driver currently anyway. More important is to have the hardware described in a standard way, so when the firmware changes there is no need to change the DT bindings. But... to make the subdev drivers reuse possible subdevs should normally not be required to know the internals of a host driver they are registered to. And it looks a bit unusual to have fimc_pipeline_* calls in the sensor's operation handlers. fimc_pipeline_* I mentioned is not the media controller pipeline. Ok, I admit I got confused a bit, since the word pipeline refers in the code to both: the internal ISP chain, and the data processing chain containing the FIMC-IS and other devices like CSI-2 receiver or GScaler. In the fimc-is driver, all the subdevs just implement the interface part. All the core functionalities happen in fimc-is-pipeline.c and fimc-is-interface.c. Since these ISP subdevs (sensor, isp, scc, scp) are not independent devices, all are controlled by the ISP firmware whose configuration and interface is done from the fimc_is_pipeline_* and fimc_is_itf_* functions. So all the ISP subdevs including sensor need to call these functions. I thought that the subdevs could provide basic methods and it would be the top level media driver that would resolve any dependencies in calling required subdev ops, according to media graph configuration done by the user on /dev/media?. In case of ISP subdevs (isp, scc and scp), there is not much configuration that the media device can do. Only control possible is to turn on/off specific scaler DMA outputs which can be done via the video node ioctls. The role of media device here is mostly to convey the pipeline structure to the user. For eg. it is not possible to directly connect isp (sd) -- scp (sd). In the media controller pipeline1 implementation, we were planning to put immutable links between these subdevs. Is that acceptable? Not sure I understand which links you mean exactly. Could you post the media graph generated by media-ctl (--print-dot) ? If you're talking about the on-the-fly (FIFO) links, then it probably makes sense. The media device driver should respond to the link_notify events and not to allow data links unsupported in the hardware. If you create immutable OTF links, then how would you switch between DMA and OTF interfaces ? Or can all processing blocks of the ISP chain work simultaneously with the DMA and OTF ? The FD block, for instance, can fed data from memory _or_ from previous processing block in the chain, right ? You will need a user interface to control which input is used and the links configuration seems most natural here. The media driver has a list of media entities
