Re: [PATCH] [media] videobuf-dma-contig: restore buffer mapping for uncached bufers
On Sat 23 June 2012 11:19:24 Hans Verkuil wrote: On Fri June 22 2012 18:53:27 Federico Vaga wrote: In data venerdì 22 giugno 2012 18:45:31, Hans Verkuil ha scritto: On Fri June 22 2012 17:28:04 Federico Vaga wrote: from commit a8f3c203e19b702fa5e8e83a9b6fb3c5a6d1cce4 restore the mapping scheme for uncached buffers, which was changed in a common scheme for cached and uncached. This apparently was wrong, and was probably intended only for cached buffers. the fix fixes the crash observed while mapping uncached buffers. Signed-off-by: Lad, Prabhakar prabhakar@ti.com Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com Acked-by: Federico Vaga federico.v...@gmail.com I tested the patch on the STA2X11 board. Was this patch ever posted on linux-media? I didn't see it on the mailinglist, nor in my personal inbox. Perhaps something went wrong? I recived the email as CC and linux-media was the main destination. Davinci list was also added as CC and you can find the patch there: http://www.mail-archive.com/davinci-linux-open- sou...@linux.davincidsp.com/msg22998.html Something went wrong. Weird, it never ended up at the linux-media mailinglist (not just me, it's not in the linux-media archives either). Anyway, I'll test this on Monday and if it works fine for me as well I'll Ack it. I've tested this patch, and it looks good: Acked-by: Hans Verkuil hans.verk...@cisco.com Prabhakar: Please post this again with all acks and marked as [PATCH for v3.5] to the linux-media mailinglist asap. This patch never made it to this list for some reason, so make sure it gets there this time. Regards, Hans Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] videobuf-dma-contig: restore buffer mapping for uncached bufers
Hi Hans, On Mon, Jun 25, 2012 at 17:13:39, Hans Verkuil wrote: On Sat 23 June 2012 11:19:24 Hans Verkuil wrote: On Fri June 22 2012 18:53:27 Federico Vaga wrote: In data venerdì 22 giugno 2012 18:45:31, Hans Verkuil ha scritto: On Fri June 22 2012 17:28:04 Federico Vaga wrote: from commit a8f3c203e19b702fa5e8e83a9b6fb3c5a6d1cce4 restore the mapping scheme for uncached buffers, which was changed in a common scheme for cached and uncached. This apparently was wrong, and was probably intended only for cached buffers. the fix fixes the crash observed while mapping uncached buffers. Signed-off-by: Lad, Prabhakar prabhakar@ti.com Signed-off-by: Hadli, Manjunath manjunath.ha...@ti.com Acked-by: Federico Vaga federico.v...@gmail.com I tested the patch on the STA2X11 board. Was this patch ever posted on linux-media? I didn't see it on the mailinglist, nor in my personal inbox. Perhaps something went wrong? I recived the email as CC and linux-media was the main destination. Davinci list was also added as CC and you can find the patch there: http://www.mail-archive.com/davinci-linux-open- sou...@linux.davincidsp.com/msg22998.html Something went wrong. Weird, it never ended up at the linux-media mailinglist (not just me, it's not in the linux-media archives either). Anyway, I'll test this on Monday and if it works fine for me as well I'll Ack it. I've tested this patch, and it looks good: Acked-by: Hans Verkuil hans.verk...@cisco.com Prabhakar: Please post this again with all acks and marked as [PATCH for v3.5] to the linux-media mailinglist asap. This patch never made it to this list for some reason, so make sure it gets there this time. Ok. Thanks for the review. Thx, --Prabhakar Lad Regards, Hans Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/13] davinci: vpif: add support for clipping on output data
Hi Manjunath,
Thank you for the patch.
On Monday 25 June 2012 16:37:30 Manjunath Hadli wrote:
add hardware clipping support for VPIF output data. This
is needed as it is possible that the external encoder
might get confused between the FF or 00 which are a part
of the data and that of the SAV or EAV codes.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/video/davinci/vpif.h | 30 +
drivers/media/video/davinci/vpif_display.c | 10 +
include/media/davinci/vpif_types.h |2 +
3 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h index a4d2141..c2ce4d9 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -211,6 +211,12 @@ static inline void vpif_clr_bit(u32 reg, u32 bit)
#define VPIF_CH3_INT_CTRL_SHIFT (6)
#define VPIF_CH_INT_CTRL_SHIFT (6)
+#define VPIF_CH2_CLIP_ANC_EN 14
+#define VPIF_CH2_CLIP_ACTIVE_EN 13
+
+#define VPIF_CH3_CLIP_ANC_EN 14
+#define VPIF_CH3_CLIP_ACTIVE_EN 13
+
/* enabled interrupt on both the fields on vpid_ch0_ctrl register */
#define channel0_intr_assert() (regw((regr(VPIF_CH0_CTRL)|\
(VPIF_INT_BOTH VPIF_CH0_INT_CTRL_SHIFT)), VPIF_CH0_CTRL))
@@ -515,6 +521,30 @@ static inline void channel3_raw_enable(int enable, u8
index) vpif_clr_bit(VPIF_CH3_CTRL, mask);
}
+/* function to enable clipping (for both active and blanking regions) on ch
2 */ +static inline void channel2_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ }
+}
+
+/* function to enable clipping (for both active and blanking regions) on ch
2 */ +static inline void channel3_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ }
+}
+
/* inline function to set buffer addresses in case of Y/C non mux mode */
static inline void ch2_set_videobuf_addr_yc_nmux(unsigned long
top_strt_luma, unsigned long btm_strt_luma,
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c index 61ea8bc..4436ef6 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1046,6 +1046,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel2_intr_assert();
channel2_intr_enable(1);
enable_channel2(1);
+ if (vpif_config_data-ch2_clip_en)
+ channel2_clipping_enable(1);
}
if ((VPIF_CHANNEL3_VIDEO == ch-channel_id)
@@ -1053,6 +1055,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel3_intr_assert();
channel3_intr_enable(1);
enable_channel3(1);
+ if (vpif_config_data-ch3_clip_en)
+ channel3_clipping_enable(1);
}
channel_first_int[VPIF_VIDEO_INDEX][ch-channel_id] = 1;
}
@@ -1065,6 +1069,8 @@ static int vpif_streamoff(struct file *file, void
*priv, struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
+ struct vpif_display_config *vpif_config_data =
+ vpif_dev-platform_data;
if (buftype != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
vpif_err(buffer type not supported\n);
@@ -1084,11 +1090,15 @@ static int vpif_streamoff(struct file *file, void
*priv, if (buftype == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
/* disable channel */
if (VPIF_CHANNEL2_VIDEO == ch-channel_id) {
+ if (vpif_config_data-ch2_clip_en)
+ channel2_clipping_enable(0);
enable_channel2(0);
channel2_intr_enable(0);
}
if ((VPIF_CHANNEL3_VIDEO == ch-channel_id) ||
(2 == common-started)) {
+ if (vpif_config_data-ch3_clip_en)
+ channel3_clipping_enable(0);
enable_channel3(0);
channel3_intr_enable(0);
}
diff --git a/include/media/davinci/vpif_types.h
Re: [PATCH v3 09/13] davinci: vpif display: Add power management support
Hi Manjunath,
Thank you for the patch.
On Monday 25 June 2012 16:37:31 Manjunath Hadli wrote:
Implement power management operations - suspend and resume as part of
dev_pm_ops for VPIF display driver.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/video/davinci/vpif_display.c | 75 +
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c index 4436ef6..7408733 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1807,10 +1807,85 @@ static int vpif_remove(struct platform_device
*device) return 0;
}
+#ifdef CONFIG_PM
+static int vpif_suspend(struct device *dev)
+{
+ struct common_obj *common;
+ struct channel_obj *ch;
+ int i;
+
+ for (i = 0; i VPIF_DISPLAY_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ common = ch-common[VPIF_VIDEO_INDEX];
+ if (mutex_lock_interruptible(common-lock))
+ return -ERESTARTSYS;
I might be wrong, but I don't think the suspend/resume handlers react
correctly to -ERESTARTSYS. If that's correct you should use mutex_lock()
instead of mutex_lock_interruptible().
+
+ if (atomic_read(ch-usrs) common-io_usrs) {
+ /* Disable channel */
+ if (ch-channel_id == VPIF_CHANNEL2_VIDEO) {
+ enable_channel2(0);
+ channel2_intr_enable(0);
+ }
+ if (ch-channel_id == VPIF_CHANNEL3_VIDEO ||
+ common-started == 2) {
+ enable_channel3(0);
+ channel3_intr_enable(0);
+ }
+ }
+ mutex_unlock(common-lock);
+ }
+
+ return 0;
+}
+
+static int vpif_resume(struct device *dev)
+{
+
+ struct common_obj *common;
+ struct channel_obj *ch;
+ int i;
+
+ for (i = 0; i VPIF_DISPLAY_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ common = ch-common[VPIF_VIDEO_INDEX];
+ if (mutex_lock_interruptible(common-lock))
+ return -ERESTARTSYS;
+
+ if (atomic_read(ch-usrs) common-io_usrs) {
+ /* Enable channel */
+ if (ch-channel_id == VPIF_CHANNEL2_VIDEO) {
+ enable_channel2(1);
+ channel2_intr_enable(1);
+ }
+ if (ch-channel_id == VPIF_CHANNEL3_VIDEO ||
+ common-started == 2) {
+ enable_channel3(1);
+ channel3_intr_enable(1);
+ }
+ }
+ mutex_unlock(common-lock);
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops vpif_pm = {
+ .suspend= vpif_suspend,
+ .resume = vpif_resume,
+};
+
+#define vpif_pm_ops (vpif_pm)
+#else
+#define vpif_pm_ops NULL
+#endif
+
static __refdata struct platform_driver vpif_driver = {
.driver = {
.name = vpif_display,
.owner = THIS_MODULE,
+ .pm = vpif_pm_ops,
},
.probe = vpif_probe,
.remove = vpif_remove,
--
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 v3 10/13] davinci: vpif capture:Add power management support
Hi Manjunath,
Thank you for the patch.
On Monday 25 June 2012 16:37:32 Manjunath Hadli wrote:
Implement power management operations - suspend and resume as part of
dev_pm_ops for VPIF capture driver.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/video/davinci/vpif_capture.c | 77 +
1 files changed, 65 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c index 097e136..f1ee137 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -2300,26 +2300,74 @@ static int vpif_remove(struct platform_device
*device) return 0;
}
+#ifdef CONFIG_PM
/**
* vpif_suspend: vpif device suspend
- *
- * TODO: Add suspend code here
*/
-static int
-vpif_suspend(struct device *dev)
+static int vpif_suspend(struct device *dev)
{
- return -1;
+
+ struct common_obj *common;
+ struct channel_obj *ch;
+ int i;
+
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ common = ch-common[VPIF_VIDEO_INDEX];
+ if (mutex_lock_interruptible(common-lock))
+ return -ERESTARTSYS;
As for the display driver, this should probably be replaced by mutex_lock().
+ if (ch-usrs common-io_usrs) {
+ /* Disable channel */
+ if (ch-channel_id == VPIF_CHANNEL0_VIDEO) {
+ enable_channel0(0);
+ channel0_intr_enable(0);
+ }
+ if (ch-channel_id == VPIF_CHANNEL1_VIDEO ||
+ common-started == 2) {
+ enable_channel1(0);
+ channel1_intr_enable(0);
+ }
+ }
+ mutex_unlock(common-lock);
+ }
+
+ return 0;
}
-/**
+/*
* vpif_resume: vpif device suspend
- *
- * TODO: Add resume code here
*/
-static int
-vpif_resume(struct device *dev)
+static int vpif_resume(struct device *dev)
{
- return -1;
+ struct common_obj *common;
+ struct channel_obj *ch;
+ int i;
+
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ common = ch-common[VPIF_VIDEO_INDEX];
+ if (mutex_lock_interruptible(common-lock))
+ return -ERESTARTSYS;
+
+ if (ch-usrs common-io_usrs) {
+ /* Disable channel */
+ if (ch-channel_id == VPIF_CHANNEL0_VIDEO) {
+ enable_channel0(1);
+ channel0_intr_enable(1);
+ }
+ if (ch-channel_id == VPIF_CHANNEL1_VIDEO ||
+ common-started == 2) {
+ enable_channel1(1);
+ channel1_intr_enable(1);
+ }
+ }
+ mutex_unlock(common-lock);
+ }
+
+ return 0;
}
static const struct dev_pm_ops vpif_dev_pm_ops = {
@@ -2327,11 +2375,16 @@ static const struct dev_pm_ops vpif_dev_pm_ops = {
.resume = vpif_resume,
};
+#define vpif_pm_ops (vpif_dev_pm_ops)
+#else
+#define vpif_pm_ops NULL
+#endif
+
static __refdata struct platform_driver vpif_driver = {
.driver = {
.name = vpif_capture,
.owner = THIS_MODULE,
- .pm = vpif_dev_pm_ops,
+ .pm = vpif_pm_ops,
},
.probe = vpif_probe,
.remove = vpif_remove,
--
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 v3 08/13] davinci: vpif: add support for clipping on output data
On Mon 25 June 2012 14:54:39 Laurent Pinchart wrote:
Hi Manjunath,
Thank you for the patch.
On Monday 25 June 2012 16:37:30 Manjunath Hadli wrote:
add hardware clipping support for VPIF output data. This
is needed as it is possible that the external encoder
might get confused between the FF or 00 which are a part
of the data and that of the SAV or EAV codes.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/video/davinci/vpif.h | 30 +
drivers/media/video/davinci/vpif_display.c | 10 +
include/media/davinci/vpif_types.h |2 +
3 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h index a4d2141..c2ce4d9 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -211,6 +211,12 @@ static inline void vpif_clr_bit(u32 reg, u32 bit)
#define VPIF_CH3_INT_CTRL_SHIFT(6)
#define VPIF_CH_INT_CTRL_SHIFT (6)
+#define VPIF_CH2_CLIP_ANC_EN 14
+#define VPIF_CH2_CLIP_ACTIVE_EN13
+
+#define VPIF_CH3_CLIP_ANC_EN 14
+#define VPIF_CH3_CLIP_ACTIVE_EN13
+
/* enabled interrupt on both the fields on vpid_ch0_ctrl register */
#define channel0_intr_assert() (regw((regr(VPIF_CH0_CTRL)|\
(VPIF_INT_BOTH VPIF_CH0_INT_CTRL_SHIFT)), VPIF_CH0_CTRL))
@@ -515,6 +521,30 @@ static inline void channel3_raw_enable(int enable, u8
index) vpif_clr_bit(VPIF_CH3_CTRL, mask);
}
+/* function to enable clipping (for both active and blanking regions) on ch
2 */ +static inline void channel2_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ }
+}
+
+/* function to enable clipping (for both active and blanking regions) on ch
2 */ +static inline void channel3_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ }
+}
+
/* inline function to set buffer addresses in case of Y/C non mux mode */
static inline void ch2_set_videobuf_addr_yc_nmux(unsigned long
top_strt_luma, unsigned long btm_strt_luma,
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c index 61ea8bc..4436ef6 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1046,6 +1046,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel2_intr_assert();
channel2_intr_enable(1);
enable_channel2(1);
+ if (vpif_config_data-ch2_clip_en)
+ channel2_clipping_enable(1);
}
if ((VPIF_CHANNEL3_VIDEO == ch-channel_id)
@@ -1053,6 +1055,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel3_intr_assert();
channel3_intr_enable(1);
enable_channel3(1);
+ if (vpif_config_data-ch3_clip_en)
+ channel3_clipping_enable(1);
}
channel_first_int[VPIF_VIDEO_INDEX][ch-channel_id] = 1;
}
@@ -1065,6 +1069,8 @@ static int vpif_streamoff(struct file *file, void
*priv, struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
+ struct vpif_display_config *vpif_config_data =
+ vpif_dev-platform_data;
if (buftype != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
vpif_err(buffer type not supported\n);
@@ -1084,11 +1090,15 @@ static int vpif_streamoff(struct file *file, void
*priv, if (buftype == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
/* disable channel */
if (VPIF_CHANNEL2_VIDEO == ch-channel_id) {
+ if (vpif_config_data-ch2_clip_en)
+ channel2_clipping_enable(0);
enable_channel2(0);
channel2_intr_enable(0);
}
if ((VPIF_CHANNEL3_VIDEO == ch-channel_id) ||
(2 == common-started)) {
+ if (vpif_config_data-ch3_clip_en)
+ channel3_clipping_enable(0);
enable_channel3(0);
channel3_intr_enable(0);
}
diff
Re: [PATCH v3 08/13] davinci: vpif: add support for clipping on output data
Hi Hans,
On Monday 25 June 2012 15:08:10 Hans Verkuil wrote:
On Mon 25 June 2012 14:54:39 Laurent Pinchart wrote:
On Monday 25 June 2012 16:37:30 Manjunath Hadli wrote:
add hardware clipping support for VPIF output data. This
is needed as it is possible that the external encoder
might get confused between the FF or 00 which are a part
of the data and that of the SAV or EAV codes.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/video/davinci/vpif.h | 30 +
drivers/media/video/davinci/vpif_display.c | 10 +
include/media/davinci/vpif_types.h |2 +
3 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h index a4d2141..c2ce4d9 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -211,6 +211,12 @@ static inline void vpif_clr_bit(u32 reg, u32 bit)
#define VPIF_CH3_INT_CTRL_SHIFT (6)
#define VPIF_CH_INT_CTRL_SHIFT (6)
+#define VPIF_CH2_CLIP_ANC_EN 14
+#define VPIF_CH2_CLIP_ACTIVE_EN 13
+
+#define VPIF_CH3_CLIP_ANC_EN 14
+#define VPIF_CH3_CLIP_ACTIVE_EN 13
+
/* enabled interrupt on both the fields on vpid_ch0_ctrl register */
#define channel0_intr_assert() (regw((regr(VPIF_CH0_CTRL)|\
(VPIF_INT_BOTH VPIF_CH0_INT_CTRL_SHIFT)), VPIF_CH0_CTRL))
@@ -515,6 +521,30 @@ static inline void channel3_raw_enable(int enable,
u8
index) vpif_clr_bit(VPIF_CH3_CTRL, mask);
}
+/* function to enable clipping (for both active and blanking regions)
on ch 2 */ +static inline void channel2_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ }
+}
+
+/* function to enable clipping (for both active and blanking regions)
on ch 2 */ +static inline void channel3_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ }
+}
+
/* inline function to set buffer addresses in case of Y/C non mux mode
*/
static inline void ch2_set_videobuf_addr_yc_nmux(unsigned long
top_strt_luma, unsigned long btm_strt_luma,
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c index 61ea8bc..4436ef6
100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1046,6 +1046,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel2_intr_assert();
channel2_intr_enable(1);
enable_channel2(1);
+ if (vpif_config_data-ch2_clip_en)
+ channel2_clipping_enable(1);
}
if ((VPIF_CHANNEL3_VIDEO == ch-channel_id)
@@ -1053,6 +1055,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel3_intr_assert();
channel3_intr_enable(1);
enable_channel3(1);
+ if (vpif_config_data-ch3_clip_en)
+ channel3_clipping_enable(1);
}
channel_first_int[VPIF_VIDEO_INDEX][ch-channel_id] = 1;
}
@@ -1065,6 +1069,8 @@ static int vpif_streamoff(struct file *file, void
*priv, struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
+ struct vpif_display_config *vpif_config_data =
+ vpif_dev-platform_data;
if (buftype != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
vpif_err(buffer type not supported\n);
@@ -1084,11 +1090,15 @@ static int vpif_streamoff(struct file *file,
void
*priv, if (buftype == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
/* disable channel */
if (VPIF_CHANNEL2_VIDEO == ch-channel_id) {
+ if (vpif_config_data-ch2_clip_en)
+ channel2_clipping_enable(0);
enable_channel2(0);
channel2_intr_enable(0);
}
if ((VPIF_CHANNEL3_VIDEO == ch-channel_id) ||
(2 == common-started)) {
+ if (vpif_config_data-ch3_clip_en)
Re: [PATCH v3 08/13] davinci: vpif: add support for clipping on output data
On Mon 25 June 2012 15:18:41 Laurent Pinchart wrote:
Hi Hans,
On Monday 25 June 2012 15:08:10 Hans Verkuil wrote:
On Mon 25 June 2012 14:54:39 Laurent Pinchart wrote:
On Monday 25 June 2012 16:37:30 Manjunath Hadli wrote:
add hardware clipping support for VPIF output data. This
is needed as it is possible that the external encoder
might get confused between the FF or 00 which are a part
of the data and that of the SAV or EAV codes.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
drivers/media/video/davinci/vpif.h | 30 +
drivers/media/video/davinci/vpif_display.c | 10 +
include/media/davinci/vpif_types.h |2 +
3 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h index a4d2141..c2ce4d9 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -211,6 +211,12 @@ static inline void vpif_clr_bit(u32 reg, u32 bit)
#define VPIF_CH3_INT_CTRL_SHIFT(6)
#define VPIF_CH_INT_CTRL_SHIFT (6)
+#define VPIF_CH2_CLIP_ANC_EN 14
+#define VPIF_CH2_CLIP_ACTIVE_EN13
+
+#define VPIF_CH3_CLIP_ANC_EN 14
+#define VPIF_CH3_CLIP_ACTIVE_EN13
+
/* enabled interrupt on both the fields on vpid_ch0_ctrl register */
#define channel0_intr_assert() (regw((regr(VPIF_CH0_CTRL)|\
(VPIF_INT_BOTH VPIF_CH0_INT_CTRL_SHIFT)), VPIF_CH0_CTRL))
@@ -515,6 +521,30 @@ static inline void channel3_raw_enable(int enable,
u8
index) vpif_clr_bit(VPIF_CH3_CTRL, mask);
}
+/* function to enable clipping (for both active and blanking regions)
on ch 2 */ +static inline void channel2_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH2_CTRL, VPIF_CH2_CLIP_ACTIVE_EN);
+ }
+}
+
+/* function to enable clipping (for both active and blanking regions)
on ch 2 */ +static inline void channel3_clipping_enable(int enable)
+{
+ if (enable) {
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_set_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ } else {
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ANC_EN);
+ vpif_clr_bit(VPIF_CH3_CTRL, VPIF_CH3_CLIP_ACTIVE_EN);
+ }
+}
+
/* inline function to set buffer addresses in case of Y/C non mux mode
*/
static inline void ch2_set_videobuf_addr_yc_nmux(unsigned long
top_strt_luma, unsigned long btm_strt_luma,
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c index 61ea8bc..4436ef6
100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1046,6 +1046,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel2_intr_assert();
channel2_intr_enable(1);
enable_channel2(1);
+ if (vpif_config_data-ch2_clip_en)
+ channel2_clipping_enable(1);
}
if ((VPIF_CHANNEL3_VIDEO == ch-channel_id)
@@ -1053,6 +1055,8 @@ static int vpif_streamon(struct file *file, void
*priv, channel3_intr_assert();
channel3_intr_enable(1);
enable_channel3(1);
+ if (vpif_config_data-ch3_clip_en)
+ channel3_clipping_enable(1);
}
channel_first_int[VPIF_VIDEO_INDEX][ch-channel_id] = 1;
}
@@ -1065,6 +1069,8 @@ static int vpif_streamoff(struct file *file, void
*priv, struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
+ struct vpif_display_config *vpif_config_data =
+ vpif_dev-platform_data;
if (buftype != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
vpif_err(buffer type not supported\n);
@@ -1084,11 +1090,15 @@ static int vpif_streamoff(struct file *file,
void
*priv, if (buftype == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
/* disable channel */
if (VPIF_CHANNEL2_VIDEO == ch-channel_id) {
[ANNOUNCEMENT] (tentative) Android generic V4L2 camera HAL
Hi all It's been a while since I've actually done this work. We have been waiting for various formalities to be resolved to be able to publish this work upstream. There are still a couple of formal issues to sort out before we can begin the submission process, but at least it has been decided to release patches for independent review and testing. For now I've uploaded a development snapshot to http://download.open-technology.de/android/20120625/ In the future we probably will provide git trees at least for the system/media/v4l_camera development. Enjoy:-) Any comments welcome. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stk1160 linux driver
Hi Gianluca, On Mon, Jun 25, 2012 at 4:09 AM, Gianluca Bergamo gianluca.berg...@gmail.com wrote: Hi Ezequiel, No problem in patching each new release you made. Please note I've just send a v3 of stk1160 driver. It adds support for controlling ac97 and for selecting video inputs. In my environment this command line gives only one format supported (UYVY) and then yavta freezes. I suspect it freezes on an ioctl to the driver. I must check it. Weird. I've just tested with yavta and it works perfectly. You should note that this command is wrong: ./yavta -f YUYV -s 720x576 -n 4 --capture=4 -F /dev/video1 and it should be: ./yavta -f UYVY -s 720x576 -n 4 --capture=4 -F /dev/video1 Since, as you noted the only supported format is UYVY. Some applications take advantage of libv4l2 wrapper library to increase the output format set. For instance, if I do ENUM_FMT using v4l2-ctl I get just one supported format: $ v4l2-ctl --list-formats ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Capture Pixel Format: 'UYVY' Name: 16 bpp YUY2, 4:2:2, packed But if I use wrapper library: $ v4l2-ctl -w --list-formats ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Capture Pixel Format: 'UYVY' Name: 16 bpp YUY2, 4:2:2, packed Index : 1 Type: Video Capture Pixel Format: 'RGB3' (emulated) Name: RGB3 Index : 2 Type: Video Capture Pixel Format: 'BGR3' (emulated) Name: BGR3 Index : 3 Type: Video Capture Pixel Format: 'YU12' (emulated) Name: YU12 Index : 4 Type: Video Capture Pixel Format: 'YV12' (emulated) Name: YV12 In case you need it, here's my yavta output: $ ./yavta --enum-formats /dev/video0 Device /dev/video0 opened. Device `stk1160' on `usb-:00:13.2-2' is a video capture device. - Available formats: Format 0: UYVY (59565955) Type: Video capture (1) Name: 16 bpp YUY2, 4:2:2, packed $ ./yavta -f YUYV -s 720x576 -n 4 --capture=4 -F /dev/video0 Device /dev/video0 opened. Device `stk1160' on `usb-:00:13.2-2' is a video capture device. Unable to set format: Invalid argument (22). localhost yavta # ./yavta -f UYVY -s 720x576 -n 4 --capture=4 -F /dev/video0 Device /dev/video0 opened. Device `stk1160' on `usb-:00:13.2-2' is a video capture device. Video format set: UYVY (59565955) 720x480 (stride 1440) buffer size 691200 Video format: UYVY (59565955) 720x480 (stride 1440) buffer size 691200 8 buffers requested. length: 691200 offset: 0 Buffer 0 mapped at address 0xb7584000. length: 691200 offset: 692224 Buffer 1 mapped at address 0xb74db000. length: 691200 offset: 1384448 Buffer 2 mapped at address 0xb7432000. length: 691200 offset: 2076672 Buffer 3 mapped at address 0xb7389000. length: 691200 offset: 2768896 Buffer 4 mapped at address 0xb72e. length: 691200 offset: 3461120 Buffer 5 mapped at address 0xb7237000. length: 691200 offset: 4153344 Buffer 6 mapped at address 0xb718e000. length: 691200 offset: 4845568 Buffer 7 mapped at address 0xb70e5000. 0 (0) [-] 0 691200 bytes 1340632305.824287 1826.669365 -0.002 fps 1 (1) [-] 1 691200 bytes 1340632305.856350 1826.709943 31.189 fps 2 (2) [-] 1 691200 bytes 1340632305.896222 1826.741385 25.080 fps 3 (3) [-] 2 691200 bytes 1340632305.928226 1826.773354 31.246 fps Captured 4 frames in 0.199372 seconds (20.062936 fps, 13867501.311552 B/s). 8 buffers released. -- 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: stk1160 linux driver
On Mon, Jun 25, 2012 at 11:09 AM, Gianluca Bergamo gianluca.berg...@gmail.com wrote: Hi Ezequiel, Have you tested with the latest version of your driver? Where can I download it? http://patchwork.linuxtv.org/patch/13043/ -- 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: [ANNOUNCEMENT] (tentative) Android generic V4L2 camera HAL
(+ My gmail address, please start using that address from next week on, since I'm leaving TI) Hi Guennadi, Thanks a lot for sharing these! Nice job. I immediately noticed you have changes on hardware/ti/omap4xxx/ subproject. So, Which devices did you used for testing this? I got confused since you had changes for the Samsung Nexus S, which has an Exynos chip... And you also have this Renesas Mackerel, which seems to use a SuperH 7372. Or maybe you just patched the omap4xxx related file to fix a build :) Regards, Sergio On Mon, Jun 25, 2012 at 8:55 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi all It's been a while since I've actually done this work. We have been waiting for various formalities to be resolved to be able to publish this work upstream. There are still a couple of formal issues to sort out before we can begin the submission process, but at least it has been decided to release patches for independent review and testing. For now I've uploaded a development snapshot to http://download.open-technology.de/android/20120625/ In the future we probably will provide git trees at least for the system/media/v4l_camera development. Enjoy:-) Any comments welcome. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCEMENT] (tentative) Android generic V4L2 camera HAL
Hi Sergio On Mon, 25 Jun 2012, Aguirre, Sergio wrote: (+ My gmail address, please start using that address from next week on, since I'm leaving TI) Hi Guennadi, Thanks a lot for sharing these! Nice job. I immediately noticed you have changes on hardware/ti/omap4xxx/ subproject. So, Which devices did you used for testing this? I got confused since you had changes for the Samsung Nexus S, which has an Exynos chip... And you also have this Renesas Mackerel, which seems to use a SuperH 7372. Or maybe you just patched the omap4xxx related file to fix a build :) Right, I only used the sh7372 based mackerel board from Renesas, as lightly hinted in the README, not all patches in that directory are really related to the camera library, some are unrelated fixes and improvements, others are build fixes to compensate for a changed API. Thanks Guennadi Regards, Sergio On Mon, Jun 25, 2012 at 8:55 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi all It's been a while since I've actually done this work. We have been waiting for various formalities to be resolved to be able to publish this work upstream. There are still a couple of formal issues to sort out before we can begin the submission process, but at least it has been decided to release patches for independent review and testing. For now I've uploaded a development snapshot to http://download.open-technology.de/android/20120625/ In the future we probably will provide git trees at least for the system/media/v4l_camera development. Enjoy:-) Any comments welcome. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stk1160 linux driver
On Mon, Jun 25, 2012 at 11:26 AM, Gianluca Bergamo gianluca.berg...@gmail.com wrote: Thank you. I'm going to test it as soon as I can. PS : Are you testing on ARM architecture? I'm starting to think my problems could be related to it...as most of the video capture drivers are working well on x86...is it possible for you to do a little test on ARM? No :-( However, if you have a small ARM device you'd like to donate I'll give it good use :-) Anyway, this thread suggests there are some issues with analog capture on ARM devices (using em28xx driver, but it's similar to stk1160): http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/48009 I've added Devin in Cc: Devin: You said you ran into some issues on em28xx on ARM, what kind of issues? Thanks, Ezequiel. -- 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: stk1160 linux driver
On Mon, Jun 25, 2012 at 10:36 AM, Ezequiel Garcia elezegar...@gmail.com wrote: I've added Devin in Cc: Devin: You said you ran into some issues on em28xx on ARM, what kind of issues? There are a handful of issues, but the big one which everybody runs into is a typo in a left shift operation that causes capture to be completely broken on ARM. I just never got around to sending a patch upstream for it. I don't know if this is the original report, but the issue is summarized well here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28407.html Others issue related to memory allocation on platforms like ARM with limited coherent memory (if the device is unplugged/replugged often, the device won't be able to allocate the URB buffers), as well as performance problems related to the type of memory used (dependent on which ARM chip is used). Most of this stuff is relatively straightforward to fix but I've just been too busy with other projects. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: add Analog Devices ADV7393 video encoder driver
Em 18-06-2012 16:32, Benoît Thébaudeau escreveu:
Add ADV7393 I²C-based video encoder driver. This driver has been tested on
custom hardware. It has been tested for composite output. It is derived from
the
ADV7343 driver.
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
---
.../drivers/media/video/Kconfig|9 +
.../drivers/media/video/Makefile |1 +
.../drivers/media/video/adv7393.c | 487
.../drivers/media/video/adv7393_regs.h | 188
.../include/media/adv7393.h| 28 ++
.../include/media/v4l2-chip-ident.h|3 +
6 files changed, 716 insertions(+)
create mode 100644 linux-next-HEAD-6c86b58/drivers/media/video/adv7393.c
create mode 100644
linux-next-HEAD-6c86b58/drivers/media/video/adv7393_regs.h
create mode 100644 linux-next-HEAD-6c86b58/include/media/adv7393.h
diff --git linux-next-HEAD-6c86b58.orig/drivers/media/video/Kconfig
linux-next-HEAD-6c86b58/drivers/media/video/Kconfig
index 99937c9..d00dee9 100644
--- linux-next-HEAD-6c86b58.orig/drivers/media/video/Kconfig
+++ linux-next-HEAD-6c86b58/drivers/media/video/Kconfig
@@ -461,6 +461,15 @@ config VIDEO_ADV7343
To compile this driver as a module, choose M here: the
module will be called adv7343.
+config VIDEO_ADV7393
+ tristate ADV7393 video encoder
+ depends on I2C
+ help
+ Support for Analog Devices I2C bus based ADV7393 encoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7393.
+
config VIDEO_AK881X
tristate AK8813/AK8814 video encoders
depends on I2C
diff --git linux-next-HEAD-6c86b58.orig/drivers/media/video/Makefile
linux-next-HEAD-6c86b58/drivers/media/video/Makefile
index d209de0..b7da9fa 100644
--- linux-next-HEAD-6c86b58.orig/drivers/media/video/Makefile
+++ linux-next-HEAD-6c86b58/drivers/media/video/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
+obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git linux-next-HEAD-6c86b58/drivers/media/video/adv7393.c
linux-next-HEAD-6c86b58/drivers/media/video/adv7393.c
new file mode 100644
index 000..ca72486
--- /dev/null
+++ linux-next-HEAD-6c86b58/drivers/media/video/adv7393.c
@@ -0,0 +1,487 @@
+/*
+ * adv7393 - ADV7393 Video Encoder Driver
+ *
+ * The encoder hardware does not support SECAM.
+ *
+ * Copyright (C) 2010-2012 ADVANSEE - http://www.advansee.com/
+ * Benoît Thébaudeau benoit.thebaud...@advansee.com
+ *
+ * Based on ADV7343 driver,
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/module.h
+#include linux/videodev2.h
+#include linux/uaccess.h
+
+#include media/adv7393.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
+
+#include adv7393_regs.h
+
+MODULE_DESCRIPTION(ADV7393 video encoder driver);
+MODULE_LICENSE(GPL);
+
+static bool debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+struct adv7393_state {
+ struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ u8 reg00;
+ u8 reg01;
+ u8 reg02;
+ u8 reg35;
+ u8 reg80;
+ u8 reg82;
+ u32 output;
+ v4l2_std_id std;
+};
+
+static inline struct adv7393_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7393_state, sd);
+}
+
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct adv7393_state, hdl)-sd;
+}
+
+static inline int adv7393_write(struct v4l2_subdev *sd, u8 reg, u8 value)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ return i2c_smbus_write_byte_data(client, reg, value);
+}
+
+static const u8 adv7393_init_reg_val[] = {
+ ADV7393_SOFT_RESET, ADV7393_SOFT_RESET_DEFAULT,
[PATCH] [media] Schedule the selections API compatibility definitions for removal
Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com --- Documentation/feature-removal-schedule.txt | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 09701af..ef9f942 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -558,3 +558,18 @@ Why: The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide similar functionality. Who: Sylwester Nawrocki sylvester.nawro...@gmail.com + + + +What: Remove the backward compatibility V4L2 selections target and selections + flags definitions +When: 3.8 +Why: The regular V4L2 selections and the subdev selection API originally + defined distinct names for the target rectangles and flags - V4L2_SEL_* + and V4L2_SUBDEV_SEL_*. Although, it turned out that the meaning of these + target rectangles is virtually identical and the APIs were consolidated + to use single set of names - V4L2_SEL_*. This consolidation didn't + change the ABI in any way. Alias definitions were created for the + original ones to avoid any instabilities in the user space interface. + After few cycles these comptibility definitions will be removed. +Who: Sylwester Nawrocki sylvester.nawro...@gmail.com -- 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: [PATCH] [media] Schedule the selections API compatibility definitions for removal
On 06/25/2012 06:51 PM, Sylwester Nawrocki wrote: Signed-off-by: Sylwester Nawrockisylvester.nawro...@gmail.com --- Hi Sakari, Let me add an explanation that was supposed to be originally included in that patch.. Here is the patch for Documentation/feature-removal-schedule.txt that is mentioned in the description of the first patch in this series. This change set looks good to me, except there seem to be missing compatibility definitions for the selections flags. I presume we are going to need those since the original subdev selections API will exist in v3.5 kernels, and this change set is going to be applied only to v3.6. So something like that might be needed: #define V4L2_SUBDEV_SEL_FLAG_SIZE_GE V4L2_SEL_FLAG_SIZE_GE #define V4L2_SUBDEV_SEL_FLAG_SIZE_LE V4L2_SEL_FLAG_SIZE_LE #define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG V4L2_SEL_FLAG_KEEP_CONFIG After adding that this series seems good for merging to me. Thanks and regards, Sylwester Documentation/feature-removal-schedule.txt | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 09701af..ef9f942 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -558,3 +558,18 @@ Why: The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide similar functionality. Who: Sylwester Nawrockisylvester.nawro...@gmail.com + + + +What: Remove the backward compatibility V4L2 selections target and selections + flags definitions +When: 3.8 +Why: The regular V4L2 selections and the subdev selection API originally + defined distinct names for the target rectangles and flags - V4L2_SEL_* + and V4L2_SUBDEV_SEL_*. Although, it turned out that the meaning of these + target rectangles is virtually identical and the APIs were consolidated + to use single set of names - V4L2_SEL_*. This consolidation didn't + change the ABI in any way. Alias definitions were created for the + original ones to avoid any instabilities in the user space interface. + After few cycles these comptibility definitions will be removed. +Who: Sylwester Nawrockisylvester.nawro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] Feature removal: V4L2 selections API target and flag definitions
Signed-off-by: Sylwester Nawrocki sylvester.nawro...@gmail.com --- Added more precise description of what is being removed. --- Documentation/feature-removal-schedule.txt | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 09701af..b998030 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -558,3 +558,21 @@ Why: The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide similar functionality. Who: Sylwester Nawrocki sylvester.nawro...@gmail.com + + + +What: V4L2 selections API target rectangle and flags unification, the + following definitions will be removed: V4L2_SEL_TGT_CROP_ACTIVE, + V4L2_SEL_TGT_COMPOSE_ACTIVE, V4L2_SUBDEV_SEL_*, V4L2_SUBDEV_SEL_FLAG_* + in favor of common V4L2_SEL_TGT_* and V4L2_SEL_FLAG_* definitions. + For more details see include/linux/v4l2-common.h. +When: 3.8 +Why: The regular V4L2 selections and the subdev selection API originally + defined distinct names for the target rectangles and flags - V4L2_SEL_* + and V4L2_SUBDEV_SEL_*. Although, it turned out that the meaning of these + target rectangles is virtually identical and the APIs were consolidated + to use single set of names - V4L2_SEL_*. This didn't involve any ABI + changes. Alias definitions were created for the original ones to avoid + any instabilities in the user space interface. After few cycles these + backward compatibility definitions will be removed. +Who: Sylwester Nawrocki sylvester.nawro...@gmail.com -- 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: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On 06/21/2012 10:10 PM, Mauro Carvalho Chehab wrote: Em 21-06-2012 10:36, Mauro Carvalho Chehab escreveu: The firmware blob may not be available when the driver probes. Instead of blocking the whole kernel use request_firmware_nowait() and continue without firmware. This shouldn't be that bad on drx-k devices, as they all seem to have an internal firmware. So, only the firmware update will take a little longer to happen. While thinking on converting another DVB frontend driver, I just realized that a patch like that won't work fine. As most of you know, there are _several_ I2C chips that don't tolerate any usage of the I2C bus while a firmware is being loaded (I dunno if this is the case of drx-k, but I won't doubt). The current approach makes the device probe() logic is serialized. So, there's no chance that two different I2C drivers to try to access the bus at the same time, if the bridge driver is properly implemented. However, now that firmware is loaded asynchronously, several other I2C drivers may be trying to use the bus at the same time. So, events like IR (and CI) polling, tuner get_status, etc can happen during a firmware transfer, causing the firmware to not load properly. A fix for that will require to lock the firmware load I2C traffic into a single transaction. How about deferring registration or probe of every bus-interface (usb, pci, firewire) drivers we have. If we defer interface driver using work or some other trick we don't need to touch any other chip-drivers that are chained behind interface driver. Demodulator, tuner, decoder, remote and all the other peripheral drivers can be left as those are currently because those are deferred by bus interface driver. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Jun 25 19:00:20 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS apps: ERRORS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] saa7164: Use i2c_rc properly to store i2c register status
Em 18-06-2012 16:23, Ezequiel Garcia escreveu: Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- drivers/media/video/saa7164/saa7164-i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/saa7164/saa7164-i2c.c b/drivers/media/video/saa7164/saa7164-i2c.c index 26148f7..536f7dc 100644 --- a/drivers/media/video/saa7164/saa7164-i2c.c +++ b/drivers/media/video/saa7164/saa7164-i2c.c @@ -123,7 +123,7 @@ int saa7164_i2c_register(struct saa7164_i2c *bus) bus-i2c_algo.data = bus; bus-i2c_adap.algo_data = bus; i2c_set_adapdata(bus-i2c_adap, bus); - i2c_add_adapter(bus-i2c_adap); + bus-i2c_rc = i2c_add_adapter(bus-i2c_adap); bus-i2c_client.adapter = bus-i2c_adap; -ENODESCRIPTION. What are you intending with this change? AFAICT, i2c_add_bus_adapter() returns 0 on success and a negative value otherwise. Why should it be stored at bus-i2c_rc? The same applies to the entire patch series. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] saa7164: Use i2c_rc properly to store i2c register status
Hi Mauro, On Mon, Jun 25, 2012 at 4:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: diff --git a/drivers/media/video/saa7164/saa7164-i2c.c b/drivers/media/video/saa7164/saa7164-i2c.c index 26148f7..536f7dc 100644 --- a/drivers/media/video/saa7164/saa7164-i2c.c +++ b/drivers/media/video/saa7164/saa7164-i2c.c @@ -123,7 +123,7 @@ int saa7164_i2c_register(struct saa7164_i2c *bus) bus-i2c_algo.data = bus; bus-i2c_adap.algo_data = bus; i2c_set_adapdata(bus-i2c_adap, bus); - i2c_add_adapter(bus-i2c_adap); + bus-i2c_rc = i2c_add_adapter(bus-i2c_adap); bus-i2c_client.adapter = bus-i2c_adap; -ENODESCRIPTION. Okey. Sorry for that. What are you intending with this change? AFAICT, i2c_add_bus_adapter() returns 0 on success and a negative value otherwise. Why should it be stored at bus-i2c_rc? My intention was to give i2c_rc its proper use. I looked at bttv-i2c.c and cx88-i2c.c and (perhaps wrongly) guessed the intended use to i2c_rc was to save i2c registration result. Without this patch, where is this bus-i2c_rc variable used? Unless I've missed something, to me there are two options: - use i2c_rc - remove it Again sorry for lack of description, I thought it was self-explaining patch. If you provide some feedback about proper solution, I can resend the patch series. Thanks, Ezequiel. -- 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 01/12] saa7164: Use i2c_rc properly to store i2c register status
Em 25-06-2012 16:42, Ezequiel Garcia escreveu: Hi Mauro, On Mon, Jun 25, 2012 at 4:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: diff --git a/drivers/media/video/saa7164/saa7164-i2c.c b/drivers/media/video/saa7164/saa7164-i2c.c index 26148f7..536f7dc 100644 --- a/drivers/media/video/saa7164/saa7164-i2c.c +++ b/drivers/media/video/saa7164/saa7164-i2c.c @@ -123,7 +123,7 @@ int saa7164_i2c_register(struct saa7164_i2c *bus) bus-i2c_algo.data = bus; bus-i2c_adap.algo_data = bus; i2c_set_adapdata(bus-i2c_adap, bus); - i2c_add_adapter(bus-i2c_adap); + bus-i2c_rc = i2c_add_adapter(bus-i2c_adap); bus-i2c_client.adapter = bus-i2c_adap; -ENODESCRIPTION. Okey. Sorry for that. What are you intending with this change? AFAICT, i2c_add_bus_adapter() returns 0 on success and a negative value otherwise. Why should it be stored at bus-i2c_rc? My intention was to give i2c_rc its proper use. I looked at bttv-i2c.c and cx88-i2c.c and (perhaps wrongly) guessed the intended use to i2c_rc was to save i2c registration result. Without this patch, where is this bus-i2c_rc variable used? Unless I've missed something, to me there are two options: - use i2c_rc - remove it If i2c_rc was never initialized, then just remove it. If it is required, then there's a bug somewhere out there on those drivers. IMHO, if the I2C bus doesn't register, any driver that requires I2C bus should return -ENODEV. It should be noticed that there are a few devices that don't need I2C bus to work: simple video grabber cards that don't have anything on their I2C. There are several of them at bttv, and a few at cx88 and saa7134. Maybe that's the reason why those drivers have a var to indicate if i2c got registered. Again sorry for lack of description, I thought it was self-explaining patch. If you provide some feedback about proper solution, I can resend the patch series. Thanks! Mauro Thanks, Ezequiel. -- 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 01/12] saa7164: Use i2c_rc properly to store i2c register status
On Mon, Jun 25, 2012 at 4:49 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: If i2c_rc was never initialized, then just remove it. If it is required, then there's a bug somewhere out there on those drivers. IMHO, if the I2C bus doesn't register, any driver that requires I2C bus should return -ENODEV. Agreed. It should be noticed that there are a few devices that don't need I2C bus to work: simple video grabber cards that don't have anything on their I2C. There are several of them at bttv, and a few at cx88 and saa7134. Maybe that's the reason why those drivers have a var to indicate if i2c got registered. Mmm, that would explain mysterious i2c_rc. Anyway, I'm still a *q-bit* unsure about which drivers require i2c to work and which don't. I'm gonna investigate this carefully and send a v2 (probably just to send a v3 later :) Thanks for reviewing, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Em 25-06-2012 16:15, Antti Palosaari escreveu: On 06/21/2012 10:10 PM, Mauro Carvalho Chehab wrote: Em 21-06-2012 10:36, Mauro Carvalho Chehab escreveu: The firmware blob may not be available when the driver probes. Instead of blocking the whole kernel use request_firmware_nowait() and continue without firmware. This shouldn't be that bad on drx-k devices, as they all seem to have an internal firmware. So, only the firmware update will take a little longer to happen. While thinking on converting another DVB frontend driver, I just realized that a patch like that won't work fine. As most of you know, there are _several_ I2C chips that don't tolerate any usage of the I2C bus while a firmware is being loaded (I dunno if this is the case of drx-k, but I won't doubt). The current approach makes the device probe() logic is serialized. So, there's no chance that two different I2C drivers to try to access the bus at the same time, if the bridge driver is properly implemented. However, now that firmware is loaded asynchronously, several other I2C drivers may be trying to use the bus at the same time. So, events like IR (and CI) polling, tuner get_status, etc can happen during a firmware transfer, causing the firmware to not load properly. A fix for that will require to lock the firmware load I2C traffic into a single transaction. How about deferring registration or probe of every bus-interface (usb, pci, firewire) drivers we have. If we defer interface driver using work or some other trick we don't need to touch any other chip-drivers that are chained behind interface driver. Demodulator, tuner, decoder, remote and all the other peripheral drivers can be left as those are currently because those are deferred by bus interface driver. There are some issues with regards to it: 1) Currently, driver core doesn't allow a deferred probe. Drivers might implement that, but they'll lie to the core that the driver were properly supported even when probe fails. So, driver's core need an .async_probe() method; 2) The firmware load issue will still happen at resume. So, a lock like that is still needed; 3) It can make some sense to async load the firmware for some drivers, especially when the device detection may not be dependent on a firmware load. I'm not fully convinced about (3), as the amount of changes are significant for not much gain. There's also another related issue: On devices where both bridge and sub-devices (like frontend) needs firmware to be loaded, the load order is important at resume(), as the bridge requires to get the firmware before the sub-devices. That's said, IMO, the best approach is to do: 1) add support for asynchronous probe at device core, for devices that requires firmware at probe(). The async_probe() will only be active if !usermodehelper_disabled. 2) export the I2C i2c_lock_adapter()/i2c_unlock_adapter() interface. We can postpone or get rid of changing the I2C drivers to use request_firmware_async(), if the request_firmware() core is not pedantic enough to complain and it is not gonna to be deprecated. Anyway, I'll open a thead c/c Greg KH (driver's core maintainer) with regards to the need of an async_probe() callback. Regards, Mauro regards Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Skystar HD2 / mantis status?
I tried xubuntu 12.04 with 3.2.0-26 kernel and no success to get it work properly. I have the 1ae4:0003 subsystem device. Pls help.-- 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
Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
Driver's documentation at Documentation/driver-model/driver.txt says that the
.probe() callback should bind the driver to a given device. That includes
verifying that the device is present, that it's a version the driver can
handle,
that driver data structures can be allocated and initialized, and that any
hardware can be initialized.
All media device drivers are complaint with that, returning 0 on success
(meaning that the device was successfully probed) or an error otherwise.
Almost all media devices are made by a SoC or a RISC CPU that works
as a DMA engine and exposes a set of registers to allow I2C access to the
device's internal and/or external I2C buses. Part of them have an internal
EEPROM/ROM that stores firmware internally at the board, but others require
a firmware to be loaded before being able to init/control the device and to
export the I2C bus interface.
The media handling function is then implemented via a series of I2C devices[1]:
- analog video decoders;
- TV tuners;
- radio tuners;
- I2C remote controller decoders;
- DVB frontends;
- mpeg decoders;
- mpeg encoders;
- video enhancement devices;
...
[1] several media chips have part of those function implemented internally,
but almost all require external I2C components to be probed.
In order to properly refer to each component, we call the main kernel module
that talks with the media device via USB/PCI bus is called bridge driver,
and the I2C components are called as sub-devices.
Different vendors use the same bridge driver to work with different sub-devices.
It is a .probe()'s task to detect what sub-devices are there inside the board.
There are several cases where the vendor switched the sub-devices without
changing the PCI ID/USB ID.
So, drivers do things like the code below, inside the .probe() callback:
static int check_if_dvb_frontend_is_supported_and_bind()
{
switch (device_model) {
case VENDOR_A_MODEL_1:
if (test_and_bind_frontend_1()) /* Doesn't require firmware */
return 0;
if (test_and_bind_frontend_2()) /* requires firmware foo */
return 0;
if (test_and_bind_frontend_3()) /* requires firmware bar */
return 0;
if (test_and_bind_frontend_4()) /* doesn't require firmware */
return 0;
break;
case VENDOR_A_MODEL_2:
/* Analog device - no DVB frontend on it */
return 0;
...
}
return -ENODEV;
}
On several devices, before being able to register the bus and do the actual
probe, the kernel needs to load a firmware.
Also, during the I2C device probing time, firmware may be required, in order
to properly expose the device's internal models and their capabilities.
For example, drx-k sub-device can have support for either DVB-C or DVB-T or
both,
depending on the device model. That affects the frontend properties exposed
to the user and might affect the bridge driver's initialization task.
In practice, a driver like em28xx have a few devices like HVR-930C that require
the drx-k sub-device. For those devices, a firmware is required; for other
devices, a firmware is not required.
What's happening is that newer versions of request_firmware and udev are being
more pedantic (for a reason) about not requesting firmwares during module_init
or PCI/USB register's probe callback.
Worse than that, the same device driver may require a firmware or not,
depending on
the I2C devices inside it. One such example is em28xx: for the great majority of
the supported devices, no firmware is needed, but devices like HVR-930C require
a firmware, because it uses a frontend that needs firmware.
After some discussions, it seems that the best model would be to add an
async_probe()
callback to be used by devices similar to media ones. The async_probe() should
be
not probed during the module_init; the probe() will be deferred to happen later,
when firmware's usermodehelper_disabled is false, allowing those drivers to
load their
firmwares if needed.
What do you think?
Regards,
Mauro
Em 25-06-2012 17:06, Mauro Carvalho Chehab escreveu:
Em 25-06-2012 16:15, Antti Palosaari escreveu:
On 06/21/2012 10:10 PM, Mauro Carvalho Chehab wrote:
Em 21-06-2012 10:36, Mauro Carvalho Chehab escreveu:
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
This shouldn't be that bad on drx-k devices, as they all seem to have an
internal firmware. So, only the firmware update will take a little longer
to happen.
While thinking on converting another DVB frontend driver, I just
Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
Driver's documentation at Documentation/driver-model/driver.txt says that the
.probe() callback should bind the driver to a given device. That includes
verifying that the device is present, that it's a version the driver can
handle,
that driver data structures can be allocated and initialized, and that any
hardware can be initialized.
All media device drivers are complaint with that, returning 0 on success
(meaning that the device was successfully probed) or an error otherwise.
Almost all media devices are made by a SoC or a RISC CPU that works
as a DMA engine and exposes a set of registers to allow I2C access to the
device's internal and/or external I2C buses. Part of them have an internal
EEPROM/ROM that stores firmware internally at the board, but others require
a firmware to be loaded before being able to init/control the device and to
export the I2C bus interface.
The media handling function is then implemented via a series of I2C devices[1]:
- analog video decoders;
- TV tuners;
- radio tuners;
- I2C remote controller decoders;
- DVB frontends;
- mpeg decoders;
- mpeg encoders;
- video enhancement devices;
...
[1] several media chips have part of those function implemented internally,
but almost all require external I2C components to be probed.
In order to properly refer to each component, we call the main kernel module
that talks with the media device via USB/PCI bus is called bridge driver,
and the I2C components are called as sub-devices.
Different vendors use the same bridge driver to work with different sub-devices.
It is a .probe()'s task to detect what sub-devices are there inside the board.
There are several cases where the vendor switched the sub-devices without
changing the PCI ID/USB ID.
So, drivers do things like the code below, inside the .probe() callback:
static int check_if_dvb_frontend_is_supported_and_bind()
{
switch (device_model) {
case VENDOR_A_MODEL_1:
if (test_and_bind_frontend_1()) /* Doesn't require firmware */
return 0;
if (test_and_bind_frontend_2()) /* requires firmware foo */
return 0;
if (test_and_bind_frontend_3()) /* requires firmware bar */
return 0;
if (test_and_bind_frontend_4()) /* doesn't require firmware */
return 0;
break;
case VENDOR_A_MODEL_2:
/* Analog device - no DVB frontend on it */
return 0;
...
}
return -ENODEV;
}
On several devices, before being able to register the bus and do the actual
probe, the kernel needs to load a firmware.
Also, during the I2C device probing time, firmware may be required, in order
to properly expose the device's internal models and their capabilities.
For example, drx-k sub-device can have support for either DVB-C or DVB-T or
both,
depending on the device model. That affects the frontend properties exposed
to the user and might affect the bridge driver's initialization task.
In practice, a driver like em28xx have a few devices like HVR-930C that require
the drx-k sub-device. For those devices, a firmware is required; for other
devices, a firmware is not required.
What's happening is that newer versions of request_firmware and udev are being
more pedantic (for a reason) about not requesting firmwares during module_init
or PCI/USB register's probe callback.
Worse than that, the same device driver may require a firmware or not,
depending on
the I2C devices inside it. One such example is em28xx: for the great majority of
the supported devices, no firmware is needed, but devices like HVR-930C require
a firmware, because it uses a frontend that needs firmware.
After some discussions, it seems that the best model would be to add an
async_probe()
callback to be used by devices similar to media ones. The async_probe() should
be
not probed during the module_init; the probe() will be deferred to happen later,
when firmware's usermodehelper_disabled is false, allowing those drivers to
load their
firmwares if needed.
What do you think?
Regards,
Mauro
Em 25-06-2012 17:06, Mauro Carvalho Chehab escreveu:
Em 25-06-2012 16:15, Antti Palosaari escreveu:
On 06/21/2012 10:10 PM, Mauro Carvalho Chehab wrote:
Em 21-06-2012 10:36, Mauro Carvalho Chehab escreveu:
The firmware blob may not be available when the driver probes.
Instead of blocking the whole kernel use request_firmware_nowait() and
continue without firmware.
This shouldn't be that bad on drx-k devices, as they all seem to have an
internal firmware. So, only the firmware update will take a little longer
to happen.
While thinking on converting another DVB frontend driver, I just
Re: [PATCH 01/12] saa7164: Use i2c_rc properly to store i2c register status
Em 25-06-2012 17:06, Ezequiel Garcia escreveu: On Mon, Jun 25, 2012 at 4:49 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: If i2c_rc was never initialized, then just remove it. If it is required, then there's a bug somewhere out there on those drivers. IMHO, if the I2C bus doesn't register, any driver that requires I2C bus should return -ENODEV. Agreed. It should be noticed that there are a few devices that don't need I2C bus to work: simple video grabber cards that don't have anything on their I2C. There are several of them at bttv, and a few at cx88 and saa7134. Maybe that's the reason why those drivers have a var to indicate if i2c got registered. Mmm, that would explain mysterious i2c_rc. Anyway, I'm still a *q-bit* unsure about which drivers require i2c to work and which don't. I'm gonna investigate this carefully and send a v2 (probably just to send a v3 later :) Yeah, research is needed ;) As bttv is the mother of the I2C code found at other PCI drivers, as it is one of the oldest implementations, I bet you'll find this field propagated without usage on some drivers (and probably other unused fields as well ;) ) Thanks for reviewing, Ezequiel. 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: Skystar HD2 / mantis status?
I'm using 3.2-4.slh.1-aptosid-amd64 It seems to me something isn't quite setup with the STB0899 properly. Tuning the same mux on a TT-3200 (which uses the same tuner and demod chip) on a windows box coming from the same signal source at the same time in TSReader, zero errors on the TT-3200, and pretty much continual continuity and TEI errors from the Skystar HD2. (I'm using DVBlast, so it prints out all the errors - makes it easy to see what's going on). The TEI errors lead me to suspect a setup problem with the STB0899, as it's actually marking the packets as uncorrectable after FEC processing. Also in the DVB wiki, it says the TT3200 doesn't work properly either in linux, and again, that would lead to a problem with the STB0899 code. I will try putting my TT3200 into the linux box and see if it does any better. I managed to find the Twinhan released source (after much searching, and setting up a windows VM to use driver guide's stupid download program - didn't trust it enough to just run it on my windows box), which seems like it's the reference code from ST for the STB0899 (been discussed before on the mailing list, in 2009 I think), but it's not exactly a 1:1 comparison between that code, and the current driver. I do notice fewer registers being set on init in the current STB0899 code than the 'reference' code, but I'm not at a point where I'm ready to actually make any official statements on that. I seem to recall the STB0899 driver is kindof a touchy subject around these parts... The other thing that would be interesting would be to scope the I2C lines on the STB0899, and tune the same things in windows and linux, and see if the STB0899 is being setup the same way. Only trouble is I don't know which pins are SCL and SDA on the STB0899, and of course the actual data sheet is NDA only. Looks like all the digital-ish looking pins have convenient series resistors which make for great soldering locations! On Mon, Jun 25, 2012 at 2:34 PM, walou walou.me...@gmail.com wrote: I tried xubuntu 12.04 with 3.2.0-26 kernel and no success to get it work properly. I have the 1ae4:0003 subsystem device. Pls help.-- 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: DiB0700 rc submit urb failed after reboot, ok after replug
On 06/23/2012 10:43 AM, cedric.dew...@telfort.nl wrote: [6.517631] rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc0 [6.517821] dvb-usb: schedule remote query interval to 50 msecs. [6.517825] dvb-usb: Pinnacle PCTV 73e SE successfully initialized and connected. [6.517951] dib0700: rc submit urb failed I am almost sure it is that issue I fixed: http://git.linuxtv.org/anttip/media_tree.git/commit/36bd9e4ba1de78bfb9f3bcf8b07c63a157da6499 Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v3] media: Add stk1160 new driver
Hi Ezequiel,
a few minor comments below...
On 06/23/2012 08:36 PM, Ezequiel Garcia wrote:
This driver adds support for stk1160 usb bridge as used in some
video/audio usb capture devices.
It is a complete rewrite of staging/media/easycap driver and
it's expected as a future replacement.
Signed-off-by: Ezequiel Garciaelezegar...@gmail.com
---
[...]
+/*
+ * Read/Write stk registers
+ */
+int stk1160_read_reg(struct stk1160 *dev, u16 reg, u8 *value)
+{
+ int ret;
+
+ *value = 0;
+ ret = usb_control_msg(dev-udev, usb_rcvctrlpipe(dev-udev, 0),
+ 0x00,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ 0x00,
+ reg,
+ value,
+ sizeof(u8),
+ HZ);
A bit strange indentation, but it's up to you to keep it or not.
+ if (ret 0) {
+ stk1160_err(read failed on reg 0x%x (%d)\n,
+ reg, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+int stk1160_write_reg(struct stk1160 *dev, u16 reg, u16 value)
+{
+ int ret;
+
+ ret = usb_control_msg(dev-udev, usb_sndctrlpipe(dev-udev, 0),
+ 0x01,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ value,
+ reg,
+ NULL,
+ 0,
+ HZ);
+ if (ret 0) {
+ stk1160_err(write failed on reg 0x%x (%d)\n,
+ reg, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+/* TODO: We should break this into pieces */
+static void stk1160_reg_reset(struct stk1160 *dev)
+{
+ int i;
+
+ static struct regval ctl[] = {
static const struct regval... ?
+ {STK1160_GCTRL+2, 0x0078},
+
+ {STK1160_RMCTL+1, 0x},
+ {STK1160_RMCTL+3, 0x0002},
+
+ {STK1160_PLLSO, 0x0010},
+ {STK1160_PLLSO+1, 0x},
+ {STK1160_PLLSO+2, 0x0014},
+ {STK1160_PLLSO+3, 0x000E},
+
+ {STK1160_PLLFD, 0x0046},
+
+ /* Timing generator setup */
+ {STK1160_TIGEN, 0x0012},
+ {STK1160_TICTL, 0x002D},
+ {STK1160_TICTL+1, 0x0001},
+ {STK1160_TICTL+2, 0x},
+ {STK1160_TICTL+3, 0x},
+ {STK1160_TIGEN, 0x0080},
+
+ {0x, 0x}
+ };
+
+ for (i = 0; ctl[i].reg != 0x; i++)
+ stk1160_write_reg(dev, ctl[i].reg, ctl[i].val);
+
+ /* Set selected input from module parameter */
+ switch (dev-ctl_input) {
+ case 0:
+ stk1160_write_reg(dev, STK1160_GCTRL, 0x98);
+ break;
+ case 1:
+ stk1160_write_reg(dev, STK1160_GCTRL, 0x90);
+ break;
+ case 2:
+ stk1160_write_reg(dev, STK1160_GCTRL, 0x88);
+ break;
+ case 3:
+ stk1160_write_reg(dev, STK1160_GCTRL, 0x80);
+ break;
How about doing something like:
static const u8 gctrl[] = {
0x98, 0x90, 0x88, 0x80
};
if (dev-ctl_input ARRAY_SIZE(gctrl))
stk1160_write_reg(dev, STK1160_GCTRL, gctrl[dev-ctl_input]);
?
+ }
+}
+
...
+static int stk1160_i2c_write_reg(struct stk1160 *dev, u8 addr,
+ u8 reg, u8 value)
+{
+ int rc, timeout;
+ u8 flag;
+
+ /* Set serial device address */
+ rc = stk1160_write_reg(dev, STK1160_SICTL_SDA, addr);
+ if (rc 0)
+ return rc;
+
+ /* Set i2c device register sub-address */
+ rc = stk1160_write_reg(dev, STK1160_SBUSW_WA, reg);
+ if (rc 0)
+ return rc;
+
+ /* Set i2c device register value */
+ rc = stk1160_write_reg(dev, STK1160_SBUSW_WD, value);
+ if (rc 0)
+ return rc;
+
+ /* Start write now */
+ rc = stk1160_write_reg(dev, STK1160_SICTL, 0x01);
+ if (rc 0)
+ return rc;
+
+ /* Wait until Write Finish bit is set */
+ for (timeout = 100; timeout 0;
+ timeout -= 20) {
+ stk1160_read_reg(dev, STK1160_SICTL+1,flag);
+ /* write done? */
+ if (flag 0x04)
+ break;
+
+ msleep(20);
+ }
A bit strange loop, perhaps it's worth to rework it as following:
unsigned long end = jiffies + msecs_to_jiffies(timeout);
while (time_is_after_jiffies(end)) {
...
usleep_range(...);
}
to better control the actual time spent on busy waiting.
You may also want to create a separate function i.e.
stk1160_i2c_busy_wait(struct stk1160 *dev, u8 wait_bit_mask, unsigned int
timeout)
and use to avoid repeating similar pattern.
+
+ if (timeout == 0)
+ /* return EBUSY, or EFAULT, or what ? */
Re: [PATCH 0/3] em28xx: Improve compatiblity with the Terratec Cinergy HTC Stick HD
Hi Soren, I just tested DVB-C (we got some local provider here). Correct. My Cinergy HTC Stick is not working for DVB-C with older drivers, too. (I didn't test DVB-T, since there are cheaper sticks for that and vdr opens the HTC stick for dvb-c) Here's the first difference: it worked with a stock 3.4.4 kernel here. The picture was completely broken for the first 10 seconds - after that everything was fine. This happened after each channel change with the vanilla kernel. Afterwards I applied the drxk driver patch (see [0]) and my main patch (see [1]) to the 3.4.4 kernel patched by Arch Linux (they don't have and media/dvb related changes in there though). With my patch everything was working fine, no broken picture after channel switching, etc. :) Only the presumably intentional error: That's also what I see. Let's start somewhere else: How are you scanning for channels? I used: w_scan -fc -c DE -X channels.conf Afterwards I opened channels.conf in VLC. Which tool do you use for viewing the DVB-C stream? PS: My patches will probably be included in linux 3.6. Regards, Martin [0] http://git.linuxtv.org/media_tree.git/commitdiff/140534432e8a7edee5814d139dd59c20607479e3?hp=b144c98ca0962ee3cbdbbeafe77a1b300be0cb4f [1] http://git.linuxtv.org/media_tree.git/commitdiff/c8dce0088a645c21cfb7e554390a4603e0e2139f?hp=729841ed0f41cfae494ad5c50df86af427078442 -- 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.5-rc5] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus For a set of fixup patches, several of them are due to regressions. Regards, Mauro Latest commit at the branch: 099987f0aaf28771261b91a41240b9228f2e32b2 [media] smia: Fix compile failures The following changes since commit 71006fb22b0f5a2045605b3887ee99a0e9adafe4: [media] saa7134-cards: Remove a PCI entry added by mistake (2012-05-21 12:48:44 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to 099987f0aaf28771261b91a41240b9228f2e32b2: [media] smia: Fix compile failures (2012-06-18 19:52:05 -0300) Alan Cox (1): [media] smia: Fix compile failures Andrzej Hajda (2): [media] v4l/s5p-mfc: corrected encoder v4l control definitions [media] v4l/s5p-mfc: added image size align in VIDIOC_TRY_FMT Antonio Ospite (1): [media] gspca_ov534: make AGC and AWB controls independent Guennadi Liakhovetski (1): [media] Revert [media] media: mx2_camera: Fix mbus format handling Hans Verkuil (15): [media] Fix vivi regression [media] Fix regression in ioctl numbering [media] Fix query/enum_dv_timings regression [media] V4L2 spec fix [media] saa7146_fops: remove unused variable [media] cx24110: fix compiler warning [media] vino: fix compiler warnings [media] v4l2-ioctl: set readbuffers to 2 in g_parm [media] v4l2-dev.c: fix g_parm regression in determine_valid_ioctls() [media] tuner-core: return the frequency range of the correct tuner [media] ivtv: fix support for big-endian systems [media] cx18: support big-endian systems [media] cx88: fix firmware load on big-endian systems [media] bw-qcam: driver and pixfmt documentation fixes [media] Fix VIDIOC_DQEVENT docbook entry Hans de Goede (10): [media] radio/si470x: Add support for the Axentia ALERT FM USB Receiver [media] snd_tea575x: Report correct frequency range for EU/US versus JA models [media] snd_tea575x: Make the module using snd_tea575x the fops owner [media] snd_tea575x: set_freq: update cached freq to the actual achieved frequency [media] bttv: Use btv-has_radio rather then the card info when registering the tuner [media] bttv: Remove unused needs_tvaudio card variable [media] bttv: The Hauppauge 61334 needs the msp3410 to do radio demodulation [media] gspca_pac7311: Correct number of controls [media] gscpa_sn9c20x: Move clustering of controls to after error checking [media] gspca-core: Fix buffers staying in queued state after a stream_off Janne Huttunen (1): [media] cxd2820r: Fix an incorrect modulation type bitmask Jean-Francois Moine (2): [media] gspca - ov534/ov534_9: Fix sccd_read/write errors [media] gspca - sonixj: Fix bad values of webcam 0458:7025 Kamil Debski (3): [media] s5p-mfc: Bug fix of timestamp/timecode copy mechanism [media] s5p-mfc: Fix setting controls [media] s5p-fimc: Fix control creation function Martin Blumenstingl (2): [media] em28xx: Add remote control support for Terratec's Cinergy HTC Stick HD [media] em28xx: Show a warning if the board does not support remote controls Michael Krufky (2): [media] lg2160: fix off-by-one error in lg216x_write_regs [media] smsusb: add autodetection support for USB ID 2040:f5a0 Sachin Kamat (1): [media] s5p-mfc: Fix checkpatch error in s5p_mfc_shm.h file Sakari Ailus (1): [media] v4l: Correct create_bufs documentation Sasha Levin (1): [media] USB: Staging: media: lirc: initialize spinlocks before usage Tomasz Moń (1): [media] v4l: mem2mem_testdev: Fix race conditions in driver Documentation/DocBook/media/v4l/pixfmt.xml |4 +- Documentation/DocBook/media/v4l/v4l2.xml |2 +- .../DocBook/media/v4l/vidioc-create-bufs.xml |5 +- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |2 +- arch/arm/plat-mxc/include/mach/mx2_cam.h |2 + drivers/hid/hid-core.c |1 + drivers/hid/hid-ids.h |3 + drivers/media/common/saa7146_fops.c|5 -- drivers/media/dvb/frontends/cx24110.c |4 +- drivers/media/dvb/frontends/cxd2820r_c.c |2 +- drivers/media/dvb/frontends/lg2160.c |2 +- drivers/media/dvb/siano/smsusb.c |2 + drivers/media/radio/radio-maxiradio.c |2 +- drivers/media/radio/radio-sf16fmr2.c |2 +- drivers/media/radio/si470x/radio-si470x-usb.c |2 + drivers/media/video/bt8xx/bttv-cards.c | 84 ++-- drivers/media/video/bt8xx/bttv-driver.c|5 ++
Re: Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Mon, Jun 25, 2012 at 05:49:25PM -0300, Mauro Carvalho Chehab wrote:
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
What change was that? How did it break anything?
Driver's documentation at Documentation/driver-model/driver.txt says that the
.probe() callback should bind the driver to a given device. That includes
verifying that the device is present, that it's a version the driver can
handle,
that driver data structures can be allocated and initialized, and that any
hardware can be initialized.
Yes.
All media device drivers are complaint with that, returning 0 on success
(meaning that the device was successfully probed) or an error otherwise.
Great, no probems then :)
Almost all media devices are made by a SoC or a RISC CPU that works
as a DMA engine and exposes a set of registers to allow I2C access to the
device's internal and/or external I2C buses. Part of them have an internal
EEPROM/ROM that stores firmware internally at the board, but others require
a firmware to be loaded before being able to init/control the device and to
export the I2C bus interface.
The media handling function is then implemented via a series of I2C
devices[1]:
- analog video decoders;
- TV tuners;
- radio tuners;
- I2C remote controller decoders;
- DVB frontends;
- mpeg decoders;
- mpeg encoders;
- video enhancement devices;
...
[1] several media chips have part of those function implemented internally,
but almost all require external I2C components to be probed.
In order to properly refer to each component, we call the main kernel module
that talks with the media device via USB/PCI bus is called bridge driver,
and the I2C components are called as sub-devices.
Different vendors use the same bridge driver to work with different
sub-devices.
It is a .probe()'s task to detect what sub-devices are there inside the board.
There are several cases where the vendor switched the sub-devices without
changing the PCI ID/USB ID.
Hardware vendors suck, we all know that :(
So, drivers do things like the code below, inside the .probe() callback:
static int check_if_dvb_frontend_is_supported_and_bind()
{
switch (device_model) {
case VENDOR_A_MODEL_1:
if (test_and_bind_frontend_1()) /* Doesn't require firmware */
return 0;
if (test_and_bind_frontend_2()) /* requires firmware foo */
return 0;
if (test_and_bind_frontend_3()) /* requires firmware bar */
return 0;
Wait, why would these, if they require firmware, not load the firmware
at this point in time? Why are they saying all is fine here?
if (test_and_bind_frontend_4()) /* doesn't require firmware */
return 0;
break;
case VENDOR_A_MODEL_2:
/* Analog device - no DVB frontend on it */
return 0;
...
}
return -ENODEV;
}
On several devices, before being able to register the bus and do the actual
probe, the kernel needs to load a firmware.
That's common.
Also, during the I2C device probing time, firmware may be required, in order
to properly expose the device's internal models and their capabilities.
For example, drx-k sub-device can have support for either DVB-C or DVB-T or
both,
depending on the device model. That affects the frontend properties exposed
to the user and might affect the bridge driver's initialization task.
In practice, a driver like em28xx have a few devices like HVR-930C that
require
the drx-k sub-device. For those devices, a firmware is required; for other
devices, a firmware is not required.
What's happening is that newer versions of request_firmware and udev are being
more pedantic (for a reason) about not requesting firmwares during module_init
or PCI/USB register's probe callback.
It is? What changed to require this? What commit id?
Worse than that, the same device driver may require a firmware or not,
depending on
the I2C devices inside it. One such example is em28xx: for the great majority
of
the supported devices, no firmware is needed, but devices like HVR-930C
require
a firmware, because it uses a frontend that needs firmware.
After some discussions, it seems that the best model would be to add an
async_probe()
callback to be used by devices similar to media ones. The async_probe()
should be
not probed during the module_init; the probe() will be deferred to happen
later,
when firmware's usermodehelper_disabled is false, allowing those drivers to
load their
firmwares if needed.
What do you think?
We already have deferred probe() calls, you just need to return a
different value (can't remember it at the moment), and your probe
function will be called again
Re: [PATCH] omap3isp: preview: Add support for non-GRBG Bayer patterns
Hi Sakari,
On Saturday 23 June 2012 11:22:37 Sakari Ailus wrote:
On Mon, Jun 18, 2012 at 04:30:53PM +0200, Laurent Pinchart wrote:
Rearrange the CFA interpolation coefficients table based on the Bayer
pattern. Modifying the table during streaming isn't supported anymore,
but didn't make sense in the first place anyway.
Why not? I could imagine someone might want to change the table while
streaming to change the white balance, for example. Gamma tables or the SRGB
matrix can be used to do mostly the same but we should leave the decision
which one to use to the user space.
Because making the CFA table runtime-configurable brings an additional
complexity without a use case I'm aware of. The preview engine has separate
gamma tables, white balance matrices, and RGB-to-RGB and RGB-to-YUV matrices
that can be modified during streaming. If a user really needs to modify the
CFA tables during streaming I'll be happy to implement that (and even happier
to receive a patch :-)), but I'm a bit reluctant to add complexity to an
already complex code without a real use case.
Support for non-Bayer CFA patterns is dropped as they were not correctly
supported, and have never been tested.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isppreview.c | 118 ++--
1 files changed, 67 insertions(+), 51 deletions(-)
Jean-Philippe,
Could you please test this patch on your hardware ?
diff --git a/drivers/media/video/omap3isp/isppreview.c
b/drivers/media/video/omap3isp/isppreview.c index 8a4935e..bfa3107 100644
--- a/drivers/media/video/omap3isp/isppreview.c
+++ b/drivers/media/video/omap3isp/isppreview.c
@@ -309,36 +309,6 @@ preview_config_dcor(struct isp_prev_device *prev,
const void *prev_dcor)
}
/*
- * preview_config_cfa - Configures the CFA Interpolation parameters.
- * @prev_cfa: Structure containing the CFA interpolation table, CFA
format
- *in the image, vertical and horizontal gradient threshold.
- */
-static void
-preview_config_cfa(struct isp_prev_device *prev, const void *prev_cfa)
-{
- struct isp_device *isp = to_isp_device(prev);
- const struct omap3isp_prev_cfa *cfa = prev_cfa;
- unsigned int i;
-
- isp_reg_clr_set(isp, OMAP3_ISP_IOMEM_PREV, ISPPRV_PCR,
- ISPPRV_PCR_CFAFMT_MASK,
- cfa-format ISPPRV_PCR_CFAFMT_SHIFT);
-
- isp_reg_writel(isp,
- (cfa-gradthrs_vert ISPPRV_CFA_GRADTH_VER_SHIFT) |
- (cfa-gradthrs_horz ISPPRV_CFA_GRADTH_HOR_SHIFT),
- OMAP3_ISP_IOMEM_PREV, ISPPRV_CFA);
-
- isp_reg_writel(isp, ISPPRV_CFA_TABLE_ADDR,
- OMAP3_ISP_IOMEM_PREV, ISPPRV_SET_TBL_ADDR);
-
- for (i = 0; i OMAP3ISP_PREV_CFA_TBL_SIZE; i++) {
- isp_reg_writel(isp, cfa-table[i],
- OMAP3_ISP_IOMEM_PREV, ISPPRV_SET_TBL_DATA);
- }
-}
-
-/*
* preview_config_gammacorrn - Configures the Gamma Correction table
values
* @gtable: Structure containing the table for red, blue, green gamma
table.
*/
@@ -813,7 +783,7 @@ static const struct preview_update update_attrs[] = {
FIELD_SIZEOF(struct prev_params, hmed),
offsetof(struct omap3isp_prev_update_config, hmed),
}, /* OMAP3ISP_PREV_CFA */ {
- preview_config_cfa,
+ NULL,
NULL,
offsetof(struct prev_params, cfa),
FIELD_SIZEOF(struct prev_params, cfa),
@@ -1043,42 +1013,88 @@ preview_config_ycpos(struct isp_prev_device *prev,
static void preview_config_averager(struct isp_prev_device *prev, u8
average) {
struct isp_device *isp = to_isp_device(prev);
- struct prev_params *params;
- int reg = 0;
- params = (prev-params.active OMAP3ISP_PREV_CFA)
- ? prev-params.params[0] : prev-params.params[1];
-
- if (params-cfa.format == OMAP3ISP_CFAFMT_BAYER)
- reg = ISPPRV_AVE_EVENDIST_2 ISPPRV_AVE_EVENDIST_SHIFT |
- ISPPRV_AVE_ODDDIST_2 ISPPRV_AVE_ODDDIST_SHIFT |
- average;
- else if (params-cfa.format == OMAP3ISP_CFAFMT_RGBFOVEON)
- reg = ISPPRV_AVE_EVENDIST_3 ISPPRV_AVE_EVENDIST_SHIFT |
- ISPPRV_AVE_ODDDIST_3 ISPPRV_AVE_ODDDIST_SHIFT |
- average;
- isp_reg_writel(isp, reg, OMAP3_ISP_IOMEM_PREV, ISPPRV_AVE);
+ isp_reg_writel(isp, ISPPRV_AVE_EVENDIST_2
ISPPRV_AVE_EVENDIST_SHIFT |
+ ISPPRV_AVE_ODDDIST_2 ISPPRV_AVE_ODDDIST_SHIFT |
+ average, OMAP3_ISP_IOMEM_PREV, ISPPRV_AVE);
}
+
+#define OMAP3ISP_PREV_CFA_BLK_SIZE (OMAP3ISP_PREV_CFA_TBL_SIZE / 4)
+
/*
* preview_config_input_format - Configure the input format
* @prev: The preview engine
* @format: Format on the preview engine
[PATCH 0/2] Miscellaneous OMAP3 ISP fixes
Hi everybody, Not much to be said here. The first patch is needed by the second, which is described in its commit message. I'd like to get this into v3.6. Laurent Pinchart (2): omap3isp: Don't access ISP_CTRL directly in the statistics modules omap3isp: Configure HS/VS interrupt source before enabling interrupts drivers/media/video/omap3isp/isp.c | 47 +-- drivers/media/video/omap3isp/isp.h |9 +++-- drivers/media/video/omap3isp/isph3a_aewb.c | 10 +- drivers/media/video/omap3isp/isph3a_af.c | 10 +- drivers/media/video/omap3isp/isphist.c |6 +-- 5 files changed, 40 insertions(+), 42 deletions(-) -- 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 2/2] omap3isp: Configure HS/VS interrupt source before enabling interrupts
This needs to be performed before enabling interrupts as the sensor
might be free-running and the ISP default setting (HS edge) would put an
unnecessary burden on the CPU.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isp.c | 43 +--
1 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 2e1f322..36805ca 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -252,13 +252,18 @@ static u32 isp_set_xclk(struct isp_device *isp, u32 xclk,
u8 xclksel)
}
/*
- * isp_power_settings - Sysconfig settings, for Power Management.
+ * isp_core_init - ISP core settings
* @isp: OMAP3 ISP device
* @idle: Consider idle state.
*
- * Sets the power settings for the ISP, and SBL bus.
+ * Set the power settings for the ISP and SBL bus and cConfigure the HS/VS
+ * interrupt source.
+ *
+ * We need to configure the HS/VS interrupt source before interrupts get
+ * enabled, as the sensor might be free-running and the ISP default setting
+ * (HS edge) would put an unnecessary burden on the CPU.
*/
-static void isp_power_settings(struct isp_device *isp, int idle)
+static void isp_core_init(struct isp_device *isp, int idle)
{
isp_reg_writel(isp,
((idle ? ISP_SYSCONFIG_MIDLEMODE_SMARTSTANDBY :
@@ -268,9 +273,10 @@ static void isp_power_settings(struct isp_device *isp, int
idle)
ISP_SYSCONFIG_AUTOIDLE : 0),
OMAP3_ISP_IOMEM_MAIN, ISP_SYSCONFIG);
- if (isp-autoidle)
- isp_reg_writel(isp, ISPCTRL_SBL_AUTOIDLE, OMAP3_ISP_IOMEM_MAIN,
- ISP_CTRL);
+ isp_reg_writel(isp,
+ (isp-autoidle ? ISPCTRL_SBL_AUTOIDLE : 0) |
+ ISPCTRL_SYNC_DETECT_VSRISE,
+ OMAP3_ISP_IOMEM_MAIN, ISP_CTRL);
}
/*
@@ -323,9 +329,6 @@ void omap3isp_configure_bridge(struct isp_device *isp,
ispctrl_val |= ((shift/2) ISPCTRL_SHIFT_SHIFT) ISPCTRL_SHIFT_MASK;
- ispctrl_val = ~ISPCTRL_SYNC_DETECT_MASK;
- ispctrl_val |= ISPCTRL_SYNC_DETECT_VSRISE;
-
isp_reg_writel(isp, ispctrl_val, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL);
}
@@ -1443,7 +1446,7 @@ static int isp_get_clocks(struct isp_device *isp)
*
* Return a pointer to the ISP device structure, or NULL if an error occurred.
*/
-struct isp_device *omap3isp_get(struct isp_device *isp)
+static struct isp_device *__omap3isp_get(struct isp_device *isp, bool irq)
{
struct isp_device *__isp = isp;
@@ -1462,10 +1465,9 @@ struct isp_device *omap3isp_get(struct isp_device *isp)
/* We don't want to restore context before saving it! */
if (isp-has_context)
isp_restore_ctx(isp);
- else
- isp-has_context = 1;
- isp_enable_interrupts(isp);
+ if (irq)
+ isp_enable_interrupts(isp);
out:
if (__isp != NULL)
@@ -1475,6 +1477,11 @@ out:
return __isp;
}
+struct isp_device *omap3isp_get(struct isp_device *isp)
+{
+ return __omap3isp_get(isp, true);
+}
+
/*
* omap3isp_put - Release the ISP
*
@@ -1490,8 +1497,10 @@ void omap3isp_put(struct isp_device *isp)
BUG_ON(isp-ref_count == 0);
if (--isp-ref_count == 0) {
isp_disable_interrupts(isp);
- if (isp-domain)
+ if (isp-domain) {
isp_save_ctx(isp);
+ isp-has_context = 1;
+ }
/* Reset the ISP if an entity has failed to stop. This is the
* only way to recover from such conditions.
*/
@@ -1975,7 +1984,7 @@ static int __devexit isp_remove(struct platform_device
*pdev)
isp_unregister_entities(isp);
isp_cleanup_modules(isp);
- omap3isp_get(isp);
+ __omap3isp_get(isp, false);
iommu_detach_device(isp-domain, pdev-dev);
iommu_domain_free(isp-domain);
isp-domain = NULL;
@@ -2093,7 +2102,7 @@ static int __devinit isp_probe(struct platform_device
*pdev)
if (ret 0)
goto error;
- if (omap3isp_get(isp) == NULL)
+ if (__omap3isp_get(isp, false) == NULL)
goto error;
ret = isp_reset(isp);
@@ -2160,7 +2169,7 @@ static int __devinit isp_probe(struct platform_device
*pdev)
if (ret 0)
goto error_modules;
- isp_power_settings(isp, 1);
+ isp_core_init(isp, 1);
omap3isp_put(isp);
return 0;
--
1.7.3.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
[PATCH 1/2] omap3isp: Don't access ISP_CTRL directly in the statistics modules
Use the existing omap3isp_subclk_enable() and omap3isp_subclk_disable()
functions instead.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/isp.c |4 +++-
drivers/media/video/omap3isp/isp.h |9 +
drivers/media/video/omap3isp/isph3a_aewb.c | 10 ++
drivers/media/video/omap3isp/isph3a_af.c | 10 ++
drivers/media/video/omap3isp/isphist.c |6 ++
5 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 1c34763..2e1f322 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1281,7 +1281,9 @@ static void __isp_subclk_update(struct isp_device *isp)
{
u32 clk = 0;
- if (isp-subclk_resources OMAP3_ISP_SUBCLK_H3A)
+ /* AEWB and AF share the same clock. */
+ if (isp-subclk_resources
+ (OMAP3_ISP_SUBCLK_AEWB | OMAP3_ISP_SUBCLK_AF))
clk |= ISPCTRL_H3A_CLK_EN;
if (isp-subclk_resources OMAP3_ISP_SUBCLK_HIST)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index fc7af3e..ba2159b 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -90,10 +90,11 @@ enum isp_sbl_resource {
enum isp_subclk_resource {
OMAP3_ISP_SUBCLK_CCDC = (1 0),
- OMAP3_ISP_SUBCLK_H3A= (1 1),
- OMAP3_ISP_SUBCLK_HIST = (1 2),
- OMAP3_ISP_SUBCLK_PREVIEW= (1 3),
- OMAP3_ISP_SUBCLK_RESIZER= (1 4),
+ OMAP3_ISP_SUBCLK_AEWB = (1 1),
+ OMAP3_ISP_SUBCLK_AF = (1 2),
+ OMAP3_ISP_SUBCLK_HIST = (1 3),
+ OMAP3_ISP_SUBCLK_PREVIEW= (1 4),
+ OMAP3_ISP_SUBCLK_RESIZER= (1 5),
};
/* ISP: OMAP 34xx ES 1.0 */
diff --git a/drivers/media/video/omap3isp/isph3a_aewb.c
b/drivers/media/video/omap3isp/isph3a_aewb.c
index a3c76bf..036e996 100644
--- a/drivers/media/video/omap3isp/isph3a_aewb.c
+++ b/drivers/media/video/omap3isp/isph3a_aewb.c
@@ -93,17 +93,11 @@ static void h3a_aewb_enable(struct ispstat *aewb, int
enable)
if (enable) {
isp_reg_set(aewb-isp, OMAP3_ISP_IOMEM_H3A, ISPH3A_PCR,
ISPH3A_PCR_AEW_EN);
- /* This bit is already set if AF is enabled */
- if (aewb-isp-isp_af.state != ISPSTAT_ENABLED)
- isp_reg_set(aewb-isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL,
- ISPCTRL_H3A_CLK_EN);
+ omap3isp_subclk_enable(aewb-isp, OMAP3_ISP_SUBCLK_AEWB);
} else {
isp_reg_clr(aewb-isp, OMAP3_ISP_IOMEM_H3A, ISPH3A_PCR,
ISPH3A_PCR_AEW_EN);
- /* This bit can't be cleared if AF is enabled */
- if (aewb-isp-isp_af.state != ISPSTAT_ENABLED)
- isp_reg_clr(aewb-isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL,
- ISPCTRL_H3A_CLK_EN);
+ omap3isp_subclk_disable(aewb-isp, OMAP3_ISP_SUBCLK_AEWB);
}
}
diff --git a/drivers/media/video/omap3isp/isph3a_af.c
b/drivers/media/video/omap3isp/isph3a_af.c
index 58e0bc4..42ccce3 100644
--- a/drivers/media/video/omap3isp/isph3a_af.c
+++ b/drivers/media/video/omap3isp/isph3a_af.c
@@ -143,17 +143,11 @@ static void h3a_af_enable(struct ispstat *af, int enable)
if (enable) {
isp_reg_set(af-isp, OMAP3_ISP_IOMEM_H3A, ISPH3A_PCR,
ISPH3A_PCR_AF_EN);
- /* This bit is already set if AEWB is enabled */
- if (af-isp-isp_aewb.state != ISPSTAT_ENABLED)
- isp_reg_set(af-isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL,
- ISPCTRL_H3A_CLK_EN);
+ omap3isp_subclk_enable(af-isp, OMAP3_ISP_SUBCLK_AF);
} else {
isp_reg_clr(af-isp, OMAP3_ISP_IOMEM_H3A, ISPH3A_PCR,
ISPH3A_PCR_AF_EN);
- /* This bit can't be cleared if AEWB is enabled */
- if (af-isp-isp_aewb.state != ISPSTAT_ENABLED)
- isp_reg_clr(af-isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL,
- ISPCTRL_H3A_CLK_EN);
+ omap3isp_subclk_disable(af-isp, OMAP3_ISP_SUBCLK_AF);
}
}
diff --git a/drivers/media/video/omap3isp/isphist.c
b/drivers/media/video/omap3isp/isphist.c
index 1163907..d1a8dee 100644
--- a/drivers/media/video/omap3isp/isphist.c
+++ b/drivers/media/video/omap3isp/isphist.c
@@ -167,13 +167,11 @@ static void hist_enable(struct ispstat *hist, int enable)
if (enable) {
isp_reg_set(hist-isp, OMAP3_ISP_IOMEM_HIST, ISPHIST_PCR,
ISPHIST_PCR_ENABLE);
- isp_reg_set(hist-isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL,
-
Re: Need of an .async_probe() type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
Em 25-06-2012 19:33, Greg KH escreveu:
On Mon, Jun 25, 2012 at 05:49:25PM -0300, Mauro Carvalho Chehab wrote:
Greg,
Basically, the recent changes at request_firmware() exposed an issue that
affects all media drivers that use firmware (64 drivers).
What change was that? How did it break anything?
https://bugzilla.redhat.com/show_bug.cgi?id=827538
Basically, userspace changes and some pm-related patches, mainly this one [1]:
@@ -613,7 +606,14 @@ request_firmware(const struct firmware **firmware_p, const
char *name,
if (ret = 0)
return ret;
- ret = _request_firmware(*firmware_p, name, device, true, false);
+ ret = usermodehelper_read_trylock();
+ if (WARN_ON(ret)) {
+ dev_err(device, firmware: %s will not be loaded\n, name);
+ } else {
+ ret = _request_firmware(*firmware_p, name, device, true, false,
+ firmware_loading_timeout());
+ usermodehelper_read_unlock();
+ }
if (ret)
_request_firmware_cleanup(firmware_p);
[1] at git commit 9b78c1da60b3c62ccdd1509f0902ad19ceaf776b
Driver's documentation at Documentation/driver-model/driver.txt says that the
.probe() callback should bind the driver to a given device. That includes
verifying that the device is present, that it's a version the driver can
handle,
that driver data structures can be allocated and initialized, and that any
hardware can be initialized.
Yes.
All media device drivers are complaint with that, returning 0 on success
(meaning that the device was successfully probed) or an error otherwise.
Great, no probems then :)
Almost all media devices are made by a SoC or a RISC CPU that works
as a DMA engine and exposes a set of registers to allow I2C access to the
device's internal and/or external I2C buses. Part of them have an internal
EEPROM/ROM that stores firmware internally at the board, but others require
a firmware to be loaded before being able to init/control the device and to
export the I2C bus interface.
The media handling function is then implemented via a series of I2C
devices[1]:
- analog video decoders;
- TV tuners;
- radio tuners;
- I2C remote controller decoders;
- DVB frontends;
- mpeg decoders;
- mpeg encoders;
- video enhancement devices;
...
[1] several media chips have part of those function implemented internally,
but almost all require external I2C components to be probed.
In order to properly refer to each component, we call the main kernel
module
that talks with the media device via USB/PCI bus is called bridge driver,
and the I2C components are called as sub-devices.
Different vendors use the same bridge driver to work with different
sub-devices.
It is a .probe()'s task to detect what sub-devices are there inside the
board.
There are several cases where the vendor switched the sub-devices without
changing the PCI ID/USB ID.
Hardware vendors suck, we all know that :(
So, drivers do things like the code below, inside the .probe() callback:
static int check_if_dvb_frontend_is_supported_and_bind()
{
switch (device_model) {
case VENDOR_A_MODEL_1:
if (test_and_bind_frontend_1()) /* Doesn't require firmware */
return 0;
if (test_and_bind_frontend_2()) /* requires firmware foo */
return 0;
if (test_and_bind_frontend_3()) /* requires firmware bar */
return 0;
Wait, why would these, if they require firmware, not load the firmware
at this point in time? Why are they saying all is fine here?
The above is a prototype of what happens. The test_and_bind_frontend_n()
logic are, in fact, more complex than that: it tries to load the firmware
inside each frontend's code when needed.
This is a real example (taken from ttpci budget driver):
switch(budget-dev-pci-subsystem_device) {
case 0x1003: // Hauppauge/TT Nova budget (stv0299/ALPS BSRU6(tsa5059)
OR ves1893/ALPS BSRV2(sp5659))
case 0x1013:
// try the ALPS BSRV2 first of all
budget-dvb_frontend = dvb_attach(ves1x93_attach,
alps_bsrv2_config, budget-i2c_adap);
if (budget-dvb_frontend) {
budget-dvb_frontend-ops.tuner_ops.set_params =
alps_bsrv2_tuner_set_params;
budget-dvb_frontend-ops.diseqc_send_master_cmd =
budget_diseqc_send_master_cmd;
budget-dvb_frontend-ops.diseqc_send_burst =
budget_diseqc_send_burst;
budget-dvb_frontend-ops.set_tone = budget_set_tone;
break;
}
// try the ALPS BSRU6 now
budget-dvb_frontend = dvb_attach(stv0299_attach,
alps_bsru6_config, budget-i2c_adap);
if (budget-dvb_frontend) {
