[PATCH] [media] s5p-mfc: Fix misplaced return statement in s5p_mfc_suspend()
return statement was wrongly placed before a code that needs to be
executed. Moved the return statement to the end of the function.
Tested suspend/resume on SMDK4412 board using 3.5-rc6 kernel.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index e3e616d..e913a1c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1148,7 +1148,7 @@ static int s5p_mfc_suspend(struct device *dev)
if (m_dev-num_inst == 0)
return 0;
- return s5p_mfc_sleep(m_dev);
+
if (test_and_set_bit(0, m_dev-enter_suspend) != 0) {
mfc_err(Error: going to suspend for a second time\n);
return -EIO;
@@ -1167,7 +1167,8 @@ static int s5p_mfc_suspend(struct device *dev)
return -EIO;
}
}
- return 0;
+
+ return s5p_mfc_sleep(m_dev);
}
static int s5p_mfc_resume(struct device *dev)
--
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
[PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()
From: Rob Clark r...@ti.com
We never really clarified if unmap could be done in atomic context.
But since mapping might require sleeping, this implies mutex in use
to synchronize mapping/unmapping, so unmap could sleep as well. Add
a might_sleep() to clarify this.
Signed-off-by: Rob Clark r...@ti.com
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/base/dma-buf.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..877eacb 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
struct sg_table *sg_table,
enum dma_data_direction direction)
{
+ might_sleep();
+
if (WARN_ON(!attach || !attach-dmabuf || !sg_table))
return;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma-buf: might_sleep() in dma_buf_unmap_attachment()
Op 28-09-12 09:29, Rob Clark schreef:
From: Rob Clark r...@ti.com
We never really clarified if unmap could be done in atomic context.
But since mapping might require sleeping, this implies mutex in use
to synchronize mapping/unmapping, so unmap could sleep as well. Add
a might_sleep() to clarify this.
Signed-off-by: Rob Clark r...@ti.com
Acked-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/base/dma-buf.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index c30f3e1..877eacb 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -298,6 +298,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
struct sg_table *sg_table,
enum dma_data_direction direction)
{
+ might_sleep();
+
if (WARN_ON(!attach || !attach-dmabuf || !sg_table))
return;
Looks good to me!
Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.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 0/3] ov7670: migrate this sensor and its users to ctrl framework.
The following series migrate ov7670 sensor and current users to ctrl framework as discussed in [1]. This has been tested against mx2_camera soc-camera bridge, so tests or acks will be required from people using cam-core and via-camera out there. This will have to be applied on top of my previous series: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. All submitted patches have been obtained from Hans' tree and slightly modified to apply on current media_tree for-v3.7 branch: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl [PATCH 1/3] ov7670: use the control framework [PATCH 2/3] mcam-core: implement the control framework. [PATCH 3/3] via-camera: implement the control framework. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.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
[PATCH 2/3] mcam-core: implement the control framework.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 54 ---
drivers/media/platform/marvell-ccic/mcam-core.h |2 +
2 files changed, 11 insertions(+), 45 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void
*priv,
return ret;
}
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff = mcam_vidioc_streamoff,
- .vidioc_queryctrl = mcam_vidioc_queryctrl,
- .vidioc_g_ctrl = mcam_vidioc_g_ctrl,
- .vidioc_s_ctrl = mcam_vidioc_s_ctrl,
.vidioc_g_parm = mcam_vidioc_g_parm,
.vidioc_s_parm = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
* Get the v4l2 setup done.
*/
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
+
mutex_lock(cam-s_mutex);
cam-vdev = mcam_v4l_template;
cam-vdev.debug = 0;
cam-vdev.v4l2_dev = cam-v4l2_dev;
+ video_set_drvdata(cam-vdev, cam);
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
- video_set_drvdata(cam-vdev, cam);
/*
* If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
out:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
mutex_unlock(cam-s_mutex);
return ret;
out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam-buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(cam-vdev);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
v4l2_device_unregister(cam-v4l2_dev);
}
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
#include linux/list.h
#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
#include media/videobuf2-core.h
@@ -104,6 +105,7 @@ struct mcam_camera {
* should not be touched by the platform code.
*/
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users; /* How many open FDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] via-camera: implement the control framework.
And added a missing kfree to clean up the via_camera struct.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/via-camera.c | 60 ---
1 file changed, 14 insertions(+), 46 deletions(-)
diff --git a/drivers/media/platform/via-camera.c
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/ov7670.h
#include media/videobuf-dma-sg.h
#include linux/delay.h
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
struct via_camera {
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void
*priv,
}
/*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-/*
* Only one input.
*/
static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp,
void *priv,
static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
- .vidioc_queryctrl = viacam_queryctrl,
- .vidioc_g_ctrl = viacam_g_ctrl,
- .vidioc_s_ctrl = viacam_s_ctrl,
.vidioc_enum_input = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
ret = v4l2_device_register(pdev-dev, cam-v4l2_dev);
if (ret) {
dev_err(pdev-dev, Unable to register v4l2 device\n);
- return ret;
+ goto out_free;
}
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
/*
* Convince the system that we can do DMA.
*/
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
*/
ret = via_sensor_power_setup(cam);
if (ret)
- goto out_unregister;
+ goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev-pdev-irq, cam);
out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
out_unregister:
v4l2_device_unregister(cam-v4l2_dev);
+out_free:
+ kfree(cam);
return ret;
}
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device
*pdev)
v4l2_device_unregister(cam-v4l2_dev);
free_irq(viadev-pdev-irq, cam);
via_sensor_power_release(cam);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
+ kfree(cam);
via_cam_info = NULL;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ov7670: use the control framework
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c | 295 +---
1 file changed, 115 insertions(+), 180 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..eead1b4 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd,
int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value = ov7670_sm_to_abs(v);
- return ret;
-}
-
static int ov7670_s_contrast(struct v4l2_subdev *sd, int value)
{
return ov7670_write(sd,
RE: [PATCH v6 6/6] [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x
Hi Kamil, Thank you for the comments. I will make the suggested changes and post the updated patch. Regards Arun On Thu, Sep 27, 2012 at 9:59 PM, Kamil Debski k.deb...@samsung.com wrote: Hi Arun, Please find my comment inline. It seems that we're very close to an ACK :) PS - you missed me in CC when posting this patch (6/6). Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center Subject: [PATCH v6 6/6] [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x Date: Fri, 31 Aug 2012 22:37:42 +0530 From: Jeongtae Park jtp.p...@samsung.com Multi Format Codec 6.x is a hardware video coding acceleration module present in new Exynos5 SoC series. It is capable of handling several new video codecs for decoding and encoding Signed-off-by: Jeongtae Park jtp.p...@samsung.com Signed-off-by: Janghyuck Kim janghyuck@samsung.com Signed-off-by: Jaeryul Oh jaeryul...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/platform/Kconfig |4 +- drivers/media/platform/s5p-mfc/Makefile |8 +- drivers/media/platform/s5p-mfc/regs-mfc.h | 32 + drivers/media/platform/s5p-mfc/s5p_mfc.c| 64 +- drivers/media/platform/s5p-mfc/s5p_mfc_cmd.c|7 +- drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c | 156 ++ drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h | 20 + drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 61 +- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 154 ++- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c| 193 ++- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 139 ++- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c| 10 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 1956 +++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 50 + drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |3 +- 15 files changed, 2689 insertions(+), 168 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index d4c034d..9269307 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -164,12 +164,12 @@ config VIDEO_SAMSUNG_S5P_JPEG This is a v4l2 driver for Samsung S5P and EXYNOS4 JPEG codec config VIDEO_SAMSUNG_S5P_MFC - tristate Samsung S5P MFC 5.1 Video Codec + tristate Samsung S5P MFC Video Codec depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P select VIDEOBUF2_DMA_CONTIG default n help - MFC 5.1 driver for V4L2. + MFC 5.1 and 6.x driver for V4L2 config VIDEO_MX2_EMMAPRP tristate MX2 eMMa-PrP support diff --git a/drivers/media/platform/s5p-mfc/Makefile b/drivers/media/platform/s5p-mfc/Makefile index cfb9ee9..379008c 100644 --- a/drivers/media/platform/s5p-mfc/Makefile +++ b/drivers/media/platform/s5p-mfc/Makefile @@ -1,6 +1,6 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) := s5p-mfc.o -s5p-mfc-y += s5p_mfc.o s5p_mfc_intr.o s5p_mfc_opr.o +s5p-mfc-y += s5p_mfc.o s5p_mfc_intr.o s5p-mfc-y += s5p_mfc_dec.o s5p_mfc_enc.o -s5p-mfc-y += s5p_mfc_ctrl.o s5p_mfc_cmd.o -s5p-mfc-y += s5p_mfc_pm.o -s5p-mfc-y += s5p_mfc_opr_v5.o s5p_mfc_cmd_v5.o +s5p-mfc-y += s5p_mfc_ctrl.o s5p_mfc_pm.o +s5p-mfc-y += s5p_mfc_opr.o s5p_mfc_opr_v5.o s5p_mfc_opr_v6.o +s5p-mfc-y += s5p_mfc_cmd.o s5p_mfc_cmd_v5.o s5p_mfc_cmd_v6.o diff --git a/drivers/media/platform/s5p-mfc/regs-mfc.h b/drivers/media/platform/s5p-mfc/regs-mfc.h index 3e2fce0..77ce293 100644 --- a/drivers/media/platform/s5p-mfc/regs-mfc.h +++ b/drivers/media/platform/s5p-mfc/regs-mfc.h @@ -144,6 +144,7 @@ #define S5P_FIMV_ENC_PROFILE_H264_MAIN 0 #define S5P_FIMV_ENC_PROFILE_H264_HIGH 1 #define S5P_FIMV_ENC_PROFILE_H264_BASELINE 2 +#define S5P_FIMV_ENC_PROFILE_H264_CONSTRAINED_BASELINE 3 #define S5P_FIMV_ENC_PROFILE_MPEG4_SIMPLE0 #define S5P_FIMV_ENC_PROFILE_MPEG4_ADVANCED_SIMPLE 1 #define S5P_FIMV_ENC_PIC_STRUCT 0x083c /* picture field/frame flag */ @@ -213,6 +214,7 @@ #define S5P_FIMV_DEC_STATUS_RESOLUTION_MASK (34) #define S5P_FIMV_DEC_STATUS_RESOLUTION_INC (14) #define S5P_FIMV_DEC_STATUS_RESOLUTION_DEC (24) +#define S5P_FIMV_DEC_STATUS_RESOLUTION_SHIFT 4 /* Decode frame address */ #define S5P_FIMV_DECODE_Y_ADR0x2024 @@ -377,6 +379,16 @@ #define S5P_FIMV_R2H_CMD_EDFU_INIT_RET 16 #define S5P_FIMV_R2H_CMD_ERR_RET 32 +/* Dummy definition for MFCv6 compatibilty */ +#define S5P_FIMV_CODEC_H264_MVC_DEC -1
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent, 2012/9/28 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Enric, On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote: 2012/9/27 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote: 2012/9/26 Laurent Pinchart laurent.pinch...@ideasonboard.com: On Wednesday 26 September 2012 09:57:53 Enric Balletbò i Serra wrote: [snip] You had reason. Checking the data lines of the camera bus with an oscilloscope I see I had a problem, exactly in D8 /D9 data lines. I'm curious, how have you fixed that ? The board had a pull-down 4k7 resistor which I removed in these lines (D8/D9). The board is prepared to accept sensors from 8 to 12 bits, lines from D8 to D12 have a pull-down resistor to tie down the line by default. With the oscilloscope I saw that D8/D9 had problems to go to high level like you said, then I checked the schematic and I saw these resistors. Now I can capture images but the color is still wrong, see the following image captured with pipeline SENSOR - CCDC OUTPUT http://downloads.isee.biz/pub/files/patterns/img-01.pnm Now the image was converted using : ./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin img-01.pnm And the raw data can be found here: http://downloads.isee.biz/pub/files/patterns/img-01.bin Any idea where I can look ? Thanks. Your sensors produces BGGR data if I'm not mistaken, not GRBG. raw2rgbpnm doesn't support BGGR (yet), but the OMAP3 ISP preview engine can convert that to YUV since v3.5. Just make your sensor driver expose the right media bus format and configure the pipeline accordingly. The datasheet (p.10,11) says that the Pixel Color Pattern is as follows. direction n 4321 .. GB GB GB GB .. RG RG RG RG So seems you're right, if the first byte is on the right the sensor produces BGGR. But for some reason the mt9v032 driver uses GRBG data. You can change the Bayer pattern by moving the crop rectangle. That how the mt9v032 driver ensures a GRBG pattern even though the first active pixel in the sensor array is a blue one. As the MT9V034 first active pixel is located at different coordinates you will have to modify the crop rectangle computation logic to get GRBG. Please, could you explain how to do this ? I'm a newbie into image sensors world :-) Let's assume the following Bayer pattern (left to right and top to bottom direction). | 1 2 3 4 5 6 7 8 ... -- 1| G R G R G R G R ... 2| B G B G B G B G ... 3| G R G R G R G R ... 4| B G B G B G B G ... 5| G R G R G R G R ... 6| B G B G B G B G ... 7| G R G R G R G R ... 8| B G B G B G B G ... .| ... If you crop the (1,1)/4x4 rectangle from that sensor you will get | 1 2 3 4 -- 1| G R G R 2| B G B G 3| G R G R 4| B G B G which is clearly a GRBG pattern. If you crop the (2,1)/4x4 rectangle you will get | 2 3 4 5 -- 1| R G R G 2| G B G B 3| R G R G 4| G B G B which is now a RGGB pattern. The pattern you get out of your sensor thus depends on the crop rectangle position. Many thanks for the explanation. I'm learning a lot with your explanations :-) Maybe is related with following lines which writes register 0x0D Read Mode (p.26,27) and presumably flips row or column bytes (not sure about this I need to check) 334 /* Configure the window size and row/column bin */ 335 hratio = DIV_ROUND_CLOSEST(crop-width, format-width); 336 vratio = DIV_ROUND_CLOSEST(crop-height, format-height); 337 338 ret = mt9v032_write(client, MT9V032_READ_MODE, 339 (hratio - 1) MT9V032_READ_MODE_ROW_BIN_SHIFT | 340 (vratio - 1) MT9V032_READ_MODE_COLUMN_BIN_SHIFT); Nonetheless, I changed the driver to configure for BGGR pattern. Using the Sensor-CCDC-Preview-Resizer pipeline I captured the data with yavta and converted using raw2rgbpnm program. ./raw2rgbpnm -s 752x480 -f UYVY img-01.uyvy img-01.pnm and the result is http://downloads.isee.biz/pub/files/patterns/img-02.pnm http://downloads.isee.biz/pub/files/patterns/img-02.bin The image looks better than older, not perfect, but better. The image is only a bit yellowish. Could be this a hardware issue ? We are close to ... It's like a white balance issue. The OMAP3 ISP hardware doesn't perform automatic white balance, you will need to implement an AWB algorithm in software. You can have a look at the omap3-isp-live project for sample code (http://git.ideasonboard.org/omap3-isp-live.git). So you think the sensor is set well now ? The hardware can produce this issue ? Do you know if this algorithm is implemented in gstreamer ? Regards, Enric -- To unsubscribe from
Re: [PATCH 1/3] ov7670: use the control framework
On Fri September 28 2012 09:48:01 Javier Martin wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c | 295
+---
1 file changed, 115 insertions(+), 180 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..eead1b4 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev
*sd, int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value = ov7670_sm_to_abs(v);
- return ret;
-}
-
static int ov7670_s_contrast(struct
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Enric,
On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote:
2012/9/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote:
2012/9/27 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote:
2012/9/26 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Wednesday 26 September 2012 09:57:53 Enric Balletbò i Serra
wrote:
[snip]
You had reason. Checking the data lines of the camera bus with an
oscilloscope I see I had a problem, exactly in D8 /D9 data lines.
I'm curious, how have you fixed that ?
The board had a pull-down 4k7 resistor which I removed in these lines
(D8/D9). The board is prepared to accept sensors from 8 to 12 bits,
lines from D8 to D12 have a pull-down resistor to tie down the line by
default.
With the oscilloscope I saw that D8/D9 had problems to go to high
level like you said, then I checked the schematic and I saw these
resistors.
Now I can capture images but the color is still wrong, see the
following
image captured with pipeline SENSOR - CCDC OUTPUT
http://downloads.isee.biz/pub/files/patterns/img-01.pnm
Now the image was converted using :
./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin
img-01.pnm
And the raw data can be found here:
http://downloads.isee.biz/pub/files/patterns/img-01.bin
Any idea where I can look ? Thanks.
Your sensors produces BGGR data if I'm not mistaken, not GRBG.
raw2rgbpnm doesn't support BGGR (yet), but the OMAP3 ISP preview
engine
can convert that to YUV since v3.5. Just make your sensor driver
expose
the right media bus format and configure the pipeline accordingly.
The datasheet (p.10,11) says that the Pixel Color Pattern is as
follows.
direction
n 4321
.. GB GB GB GB
.. RG RG RG RG
So seems you're right, if the first byte is on the right the sensor
produces BGGR. But for some reason the mt9v032 driver uses GRBG data.
You can change the Bayer pattern by moving the crop rectangle. That how
the mt9v032 driver ensures a GRBG pattern even though the first active
pixel in the sensor array is a blue one. As the MT9V034 first active
pixel
is located at different coordinates you will have to modify the crop
rectangle computation logic to get GRBG.
Please, could you explain how to do this ? I'm a newbie into image
sensors world :-)
Let's assume the following Bayer pattern (left to right and top to bottom
direction).
| 1 2 3 4 5 6 7 8 ...
--
1| G R G R G R G R ...
2| B G B G B G B G ...
3| G R G R G R G R ...
4| B G B G B G B G ...
5| G R G R G R G R ...
6| B G B G B G B G ...
7| G R G R G R G R ...
8| B G B G B G B G ...
.| ...
If you crop the (1,1)/4x4 rectangle from that sensor you will get
| 1 2 3 4
--
1| G R G R
2| B G B G
3| G R G R
4| B G B G
which is clearly a GRBG pattern. If you crop the (2,1)/4x4 rectangle you
will get
| 2 3 4 5
--
1| R G R G
2| G B G B
3| R G R G
4| G B G B
which is now a RGGB pattern. The pattern you get out of your sensor thus
depends on the crop rectangle position.
Many thanks for the explanation. I'm learning a lot with your explanations
:-)
Maybe is related with following lines which writes register 0x0D Read
Mode (p.26,27) and presumably flips row or column bytes (not sure
about this I need to check)
334 /* Configure the window size and row/column bin */
335 hratio = DIV_ROUND_CLOSEST(crop-width, format-width);
336 vratio = DIV_ROUND_CLOSEST(crop-height, format-height);
337
338 ret = mt9v032_write(client, MT9V032_READ_MODE,
339 (hratio - 1)
MT9V032_READ_MODE_ROW_BIN_SHIFT |
340 (vratio - 1)
MT9V032_READ_MODE_COLUMN_BIN_SHIFT);
Nonetheless, I changed the driver to configure for BGGR pattern. Using
the Sensor-CCDC-Preview-Resizer pipeline I captured the data with
yavta and converted using raw2rgbpnm program.
./raw2rgbpnm -s 752x480 -f UYVY img-01.uyvy img-01.pnm
and the result is
http://downloads.isee.biz/pub/files/patterns/img-02.pnm
http://downloads.isee.biz/pub/files/patterns/img-02.bin
The image looks better than older, not perfect, but better. The image
is only a bit yellowish. Could be this a hardware issue ? We are close
to ...
It's like a white balance issue. The OMAP3 ISP hardware doesn't perform
automatic white balance, you will need to implement an AWB algorithm in
software. You can have a look at the omap3-isp-live project for
[PATCH 1/2] [media] iguanair: cannot send data from the stack
Note that the firmware already disables the receiver before transmit,
there is no need to do this from the driver.
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/iguanair.c | 147 ++--
1 file changed, 75 insertions(+), 72 deletions(-)
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 1e4c68a..51d7057 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -28,6 +28,7 @@
#include media/rc-core.h
#define DRIVER_NAME iguanair
+#define BUF_SIZE 152
struct iguanair {
struct rc_dev *rc;
@@ -35,26 +36,23 @@ struct iguanair {
struct device *dev;
struct usb_device *udev;
- int pipe_out;
uint16_t version;
uint8_t bufsize;
+ uint8_t cycle_overhead;
struct mutex lock;
/* receiver support */
bool receiver_on;
- dma_addr_t dma_in;
+ dma_addr_t dma_in, dma_out;
uint8_t *buf_in;
- struct urb *urb_in;
+ struct urb *urb_in, *urb_out;
struct completion completion;
/* transmit support */
bool tx_overflow;
uint32_t carrier;
- uint8_t cycle_overhead;
- uint8_t channels;
- uint8_t busy4;
- uint8_t busy7;
+ struct send_packet *packet;
char name[64];
char phys[64];
@@ -73,7 +71,8 @@ struct iguanair {
#define DIR_IN 0xdc
#define DIR_OUT0xcd
-#define MAX_PACKET_SIZE8u
+#define MAX_IN_PACKET 8u
+#define MAX_OUT_PACKET (sizeof(struct send_packet) + BUF_SIZE)
#define TIMEOUT1000
#define RX_RESOLUTION 21333
@@ -191,20 +190,25 @@ static void iguanair_rx(struct urb *urb)
dev_warn(ir-dev, failed to resubmit urb: %d\n, rc);
}
-static int iguanair_send(struct iguanair *ir, void *data, unsigned size)
+static void iguanair_irq_out(struct urb *urb)
{
- int rc, transferred;
+ struct iguanair *ir = urb-context;
+
+ if (urb-status)
+ dev_dbg(ir-dev, Error: out urb status = %d\n, urb-status);
+}
+
+static int iguanair_send(struct iguanair *ir, unsigned size)
+{
+ int rc;
INIT_COMPLETION(ir-completion);
- rc = usb_interrupt_msg(ir-udev, ir-pipe_out, data, size,
- transferred, TIMEOUT);
+ ir-urb_out-transfer_buffer_length = size;
+ rc = usb_submit_urb(ir-urb_out, GFP_KERNEL);
if (rc)
return rc;
- if (transferred != size)
- return -EIO;
-
if (wait_for_completion_timeout(ir-completion, TIMEOUT) == 0)
return -ETIMEDOUT;
@@ -213,14 +217,13 @@ static int iguanair_send(struct iguanair *ir, void *data,
unsigned size)
static int iguanair_get_features(struct iguanair *ir)
{
- struct packet packet;
int rc;
- packet.start = 0;
- packet.direction = DIR_OUT;
- packet.cmd = CMD_GET_VERSION;
+ ir-packet-header.start = 0;
+ ir-packet-header.direction = DIR_OUT;
+ ir-packet-header.cmd = CMD_GET_VERSION;
- rc = iguanair_send(ir, packet, sizeof(packet));
+ rc = iguanair_send(ir, sizeof(ir-packet-header));
if (rc) {
dev_info(ir-dev, failed to get version\n);
goto out;
@@ -235,17 +238,23 @@ static int iguanair_get_features(struct iguanair *ir)
ir-bufsize = 150;
ir-cycle_overhead = 65;
- packet.cmd = CMD_GET_BUFSIZE;
+ ir-packet-header.cmd = CMD_GET_BUFSIZE;
- rc = iguanair_send(ir, packet, sizeof(packet));
+ rc = iguanair_send(ir, sizeof(ir-packet-header));
if (rc) {
dev_info(ir-dev, failed to get buffer size\n);
goto out;
}
- packet.cmd = CMD_GET_FEATURES;
+ if (ir-bufsize BUF_SIZE) {
+ dev_info(ir-dev, buffer size %u larger than expected\n,
+ ir-bufsize);
+ ir-bufsize = BUF_SIZE;
+ }
+
+ ir-packet-header.cmd = CMD_GET_FEATURES;
- rc = iguanair_send(ir, packet, sizeof(packet));
+ rc = iguanair_send(ir, sizeof(ir-packet-header));
if (rc) {
dev_info(ir-dev, failed to get features\n);
goto out;
@@ -257,13 +266,18 @@ out:
static int iguanair_receiver(struct iguanair *ir, bool enable)
{
- struct packet packet = { 0, DIR_OUT, enable ?
- CMD_RECEIVER_ON : CMD_RECEIVER_OFF };
+ int rc;
+
+ ir-packet-header.start = 0;
+ ir-packet-header.direction = DIR_OUT;
+ ir-packet-header.cmd = enable ? CMD_RECEIVER_ON : CMD_RECEIVER_OFF;
if (enable)
ir_raw_event_reset(ir-rc);
- return iguanair_send(ir, packet, sizeof(packet));
+ rc =
[PATCH 2/2] [media] winbond: remove space from driver name
[root@pequod ~]# udevadm test /sys/class/rc/rc0
-snip-
ACTION=add
DEVPATH=/devices/pnp0/00:04/rc/rc0
DRV_NAME=Winbond CIR
NAME=rc-rc6-mce
SUBSYSTEM=rc
UDEV_LOG=6
USEC_INITIALIZED=88135858
run: '/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0'
Having a space makes it impossible to match in /etc/rc_maps.cfg.
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/winbond-cir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 30ae1f2..7c9b5f3 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -184,7 +184,7 @@ enum wbcir_txstate {
};
/* Misc */
-#define WBCIR_NAME Winbond CIR
+#define WBCIR_NAME winbond-cir
#define WBCIR_ID_FAMILY 0xF1 /* Family ID for the WPCD376I*/
#defineWBCIR_ID_CHIP0x04 /* Chip ID for the WPCD376I
*/
#define INVALID_SCANCODE 0x7FFF /* Invalid with all protos */
--
1.7.11.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
Re: [PATCH 1/3] ov7670: use the control framework
Hi Hans,
On 28 September 2012 10:23, Hans Verkuil hverk...@xs4all.nl wrote:
On Fri September 28 2012 09:48:01 Javier Martin wrote:
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ctrl = ov7670_g_ctrl,
- .s_ctrl = ov7670_s_ctrl,
- .queryctrl = ov7670_queryctrl,
+ .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
+ .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
+ .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
+ .g_ctrl = v4l2_subdev_g_ctrl,
+ .s_ctrl = v4l2_subdev_s_ctrl,
+ .queryctrl = v4l2_subdev_queryctrl,
+ .querymenu = v4l2_subdev_querymenu,
Can you make a fourth patch removing these lines again after mcam-core and
via-camera are converted to the control framework? These control ops are
only needed if there are bridge drivers using this sensor driver that are
not yet converted to the control framework. Since that limitation is now
lifted, these ops can be removed as well.
Fine, I will do that.
.reset = ov7670_reset,
.init = ov7670_init,
#ifdef CONFIG_VIDEO_ADV_DEBUG
@@ -1732,7 +1630,6 @@ static int ov7670_probe(struct i2c_client *client,
info-devtype = ov7670_devdata[id-driver_data];
info-fmt = ov7670_formats[0];
- info-sat = 128;/* Review this */
info-clkrc = 0;
/* Set default frame rate to 30 fps */
@@ -1743,6 +1640,42 @@ static int ov7670_probe(struct i2c_client *client,
if (info-pclk_hb_disable)
ov7670_write(sd, REG_COM10, COM10_PCLK_HB);
+ v4l2_ctrl_handler_init(info-hdl, 10);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_CONTRAST, 0, 127, 1, 64);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_VFLIP, 0, 1, 1, 0);
+ v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_HFLIP, 0, 1, 1, 0);
+ info-saturation = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_SATURATION, 0, 256, 1, 128);
+ info-hue = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_HUE, -180, 180, 5, 0);
+ info-gain = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_GAIN, 0, 255, 1, 128);
+ info-auto_gain = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
+ info-exposure = v4l2_ctrl_new_std(info-hdl, ov7670_ctrl_ops,
+ V4L2_CID_EXPOSURE, 0, 65535, 1, 500);
+ info-auto_exposure = v4l2_ctrl_new_std_menu(info-hdl,
ov7670_ctrl_ops,
+ V4L2_CID_EXPOSURE_AUTO, 1, 0, 0);
+ sd-ctrl_handler = info-hdl;
+ if (info-hdl.error) {
+ int err = info-hdl.error;
+
+ v4l2_ctrl_handler_free(info-hdl);
+ kfree(info);
+ return err;
+ }
+ info-gain-flags |= V4L2_CTRL_FLAG_VOLATILE;
+ info-exposure-flags |= V4L2_CTRL_FLAG_VOLATILE;
+ v4l2_ctrl_cluster(2, info-auto_gain);
+ v4l2_ctrl_cluster(2, info-auto_exposure);
You need to use v4l2_ctrl_auto_cluster for these two. Not having that function
at the time was the reason my work on this driver stalled. The auto cluster
functionality takes care of most of the nitty gritty details of handling
these situations.
OK, let me take a look.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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 1/2] V4L: soc_camera: add driver for IFM camera sensor interface on mpc5200
IFM O2D cameras use special sensor bus interface glue-logic to
connect camera sensors to mpc5200 LocalPlus bus. Add camera
sensor driver for this mpc5200 camera interface.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/platform/soc_camera/Kconfig |7 +
drivers/media/platform/soc_camera/Makefile |1 +
.../media/platform/soc_camera/mpc5200-csi-camera.c | 1212
3 files changed, 1220 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/platform/soc_camera/mpc5200-csi-camera.c
diff --git a/drivers/media/platform/soc_camera/Kconfig
b/drivers/media/platform/soc_camera/Kconfig
index 9afe1e7..4d6c74d 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -85,3 +85,10 @@ config VIDEO_ATMEL_ISI
This module makes the ATMEL Image Sensor Interface available
as a v4l2 device.
+config VIDEO_MPC52xx_CSI
+ tristate IFM MPC5200 Camera Sensor Interface driver
+ depends on SOC_CAMERA PPC_MPC52xx
+ select PPC_BESTCOMM_GEN_BD
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a driver for IFM camera sensor interface on mpc5200.
diff --git a/drivers/media/platform/soc_camera/Makefile
b/drivers/media/platform/soc_camera/Makefile
index 136b7f8..79e6339 100644
--- a/drivers/media/platform/soc_camera/Makefile
+++ b/drivers/media/platform/soc_camera/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
+obj-$(CONFIG_VIDEO_MPC52xx_CSI)+= mpc5200-csi-camera.o
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
diff --git a/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
b/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
new file mode 100644
index 000..84746c1
--- /dev/null
+++ b/drivers/media/platform/soc_camera/mpc5200-csi-camera.c
@@ -0,0 +1,1212 @@
+/*
+ * Driver for image sensor/fpga interface on mpc5200 LPB found
+ * on IFM o2d based boards
+ *
+ * Code base taken from i.MX3x camera host driver
+ * Copyright (C) 2008
+ * Guennadi Liakhovetski, DENX Software Engineering, l...@denx.de
+ *
+ * Copyright (C) 2012
+ * Anatolij Gustschin ag...@denx.de, DENX Software Engineering
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/string.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/unistd.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/init.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/dma-mapping.h
+#include asm/mpc52xx.h
+
+#include linux/i2c.h
+#include linux/videodev2.h
+#include linux/sched.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#define O2XXX_CAM_DRV_NAME o2d_csi
+
+#define MAX_VIDEO_MEM 2 /* Video memory limit in megabytes */
+
+#define DEFAULT_IMAGE_WIDTH688 /* Default image width */
+#define DEFAULT_IMAGE_HEIGHT 480 /* Default image height */
+#define DEFAULT_IMAGE_LENGTH (DEFAULT_IMAGE_WIDTH * DEFAULT_IMAGE_HEIGHT)
+
+enum o2xxx_buffer_state {
+ BUF_NEEDS_INIT,
+ BUF_PREPARED,
+};
+
+struct o2xxx_camera_buffer {
+ /* v4l2_buffer must be first */
+ struct vb2_buffer vb;
+ dma_addr_t paddr;
+ size_t bsize;
+ enum o2xxx_buffer_state state;
+ struct list_headqueue;
+};
+
+struct o2d_csi_priv {
+ /* sensor control gpios */
+ int imag_capture;
+ int imag_reset;
+ int imag_master_en;
+
+ struct device_node *gpt_np;
+ struct mpc52xx_gpt __iomem *gpt;
+ struct mpc52xx_intr __iomem *intr;
+ int irq;
+ int chip_select;
+
+ /* LocalPlus Bus camera CS phys addr */
+ resource_size_t lpb_cs_phys;
+
+ resource_size_t lpbfifo_regs_phys;
+ void __iomem *lpbfifo_regs;
+
+ /* soc_camera and v4l2 interface */
+ struct platform_device *soc_cam_pdev;
+ struct soc_camera_device *icd;
+ struct soc_camera_host soc_host;
+ size_t buf_total;
+ int sequence;
+ struct vb2_alloc_ctx *alloc_ctx;
+
+ unsigned long image_length;
+
+ struct o2xxx_camera_buffer *active;
+ spinlock_t lock;/* Protects video buffer
[PATCH 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
With mpc52xx_csi interface I2C subdev streamon after vb2_streamon()
doesn't work due to mpc52xx sensor interface glue-logic restrictions.
Since mpc5200 doesn't have a camera sensor interface, the sensor on
O2D cameras is connected to the LocalPlus bus by special glue-logic.
While sensor read-out the sensor will be clocked with the bus chip-
select signal as the sensor clock so that the read-out is synchronous
with the data accesses on the bus. Therefore, I2C access can't be
performed when the glue-logic is setup for sensor read-out.
mpc52xx_csi driver for O2D cameras performs I2C subdev streamon in
its start_streaming() operation and then disables the I2C bus access
by configuring the interface glue-logic for sensor read-out.
For above-mentioned reasons we disable this subdev call here.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/platform/soc_camera/soc_camera.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f6b1c1f..64e0abb 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -809,7 +809,7 @@ static int soc_camera_streamon(struct file *file, void
*priv,
{
struct soc_camera_device *icd = file-private_data;
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct v4l2_subdev __maybe_unused *sd = soc_camera_to_subdev(icd);
int ret;
WARN_ON(priv != file-private_data);
@@ -826,8 +826,11 @@ static int soc_camera_streamon(struct file *file, void
*priv,
else
ret = vb2_streamon(icd-vb2_vidq, i);
+#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \
+!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE)
if (!ret)
v4l2_subdev_call(sd, video, s_stream, 1);
+#endif
return ret;
}
--
1.7.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] s5p-mfc: Fix misplaced return statement in s5p_mfc_suspend()
Hi Sachin,
Thank you for your patch, fixing this bug and testing suspend/resume.
Best wishes,
--
Kamil Debski
Linux Platform Group
Samsung Poland RD Center
-Original Message-
From: Sachin Kamat [mailto:sachin.ka...@linaro.org]
Sent: 28 September 2012 09:02
To: linux-media@vger.kernel.org
Cc: k.deb...@samsung.com; s.nawro...@samsung.com; sachin.ka...@linaro.org;
patc...@linaro.org
Subject: [PATCH] [media] s5p-mfc: Fix misplaced return statement in
s5p_mfc_suspend()
return statement was wrongly placed before a code that needs to be
executed. Moved the return statement to the end of the function.
Tested suspend/resume on SMDK4412 board using 3.5-rc6 kernel.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Acked-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index e3e616d..e913a1c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1148,7 +1148,7 @@ static int s5p_mfc_suspend(struct device *dev)
if (m_dev-num_inst == 0)
return 0;
- return s5p_mfc_sleep(m_dev);
+
if (test_and_set_bit(0, m_dev-enter_suspend) != 0) {
mfc_err(Error: going to suspend for a second time\n);
return -EIO;
@@ -1167,7 +1167,8 @@ static int s5p_mfc_suspend(struct device *dev)
return -EIO;
}
}
- return 0;
+
+ return s5p_mfc_sleep(m_dev);
}
static int s5p_mfc_resume(struct device *dev)
--
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
[RFCv2 PATCH 4/4] DocBook: various updates w.r.t. v4l2_buffer and multiplanar.
From: Hans Verkuil hans.verk...@cisco.com Clarify the behavior of v4l2_buffer in the multiplanar case, including fixing a false statement: you can't set m.planes to NULL when calling DQBUF. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml |6 -- Documentation/DocBook/media/v4l/vidioc-qbuf.xml |3 +-- Documentation/DocBook/media/v4l/vidioc-querybuf.xml | 11 +++ 3 files changed, 12 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 97f785a..b5d1cbd 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -677,8 +677,10 @@ memory, set by the application. See xref linkend=userp / for details. entrystructfieldlength/structfield/entry entry/entry entrySize of the buffer (not the payload) in bytes for the - single-planar API. For the multi-planar API should contain the - number of elements in the structfieldplanes/structfield array. + single-planar API. For the multi-planar API the application sets + this to the number of elements in the structfieldplanes/structfield + array. The driver will fill in the actual number of valid elements in + that array. /entry /row row diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml index 6a821a6..2d37abe 100644 --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -121,8 +121,7 @@ remaining fields or returns an error code. The driver may also set field. It indicates a non-critical (recoverable) streaming error. In such case the application may continue as normal, but should be aware that data in the dequeued buffer might be corrupted. When using the multi-planar API, the -planes array does not have to be passed; the structfieldm.planes/structfield -member must be set to NULL in that case./para +planes array must be passed in as well./para paraBy default constantVIDIOC_DQBUF/constant blocks when no buffer is in the outgoing queue. When the diff --git a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml index 6e414d7..a597155 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml @@ -48,8 +48,8 @@ refsect1 titleDescription/title -paraThis ioctl is part of the link linkend=mmapmemory -mapping/link I/O method. It can be used to query the status of a +paraThis ioctl is part of the link linkend=mmapstreaming +/link I/O method. It can be used to query the status of a buffer at any time after buffers have been allocated with the VIDIOC-REQBUFS; ioctl./para @@ -71,6 +71,7 @@ the structure./para paraIn the structfieldflags/structfield field the constantV4L2_BUF_FLAG_MAPPED/constant, +constantV4L2_BUF_FLAG_PREPARED/constant, constantV4L2_BUF_FLAG_QUEUED/constant and constantV4L2_BUF_FLAG_DONE/constant flags will be valid. The structfieldmemory/structfield field will be set to the current @@ -79,8 +80,10 @@ contains the offset of the buffer from the start of the device memory, the structfieldlength/structfield field its size. For the multi-planar API, fields structfieldm.mem_offset/structfield and structfieldlength/structfield in the structfieldm.planes/structfield -array elements will be used instead. The driver may or may not set the remaining -fields and flags, they are meaningless in this context./para +array elements will be used instead and the structfieldlength/structfield +field of v4l2-buffer; is set to the number of filled-in array elements. +The driver may or may not set the remaining fields and flags, they are +meaningless in this context./para paraThe structnamev4l2_buffer/structname structure is specified in xref linkend=buffer /./para -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 1/4] videobuf2-core: move plane verification out of __fill_v4l2/vb_buffer.
From: Hans Verkuil hans.verk...@cisco.com
The plane verification should be done before actually queuing or
dequeuing buffers, so move it out of __fill_v4l2_buffer and __fill_vb_buffer
and call it as a separate step.
This also makes it possible to change the return type of __fill_v4l2/vb_buffer
to void.
The dqbuf case took some special care: before removing a buffer from the
done_list you have to verify that the receiving v4l2_buffer has enough room
for all the planes. The number of planes can differ between buffers due to the
fact that buffers for other formats can be prepared using VIDIOC_PREPARE_BUF.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c | 78 +++---
1 file changed, 38 insertions(+), 40 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index e6a26b4..5a132b2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -276,6 +276,9 @@ static void __vb2_queue_free(struct vb2_queue *q, unsigned
int buffers)
*/
static int __verify_planes_array(struct vb2_buffer *vb, const struct
v4l2_buffer *b)
{
+ if (!V4L2_TYPE_IS_MULTIPLANAR(b-type))
+ return 0;
+
/* Is memory for copying plane information present? */
if (NULL == b-m.planes) {
dprintk(1, Multi-planar buffer passed but
@@ -331,10 +334,9 @@ static bool __buffers_in_use(struct vb2_queue *q)
* __fill_v4l2_buffer() - fill in a struct v4l2_buffer with information to be
* returned to userspace
*/
-static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
+static void __fill_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
{
struct vb2_queue *q = vb-vb2_queue;
- int ret;
/* Copy back data such as timestamp, flags, etc. */
memcpy(b, vb-v4l2_buf, offsetof(struct v4l2_buffer, m));
@@ -342,13 +344,9 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
b-reserved = vb-v4l2_buf.reserved;
if (V4L2_TYPE_IS_MULTIPLANAR(q-type)) {
- ret = __verify_planes_array(vb, b);
- if (ret)
- return ret;
-
/*
* Fill in plane-related data if userspace provided an array
-* for it. The memory and size is verified above.
+* for it. The caller has already verified memory and size.
*/
memcpy(b-m.planes, vb-v4l2_planes,
b-length * sizeof(struct v4l2_plane));
@@ -391,8 +389,6 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct
v4l2_buffer *b)
if (__buffer_in_use(q, vb))
b-flags |= V4L2_BUF_FLAG_MAPPED;
-
- return 0;
}
/**
@@ -411,6 +407,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct
v4l2_buffer *b)
int vb2_querybuf(struct vb2_queue *q, struct v4l2_buffer *b)
{
struct vb2_buffer *vb;
+ int ret;
if (b-type != q-type) {
dprintk(1, querybuf: wrong buffer type\n);
@@ -422,8 +419,10 @@ int vb2_querybuf(struct vb2_queue *q, struct v4l2_buffer
*b)
return -EINVAL;
}
vb = q-bufs[b-index];
-
- return __fill_v4l2_buffer(vb, b);
+ ret = __verify_planes_array(vb, b);
+ if (!ret)
+ __fill_v4l2_buffer(vb, b);
+ return ret;
}
EXPORT_SYMBOL(vb2_querybuf);
@@ -813,24 +812,16 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
EXPORT_SYMBOL_GPL(vb2_buffer_done);
/**
- * __fill_vb2_buffer() - fill a vb2_buffer with information provided in
- * a v4l2_buffer by the userspace
+ * __fill_vb2_buffer() - fill a vb2_buffer with information provided in a
+ * v4l2_buffer by the userspace. The caller has already verified that struct
+ * v4l2_buffer has a valid number of planes.
*/
-static int __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer
*b,
+static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer
*b,
struct v4l2_plane *v4l2_planes)
{
unsigned int plane;
- int ret;
if (V4L2_TYPE_IS_MULTIPLANAR(b-type)) {
- /*
-* Verify that the userspace gave us a valid array for
-* plane information.
-*/
- ret = __verify_planes_array(vb, b);
- if (ret)
- return ret;
-
/* Fill in driver-provided information for OUTPUT types */
if (V4L2_TYPE_IS_OUTPUT(b-type)) {
/*
@@ -872,8 +863,6 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, const
struct v4l2_buffer *b,
vb-v4l2_buf.field = b-field;
vb-v4l2_buf.timestamp = b-timestamp;
vb-v4l2_buf.flags = b-flags ~V4L2_BUFFER_STATE_FLAGS;
-
- return 0;
}
/**
[RFCv2 PATCH 3/4] v4l2-ioctl.c: handle PREPARE_BUF like QUERYBUF.
From: Hans Verkuil hans.verk...@cisco.com
The core code for PREPARE_BUF didn't take the multiplanar case into account,
which might cause page faults. Handle PREPARE_BUF just like QUERYBUF and
QBUF/DQBUF.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ioctl.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 09512eb..6ae885d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2182,6 +2182,7 @@ static int check_array_args(unsigned int cmd, void *parg,
size_t *array_size,
int ret = 0;
switch (cmd) {
+ case VIDIOC_PREPARE_BUF:
case VIDIOC_QUERYBUF:
case VIDIOC_QBUF:
case VIDIOC_DQBUF: {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH 0/4] vb2 multiplanar fixes/changes
Changes since RFCv1: - Don't move num_planes to vb2_queue. In certain circumstances it is possible to have buffers with different number of planes, so keep num_planes in vb2_buffer. This complicated vb2_dqbuf a bit since the plane verification now has to be done just before the buffer is dequeued from the done_list. You don't want to dequeue it if the v4l2_buffer didn't provide enough room for all the planes. This RFC PATCH series is related to this email I sent: http://www.mail-archive.com/linux-media@vger.kernel.org/msg52193.html I've decided to fix the plane verification problem. This is done in the first patch. The second patch fills in the length field as I proposed in the mail above. The third fixes a bug for PREPARE_BUF in the multiplanar case that I came across by accident. The last patch updates the DocBook and clarifies a number of things. Comments are welcome, 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
[RFCv2 PATCH 2/4] videobuf2-core: fill in length field for multiplanar buffers.
From: Hans Verkuil hans.verk...@cisco.com
length should be set to num_planes in __fill_v4l2_buffer(). That way the
caller knows how many planes there are in the buffer.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/videobuf2-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 5a132b2..432df11 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -348,6 +348,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
struct v4l2_buffer *b)
* Fill in plane-related data if userspace provided an array
* for it. The caller has already verified memory and size.
*/
+ b-length = vb-num_planes;
memcpy(b-m.planes, vb-v4l2_planes,
b-length * sizeof(struct v4l2_plane));
} else {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-mfc: Fix misplaced return statement in s5p_mfc_suspend()
On 09/28/2012 11:21 AM, Kamil Debski wrote: -Original Message- From: Sachin Kamat [mailto:sachin.ka...@linaro.org] Sent: 28 September 2012 09:02 To: linux-media@vger.kernel.org Cc: k.deb...@samsung.com; s.nawro...@samsung.com; sachin.ka...@linaro.org; patc...@linaro.org Subject: [PATCH] [media] s5p-mfc: Fix misplaced return statement in s5p_mfc_suspend() return statement was wrongly placed before a code that needs to be executed. Moved the return statement to the end of the function. Tested suspend/resume on SMDK4412 board using 3.5-rc6 kernel. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Acked-by: Kamil Debski k.deb...@samsung.com Applied, thank you. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] drivers/media: Remove unnecessary semicolon
A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@r1@
statement S;
position p,p1;
@@
S@p1;@p
@script:python r2@
p r1.p;
p1 r1.p1;
@@
if p[0].line != p1[0].line_end:
cocci.include_match(False)
@@
position r1.p;
@@
-;@p
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
Changes from v2:
Include semantic patch in the commit message.
The full version of the semantic patch can be found at:
http://comments.gmane.org/gmane.comp.version-control.coccinelle/2724
drivers/media/dvb-core/dvb_frontend.c | 2 +-
drivers/media/dvb-frontends/a8293.c | 2 +-
drivers/media/dvb-frontends/af9013.c | 6 +++---
drivers/media/dvb-frontends/bcm3510.c | 2 +-
drivers/media/dvb-frontends/cx24110.c | 6 +++---
drivers/media/dvb-frontends/drxd_hard.c | 2 +-
drivers/media/dvb-frontends/isl6405.c | 2 +-
drivers/media/dvb-frontends/isl6421.c | 2 +-
drivers/media/dvb-frontends/itd1000.c | 2 +-
drivers/media/dvb-frontends/lnbp21.c | 4 ++--
drivers/media/dvb-frontends/lnbp22.c | 2 +-
drivers/media/dvb-frontends/si21xx.c | 4 ++--
drivers/media/dvb-frontends/sp8870.c | 6 +++---
drivers/media/dvb-frontends/sp887x.c | 6 +++---
drivers/media/dvb-frontends/stv0299.c | 6 +++---
drivers/media/dvb-frontends/stv0900_core.c| 4 ++--
drivers/media/dvb-frontends/tda8083.c | 4 ++--
drivers/media/i2c/cx25840/cx25840-core.c | 2 +-
drivers/media/pci/bt8xx/dst_ca.c | 2 +-
drivers/media/pci/cx23885/altera-ci.c | 4 ++--
drivers/media/pci/cx23885/cimax2.c| 2 +-
drivers/media/pci/cx88/cx88-blackbird.c | 6 +++---
drivers/media/pci/cx88/cx88-dvb.c | 2 +-
drivers/media/pci/cx88/cx88-mpeg.c| 2 +-
drivers/media/pci/cx88/cx88-tvaudio.c | 4 ++--
drivers/media/pci/cx88/cx88-video.c | 2 +-
drivers/media/pci/saa7134/saa7134-video.c | 2 +-
drivers/media/platform/exynos-gsc/gsc-regs.c | 4 ++--
drivers/media/radio/si470x/radio-si470x-i2c.c | 2 +-
drivers/media/radio/si470x/radio-si470x-usb.c | 2 +-
drivers/media/radio/si4713-i2c.c | 12 ++--
drivers/media/usb/dvb-usb-v2/af9015.c | 4 ++--
drivers/media/usb/dvb-usb-v2/af9035.c | 2 +-
33 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 479a5e5..b5f141a 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -2288,7 +2288,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
fepriv-tune_mode_flags = (unsigned long) parg;
err = 0;
break;
- };
+ }
return err;
}
diff --git a/drivers/media/dvb-frontends/a8293.c
b/drivers/media/dvb-frontends/a8293.c
index cff44a3..74fbb5d 100644
--- a/drivers/media/dvb-frontends/a8293.c
+++ b/drivers/media/dvb-frontends/a8293.c
@@ -90,7 +90,7 @@ static int a8293_set_voltage(struct dvb_frontend *fe,
default:
ret = -EINVAL;
goto err;
- };
+ }
ret = a8293_wr(priv, priv-reg[0], 1);
if (ret)
diff --git a/drivers/media/dvb-frontends/af9013.c
b/drivers/media/dvb-frontends/af9013.c
index e9f04a3..a204f28 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -241,7 +241,7 @@ static int af9013_set_gpio(struct af9013_state *state, u8
gpio, u8 gpioval)
KBUILD_MODNAME, gpio);
ret = -EINVAL;
goto err;
- };
+ }
switch (gpio) {
case 0:
@@ -253,7 +253,7 @@ static int af9013_set_gpio(struct af9013_state *state, u8
gpio, u8 gpioval)
default:
pos = 4;
break;
- };
+ }
ret = af9013_wr_reg_bits(state, addr, pos, 4, gpioval);
if (ret)
@@ -726,7 +726,7 @@ static int af9013_set_frontend(struct dvb_frontend *fe)
default:
dev_dbg(state-i2c-dev, %s: invalid hierarchy\n, __func__);
auto_mode = 1;
- };
+ }
switch (c-modulation) {
case QAM_AUTO:
diff --git a/drivers/media/dvb-frontends/bcm3510.c
b/drivers/media/dvb-frontends/bcm3510.c
index 033cd7a..1b77909 100644
--- a/drivers/media/dvb-frontends/bcm3510.c
+++ b/drivers/media/dvb-frontends/bcm3510.c
@@ -527,7 +527,7 @@ static int bcm3510_set_frontend(struct dvb_frontend *fe)
cmd.ACQUIRE1.IF_FREQ = 0x0;
default:
return -EINVAL;
- };
+ }
cmd.ACQUIRE0.OFFSET = 0;
cmd.ACQUIRE0.NTSCSWEEP = 1;
cmd.ACQUIRE0.FA = 1;
diff --git a/drivers/media/dvb-frontends/cx24110.c
b/drivers/media/dvb-frontends/cx24110.c
[PATCH v7 0/6] Update MFC v4l2 driver to support MFC6.x
The patchset adds support for MFCv6 firmware in s5p-mfc driver. The patches are rebased to the latest media-tree. Changelog v7 - Removed unused macros from register files Changelog v6 - Use s5p_mfc_hw_call macro to call all HW related ops and cmds - Rebased onto latest media-tree - Resending patches adding required v4l controls - Addressed review comments of Patch v5 Changelog v5 - Modified ops mechanism for macro based function call - Addressed all other review comments on Patch v4 Changelog v4 - Separate patch for callback based architecture. - Patches divided to enable incremental compilation. - Working MFCv6 encoder and decoder. - Addressed review comments given for v3 patchset. Changelog v3 - Supports MFCv5 and v6 co-existence. - Tested for encoding decoding in MFCv5. - Supports only decoding in MFCv6 now. - Can be compiled with kernel image and as module. - Config macros for MFC version selection removed. - All previous review comments addressed. Changelog v2 - Addressed review comments received http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/45189 Changelog v1 - Fixed crash issue in Exynos4 SoCs running MFC 5.1 - Encoder not tested Arun Kumar K (4): [media] v4l: Add fourcc definitions for new formats [media] v4l: Add control definitions for new H264 encoder features [media] s5p-mfc: Update MFCv5 driver for callback based architecture [media] s5p-mfc: Add MFC variant data to device context Jeongtae Park (2): [media] s5p-mfc: MFCv6 register definitions [media] s5p-mfc: Update MFC v4l2 driver to support MFC6.x Documentation/DocBook/media/v4l/controls.xml | 268 +++- Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 +- Documentation/DocBook/media/v4l/pixfmt.xml | 10 + drivers/media/platform/Kconfig |4 +- drivers/media/platform/s5p-mfc/Makefile |7 +- drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 408 + drivers/media/platform/s5p-mfc/regs-mfc.h| 38 + drivers/media/platform/s5p-mfc/s5p_mfc.c | 296 +++-- drivers/media/platform/s5p-mfc/s5p_mfc_cmd.c | 109 +-- drivers/media/platform/s5p-mfc/s5p_mfc_cmd.h | 15 +- drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c | 166 ++ drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h | 20 + drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c | 156 ++ drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h | 20 + drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 191 ++- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c| 194 ++- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h|1 + drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 258 ++- drivers/media/platform/s5p-mfc/s5p_mfc_dec.h |1 + drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 239 ++-- drivers/media/platform/s5p-mfc/s5p_mfc_enc.h |1 + drivers/media/platform/s5p-mfc/s5p_mfc_intr.c| 11 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c | 1386 +--- drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 133 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 1763 +++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.h | 85 + drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 1956 ++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 50 + drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |3 +- drivers/media/platform/s5p-mfc/s5p_mfc_shm.c | 47 - drivers/media/platform/s5p-mfc/s5p_mfc_shm.h | 90 - drivers/media/v4l2-core/v4l2-ctrls.c | 42 + include/linux/v4l2-controls.h| 41 + include/linux/videodev2.h|4 + 34 files changed, 5937 insertions(+), 2093 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.h create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h delete mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_shm.c delete mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_shm.h -- 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 v7 1/6] [media] v4l: Add fourcc definitions for new formats
Adds the following new fourcc definitions.
For multiplanar YCbCr
- V4L2_PIX_FMT_NV21M
- V4L2_PIX_FMT_NV12MT_16X16
and compressed formats
- V4L2_PIX_FMT_H264_MVC
- V4L2_PIX_FMT_VP8
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 -
Documentation/DocBook/media/v4l/pixfmt.xml | 10 ++
include/linux/videodev2.h|4
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
index 5274c24..a990b34 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
@@ -1,11 +1,13 @@
-refentry id=V4L2-PIX-FMT-NV12M
+refentry
refmeta
- refentrytitleV4L2_PIX_FMT_NV12M ('NM12')/refentrytitle
+ refentrytitleV4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M
('NM21'), V4L2_PIX_FMT_NV12MT_16X16/refentrytitle
manvol;
/refmeta
refnamediv
- refname constantV4L2_PIX_FMT_NV12M/constant/refname
- refpurposeVariation of constantV4L2_PIX_FMT_NV12/constant with
planes
+ refname
id=V4L2-PIX-FMT-NV12MconstantV4L2_PIX_FMT_NV12M/constant/refname
+ refname
id=V4L2-PIX-FMT-NV21MconstantV4L2_PIX_FMT_NV21M/constant/refname
+ refname
id=V4L2-PIX-FMT-NV12MT_16X16constantV4L2_PIX_FMT_NV12MT_16X16/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV12/constant and
constantV4L2_PIX_FMT_NV21/constant with planes
non contiguous in memory. /refpurpose
/refnamediv
refsect1
@@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane
(and of the image),
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For
example,
Cbsubscript0/subscript/Crsubscript0/subscript belongs to
Y'subscript00/subscript, Y'subscript01/subscript,
-Y'subscript10/subscript, Y'subscript11/subscript. /para
+Y'subscript10/subscript, Y'subscript11/subscript.
+constantV4L2_PIX_FMT_NV12MT_16X16/constant is the tiled version of
+constantV4L2_PIX_FMT_NV12M/constant with 16x16 macroblock tiles. Here
pixels
+are arranged in 16x16 2D tiles and tiles are arranged in linear order in
memory.
+constantV4L2_PIX_FMT_NV21M/constant is the same as
constantV4L2_PIX_FMT_NV12M/constant
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte./para
paraconstantV4L2_PIX_FMT_NV12M/constant is intended to be
used only in drivers and applications that support the multi-planar API,
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 1ddbfab..6ca0be4 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -758,6 +758,11 @@ extended control
constantV4L2_CID_MPEG_STREAM_TYPE/constant, see
entry'AVC1'/entry
entryH264 video elementary stream without start codes./entry
/row
+ row id=V4L2-PIX-FMT-H264-MVC
+ entryconstantV4L2_PIX_FMT_H264_MVC/constant/entry
+ entry'MVC'/entry
+ entryH264 MVC video elementary stream./entry
+ /row
row id=V4L2-PIX-FMT-H263
entryconstantV4L2_PIX_FMT_H263/constant/entry
entry'H263'/entry
@@ -793,6 +798,11 @@ extended control
constantV4L2_CID_MPEG_STREAM_TYPE/constant, see
entry'VC1L'/entry
entryVC1, SMPTE 421M Annex L compliant stream./entry
/row
+ row id=V4L2-PIX-FMT-VP8
+ entryconstantV4L2_PIX_FMT_VP8/constant/entry
+ entry'VP8'/entry
+ entryVP8 video elementary stream./entry
+ /row
/tbody
/tgroup
/table
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 61395ef..16e6ab0 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -366,7 +366,9 @@ struct v4l2_pix_format {
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 */
+#define V4L2_PIX_FMT_NV21M v4l2_fourcc('N', 'M', '2', '1') /* 21 Y/CrCb
4:2:0 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 64x32 macroblocks */
+#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
/* three non contiguous planes - Y, Cb, Cr */
#define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12 YUV420
planar */
@@ -403,6 +405,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
Multiplexed */
#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with
[PATCH v7 2/6] [media] v4l: Add control definitions for new H264 encoder features
New controls are added for supporting H264 encoding features like - MVC frame packing - Flexible macroblock ordering - Arbitrary slice ordering - Hierarchial coding Signed-off-by: Jeongtae Park jtp.p...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com --- Documentation/DocBook/media/v4l/controls.xml | 268 +- drivers/media/v4l2-core/v4l2-ctrls.c | 42 include/linux/v4l2-controls.h| 41 3 files changed, 350 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 272a5f7..ce2cfd3 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed (decoded). This value is the decoder is started./entry /row - rowentry/entry/row row entry spanname=idconstantV4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE/constantnbsp;/entry @@ -2270,6 +2269,14 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders./entry /row rowentry/entry/row + row id=v4l2-mpeg-video-vbv-delay + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_VBV_DELAY/constantnbsp;/entry + entryinteger/entry + /rowrowentry spanname=descrSets the initial delay in milliseconds for +VBV buffer control./entry + /row + + rowentry/entry/row row entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_CPB_SIZE/constantnbsp;/entry entryinteger/entry @@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder./entry /rowrowentry spanname=descrvop_time_increment value for MPEG4. Applicable to the MPEG4 encoder./entry /row + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnable generation of frame packing supplemental enhancement information in the encoded bitstream. +The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrSets current frame as frame0 in frame packing SEI. +Applicable to the H264 encoder./entry + /row + + rowentry/entry/row + row id=v4l2-mpeg-video-h264-sei-fp-arrangement-type + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE/constantnbsp;/entry + entryenumnbsp;v4l2_mpeg_video_h264_sei_fp_arrangement_type/entry + /row + rowentry spanname=descrFrame packing arrangement type for H264 SEI. +Applicable to the H264 encoder. +Possible values are:/entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + row + entryconstantV4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD/constantnbsp;/entry + entryPixels are alternatively from L and R./entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN/constantnbsp;/entry + entryL and R are interlaced by column./entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW/constantnbsp;/entry + entryL and R are interlaced by row./entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE/constantnbsp;/entry + entryL is on the left, R on the right./entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM/constantnbsp;/entry + entryL is on top, R on bottom./entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL/constantnbsp;/entry + entryOne view per frame./entry + /row + /tbody + /entrytbl + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_FMO/constantnbsp;/entry + entryboolean/entry + /row +
[PATCH v7 4/6] [media] s5p-mfc: Add MFC variant data to device context
MFC variant data replaces various macros used in the driver
which will change in a different version of MFC hardware.
Also does a cleanup of MFC context structure and common files.
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Signed-off-by: Janghyuck Kim janghyuck@samsung.com
Signed-off-by: Jaeryul Oh jaeryul...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/regs-mfc.h | 17 ++
drivers/media/platform/s5p-mfc/s5p_mfc.c| 78 +
drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c |4 +-
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 85 ++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |7 +-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 44 +
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 213 +++
7 files changed, 263 insertions(+), 185 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc.h
b/drivers/media/platform/s5p-mfc/regs-mfc.h
index a19bece..3e2fce0 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc.h
@@ -414,5 +414,22 @@
#define S5P_FIMV_SHARED_EXTENDED_SAR 0x0078
#define S5P_FIMV_SHARED_H264_I_PERIOD 0x009C
#define S5P_FIMV_SHARED_RC_CONTROL_CONFIG 0x00A0
+#define S5P_FIMV_SHARED_DISP_FRAME_TYPE_SHIFT 2
+
+/* Offset used by the hardware to store addresses */
+#define MFC_OFFSET_SHIFT 11
+
+#define FIRMWARE_ALIGN 0x2 /* 128KB */
+#define MFC_H264_CTX_BUF_SIZE 0x96000 /* 600KB per H264 instance */
+#define MFC_CTX_BUF_SIZE 0x2800 /* 10KB per instance */
+#define DESC_BUF_SIZE 0x2 /* 128KB for DESC buffer */
+#define SHARED_BUF_SIZE0x2000 /* 8KB for shared
buffer */
+
+#define DEF_CPB_SIZE 0x4 /* 512KB */
+#define MAX_CPB_SIZE 0x40/* 4MB */
+#define MAX_FW_SIZE0x6
+
+#define MFC_VERSION0x51
+#define MFC_NUM_PORTS 2
#endif /* _REGS_FIMV_H */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3319410..a8299ce 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -436,7 +436,6 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx *ctx,
unsigned int reason, unsigned int err)
{
struct s5p_mfc_dev *dev;
- unsigned int guard_width, guard_height;
if (ctx == NULL)
return;
@@ -450,40 +449,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx
*ctx,
ctx-img_height = s5p_mfc_hw_call(dev-mfc_ops, get_img_height,
dev);
- ctx-buf_width = ALIGN(ctx-img_width,
- S5P_FIMV_NV12MT_HALIGN);
- ctx-buf_height = ALIGN(ctx-img_height,
- S5P_FIMV_NV12MT_VALIGN);
- mfc_debug(2, SEQ Done: Movie dimensions %dx%d,
- buffer dimensions: %dx%d\n, ctx-img_width,
- ctx-img_height, ctx-buf_width,
- ctx-buf_height);
- if (ctx-codec_mode == S5P_FIMV_CODEC_H264_DEC) {
- ctx-luma_size = ALIGN(ctx-buf_width *
- ctx-buf_height, S5P_FIMV_DEC_BUF_ALIGN);
- ctx-chroma_size = ALIGN(ctx-buf_width *
-ALIGN((ctx-img_height 1),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- ctx-mv_size = ALIGN(ctx-buf_width *
- ALIGN((ctx-buf_height 2),
- S5P_FIMV_NV12MT_VALIGN),
- S5P_FIMV_DEC_BUF_ALIGN);
- } else {
- guard_width = ALIGN(ctx-img_width + 24,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN(ctx-img_height + 16,
- S5P_FIMV_NV12MT_VALIGN);
- ctx-luma_size = ALIGN(guard_width *
- guard_height, S5P_FIMV_DEC_BUF_ALIGN);
- guard_width = ALIGN(ctx-img_width + 16,
- S5P_FIMV_NV12MT_HALIGN);
- guard_height = ALIGN((ctx-img_height 1) + 4,
- S5P_FIMV_NV12MT_VALIGN);
- ctx-chroma_size = ALIGN(guard_width *
- guard_height, S5P_FIMV_DEC_BUF_ALIGN);
- ctx-mv_size = 0;
- }
[PATCH v7 5/6] [media] s5p-mfc: MFCv6 register definitions
From: Jeongtae Park jtp.p...@samsung.com Adds register definitions for MFC v6.x firmware Signed-off-by: Jeongtae Park jtp.p...@samsung.com Signed-off-by: Janghyuck Kim janghyuck@samsung.com Signed-off-by: Jaeryul Oh jaeryul...@samsung.com Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 408 ++ 1 files changed, 408 insertions(+), 0 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v6.h diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h new file mode 100644 index 000..cce1841 --- /dev/null +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h @@ -0,0 +1,408 @@ +/* + * Register definition file for Samsung MFC V6.x Interface (FIMV) driver + * + * Copyright (c) 2012 Samsung Electronics + * http://www.samsung.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef _REGS_FIMV_V6_H +#define _REGS_FIMV_V6_H + +#define S5P_FIMV_REG_SIZE_V6 (S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) +#define S5P_FIMV_REG_COUNT_V6 ((S5P_FIMV_END_ADDR - S5P_FIMV_START_ADDR) / 4) + +/* Number of bits that the buffer address should be shifted for particular + * MFC buffers. */ +#define S5P_FIMV_MEM_OFFSET_V6 0 + +#define S5P_FIMV_START_ADDR_V6 0x +#define S5P_FIMV_END_ADDR_V6 0xfd80 + +#define S5P_FIMV_REG_CLEAR_BEGIN_V60xf000 +#define S5P_FIMV_REG_CLEAR_COUNT_V61024 + +/* Codec Common Registers */ +#define S5P_FIMV_RISC_ON_V60x +#define S5P_FIMV_RISC2HOST_INT_V6 0x003C +#define S5P_FIMV_HOST2RISC_INT_V6 0x0044 +#define S5P_FIMV_RISC_BASE_ADDRESS_V6 0x0054 + +#define S5P_FIMV_MFC_RESET_V6 0x1070 + +#define S5P_FIMV_HOST2RISC_CMD_V6 0x1100 +#define S5P_FIMV_H2R_CMD_EMPTY_V6 0 +#define S5P_FIMV_H2R_CMD_SYS_INIT_V6 1 +#define S5P_FIMV_H2R_CMD_OPEN_INSTANCE_V6 2 +#define S5P_FIMV_CH_SEQ_HEADER_V6 3 +#define S5P_FIMV_CH_INIT_BUFS_V6 4 +#define S5P_FIMV_CH_FRAME_START_V6 5 +#define S5P_FIMV_H2R_CMD_CLOSE_INSTANCE_V6 6 +#define S5P_FIMV_H2R_CMD_SLEEP_V6 7 +#define S5P_FIMV_H2R_CMD_WAKEUP_V6 8 +#define S5P_FIMV_CH_LAST_FRAME_V6 9 +#define S5P_FIMV_H2R_CMD_FLUSH_V6 10 +/* RMVME: REALLOC used? */ +#define S5P_FIMV_CH_FRAME_START_REALLOC_V6 5 + +#define S5P_FIMV_RISC2HOST_CMD_V6 0x1104 +#define S5P_FIMV_R2H_CMD_EMPTY_V6 0 +#define S5P_FIMV_R2H_CMD_SYS_INIT_RET_V6 1 +#define S5P_FIMV_R2H_CMD_OPEN_INSTANCE_RET_V6 2 +#define S5P_FIMV_R2H_CMD_SEQ_DONE_RET_V6 3 +#define S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET_V6 4 + +#define S5P_FIMV_R2H_CMD_CLOSE_INSTANCE_RET_V6 6 +#define S5P_FIMV_R2H_CMD_SLEEP_RET_V6 7 +#define S5P_FIMV_R2H_CMD_WAKEUP_RET_V6 8 +#define S5P_FIMV_R2H_CMD_COMPLETE_SEQ_RET_V6 9 +#define S5P_FIMV_R2H_CMD_DPB_FLUSH_RET_V6 10 +#define S5P_FIMV_R2H_CMD_NAL_ABORT_RET_V6 11 +#define S5P_FIMV_R2H_CMD_FW_STATUS_RET_V6 12 +#define S5P_FIMV_R2H_CMD_FRAME_DONE_RET_V6 13 +#define S5P_FIMV_R2H_CMD_FIELD_DONE_RET_V6 14 +#define S5P_FIMV_R2H_CMD_SLICE_DONE_RET_V6 15 +#define S5P_FIMV_R2H_CMD_ENC_BUFFER_FUL_RET_V6 16 +#define S5P_FIMV_R2H_CMD_ERR_RET_V632 + +#define S5P_FIMV_FW_VERSION_V6 0xF000 + +#define S5P_FIMV_INSTANCE_ID_V60xF008 +#define S5P_FIMV_CODEC_TYPE_V6 0xF00C +#define S5P_FIMV_CONTEXT_MEM_ADDR_V6 0xF014 +#define S5P_FIMV_CONTEXT_MEM_SIZE_V6 0xF018 +#define S5P_FIMV_PIXEL_FORMAT_V6 0xF020 + +#define S5P_FIMV_METADATA_ENABLE_V60xF024 +#define S5P_FIMV_DBG_BUFFER_ADDR_V60xF030 +#define S5P_FIMV_DBG_BUFFER_SIZE_V60xF034 +#define S5P_FIMV_RET_INSTANCE_ID_V60xF070 + +#define S5P_FIMV_ERROR_CODE_V6 0xF074 +#define S5P_FIMV_ERR_WARNINGS_START_V6 160 +#define S5P_FIMV_ERR_DEC_MASK_V6 0x +#define S5P_FIMV_ERR_DEC_SHIFT_V6 0 +#define S5P_FIMV_ERR_DSPL_MASK_V6 0x +#define S5P_FIMV_ERR_DSPL_SHIFT_V6 16 + +#define S5P_FIMV_DBG_BUFFER_OUTPUT_SIZE_V6 0xF078 +#define S5P_FIMV_METADATA_STATUS_V60xF07C +#define S5P_FIMV_METADATA_ADDR_MB_INFO_V6 0xF080 +#define S5P_FIMV_METADATA_SIZE_MB_INFO_V6 0xF084 + +/* Decoder Registers */ +#define S5P_FIMV_D_CRC_CTRL_V6 0xF0B0 +#define S5P_FIMV_D_DEC_OPTIONS_V6 0xF0B4 +#define S5P_FIMV_D_OPT_FMO_ASO_CTRL_MASK_V64 +#define S5P_FIMV_D_OPT_DDELAY_EN_SHIFT_V6 3 +#define S5P_FIMV_D_OPT_LF_CTRL_SHIFT_V6
Re: [GIT PULL FOR v3.7] all the rest patches!
PULL request updated, contains now 3 fc2580 driver fixes from Gianluca Gennari. Could you handle these quickly :) The following changes since commit 8928b6d1568eb9104cc9e2e6627d7086437b2fb3: [media] media: mx2_camera: use managed functions to clean up code (2012-09-27 15:56:47 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for_v3.7_mauro-3 for you to fetch changes up to 5c3cc06e4922d2d6a050948181a8601281227c66: fc2580: use macro for 64 bit division and reminder (2012-09-28 13:18:56 +0300) Antti Palosaari (4): em28xx: implement FE set_lna() callback cxd2820r: use static GPIO config when GPIOLIB is undefined em28xx: do not set PCTV 290e LNA handler if fe attach fail em28xx: PCTV 520e workaround for DRX-K fw loading Gianluca Gennari (3): fc2580: define const as UL to silence a warning fc2580: silence uninitialized variable warning fc2580: use macro for 64 bit division and reminder drivers/media/dvb-frontends/cxd2820r_core.c | 29 - drivers/media/tuners/fc2580.c | 7 +++ drivers/media/usb/em28xx/em28xx-dvb.c | 61 ++--- 3 files changed, 73 insertions(+), 24 deletions(-) On 09/28/2012 01:15 AM, Antti Palosaari wrote: Mauro, New attempt. I really want that PCTV 520e workaround for DRX-K fw loading in too or find out other fix quickly. I have answered too many bug reports according to it currently. Will take debugs now... regards Antti The following changes since commit 8928b6d1568eb9104cc9e2e6627d7086437b2fb3: [media] media: mx2_camera: use managed functions to clean up code (2012-09-27 15:56:47 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for_v3.7_mauro-2 for you to fetch changes up to 2baf1e9dd547402b8a5748e66f894af9c6a2789a: em28xx: PCTV 520e workaround for DRX-K fw loading (2012-09-28 01:06:38 +0300) Antti Palosaari (4): em28xx: implement FE set_lna() callback cxd2820r: use static GPIO config when GPIOLIB is undefined em28xx: do not set PCTV 290e LNA handler if fe attach fail em28xx: PCTV 520e workaround for DRX-K fw loading drivers/media/dvb-frontends/cxd2820r_core.c | 29 - drivers/media/usb/em28xx/em28xx-dvb.c | 61 ++--- 2 files changed, 70 insertions(+), 20 deletions(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] ov7670: migrate this sensor and its users to ctrl framework.
The following series migrate ov7670 sensor and current users to ctrl framework as discussed in [1]. This has been tested against mx2_camera soc-camera bridge, so tests or acks will be required from people using cam-core and via-camera out there. This will have to be applied on top of my previous series: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. All submitted patches have been obtained from Hans' tree and slightly modified to apply on current media_tree for-v3.7 branch: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl Changes since v1: - A 4th patch has been added as requested by Hans. - See changelog in patch 1. [PATCH v2 1/4] ov7670: use the control framework [PATCH v2 2/4] mcam-core: implement the control framework. [PATCH v2 3/4] via-camera: implement the control framework. [PATCH v2 4/4] ov7670: remove legacy ctrl callbacks. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.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
[PATCH v2 1/4] ov7670: use the control framework
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Use v4l2_ctrl_auto_cluster() for auto_gain and auto_exp.
---
drivers/media/i2c/ov7670.c | 310
1 file changed, 112 insertions(+), 198 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..babd55c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd,
int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value = ov7670_sm_to_abs(v);
- return ret;
-}
-
static int
[PATCH v2 2/4] mcam-core: implement the control framework.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 54 ---
drivers/media/platform/marvell-ccic/mcam-core.h |2 +
2 files changed, 11 insertions(+), 45 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void
*priv,
return ret;
}
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff = mcam_vidioc_streamoff,
- .vidioc_queryctrl = mcam_vidioc_queryctrl,
- .vidioc_g_ctrl = mcam_vidioc_g_ctrl,
- .vidioc_s_ctrl = mcam_vidioc_s_ctrl,
.vidioc_g_parm = mcam_vidioc_g_parm,
.vidioc_s_parm = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
* Get the v4l2 setup done.
*/
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
+
mutex_lock(cam-s_mutex);
cam-vdev = mcam_v4l_template;
cam-vdev.debug = 0;
cam-vdev.v4l2_dev = cam-v4l2_dev;
+ video_set_drvdata(cam-vdev, cam);
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
- video_set_drvdata(cam-vdev, cam);
/*
* If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
out:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
mutex_unlock(cam-s_mutex);
return ret;
out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam-buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(cam-vdev);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
v4l2_device_unregister(cam-v4l2_dev);
}
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
#include linux/list.h
#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
#include media/videobuf2-core.h
@@ -104,6 +105,7 @@ struct mcam_camera {
* should not be touched by the platform code.
*/
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users; /* How many open FDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] via-camera: implement the control framework.
And added a missing kfree to clean up the via_camera struct.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/via-camera.c | 60 ---
1 file changed, 14 insertions(+), 46 deletions(-)
diff --git a/drivers/media/platform/via-camera.c
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/ov7670.h
#include media/videobuf-dma-sg.h
#include linux/delay.h
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
struct via_camera {
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void
*priv,
}
/*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-/*
* Only one input.
*/
static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp,
void *priv,
static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
- .vidioc_queryctrl = viacam_queryctrl,
- .vidioc_g_ctrl = viacam_g_ctrl,
- .vidioc_s_ctrl = viacam_s_ctrl,
.vidioc_enum_input = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
ret = v4l2_device_register(pdev-dev, cam-v4l2_dev);
if (ret) {
dev_err(pdev-dev, Unable to register v4l2 device\n);
- return ret;
+ goto out_free;
}
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
/*
* Convince the system that we can do DMA.
*/
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
*/
ret = via_sensor_power_setup(cam);
if (ret)
- goto out_unregister;
+ goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev-pdev-irq, cam);
out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
out_unregister:
v4l2_device_unregister(cam-v4l2_dev);
+out_free:
+ kfree(cam);
return ret;
}
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device
*pdev)
v4l2_device_unregister(cam-v4l2_dev);
free_irq(viadev-pdev-irq, cam);
via_sensor_power_release(cam);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
+ kfree(cam);
via_cam_info = NULL;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ov7670: remove legacy ctrl callbacks.
via-camera and mcam-core were the only bridge drivers that used ov7670.
Since now they have been moved to use the ctrl framework, the old
legacy callbacks in the ov7670 can be removed.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index babd55c..113a4f3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1504,13 +1504,6 @@ static int ov7670_s_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *r
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
- .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
- .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
- .queryctrl = v4l2_subdev_queryctrl,
- .querymenu = v4l2_subdev_querymenu,
.reset = ov7670_reset,
.init = ov7670_init,
#ifdef CONFIG_VIDEO_ADV_DEBUG
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/14] OF: define of_*_cmp() macros also if CONFIG_OF isn't set
of_*_cmp() macros do not depend on any OF functions and can be defined also
if CONFIG_OF isn't set. Also include linux/string.h, required by those
macros.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
These definitions are also required for # CONFIG_OF is not set builds.
include/linux/of.h | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 3636fae..ad2e79b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -85,6 +85,14 @@ static inline struct device_node *of_node_get(struct
device_node *node)
static inline void of_node_put(struct device_node *node) { }
#endif /* !CONFIG_OF_DYNAMIC */
+/* Default string compare functions, Allow arch asm/prom.h to override */
+#if !defined(of_compat_cmp)
+#include linux/string.h
+#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
+#define of_prop_cmp(s1, s2)strcmp((s1), (s2))
+#define of_node_cmp(s1, s2)strcasecmp((s1), (s2))
+#endif
+
#ifdef CONFIG_OF
/* Pointer for first entry in chain of all nodes. */
@@ -143,13 +151,6 @@ static inline unsigned long of_read_ulong(const __be32
*cell, int size)
#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
#endif
-/* Default string compare functions, Allow arch asm/prom.h to override */
-#if !defined(of_compat_cmp)
-#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
-#define of_prop_cmp(s1, s2)strcmp((s1), (s2))
-#define of_node_cmp(s1, s2)strcasecmp((s1), (s2))
-#endif
-
/* flag descriptions */
#define OF_DYNAMIC 1 /* node and properties were allocated via kmalloc */
#define OF_DETACHED2 /* node has been detached from the device tree */
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ov7670: use the control framework
On Fri September 28 2012 12:50:55 Javier Martin wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Use v4l2_ctrl_auto_cluster() for auto_gain and auto_exp.
---
drivers/media/i2c/ov7670.c | 310
1 file changed, 112 insertions(+), 198 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..babd55c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev
*sd, int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value =
[GIT PULL FOR v3.7] Two control framework enhancements
This pull request adds two new features to the control framework: - a notify function that is needed to have a bridge driver be notified of subdevice control changes - a new filter function to have more control over which controls are added by v4l2_ctrl_add_handler. Both of these features are used by upcoming driver conversions (bttv, em28xx, others). Although Laurent had some comments I disagreed with them (see: http://www.mail-archive.com/linux-media@vger.kernel.org/msg52708.html). Laurent is OK with that. This pull request is identical to my previous pull request, except for being rebased to the latest v3.7 code. Regards, Hans The following changes since commit 8928b6d1568eb9104cc9e2e6627d7086437b2fb3: [media] media: mx2_camera: use managed functions to clean up code (2012-09-27 15:56:47 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git ctrlfw for you to fetch changes up to 9983a1138bc7bed3dae801db430478effcc997c6: v4l2-ctrls: add a filter function to v4l2_ctrl_add_handler. (2012-09-28 13:05:34 +0200) Hans Verkuil (2): v4l2-ctrls: add a notify callback. v4l2-ctrls: add a filter function to v4l2_ctrl_add_handler. Documentation/video4linux/v4l2-controls.txt| 28 +++- drivers/media/pci/cx88/cx88-blackbird.c|2 +- drivers/media/pci/cx88/cx88-video.c|2 +- drivers/media/platform/s5p-fimc/fimc-capture.c |2 +- drivers/media/platform/soc_camera/soc_camera.c |2 +- drivers/media/v4l2-core/v4l2-ctrls.c | 50 +- drivers/media/v4l2-core/v4l2-device.c |2 +- include/media/v4l2-ctrls.h | 43 +-- 8 files changed, 114 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ov7670: use the control framework
Hi Hans,
On 28 September 2012 13:05, Hans Verkuil hverk...@xs4all.nl wrote:
On Fri September 28 2012 12:50:55 Javier Martin wrote:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Use v4l2_ctrl_auto_cluster() for auto_gain and auto_exp.
---
drivers/media/i2c/ov7670.c | 310
1 file changed, 112 insertions(+), 198 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..babd55c 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev
*sd, int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret =
Re: [PATCH 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
Hi Anatolij
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
With mpc52xx_csi interface I2C subdev streamon after vb2_streamon()
doesn't work due to mpc52xx sensor interface glue-logic restrictions.
Since mpc5200 doesn't have a camera sensor interface, the sensor on
O2D cameras is connected to the LocalPlus bus by special glue-logic.
While sensor read-out the sensor will be clocked with the bus chip-
select signal as the sensor clock so that the read-out is synchronous
with the data accesses on the bus. Therefore, I2C access can't be
performed when the glue-logic is setup for sensor read-out.
mpc52xx_csi driver for O2D cameras performs I2C subdev streamon in
its start_streaming() operation and then disables the I2C bus access
by configuring the interface glue-logic for sensor read-out.
For above-mentioned reasons we disable this subdev call here.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/platform/soc_camera/soc_camera.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f6b1c1f..64e0abb 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -809,7 +809,7 @@ static int soc_camera_streamon(struct file *file, void
*priv,
{
struct soc_camera_device *icd = file-private_data;
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ struct v4l2_subdev __maybe_unused *sd = soc_camera_to_subdev(icd);
int ret;
WARN_ON(priv != file-private_data);
@@ -826,8 +826,11 @@ static int soc_camera_streamon(struct file *file, void
*priv,
else
ret = vb2_streamon(icd-vb2_vidq, i);
+#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \
+!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE)
No, we're not adding any preprocessor or run-time hardware dependencies to
soc-camera or to any other generic code. I have no idea what those IFM
O2D cameras are. If it's their common feature, that they cannot take any
further I2C commands, while streaming, their drivers have to do that
themselves. And not only for stream-on, there are many operations, that
are allowed during streaming.
Thanks
Guennadi
if (!ret)
v4l2_subdev_call(sd, video, s_stream, 1);
+#endif
return ret;
}
--
1.7.1
---
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
[RFCv2 PATCH] tuner-core: map audmode to STEREO for radio devices.
From: Hans Verkuil hans.verk...@cisco.com
Fixes a v4l2-compliance error: setting audmode to a value other than mono
or stereo for a radio device should map to MODE_STEREO.
The spec specifies that for radio devices only mono and stereo audmodes are
valid. If the user specifies another audmode in v4l2_tuner, then that should
be mapped to valid audmode. That didn't happen here.
Note that tuner drivers might decide to limit the possible audmode even
further if it only supports mono. In that case the tuner driver can set
audmode to mono. However, that new value wasn't copied back to t-audmode,
and that has been fixed as well in this patch.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/tuner-core.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index b5a819a..b5a8aac 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -1013,6 +1013,11 @@ static void set_radio_freq(struct i2c_client *c,
unsigned int freq)
t-standby = false;
analog_ops-set_params(t-fe, params);
+ /*
+* The tuner driver might decide to change the audmode if it only
+* supports stereo, so update t-audmode.
+*/
+ t-audmode = params.audmode;
}
/*
@@ -1235,8 +1240,18 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
if (set_mode(t, vt-type))
return 0;
- if (t-mode == V4L2_TUNER_RADIO)
+ if (t-mode == V4L2_TUNER_RADIO) {
t-audmode = vt-audmode;
+ /*
+* For radio audmode can only be mono or stereo. Map any
+* other values to stereo. The actual tuner driver that is
+* called in set_radio_freq can decide to limit the audmode to
+* mono if only mono is supported.
+*/
+ if (t-audmode != V4L2_TUNER_MODE_MONO
+ t-audmode != V4L2_TUNER_MODE_STEREO)
+ t-audmode = V4L2_TUNER_MODE_STEREO;
+ }
set_freq(t, 0);
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 PATCH] tuner-core: map audmode to STEREO for radio devices.
Changes since RFCv1: - Improved the commit text - Changed 'if (t-audmode V4L2_TUNER_MODE_STEREO)' as suggested by Mauro. - Update t-audmode after having called the tuner driver, allowing the tuner driver to modify audmode if it only supports mono. 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
[PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework.
The following series migrate ov7670 sensor and current users to ctrl framework as discussed in [1]. This has been tested against mx2_camera soc-camera bridge, so tests or acks will be required from people using cam-core and via-camera out there. This will have to be applied on top of my previous series: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. All submitted patches have been obtained from Hans' tree and slightly modified to apply on current media_tree for-v3.7 branch: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/cafe-ctrl Changes since v2: - See changelog in patch 1. [PATCH v3 1/4] ov7670: use the control framework [PATCH v3 2/4] mcam-core: implement the control framework. [PATCH v3 3/4] via-camera: implement the control framework. [PATCH v3 4/4] ov7670: remove legacy ctrl callbacks. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg51778.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
[PATCH v3 1/4] ov7670: use the control framework
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v2:
- Do not use 'cur.val' to get gain value.
---
drivers/media/i2c/ov7670.c | 310
1 file changed, 112 insertions(+), 198 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 9d7a92e..2f6470a 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -18,6 +18,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/v4l2-mediabus.h
#include media/ov7670.h
@@ -222,9 +223,23 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct v4l2_ctrl_handler hdl;
+ struct {
+ /* gain cluster */
+ struct v4l2_ctrl *auto_gain;
+ struct v4l2_ctrl *gain;
+ };
+ struct {
+ /* exposure cluster */
+ struct v4l2_ctrl *auto_exposure;
+ struct v4l2_ctrl *exposure;
+ };
+ struct {
+ /* saturation/hue cluster */
+ struct v4l2_ctrl *saturation;
+ struct v4l2_ctrl *hue;
+ };
struct ov7670_format_struct *fmt; /* Current format */
- unsigned char sat; /* Saturation value */
- int hue;/* Hue value */
int min_width; /* Filter out smaller sizes */
int min_height; /* Filter out smaller sizes */
int clock_speed;/* External clock speed (MHz) */
@@ -240,6 +255,11 @@ static inline struct ov7670_info *to_state(struct
v4l2_subdev *sd)
return container_of(sd, struct ov7670_info, sd);
}
+static inline struct v4l2_subdev *to_sd(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl-handler, struct ov7670_info, hdl)-sd;
+}
+
/*
@@ -1195,23 +1215,23 @@ static int ov7670_cosine(int theta)
static void ov7670_calc_cmatrix(struct ov7670_info *info,
- int matrix[CMATRIX_LEN])
+ int matrix[CMATRIX_LEN], int sat, int hue)
{
int i;
/*
* Apply the current saturation setting first.
*/
for (i = 0; i CMATRIX_LEN; i++)
- matrix[i] = (info-fmt-cmatrix[i]*info-sat) 7;
+ matrix[i] = (info-fmt-cmatrix[i] * sat) 7;
/*
* Then, if need be, rotate the hue value.
*/
- if (info-hue != 0) {
+ if (hue != 0) {
int sinth, costh, tmpmatrix[CMATRIX_LEN];
memcpy(tmpmatrix, matrix, CMATRIX_LEN*sizeof(int));
- sinth = ov7670_sine(info-hue);
- costh = ov7670_cosine(info-hue);
+ sinth = ov7670_sine(hue);
+ costh = ov7670_cosine(hue);
matrix[0] = (matrix[3]*sinth + matrix[0]*costh)/1000;
matrix[1] = (matrix[4]*sinth + matrix[1]*costh)/1000;
@@ -1224,60 +1244,21 @@ static void ov7670_calc_cmatrix(struct ov7670_info
*info,
-static int ov7670_s_sat(struct v4l2_subdev *sd, int value)
+static int ov7670_s_sat_hue(struct v4l2_subdev *sd, int sat, int hue)
{
struct ov7670_info *info = to_state(sd);
int matrix[CMATRIX_LEN];
int ret;
- info-sat = value;
- ov7670_calc_cmatrix(info, matrix);
+ ov7670_calc_cmatrix(info, matrix, sat, hue);
ret = ov7670_store_cmatrix(sd, matrix);
return ret;
}
-static int ov7670_g_sat(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-sat;
- return 0;
-}
-
-static int ov7670_s_hue(struct v4l2_subdev *sd, int value)
-{
- struct ov7670_info *info = to_state(sd);
- int matrix[CMATRIX_LEN];
- int ret;
-
- if (value -180 || value 180)
- return -EINVAL;
- info-hue = value;
- ov7670_calc_cmatrix(info, matrix);
- ret = ov7670_store_cmatrix(sd, matrix);
- return ret;
-}
-
-
-static int ov7670_g_hue(struct v4l2_subdev *sd, __s32 *value)
-{
- struct ov7670_info *info = to_state(sd);
-
- *value = info-hue;
- return 0;
-}
-
/*
* Some weird registers seem to store values in a sign/magnitude format!
*/
-static unsigned char ov7670_sm_to_abs(unsigned char v)
-{
- if ((v 0x80) == 0)
- return v + 128;
- return 128 - (v 0x7f);
-}
-
static unsigned char ov7670_abs_to_sm(unsigned char v)
{
@@ -1299,40 +1280,11 @@ static int ov7670_s_brightness(struct v4l2_subdev *sd,
int value)
return ret;
}
-static int ov7670_g_brightness(struct v4l2_subdev *sd, __s32 *value)
-{
- unsigned char v = 0;
- int ret = ov7670_read(sd, REG_BRIGHT, v);
-
- *value = ov7670_sm_to_abs(v);
- return ret;
-}
-
static int ov7670_s_contrast(struct
[PATCH v3 4/4] ov7670: remove legacy ctrl callbacks.
via-camera and mcam-core were the only bridge drivers that used ov7670.
Since now they have been moved to use the ctrl framework, the old
legacy callbacks in the ov7670 can be removed.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/i2c/ov7670.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 2f6470a..361b101 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1504,13 +1504,6 @@ static int ov7670_s_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *r
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
.g_chip_ident = ov7670_g_chip_ident,
- .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
- .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
- .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
- .queryctrl = v4l2_subdev_queryctrl,
- .querymenu = v4l2_subdev_querymenu,
.reset = ov7670_reset,
.init = ov7670_init,
#ifdef CONFIG_VIDEO_ADV_DEBUG
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] via-camera: implement the control framework.
And added a missing kfree to clean up the via_camera struct.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/via-camera.c | 60 ---
1 file changed, 14 insertions(+), 46 deletions(-)
diff --git a/drivers/media/platform/via-camera.c
b/drivers/media/platform/via-camera.c
index eb404c2..1b5f97d 100644
--- a/drivers/media/platform/via-camera.c
+++ b/drivers/media/platform/via-camera.c
@@ -18,6 +18,7 @@
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-chip-ident.h
+#include media/v4l2-ctrls.h
#include media/ov7670.h
#include media/videobuf-dma-sg.h
#include linux/delay.h
@@ -63,6 +64,7 @@ enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
struct via_camera {
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
struct video_device vdev;
struct v4l2_subdev *sensor;
struct platform_device *platdev;
@@ -818,47 +820,6 @@ static int viacam_g_chip_ident(struct file *file, void
*priv,
}
/*
- * Control ops are passed through to the sensor.
- */
-static int viacam_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-
-static int viacam_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct via_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-lock);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-lock);
- return ret;
-}
-
-/*
* Only one input.
*/
static int viacam_enum_input(struct file *filp, void *priv,
@@ -1214,9 +1175,6 @@ static int viacam_enum_frameintervals(struct file *filp,
void *priv,
static const struct v4l2_ioctl_ops viacam_ioctl_ops = {
.vidioc_g_chip_ident= viacam_g_chip_ident,
- .vidioc_queryctrl = viacam_queryctrl,
- .vidioc_g_ctrl = viacam_g_ctrl,
- .vidioc_s_ctrl = viacam_s_ctrl,
.vidioc_enum_input = viacam_enum_input,
.vidioc_g_input = viacam_g_input,
.vidioc_s_input = viacam_s_input,
@@ -1418,8 +1376,12 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
ret = v4l2_device_register(pdev-dev, cam-v4l2_dev);
if (ret) {
dev_err(pdev-dev, Unable to register v4l2 device\n);
- return ret;
+ goto out_free;
}
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
/*
* Convince the system that we can do DMA.
*/
@@ -1436,7 +1398,7 @@ static __devinit int viacam_probe(struct platform_device
*pdev)
*/
ret = via_sensor_power_setup(cam);
if (ret)
- goto out_unregister;
+ goto out_ctrl_hdl_free;
via_sensor_power_up(cam);
/*
@@ -1485,8 +1447,12 @@ out_irq:
free_irq(viadev-pdev-irq, cam);
out_power_down:
via_sensor_power_release(cam);
+out_ctrl_hdl_free:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
out_unregister:
v4l2_device_unregister(cam-v4l2_dev);
+out_free:
+ kfree(cam);
return ret;
}
@@ -1499,6 +1465,8 @@ static __devexit int viacam_remove(struct platform_device
*pdev)
v4l2_device_unregister(cam-v4l2_dev);
free_irq(viadev-pdev-irq, cam);
via_sensor_power_release(cam);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
+ kfree(cam);
via_cam_info = NULL;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] mcam-core: implement the control framework.
Reviewed-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 54 ---
drivers/media/platform/marvell-ccic/mcam-core.h |2 +
2 files changed, 11 insertions(+), 45 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..568f8a5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -22,6 +22,7 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
#include media/v4l2-chip-ident.h
#include media/ov7670.h
#include media/videobuf2-vmalloc.h
@@ -1232,47 +1233,6 @@ static int mcam_vidioc_dqbuf(struct file *filp, void
*priv,
return ret;
}
-
-
-static int mcam_vidioc_queryctrl(struct file *filp, void *priv,
- struct v4l2_queryctrl *qc)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, queryctrl, qc);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_g_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, g_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
-static int mcam_vidioc_s_ctrl(struct file *filp, void *priv,
- struct v4l2_control *ctrl)
-{
- struct mcam_camera *cam = priv;
- int ret;
-
- mutex_lock(cam-s_mutex);
- ret = sensor_call(cam, core, s_ctrl, ctrl);
- mutex_unlock(cam-s_mutex);
- return ret;
-}
-
-
static int mcam_vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
@@ -1520,9 +1480,6 @@ static const struct v4l2_ioctl_ops mcam_v4l_ioctl_ops = {
.vidioc_dqbuf = mcam_vidioc_dqbuf,
.vidioc_streamon= mcam_vidioc_streamon,
.vidioc_streamoff = mcam_vidioc_streamoff,
- .vidioc_queryctrl = mcam_vidioc_queryctrl,
- .vidioc_g_ctrl = mcam_vidioc_g_ctrl,
- .vidioc_s_ctrl = mcam_vidioc_s_ctrl,
.vidioc_g_parm = mcam_vidioc_g_parm,
.vidioc_s_parm = mcam_vidioc_s_parm,
.vidioc_enum_framesizes = mcam_vidioc_enum_framesizes,
@@ -1786,14 +1743,19 @@ int mccic_register(struct mcam_camera *cam)
/*
* Get the v4l2 setup done.
*/
+ ret = v4l2_ctrl_handler_init(cam-ctrl_handler, 10);
+ if (ret)
+ goto out_unregister;
+ cam-v4l2_dev.ctrl_handler = cam-ctrl_handler;
+
mutex_lock(cam-s_mutex);
cam-vdev = mcam_v4l_template;
cam-vdev.debug = 0;
cam-vdev.v4l2_dev = cam-v4l2_dev;
+ video_set_drvdata(cam-vdev, cam);
ret = video_register_device(cam-vdev, VFL_TYPE_GRABBER, -1);
if (ret)
goto out;
- video_set_drvdata(cam-vdev, cam);
/*
* If so requested, try to get our DMA buffers now.
@@ -1805,6 +1767,7 @@ int mccic_register(struct mcam_camera *cam)
}
out:
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
mutex_unlock(cam-s_mutex);
return ret;
out_unregister:
@@ -1829,6 +1792,7 @@ void mccic_shutdown(struct mcam_camera *cam)
if (cam-buffer_mode == B_vmalloc)
mcam_free_dma_bufs(cam);
video_unregister_device(cam-vdev);
+ v4l2_ctrl_handler_free(cam-ctrl_handler);
v4l2_device_unregister(cam-v4l2_dev);
}
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index bd6acba..f7c34ab 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -8,6 +8,7 @@
#include linux/list.h
#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
#include media/v4l2-dev.h
#include media/videobuf2-core.h
@@ -104,6 +105,7 @@ struct mcam_camera {
* should not be touched by the platform code.
*/
struct v4l2_device v4l2_dev;
+ struct v4l2_ctrl_handler ctrl_handler;
enum mcam_state state;
unsigned long flags;/* Buffer status, mainly (dev_lock) */
int users; /* How many open FDs */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tda18271 driver power consumption
Em Thu, 27 Sep 2012 17:58:24 -0400 Michael Krufky mkru...@linuxtv.org escreveu: On Thu, Sep 27, 2012 at 5:38 PM, Antti Palosaari cr...@iki.fi wrote: On 09/28/2012 12:20 AM, Michael Krufky wrote: Mike, There is other problem too. PCTV 520e, which is Em28xx + DRX-K + TDA18271, fails to attach tuner now. Tuner is wired behind DRX-K I2C bus. TDA18271 driver does very much I/O during attach and I2C error is raised during attach now. Earlier it worked as DRX-K firmware was downloaded before tuner was attached, but now both DRX-K fw download and tuner attach happens same time leading that error. Why is the DRX-K firmware downloading at the same time as tuner attach? Shouldn't the demod attach be finished before the tuner attach begins? Michael, What happens is that udev changes forced drivers to load firmware asynchronously, as, otherwise, udev won't load any firmware at all. Also, there's no warranty that the firmware will be loaded on 2 seconds or so (Anti's hack were to add a 2 seconds wait after drxk atttach, to wait for firmware load). What I suspect is that tda18271 init is being interruped in the middle, by the drxk firmware load. If this is the case, the solution is clean and quick: just use the new i2c_lock_adapter() way to lock the I2C bus to tda18271 during the critical part of the code where the register init happens. -- 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 v2 3/3] mt9v022: set y_skip_top field to zero as default
Hi Anatolij
I can take this patch, but we need an ack from a PXA / ARM maintainer.
Thanks
Guennadi
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
Set y_skip_top to zero and revise comment as I do not see this line
corruption on two different mt9v022 setups. The first read-out line
is perfectly fine. Add mt9v022 platform data configuring y_skip_top
for platforms that have issues with the first read-out line. Set
y_skip_top to 1 for pcm990 board.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first version:
- add platform data to mt9v022 with only one parameter to initialise
y_skip_top, use 0 as default and set it to 1 on pcm990-baseboard.c
- revise commit log
- rebase on staging/for_v3.7 branch
arch/arm/mach-pxa/pcm990-baseboard.c |6 ++
drivers/media/i2c/soc_camera/mt9v022.c |8 +---
include/media/mt9v022.h| 16
3 files changed, 27 insertions(+), 3 deletions(-)
create mode 100644 include/media/mt9v022.h
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index cb723e8..e2973f2 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -26,6 +26,7 @@
#include linux/i2c/pxa-i2c.h
#include linux/pwm_backlight.h
+#include media/mt9v022.h
#include media/soc_camera.h
#include mach/camera.h
@@ -468,6 +469,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
},
};
+static struct mt9v022_platform_data mt9v022_pdata = {
+ .y_skip_top = 1,
+};
+
static struct i2c_board_info pcm990_camera_i2c[] = {
{
I2C_BOARD_INFO(mt9v022, 0x48),
@@ -480,6 +485,7 @@ static struct soc_camera_link iclink[] = {
{
.bus_id = 0, /* Must match with the camera ID */
.board_info = pcm990_camera_i2c[0],
+ .priv = mt9v022_pdata,
.i2c_adapter_id = 0,
.query_bus_param= pcm990_camera_query_bus_param,
.set_bus_param = pcm990_camera_set_bus_param,
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index e0f4cb4..8feaddc 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -15,6 +15,7 @@
#include linux/log2.h
#include linux/module.h
+#include media/mt9v022.h
#include media/soc_camera.h
#include media/soc_mediabus.h
#include media/v4l2-subdev.h
@@ -849,6 +850,7 @@ static int mt9v022_probe(struct i2c_client *client,
struct mt9v022 *mt9v022;
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ struct mt9v022_platform_data *pdata = icl-priv;
int ret;
if (!icl) {
@@ -912,10 +914,10 @@ static int mt9v022_probe(struct i2c_client *client,
mt9v022-chip_control = MT9V022_CHIP_CONTROL_DEFAULT;
/*
- * MT9V022 _really_ corrupts the first read out line.
- * TODO: verify on i.MX31
+ * On some platforms the first read out line is corrupted.
+ * Workaround it by skipping if indicated by platform data.
*/
- mt9v022-y_skip_top = 1;
+ mt9v022-y_skip_top = pdata ? pdata-y_skip_top : 0;
mt9v022-rect.left = MT9V022_COLUMN_SKIP;
mt9v022-rect.top = MT9V022_ROW_SKIP;
mt9v022-rect.width = MT9V022_MAX_WIDTH;
diff --git a/include/media/mt9v022.h b/include/media/mt9v022.h
new file mode 100644
index 000..4056180
--- /dev/null
+++ b/include/media/mt9v022.h
@@ -0,0 +1,16 @@
+/*
+ * mt9v022 sensor
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __MT9V022_H__
+#define __MT9V022_H__
+
+struct mt9v022_platform_data {
+ unsigned short y_skip_top; /* Lines to skip at the top */
+};
+
+#endif
--
1.7.1
---
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: [PATCH v2 3/3] mt9v022: set y_skip_top field to zero as default
Hi Eric
On Fri, 28 Sep 2012, Guennadi Liakhovetski wrote:
Hi Anatolij
I can take this patch, but we need an ack from a PXA / ARM maintainer.
Could we have your ack, please?
Thanks
Guennadi
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
Set y_skip_top to zero and revise comment as I do not see this line
corruption on two different mt9v022 setups. The first read-out line
is perfectly fine. Add mt9v022 platform data configuring y_skip_top
for platforms that have issues with the first read-out line. Set
y_skip_top to 1 for pcm990 board.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first version:
- add platform data to mt9v022 with only one parameter to initialise
y_skip_top, use 0 as default and set it to 1 on pcm990-baseboard.c
- revise commit log
- rebase on staging/for_v3.7 branch
arch/arm/mach-pxa/pcm990-baseboard.c |6 ++
drivers/media/i2c/soc_camera/mt9v022.c |8 +---
include/media/mt9v022.h| 16
3 files changed, 27 insertions(+), 3 deletions(-)
create mode 100644 include/media/mt9v022.h
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index cb723e8..e2973f2 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -26,6 +26,7 @@
#include linux/i2c/pxa-i2c.h
#include linux/pwm_backlight.h
+#include media/mt9v022.h
#include media/soc_camera.h
#include mach/camera.h
@@ -468,6 +469,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
},
};
+static struct mt9v022_platform_data mt9v022_pdata = {
+ .y_skip_top = 1,
+};
+
static struct i2c_board_info pcm990_camera_i2c[] = {
{
I2C_BOARD_INFO(mt9v022, 0x48),
@@ -480,6 +485,7 @@ static struct soc_camera_link iclink[] = {
{
.bus_id = 0, /* Must match with the camera ID */
.board_info = pcm990_camera_i2c[0],
+ .priv = mt9v022_pdata,
.i2c_adapter_id = 0,
.query_bus_param= pcm990_camera_query_bus_param,
.set_bus_param = pcm990_camera_set_bus_param,
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index e0f4cb4..8feaddc 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -15,6 +15,7 @@
#include linux/log2.h
#include linux/module.h
+#include media/mt9v022.h
#include media/soc_camera.h
#include media/soc_mediabus.h
#include media/v4l2-subdev.h
@@ -849,6 +850,7 @@ static int mt9v022_probe(struct i2c_client *client,
struct mt9v022 *mt9v022;
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ struct mt9v022_platform_data *pdata = icl-priv;
int ret;
if (!icl) {
@@ -912,10 +914,10 @@ static int mt9v022_probe(struct i2c_client *client,
mt9v022-chip_control = MT9V022_CHIP_CONTROL_DEFAULT;
/*
-* MT9V022 _really_ corrupts the first read out line.
-* TODO: verify on i.MX31
+* On some platforms the first read out line is corrupted.
+* Workaround it by skipping if indicated by platform data.
*/
- mt9v022-y_skip_top = 1;
+ mt9v022-y_skip_top = pdata ? pdata-y_skip_top : 0;
mt9v022-rect.left = MT9V022_COLUMN_SKIP;
mt9v022-rect.top = MT9V022_ROW_SKIP;
mt9v022-rect.width = MT9V022_MAX_WIDTH;
diff --git a/include/media/mt9v022.h b/include/media/mt9v022.h
new file mode 100644
index 000..4056180
--- /dev/null
+++ b/include/media/mt9v022.h
@@ -0,0 +1,16 @@
+/*
+ * mt9v022 sensor
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __MT9V022_H__
+#define __MT9V022_H__
+
+struct mt9v022_platform_data {
+ unsigned short y_skip_top; /* Lines to skip at the top */
+};
+
+#endif
--
1.7.1
---
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: [PATCH] mt9v022: support required register settings in snapshot mode
Hi Anatolij
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
Some camera systems cannot operate mt9v022 in normal mode and use
only the snapshot mode. The TechNote for mt9v022 (TN0960) and mt9v024
(TN-09-225) describes required register settings when configuring the
snapshot operation. The snapshot mode requires that certain automatic
functions of the image sensor should be disabled or set to fixed values.
According to the TechNote bit 2 and bit 9 in the register 0x20 must be
set in snapshot mode and unset for normal operation. This applies for
mt9v022 Rev.3 and mt9v024. Add required reg. 0x20 settings dependent on
sensor chip version.
Signed-off-by: Anatolij Gustschin ag...@denx.de
I'm afraid, I don't understand again
---
drivers/media/i2c/soc_camera/mt9v022.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index 8feaddc..2abe999 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -51,6 +51,7 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_PIXEL_OPERATION_MODE 0x0f
#define MT9V022_LED_OUT_CONTROL 0x1b
#define MT9V022_ADC_MODE_CONTROL 0x1c
+#define MT9V022_REG320x20
#define MT9V022_ANALOG_GAIN 0x35
#define MT9V022_BLACK_LEVEL_CALIB_CTRL 0x47
#define MT9V022_PIXCLK_FV_LV 0x74
@@ -79,7 +80,8 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_VERTICAL_BLANKING_MAX3000
#define MT9V022_VERTICAL_BLANKING_DEF45
-#define is_mt9v024(id) (id == 0x1324)
+#define is_mt9v022_rev3(id) (id == 0x1313)
+#define is_mt9v024(id) (id == 0x1324)
/* MT9V022 has only one fixed colorspace per pixelcode */
struct mt9v022_datafmt {
@@ -153,6 +155,7 @@ struct mt9v022 {
int num_fmts;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
u16 chip_control;
+ u16 chip_version;
unsigned short y_skip_top; /* Lines to skip at the top */
};
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd, int
enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+ * Unset snapshot mode specific settings: clear bit 9
+ * and bit 2 in reg. 0x20 when in normal mode.
+ */
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+ * Required settings for snapshot mode: set bit 9
+ * (RST enable) and bit 2 (CR enable) in reg. 0x20
+ * See TechNote TN0960 or TN-09-225.
+ */
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you
unconditionally added using REG32 for leaving the snapshot mode on
streamon and entering it on streamoff. This should be ok in principle,
since that's also what we're trying to do, using the CHIP_CONTROL
register. But in your comment you say, that on some _systems_ you can only
_operate_ in snapshot mode. I.e. the snapshot mode enabled during running
streaming, right? Then how does this patch help you with that?
Thanks
Guennadi
if (reg_write(client, MT9V022_CHIP_CONTROL, mt9v022-chip_control) 0)
return -EIO;
@@ -652,6 +675,8 @@ static int mt9v022_video_probe(struct i2c_client *client)
goto ei2c;
}
+ mt9v022-chip_version = data;
+
mt9v022-reg = is_mt9v024(data) ? mt9v024_register :
mt9v022_register;
--
1.7.1
---
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: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API
Hi Antti,
Mauro asked me to look into LNA as well, in particular how this could be done
on the analog side as well.
While reading through this patch I noticed that the new property was added to
dtv_property_process_set, but not to dtv_property_process_get. Can you look
into that and add 'get' support for this property?
Thanks!
Hans
On Thu September 27 2012 19:28:09 Mauro Carvalho Chehab wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] add LNA support for DVB API
Author: Antti Palosaari cr...@iki.fi
Date:Wed Jul 11 21:54:50 2012 -0300
Signed-off-by: Antti Palosaari cr...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/dvb-core/dvb_frontend.c |5 +
drivers/media/dvb-core/dvb_frontend.h |1 +
include/linux/dvb/frontend.h |4 +++-
3 files changed, 9 insertions(+), 1 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=8a2697abc1f0388d44b78ac109d9f03ec75c2683
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 1f3b16d..8f58f24 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -1022,6 +1022,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1]
= {
_DTV_CMD(DTV_STREAM_ID, 1, 0),
_DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),
+ _DTV_CMD(DTV_LNA, 1, 0),
/* Get */
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1730,6 +1731,10 @@ static int dtv_property_process_set(struct
dvb_frontend *fe,
case DTV_INTERLEAVING:
c-interleaving = tvp-u.data;
break;
+ case DTV_LNA:
+ if (fe-ops.set_lna)
+ r = fe-ops.set_lna(fe, tvp-u.data);
+ break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 33996a0..44a445c 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -303,6 +303,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe,
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
+ int (*set_lna)(struct dvb_frontend *, int);
/* These callbacks are for devices that implement their own
* tuning algorithms, rather than a simple swzigzag
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 57e2b17..c12d452 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -363,8 +363,9 @@ struct dvb_frontend_event {
#define DTV_ATSCMH_SCCC_CODE_MODE_D 59
#define DTV_INTERLEAVING 60
+#define DTV_LNA 61
-#define DTV_MAX_COMMAND DTV_INTERLEAVING
+#define DTV_MAX_COMMAND DTV_LNA
typedef enum fe_pilot {
PILOT_ON,
@@ -438,6 +439,7 @@ enum atscmh_rs_code_mode {
};
#define NO_STREAM_ID_FILTER (~0U)
+#define LNA_AUTO(~0U)
struct dtv_cmds_h {
char*name; /* A display name for debugging purposes */
___
linuxtv-commits mailing list
linuxtv-comm...@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
--
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 1/2] dm644x: replace the obsolete preset API by the timings API.
Hi Kevin,
On Wed, Aug 8, 2012 at 6:00 PM, Prabhakar Lad prabhakar@ti.com wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++--
arch/arm/mach-davinci/dm644x.c | 17 +---
drivers/media/video/davinci/vpbe.c | 110
drivers/media/video/davinci/vpbe_display.c | 60 +++
drivers/media/video/davinci/vpbe_venc.c| 25 +++---
include/media/davinci/vpbe.h | 14 ++--
include/media/davinci/vpbe_types.h |8 +--
include/media/davinci/vpbe_venc.h |2 +-
8 files changed, 111 insertions(+), 140 deletions(-)
Can you ACK this patch? Since this patch needs to go from Mauro's tree
due to changes in media drivers folder structure.
Regards,
--Prabhakar Lad
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index d34ed55..3baf56d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -23,6 +23,7 @@
#include linux/phy.h
#include linux/clk.h
#include linux/videodev2.h
+#include linux/v4l2-dv-timings.h
#include linux/export.h
#include media/tvp514x.h
@@ -620,7 +621,7 @@ static struct vpbe_enc_mode_info
dm644xevm_enc_std_timing[] = {
{
.name = ntsc,
.timings_type = VPBE_ENC_STD,
- .timings= {V4L2_STD_525_60},
+ .std_id = V4L2_STD_525_60,
.interlaced = 1,
.xres = 720,
.yres = 480,
@@ -632,7 +633,7 @@ static struct vpbe_enc_mode_info
dm644xevm_enc_std_timing[] = {
{
.name = pal,
.timings_type = VPBE_ENC_STD,
- .timings= {V4L2_STD_625_50},
+ .std_id = V4L2_STD_625_50,
.interlaced = 1,
.xres = 720,
.yres = 576,
@@ -647,8 +648,8 @@ static struct vpbe_enc_mode_info
dm644xevm_enc_std_timing[] = {
static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = {
{
.name = 480p59_94,
- .timings_type = VPBE_ENC_DV_PRESET,
- .timings= {V4L2_DV_480P59_94},
+ .timings_type = VPBE_ENC_CUSTOM_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_720X480P59_94,
.interlaced = 0,
.xres = 720,
.yres = 480,
@@ -659,8 +660,8 @@ static struct vpbe_enc_mode_info
dm644xevm_enc_preset_timing[] = {
},
{
.name = 576p50,
- .timings_type = VPBE_ENC_DV_PRESET,
- .timings= {V4L2_DV_576P50},
+ .timings_type = VPBE_ENC_CUSTOM_TIMINGS,
+ .dv_timings = V4L2_DV_BT_CEA_720X576P50,
.interlaced = 0,
.xres = 720,
.yres = 576,
@@ -698,7 +699,7 @@ static struct vpbe_output dm644xevm_vpbe_outputs[] = {
.index = 1,
.name = Component,
.type = V4L2_OUTPUT_TYPE_ANALOG,
- .capabilities = V4L2_OUT_CAP_PRESETS,
+ .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
},
.subdev_name= VPBE_VENC_SUBDEV_NAME,
.default_mode = 480p59_94,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index c8b8666..79d2880 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -701,7 +701,7 @@ static struct resource dm644x_venc_resources[] = {
#define DM644X_VPSS_DACCLKEN BIT(4)
static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
- unsigned int mode)
+ unsigned int pclock)
{
int ret = 0;
u32 v = DM644X_VPSS_VENCLKEN;
@@ -711,27 +711,18 @@ static int dm644x_venc_setup_clock(enum
vpbe_enc_timings_type type,
v |= DM644X_VPSS_DACCLKEN;
writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
break;
- case VPBE_ENC_DV_PRESET:
- switch (mode) {
- case V4L2_DV_480P59_94:
- case V4L2_DV_576P50:
+ case VPBE_ENC_CUSTOM_TIMINGS:
+ if (pclock = 2700) {
v |= DM644X_VPSS_MUXSEL_PLL2_MODE |
DM644X_VPSS_DACCLKEN;
writel(v,
[PATCH 2/7] media: pxa_camera: fix const cropping related warnings
A recent commit [media] v4l2: make vidioc_s_crop const introduced
warnings in pxa_camera.c. Fix them by adjusting a function declaration.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/soc_camera/pxa_camera.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 9c21e01..329b477 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -1337,9 +1337,9 @@ static int pxa_camera_check_frame(u32 width, u32 height)
}
static int pxa_camera_set_crop(struct soc_camera_device *icd,
- struct v4l2_crop *a)
+ const struct v4l2_crop *a)
{
- struct v4l2_rect *rect = a-c;
+ const struct v4l2_rect *rect = a-c;
struct device *dev = icd-parent;
struct soc_camera_host *ici = to_soc_camera_host(dev);
struct pxa_camera_dev *pcdev = ici-priv;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] media: mx3_camera: fix const cropping related warnings
A recent commit [media] v4l2: make vidioc_s_crop const introduced
warnings in mx3_camera. Fix them by cleanly separating writable and
read-only variables in cropping operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/soc_camera/mx3_camera.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index 16975c6..968b6d7 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -799,9 +799,10 @@ static inline void stride_align(__u32 *width)
* default g_crop and cropcap from soc_camera.c
*/
static int mx3_camera_set_crop(struct soc_camera_device *icd,
- struct v4l2_crop *a)
+ const struct v4l2_crop *a)
{
- struct v4l2_rect *rect = a-c;
+ struct v4l2_crop a_writable = *a;
+ struct v4l2_rect *rect = a_writable.c;
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx3_camera_dev *mx3_cam = ici-priv;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] media: sh_vou: fix const cropping related warnings
A recent commit [media] v4l2: make vidioc_s_crop const introduced
warnings in sh_vou. Fix them by cleanly separating writable and
read-only variables in cropping operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/sh_vou.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 85fd312..a1c87f0 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -935,9 +935,10 @@ static int sh_vou_g_crop(struct file *file, void *fh,
struct v4l2_crop *a)
/* Assume a dull encoder, do all the work ourselves. */
static int sh_vou_s_crop(struct file *file, void *fh, const struct v4l2_crop
*a)
{
+ struct v4l2_crop a_writable = *a;
struct video_device *vdev = video_devdata(file);
struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
- struct v4l2_rect *rect = a-c;
+ struct v4l2_rect *rect = a_writable.c;
struct v4l2_crop sd_crop = {.type = V4L2_BUF_TYPE_VIDEO_OUTPUT};
struct v4l2_pix_format *pix = vou_dev-pix;
struct sh_vou_geometry geo;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] media: omap1_camera: fix const cropping related warnings
A recent commit [media] v4l2: make vidioc_s_crop const introduced
warnings in omap1_camera. Fix them by adjusting a function declaration.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/soc_camera/omap1_camera.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/omap1_camera.c
b/drivers/media/platform/soc_camera/omap1_camera.c
index fa08c76..13636a5 100644
--- a/drivers/media/platform/soc_camera/omap1_camera.c
+++ b/drivers/media/platform/soc_camera/omap1_camera.c
@@ -1215,9 +1215,9 @@ static int set_mbus_format(struct omap1_cam_dev *pcdev,
struct device *dev,
}
static int omap1_cam_set_crop(struct soc_camera_device *icd,
- struct v4l2_crop *crop)
+ const struct v4l2_crop *crop)
{
- struct v4l2_rect *rect = crop-c;
+ const struct v4l2_rect *rect = crop-c;
const struct soc_camera_format_xlate *xlate = icd-current_fmt;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct device *dev = icd-parent;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] soc-camera and sh_vou cropping constification fixes
These patches fix warnings, added by the recent commit commit 4f996594ceaf6c3f9bc42b40c40b0f7f87b79c86 Author: Hans Verkuil hans.verk...@cisco.com Date: Wed Sep 5 05:10:48 2012 -0300 [media] v4l2: make vidioc_s_crop const If there are no objections, I'll include them in my (hopefully) last 3.7-merge pull request. Thanks Guennadi Guennadi Liakhovetski (7): media: sh_mobile_ceu_camera: fix const cropping related warnings media: pxa_camera: fix const cropping related warnings media: sh_vou: fix const cropping related warnings media: mx3_camera: fix const cropping related warnings media: mx2_camera: fix const cropping related warnings media: mx1_camera: use the default .set_crop() implementation media: omap1_camera: fix const cropping related warnings drivers/media/platform/sh_vou.c|3 ++- drivers/media/platform/soc_camera/mx1_camera.c |9 - drivers/media/platform/soc_camera/mx2_camera.c |5 +++-- drivers/media/platform/soc_camera/mx3_camera.c |5 +++-- drivers/media/platform/soc_camera/omap1_camera.c |4 ++-- drivers/media/platform/soc_camera/pxa_camera.c |4 ++-- .../platform/soc_camera/sh_mobile_ceu_camera.c | 13 +++-- 7 files changed, 19 insertions(+), 24 deletions(-) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] media: mx1_camera: use the default .set_crop() implementation
.set_crop() implementation in mx1_camera is identical with the default.
Remove the copy to switch to using the default stab.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/soc_camera/mx1_camera.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx1_camera.c
b/drivers/media/platform/soc_camera/mx1_camera.c
index 560a65a..bbd18e6 100644
--- a/drivers/media/platform/soc_camera/mx1_camera.c
+++ b/drivers/media/platform/soc_camera/mx1_camera.c
@@ -470,14 +470,6 @@ static void mx1_camera_remove_device(struct
soc_camera_device *icd)
pcdev-icd = NULL;
}
-static int mx1_camera_set_crop(struct soc_camera_device *icd,
- struct v4l2_crop *a)
-{
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
-
- return v4l2_subdev_call(sd, video, s_crop, a);
-}
-
static int mx1_camera_set_bus_param(struct soc_camera_device *icd)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
@@ -689,7 +681,6 @@ static struct soc_camera_host_ops mx1_soc_camera_host_ops =
{
.add= mx1_camera_add_device,
.remove = mx1_camera_remove_device,
.set_bus_param = mx1_camera_set_bus_param,
- .set_crop = mx1_camera_set_crop,
.set_fmt= mx1_camera_set_fmt,
.try_fmt= mx1_camera_try_fmt,
.init_videobuf = mx1_camera_init_videobuf,
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] media: sh_mobile_ceu_camera: fix const cropping related warnings
A recent commit [media] v4l2: make vidioc_s_crop const introduced
warnings in sh_mobile_ceu_camera. Fix them by cleanly separating writable
and read-only variables in cropping operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
.../platform/soc_camera/sh_mobile_ceu_camera.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 78bcf23..4642e0d 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -1213,13 +1213,13 @@ static void sh_mobile_ceu_put_formats(struct
soc_camera_device *icd)
}
/* Check if any dimension of r1 is smaller than respective one of r2 */
-static bool is_smaller(struct v4l2_rect *r1, struct v4l2_rect *r2)
+static bool is_smaller(const struct v4l2_rect *r1, const struct v4l2_rect *r2)
{
return r1-width r2-width || r1-height r2-height;
}
/* Check if r1 fails to cover r2 */
-static bool is_inside(struct v4l2_rect *r1, struct v4l2_rect *r2)
+static bool is_inside(const struct v4l2_rect *r1, const struct v4l2_rect *r2)
{
return r1-left r2-left || r1-top r2-top ||
r1-left + r1-width r2-left + r2-width ||
@@ -1294,7 +1294,7 @@ static void update_subrect(struct sh_mobile_ceu_cam *cam)
* 3. if (2) failed, try to request the maximum image
*/
static int client_s_crop(struct soc_camera_device *icd, struct v4l2_crop *crop,
-const struct v4l2_crop *cam_crop)
+struct v4l2_crop *cam_crop)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct v4l2_rect *rect = crop-c, *cam_rect = cam_crop-c;
@@ -1550,7 +1550,8 @@ static int client_scale(struct soc_camera_device *icd,
static int sh_mobile_ceu_set_crop(struct soc_camera_device *icd,
const struct v4l2_crop *a)
{
- struct v4l2_rect *rect = a-c;
+ struct v4l2_crop a_writable = *a;
+ const struct v4l2_rect *rect = a_writable.c;
struct device *dev = icd-parent;
struct soc_camera_host *ici = to_soc_camera_host(dev);
struct sh_mobile_ceu_dev *pcdev = ici-priv;
@@ -1576,7 +1577,7 @@ static int sh_mobile_ceu_set_crop(struct
soc_camera_device *icd,
* 1. - 2. Apply iterative camera S_CROP for new input window, read back
* actual camera rectangle.
*/
- ret = client_s_crop(icd, a, cam_crop);
+ ret = client_s_crop(icd, a_writable, cam_crop);
if (ret 0)
return ret;
@@ -1977,7 +1978,7 @@ static int sh_mobile_ceu_try_fmt(struct soc_camera_device
*icd,
}
static int sh_mobile_ceu_set_livecrop(struct soc_camera_device *icd,
- struct v4l2_crop *a)
+ const struct v4l2_crop *a)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] media: mx2_camera: fix const cropping related warnings
A recent commit [media] v4l2: make vidioc_s_crop const introduced
warnings in mx2_camera. Fix them by cleanly separating writable and
read-only variables in cropping operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/soc_camera/mx2_camera.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 29758b0..0854f83 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1104,9 +1104,10 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
}
static int mx2_camera_set_crop(struct soc_camera_device *icd,
- struct v4l2_crop *a)
+ const struct v4l2_crop *a)
{
- struct v4l2_rect *rect = a-c;
+ struct v4l2_crop a_writable = *a;
+ struct v4l2_rect *rect = a_writable.c;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct v4l2_mbus_framefmt mf;
int ret;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dm644x: replace the obsolete preset API by the timings API.
Hi Prabhakar!
On Fri September 28 2012 14:44:59 Prabhakar Lad wrote:
Hi Kevin,
On Wed, Aug 8, 2012 at 6:00 PM, Prabhakar Lad prabhakar@ti.com wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++--
arch/arm/mach-davinci/dm644x.c | 17 +---
drivers/media/video/davinci/vpbe.c | 110
drivers/media/video/davinci/vpbe_display.c | 60 +++
drivers/media/video/davinci/vpbe_venc.c| 25 +++---
include/media/davinci/vpbe.h | 14 ++--
include/media/davinci/vpbe_types.h |8 +--
include/media/davinci/vpbe_venc.h |2 +-
8 files changed, 111 insertions(+), 140 deletions(-)
Can you ACK this patch? Since this patch needs to go from Mauro's tree
due to changes in media drivers folder structure.
Regards,
--Prabhakar Lad
...
-static int vpbe_s_dv_preset(struct vpbe_device *vpbe_dev,
-struct v4l2_dv_preset *dv_preset)
+static int vpbe_s_dv_timings(struct vpbe_device *vpbe_dev,
+struct v4l2_dv_timings *dv_timings)
{
struct vpbe_config *cfg = vpbe_dev-cfg;
int out_index = vpbe_dev-current_out_index;
+ struct vpbe_output *output = cfg-outputs[out_index];
int sd_index = vpbe_dev-current_sd_index;
- int ret;
+ int ret, i;
if (!(cfg-outputs[out_index].output.capabilities
- V4L2_OUT_CAP_PRESETS))
+ V4L2_OUT_CAP_CUSTOM_TIMINGS))
Can you make a follow-up patch that renames V4L2_IN/OUT_CAP_CUSTOM_TIMINGS to
V4L2_IN/OUT_CAP_DV_TIMINGS? The old name for this define is deprecated, so it
would be nice to fix this in this driver as well.
The code that adds the new define names went in just two days ago, so as far
as I am concerned there is no need to modify the patch again. A follow-up
patch is sufficient.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dm644x: replace the obsolete preset API by the timings API.
Hi Hans,
On Fri, Sep 28, 2012 at 6:22 PM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Prabhakar!
On Fri September 28 2012 14:44:59 Prabhakar Lad wrote:
Hi Kevin,
On Wed, Aug 8, 2012 at 6:00 PM, Prabhakar Lad prabhakar@ti.com wrote:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++--
arch/arm/mach-davinci/dm644x.c | 17 +---
drivers/media/video/davinci/vpbe.c | 110
drivers/media/video/davinci/vpbe_display.c | 60 +++
drivers/media/video/davinci/vpbe_venc.c| 25 +++---
include/media/davinci/vpbe.h | 14 ++--
include/media/davinci/vpbe_types.h |8 +--
include/media/davinci/vpbe_venc.h |2 +-
8 files changed, 111 insertions(+), 140 deletions(-)
Can you ACK this patch? Since this patch needs to go from Mauro's tree
due to changes in media drivers folder structure.
Regards,
--Prabhakar Lad
...
-static int vpbe_s_dv_preset(struct vpbe_device *vpbe_dev,
-struct v4l2_dv_preset *dv_preset)
+static int vpbe_s_dv_timings(struct vpbe_device *vpbe_dev,
+struct v4l2_dv_timings *dv_timings)
{
struct vpbe_config *cfg = vpbe_dev-cfg;
int out_index = vpbe_dev-current_out_index;
+ struct vpbe_output *output = cfg-outputs[out_index];
int sd_index = vpbe_dev-current_sd_index;
- int ret;
+ int ret, i;
if (!(cfg-outputs[out_index].output.capabilities
- V4L2_OUT_CAP_PRESETS))
+ V4L2_OUT_CAP_CUSTOM_TIMINGS))
Can you make a follow-up patch that renames V4L2_IN/OUT_CAP_CUSTOM_TIMINGS to
V4L2_IN/OUT_CAP_DV_TIMINGS? The old name for this define is deprecated, so it
would be nice to fix this in this driver as well.
The code that adds the new define names went in just two days ago, so as far
as I am concerned there is no need to modify the patch again. A follow-up
patch is sufficient.
Ok, I'll create a follow up patch.
Regards,
--Prabhakar
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
[PATCH 6/7] [media] ds3000: add module parameter to force firmware upload
Signed-off-by: Rémi Cardona remi.card...@smartjog.com
---
drivers/media/dvb-frontends/ds3000.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/ds3000.c
b/drivers/media/dvb-frontends/ds3000.c
index 59184a8..c66d731 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -30,6 +30,7 @@
#include ds3000.h
static int debug;
+static int force_fw_upload;
#define dprintk(args...) \
do { \
@@ -396,7 +397,7 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
dprintk(%s()\n, __func__);
ret = ds3000_readreg(state, 0xb2);
- if (ret == 0) {
+ if (ret == 0 force_fw_upload == 0) {
/* Firmware already uploaded, skipping */
return ret;
} else if (ret 0) {
@@ -1307,6 +1308,9 @@ static struct dvb_frontend_ops ds3000_ops = {
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Activates frontend debugging (default:0));
+module_param(force_fw_upload, int, 0644);
+MODULE_PARM_DESC(force_fw_upload, Force firmware upload (default:0));
+
MODULE_DESCRIPTION(DVB Frontend module for Montage Technology
DS3000/TS2020 hardware);
MODULE_AUTHOR(Konstantin Dimitrov);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] [media] dw2102: Declare MODULE_FIRMWARE usage
Signed-off-by: Rémi Cardona remi.card...@smartjog.com
---
drivers/media/usb/dvb-usb/dw2102.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index 9382895..937c744 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -80,6 +80,15 @@
#define DW2102_RC_QUERY (0x1a00)
#define DW2102_LED_CTRL (0x1b00)
+#define DW2101_FIRMWARE dvb-usb-dw2101.fw
+#define DW2102_FIRMWARE dvb-usb-dw2102.fw
+#define DW2104_FIRMWARE dvb-usb-dw2104.fw
+#define DW3101_FIRMWARE dvb-usb-dw3101.fw
+#define S630_FIRMWARE dvb-usb-s630.fw
+#define S660_FIRMWARE dvb-usb-s660.fw
+#define P1100_FIRMWARE dvb-usb-p1100.fw
+#define P7500_FIRMWARE dvb-usb-p7500.fw
+
#defineerr_str did not find the firmware file. (%s) \
Please see linux/Documentation/dvb/ for more details \
on firmware-problems.
@@ -1478,13 +1487,12 @@ static int dw2102_load_firmware(struct usb_device *dev,
u8 reset;
u8 reset16[] = {0, 0, 0, 0, 0, 0, 0};
const struct firmware *fw;
- const char *fw_2101 = dvb-usb-dw2101.fw;
switch (dev-descriptor.idProduct) {
case 0x2101:
- ret = request_firmware(fw, fw_2101, dev-dev);
+ ret = request_firmware(fw, DW2101_FIRMWARE, dev-dev);
if (ret != 0) {
- err(err_str, fw_2101);
+ err(err_str, DW2101_FIRMWARE);
return ret;
}
break;
@@ -1586,7 +1594,7 @@ static int dw2102_load_firmware(struct usb_device *dev,
static struct dvb_usb_device_properties dw2102_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
- .firmware = dvb-usb-dw2102.fw,
+ .firmware = DW2102_FIRMWARE,
.no_reconnect = 1,
.i2c_algo = dw2102_serit_i2c_algo,
@@ -1641,7 +1649,7 @@ static struct dvb_usb_device_properties dw2102_properties
= {
static struct dvb_usb_device_properties dw2104_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
- .firmware = dvb-usb-dw2104.fw,
+ .firmware = DW2104_FIRMWARE,
.no_reconnect = 1,
.i2c_algo = dw2104_i2c_algo,
@@ -1691,7 +1699,7 @@ static struct dvb_usb_device_properties dw2104_properties
= {
static struct dvb_usb_device_properties dw3101_properties = {
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
- .firmware = dvb-usb-dw3101.fw,
+ .firmware = DW3101_FIRMWARE,
.no_reconnect = 1,
.i2c_algo = dw3101_i2c_algo,
@@ -1739,7 +1747,7 @@ static struct dvb_usb_device_properties s6x0_properties =
{
.caps = DVB_USB_IS_AN_I2C_ADAPTER,
.usb_ctrl = DEVICE_SPECIFIC,
.size_of_priv = sizeof(struct s6x0_state),
- .firmware = dvb-usb-s630.fw,
+ .firmware = S630_FIRMWARE,
.no_reconnect = 1,
.i2c_algo = s6x0_i2c_algo,
@@ -1879,7 +1887,7 @@ static int dw2102_probe(struct usb_interface *intf,
return -ENOMEM;
/* copy default structure */
/* fill only different fields */
- p1100-firmware = dvb-usb-p1100.fw;
+ p1100-firmware = P1100_FIRMWARE;
p1100-devices[0] = d1100;
p1100-rc.legacy.rc_map_table = rc_map_tbs_table;
p1100-rc.legacy.rc_map_size = ARRAY_SIZE(rc_map_tbs_table);
@@ -1891,7 +1899,7 @@ static int dw2102_probe(struct usb_interface *intf,
kfree(p1100);
return -ENOMEM;
}
- s660-firmware = dvb-usb-s660.fw;
+ s660-firmware = S660_FIRMWARE;
s660-num_device_descs = 3;
s660-devices[0] = d660;
s660-devices[1] = d480_1;
@@ -1905,7 +1913,7 @@ static int dw2102_probe(struct usb_interface *intf,
kfree(s660);
return -ENOMEM;
}
- p7500-firmware = dvb-usb-p7500.fw;
+ p7500-firmware = P7500_FIRMWARE;
p7500-devices[0] = d7500;
p7500-rc.legacy.rc_map_table = rc_map_tbs_table;
p7500-rc.legacy.rc_map_size = ARRAY_SIZE(rc_map_tbs_table);
@@ -1949,3 +1957,11 @@ MODULE_DESCRIPTION(Driver for DVBWorld DVB-S 2101,
2102, DVB-S2 2104,
Geniatech SU3000 devices);
MODULE_VERSION(0.1);
MODULE_LICENSE(GPL);
+MODULE_FIRMWARE(DW2101_FIRMWARE);
+MODULE_FIRMWARE(DW2102_FIRMWARE);
+MODULE_FIRMWARE(DW2104_FIRMWARE);
+MODULE_FIRMWARE(DW3101_FIRMWARE);
+MODULE_FIRMWARE(S630_FIRMWARE);
+MODULE_FIRMWARE(S660_FIRMWARE);
+MODULE_FIRMWARE(P1100_FIRMWARE);
+MODULE_FIRMWARE(P7500_FIRMWARE);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] ds3000/dw2102 improvements
Hi all, Here's hopefully the final round of patches for ds3000. All of the patches have been rebased on top of today's staging/for_v3.7 branch. Patches 1 through 4 are identical to the previous v2. Patches 5 and 6 are functionally identical, only the printk()s have been removed. Patch 7 is new, as we have recently gotten a few S480 cards from TeVii and we were missing their firmware, and found modinfo to be lacking the info. Thanks again for any review/comments. Cheers, Rémi Cardona -- SmartJog | T: +33 1 5868 6229 27 Blvd Hippolyte Marquès, 94200 Ivry-sur-Seine, France www.smartjog.com | a TDF Group company -- 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/7] [media] ds3000: remove useless 'locking'
Since b9bf2eafaad9c1ef02fb3db38c74568be601a43a, the function
ds3000_firmware_ondemand() is called only once during init. This
locking scheme may have been useful when the firmware was loaded at
each tune.
Furthermore, it looks like this 'lock' was put in to prevent concurrent
access (and not recursion as the comments suggest). However, this open-
coded mechanism is anything but race-free and should have used a proper
mutex.
Signed-off-by: Rémi Cardona remi.card...@smartjog.com
---
drivers/media/dvb-frontends/ds3000.c |9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/media/dvb-frontends/ds3000.c
b/drivers/media/dvb-frontends/ds3000.c
index 46874c7..474f26e 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -233,7 +233,6 @@ struct ds3000_state {
struct i2c_adapter *i2c;
const struct ds3000_config *config;
struct dvb_frontend frontend;
- u8 skip_fw_load;
/* previous uncorrected block counter for DVB-S2 */
u16 prevUCBS2;
};
@@ -395,8 +394,6 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
if (ds3000_readreg(state, 0xb2) = 0)
return ret;
- if (state-skip_fw_load)
- return 0;
/* Load firmware */
/* request the firmware, this will block until someone uploads it */
printk(KERN_INFO %s: Waiting for firmware upload (%s)...\n, __func__,
@@ -410,9 +407,6 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
return ret;
}
- /* Make sure we don't recurse back through here during loading */
- state-skip_fw_load = 1;
-
ret = ds3000_load_firmware(fe, fw);
if (ret)
printk(%s: Writing firmware to device failed\n, __func__);
@@ -422,9 +416,6 @@ static int ds3000_firmware_ondemand(struct dvb_frontend *fe)
dprintk(%s: Firmware upload %s\n, __func__,
ret == 0 ? complete : failed);
- /* Ensure firmware is always loaded if required */
- state-skip_fw_load = 0;
-
return ret;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] [media] ds3000: bail out early on i2c failures during firmware load
- if kmalloc() returns NULL, we can return immediately without trying
to kfree() a NULL pointer.
- if i2c_transfer() fails, error out immediately instead of trying to
upload the remaining bytes of the firmware.
- the error code is then properly propagated down to ds3000_initfe().
Signed-off-by: Rémi Cardona remi.card...@smartjog.com
---
drivers/media/dvb-frontends/ds3000.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/ds3000.c
b/drivers/media/dvb-frontends/ds3000.c
index 675..162faaf 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -280,15 +280,14 @@ static int ds3000_tuner_writereg(struct ds3000_state
*state, int reg, int data)
static int ds3000_writeFW(struct ds3000_state *state, int reg,
const u8 *data, u16 len)
{
- int i, ret = -EREMOTEIO;
+ int i, ret = 0;
struct i2c_msg msg;
u8 *buf;
buf = kmalloc(33, GFP_KERNEL);
if (buf == NULL) {
printk(KERN_ERR Unable to kmalloc\n);
- ret = -ENOMEM;
- goto error;
+ return -ENOMEM;
}
*(buf) = reg;
@@ -308,8 +307,10 @@ static int ds3000_writeFW(struct ds3000_state *state, int
reg,
printk(KERN_ERR %s: write error(err == %i,
reg == 0x%02x\n, __func__, ret, reg);
ret = -EREMOTEIO;
+ goto error;
}
}
+ ret = 0;
error:
kfree(buf);
@@ -426,6 +427,7 @@ static int ds3000_load_firmware(struct dvb_frontend *fe,
const struct firmware *fw)
{
struct ds3000_state *state = fe-demodulator_priv;
+ int ret = 0;
dprintk(%s\n, __func__);
dprintk(Firmware is %zu bytes (%02x %02x .. %02x %02x)\n,
@@ -438,10 +440,10 @@ static int ds3000_load_firmware(struct dvb_frontend *fe,
/* Begin the firmware load process */
ds3000_writereg(state, 0xb2, 0x01);
/* write the entire firmware */
- ds3000_writeFW(state, 0xb0, fw-data, fw-size);
+ ret = ds3000_writeFW(state, 0xb0, fw-data, fw-size);
ds3000_writereg(state, 0xb2, 0x00);
- return 0;
+ return ret;
}
static int ds3000_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t
voltage)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] [media] ds3000: properly report firmware probing issues
ds3000_readreg() returns negative values in case of i2c failures. The
old code would simply return 0 when failing to read the 0xb2 register,
misleading ds3000_initfe() into believing that the firmware had been
correctly loaded.
Signed-off-by: Rémi Cardona remi.card...@smartjog.com
---
drivers/media/dvb-frontends/ds3000.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/ds3000.c
b/drivers/media/dvb-frontends/ds3000.c
index 162faaf..59184a8 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -395,8 +395,13 @@ static int ds3000_firmware_ondemand(struct dvb_frontend
*fe)
dprintk(%s()\n, __func__);
- if (ds3000_readreg(state, 0xb2) = 0)
+ ret = ds3000_readreg(state, 0xb2);
+ if (ret == 0) {
+ /* Firmware already uploaded, skipping */
return ret;
+ } else if (ret 0) {
+ return ret;
+ }
/* Load firmware */
/* request the firmware, this will block until someone uploads it */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] [media] ds3000: Declare MODULE_FIRMWARE usage
Signed-off-by: Rémi Cardona remi.card...@smartjog.com --- drivers/media/dvb-frontends/ds3000.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/dvb-frontends/ds3000.c b/drivers/media/dvb-frontends/ds3000.c index 4c8ac26..46874c7 100644 --- a/drivers/media/dvb-frontends/ds3000.c +++ b/drivers/media/dvb-frontends/ds3000.c @@ -1310,3 +1310,4 @@ MODULE_DESCRIPTION(DVB Frontend module for Montage Technology DS3000/TS2020 hardware); MODULE_AUTHOR(Konstantin Dimitrov); MODULE_LICENSE(GPL); +MODULE_FIRMWARE(DS3000_DEFAULT_FIRMWARE); -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] [media] ds3000: properly report register read errors
This brings both ds3000_readreg() and ds3000_tuner_readreg() in line
with ds3000_writereg() and ds3000_tuner_writereg() respectively.
Signed-off-by: Rémi Cardona remi.card...@smartjog.com
---
drivers/media/dvb-frontends/ds3000.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/ds3000.c
b/drivers/media/dvb-frontends/ds3000.c
index 474f26e..675 100644
--- a/drivers/media/dvb-frontends/ds3000.c
+++ b/drivers/media/dvb-frontends/ds3000.c
@@ -340,7 +340,7 @@ static int ds3000_readreg(struct ds3000_state *state, u8
reg)
if (ret != 2) {
printk(KERN_ERR %s: reg=0x%x(error=%d)\n, __func__, reg, ret);
- return ret;
+ return -EREMOTEIO;
}
dprintk(%s: read reg 0x%02x, value 0x%02x\n, __func__, reg, b1[0]);
@@ -367,12 +367,15 @@ static int ds3000_tuner_readreg(struct ds3000_state
*state, u8 reg)
}
};
- ds3000_writereg(state, 0x03, 0x12);
- ret = i2c_transfer(state-i2c, msg, 2);
+ ret = ds3000_writereg(state, 0x03, 0x12);
+ if (ret 0) {
+ return -EREMOTEIO;
+ }
+ ret = i2c_transfer(state-i2c, msg, 2);
if (ret != 2) {
printk(KERN_ERR %s: reg=0x%x(error=%d)\n, __func__, reg, ret);
- return ret;
+ return -EREMOTEIO;
}
dprintk(%s: read reg 0x%02x, value 0x%02x\n, __func__, reg, b1[0]);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] seqno-fence: Hardware dma-buf implementation of fencing (v3)
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) = 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Documentation/DocBook/device-drivers.tmpl |1
drivers/base/fence.c | 36 ++
include/linux/seqno-fence.h | 107 +
3 files changed, 144 insertions(+)
create mode 100644 include/linux/seqno-fence.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 6f53fc0..ad14396 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,6 +128,7 @@ X!Edrivers/base/interface.c
!Edrivers/base/dma-buf.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
/sect1
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index b90a09e..0a184b2 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -24,6 +24,7 @@
#include linux/slab.h
#include linux/export.h
#include linux/fence.h
+#include linux/seqno-fence.h
static int __fence_signal(struct fence *fence)
{
@@ -335,3 +336,38 @@ struct fence *fence_create(void *priv)
return fence;
}
EXPORT_SYMBOL(fence_create);
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence-ops-enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+ struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence-ops-signaled seqno_fence-ops-signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+
+ if (f-ops-release)
+ f-ops-release(fence);
+ dma_buf_put(f-sync_buf);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+ struct seqno_fence *f = to_seqno_fence(fence);
+ return f-ops-wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+ .enable_signaling = seqno_enable_signaling,
+ .signaled = seqno_signaled,
+ .wait = seqno_wait,
+ .release = seqno_release
+};
+EXPORT_SYMBOL_GPL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index 000..971cebe
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,107 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ * Rob Clark rob.cl...@linaro.org
+ * Maarten Lankhorst maarten.lankho...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef __SEQNO_FENCE_H__
+#define __SEQNO_FENCE_H__
+
+#include linux/fence.h
+#include linux/dma-buf.h
+
+struct seqno_fence {
+ struct fence base;
+
+ const struct fence_ops *ops;
+ struct dma_buf *sync_buf;
+ uint32_t seqno_ofs;
+ uint32_t seqno;
+};
+
+extern const struct fence_ops seqno_fence_ops;
+
+/**
+ * to_seqno_fence - cast a fence to a seqno_fence
+ * @fence: fence to cast to a seqno_fence
+ *
+ * Returns NULL if the fence is not a seqno_fence,
+ * or the seqno_fence otherwise.
+ */
+static inline struct seqno_fence *
+to_seqno_fence(struct fence *fence)
+{
+ if (fence-ops != seqno_fence_ops)
+ return NULL;
+ return container_of(fence, struct seqno_fence, base);
+}
+
+/**
+ * seqno_fence_init - initialize a seqno fence
+ * @fence: seqno_fence to initialize
+ * @sync_buf: buffer containing the memory location to signal on
+ * @seqno_ofs:
[PATCH 2/5] fence: dma-buf cross-device synchronization (v9)
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence:
+ fence_signal()
To have a rough approximation whether a fence is fired, call:
+ fence_is_signaled()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
The one pending on the fence can add an async callback:
+ fence_add_callback()
The callback can optionally be cancelled with:
+ fence_remove_callback()
To wait synchronously, optionally with a timeout:
+ fence_wait()
+ fence_wait_timeout()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = custom_get_fence(...);
if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence-sync_buf;
get_dma_buf(fence_buf);
... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
} else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence. If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily. The handler of the enable_signaling
op should take a refcount until the fence is signaled, then release its ref.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
[PATCH 5/5] reservation: Add lockdep annotation and selftests
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
The self-tests will fail if the commit lockdep: Check if nested
lock is actually held from linux tip core/locking is not applied.
---
drivers/base/reservation.c | 46 +-
include/linux/reservation.h | 29 +++-
lib/Kconfig.debug |1
lib/locking-selftest.c | 353 +--
4 files changed, 403 insertions(+), 26 deletions(-)
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
index 93e2d9f..b8d4f4d 100644
--- a/drivers/base/reservation.c
+++ b/drivers/base/reservation.c
@@ -41,6 +41,18 @@
atomic64_t reservation_counter = ATOMIC64_INIT(1);
EXPORT_SYMBOL(reservation_counter);
+const char reservation_object_name[] = reservation_object;
+EXPORT_SYMBOL(reservation_object_name);
+
+const char reservation_ticket_name[] = reservation_ticket;
+EXPORT_SYMBOL(reservation_ticket_name);
+
+struct lock_class_key reservation_object_class;
+EXPORT_SYMBOL(reservation_object_class);
+
+struct lock_class_key reservation_ticket_class;
+EXPORT_SYMBOL(reservation_ticket_class);
+
int
object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
reservation_ticket_t *ticket)
@@ -49,6 +61,10 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
u64 sequence = ticket ? ticket-seqno : 1;
u64 oldseq;
+ if (!no_wait)
+ mutex_acquire_nest(obj-dep_map, 0, 0,
+ ticket ? ticket-dep_map : NULL, _RET_IP_);
+
while (unlikely(oldseq = atomic64_cmpxchg(obj-reserved, 0,
sequence))) {
/**
@@ -58,14 +74,18 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
/**
* We've already reserved this one.
*/
- if (unlikely(sequence == oldseq))
- return -EDEADLK;
+ if (unlikely(sequence == oldseq)) {
+ ret = -EDEADLK;
+ goto fail;
+ }
/**
* Already reserved by a thread that will not back
* off for us. We need to back off.
*/
- if (unlikely(sequence - oldseq (1ULL 63)))
- return -EAGAIN;
+ if (unlikely(sequence - oldseq (1ULL 63))) {
+ ret = -EAGAIN;
+ goto fail;
+ }
}
if (no_wait)
@@ -74,9 +94,12 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
ret = object_wait_unreserved(obj, intr);
if (unlikely(ret))
- return ret;
+ goto fail;
}
+ if (no_wait)
+ mutex_acquire(obj-dep_map, 0, 1, _RET_IP_);
+
/**
* Wake up waiters that may need to recheck for deadlock,
* if we decreased the sequence number.
@@ -84,6 +107,11 @@ object_reserve(struct reservation_object *obj, bool intr,
bool no_wait,
wake_up_all(obj-event_queue);
return 0;
+
+fail:
+ if (!no_wait)
+ mutex_release(obj-dep_map, 1, _RET_IP_);
+ return ret;
}
EXPORT_SYMBOL(object_reserve);
@@ -105,6 +133,14 @@ void
object_unreserve(struct reservation_object *obj,
reservation_ticket_t *ticket)
{
+ mutex_release(obj-dep_map, 1, _RET_IP_);
+
+ if (!object_is_reserved(obj)) {
+#ifndef CONFIG_DEBUG_LOCKING_API_SELFTESTS
+ WARN_ON(1);
+#endif
+ return;
+ }
smp_mb();
atomic64_set(obj-reserved, 0);
wake_up_all(obj-event_queue);
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 93280af..6fa0cdb 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -44,6 +44,10 @@
#include linux/fence.h
extern atomic64_t reservation_counter;
+extern const char reservation_object_name[];
+extern struct lock_class_key reservation_object_class;
+extern const char reservation_ticket_name[];
+extern struct lock_class_key reservation_ticket_class;
struct reservation_object {
wait_queue_head_t event_queue;
@@ -53,10 +57,17 @@ struct reservation_object {
u32 fence_shared_count;
struct fence *fence_excl;
struct fence *fence_shared[BUF_MAX_SHARED_FENCE];
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
};
typedef struct reservation_ticket {
u64 seqno;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
} reservation_ticket_t;
/**
@@ -73,11 +84,13 @@ struct reservation_entry {
unsigned long obj_shared;
};
-
static inline void
[PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
include/linux/dma-buf.h | 99 ---
1 file changed, 99 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..bd2e52c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf-file);
}
-#ifdef CONFIG_DMA_SHARED_BUFFER
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
@@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
*,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-#else
-
-static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *dmabuf_attach)
-{
- return;
-}
-
-static inline struct dma_buf *dma_buf_export(void *priv,
-const struct dma_buf_ops *ops,
-size_t size, int flags)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
-{
- return -ENODEV;
-}
-
-static inline struct dma_buf *dma_buf_get(int fd)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_put(struct dma_buf *dmabuf)
-{
- return;
-}
-
-static inline struct sg_table *dma_buf_map_attachment(
- struct dma_buf_attachment *attach, enum dma_data_direction write)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
- struct sg_table *sg, enum dma_data_direction dir)
-{
- return;
-}
-
-static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
- return -ENODEV;
-}
-
-static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
-}
-
-static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
- unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
-unsigned long pnum, void *vaddr)
-{
-}
-
-static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
- unsigned long pnum, void *vaddr)
-{
-}
-
-static inline int dma_buf_mmap(struct dma_buf *dmabuf,
- struct vm_area_struct *vma,
- unsigned long pgoff)
-{
- return -ENODEV;
-}
-
-static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
-{
- return NULL;
-}
-
-static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
-{
-}
-#endif /* CONFIG_DMA_SHARED_BUFFER */
#endif /* __DMA_BUF_H__ */
--
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 4/5] reservation: cross-device reservation support
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the buffer.
Some followup patches are needed in ttm so the lru_lock is no longer
taken during the reservation step. This makes the lockdep annotation
patch a lot more useful, and the assumption that the lru lock protects
atomic removal off the lru list will fail soon, anyway.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Documentation/DocBook/device-drivers.tmpl |2
drivers/base/Makefile |2
drivers/base/reservation.c| 285 +
include/linux/reservation.h | 179 ++
4 files changed, 467 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/reservation.c
create mode 100644 include/linux/reservation.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index ad14396..24e6e80 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -129,6 +129,8 @@ X!Edrivers/base/interface.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
!Iinclude/linux/seqno-fence.h
+!Edrivers/base/reservation.c
+!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
/sect1
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 0026563..f6f731d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
new file mode 100644
index 000..93e2d9f
--- /dev/null
+++ b/drivers/base/reservation.c
@@ -0,0 +1,285 @@
+/*
+ * Copyright (C) 2012 Canonical Ltd
+ *
+ * Based on bo.c which bears the following copyright notice,
+ * but is dual licensed:
+ *
+ * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+/*
+ * Authors: Thomas Hellstrom thellstrom-at-vmware-dot-com
+ */
+
+#include linux/fence.h
+#include linux/reservation.h
+#include linux/export.h
+#include linux/sched.h
+#include linux/slab.h
+
+atomic64_t reservation_counter = ATOMIC64_INIT(1);
+EXPORT_SYMBOL(reservation_counter);
+
+int
+object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
+ reservation_ticket_t *ticket)
+{
+ int ret;
+ u64 sequence = ticket ? ticket-seqno : 1;
+ u64 oldseq;
+
+ while (unlikely(oldseq = atomic64_cmpxchg(obj-reserved, 0,
sequence))) {
+
+ /**
+* Deadlock avoidance for multi-obj reserving.
+*/
+ if (sequence 1 oldseq 1) {
+ /**
+* We've already reserved this one.
+*/
+ if (unlikely(sequence == oldseq))
+ return -EDEADLK;
+ /**
+* Already reserved by a thread that will not back
+* off for us. We need to back off.
+*/
+ if (unlikely(sequence - oldseq (1ULL 63)))
+
Re: [PATCH] mt9v022: support required register settings in snapshot mode
Hi Guennadi,
On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
...
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd,
int enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Unset snapshot mode specific settings: clear bit 9
+* and bit 2 in reg. 0x20 when in normal mode.
+*/
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+* Required settings for snapshot mode: set bit 9
+* (RST enable) and bit 2 (CR enable) in reg. 0x20
+* See TechNote TN0960 or TN-09-225.
+*/
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you
unconditionally added using REG32 for leaving the snapshot mode on
streamon and entering it on streamoff. This should be ok in principle,
since that's also what we're trying to do, using the CHIP_CONTROL
register. But in your comment you say, that on some _systems_ you can only
_operate_ in snapshot mode. I.e. the snapshot mode enabled during running
streaming, right? Then how does this patch help you with that?
Yes. But i.e. the driver calling the sub-device stream control function
on streamon knows that the normal mode is not supported and therefore it
calls this function with argument enable == 0, effectively setting the
snapshot mode.
Thanks,
Anatolij
--
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
account got bounced at vger that might affect patch reviews
Dear developers, Due to some temporary trouble, I was unable to receive emails from linux-media, since 10 hours ago. As I use my IMAP box to check for review e-mails, if you replied to an existing patch during that period of time, and didn't answered it with a Nacked-by/Acked-by tag[1], please ping me, as otherwise I might be applying a patch without noticing to your comments. Thank you! Mauro [1] patchwork properly handles those tags (and a few others, like tested-by and reviewed-by), and joins those when patches are downloaded. As my main resource when applying patches is patchwork, you don't need to worry if you use those tags, as I'll see it, even if I loose your email. -- 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] mt9v022: support required register settings in snapshot mode
On Fri, 28 Sep 2012, Anatolij Gustschin wrote:
Hi Guennadi,
On Fri, 28 Sep 2012 14:33:34 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
...
@@ -235,12 +238,32 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd,
int enable)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct mt9v022 *mt9v022 = to_mt9v022(client);
- if (enable)
+ if (enable) {
/* Switch to master normal mode */
mt9v022-chip_control = ~0x10;
- else
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+ * Unset snapshot mode specific settings: clear bit 9
+ * and bit 2 in reg. 0x20 when in normal mode.
+ */
+ if (reg_clear(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ } else {
/* Switch to snapshot mode */
mt9v022-chip_control |= 0x10;
+ if (is_mt9v022_rev3(mt9v022-chip_version) ||
+ is_mt9v024(mt9v022-chip_version)) {
+ /*
+ * Required settings for snapshot mode: set bit 9
+ * (RST enable) and bit 2 (CR enable) in reg. 0x20
+ * See TechNote TN0960 or TN-09-225.
+ */
+ if (reg_set(client, MT9V022_REG32, 0x204))
+ return -EIO;
+ }
+ }
Do I understand it right, that now on mt9v022 rev.3 and mt9v024 you
unconditionally added using REG32 for leaving the snapshot mode on
streamon and entering it on streamoff. This should be ok in principle,
since that's also what we're trying to do, using the CHIP_CONTROL
register. But in your comment you say, that on some _systems_ you can only
_operate_ in snapshot mode. I.e. the snapshot mode enabled during running
streaming, right? Then how does this patch help you with that?
Yes. But i.e. the driver calling the sub-device stream control function
on streamon knows that the normal mode is not supported and therefore it
calls this function with argument enable == 0, effectively setting the
snapshot mode.
Right, I thought you could be doing that... Well, on the one hand I should
be happy, that the problem is solved without driver modifications, OTOH
this isn't pretty... In fact this shouldn't work at all. After a
stream-off the buffer queue should be stopped too. However, to properly
implement this you'd have to add a new V4L2 control to switch into
snapshot mode.
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: [PATCH] mt9v022: support required register settings in snapshot mode
On Fri, 28 Sep 2012 15:30:33 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Yes. But i.e. the driver calling the sub-device stream control function on streamon knows that the normal mode is not supported and therefore it calls this function with argument enable == 0, effectively setting the snapshot mode. Right, I thought you could be doing that... Well, on the one hand I should be happy, that the problem is solved without driver modifications, OTOH this isn't pretty... In fact this shouldn't work at all. After a stream-off the buffer queue should be stopped too. Yes, the capture driver stops its buffer queue on stream-off. Thanks, Anatolij -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] [media] marvell-ccic: add soc camera support on marvell-ccic
The following patches series will add soc camera support on marvell-ccic [PATCH 1/4] [media] mmp: add register definition for marvell ccic [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core [PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic mmp-driver [PATCH 4/4] [media] marvell-ccic: core: add 3 frame buffers support in DMA_CONTIG mode Thanks Albert Wang -- 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/4] [media] mmp: add register definition for marvell ccic
From: Libin Yang lby...@marvell.com This patch adds the definition of CCIC1/2 Clock Reset register address Signed-off-by: Albert Wang twan...@marvell.com Signed-off-by: Libin Yang lby...@marvell.com --- arch/arm/mach-mmp/include/mach/regs-apmu.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-mmp/include/mach/regs-apmu.h b/arch/arm/mach-mmp/include/mach/regs-apmu.h index 7af8deb..f2cf231 100755 --- a/arch/arm/mach-mmp/include/mach/regs-apmu.h +++ b/arch/arm/mach-mmp/include/mach/regs-apmu.h @@ -16,7 +16,8 @@ /* Clock Reset Control */ #define APMU_IRE APMU_REG(0x048) #define APMU_LCD APMU_REG(0x04c) -#define APMU_CCIC APMU_REG(0x050) +#define APMU_CCIC_RST APMU_REG(0x050) +#define APMU_CCIC2_RST APMU_REG(0x0f4) #define APMU_SDH0 APMU_REG(0x054) #define APMU_SDH1 APMU_REG(0x058) #define APMU_USB APMU_REG(0x05c) -- 1.7.0.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 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core
From: Libin Yang lby...@marvell.com
This patch adds the support of Soc Camera on marvell-ccic mcam-core.
The Soc Camera mode does not compatible with current mode.
Only one mode can be used at one time.
To use Soc Camera, CONFIG_VIDEO_MMP_SOC_CAMERA should be defined.
What's more, the platform driver should support Soc camera at the same time.
Also add MIPI interface and dual CCICs support in Soc Camera mode.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 1034
++
drivers/media/platform/marvell-ccic/mcam-core.h | 126 +++-
2 files changed, 997 insertions(+), 163 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..4adb1ca 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -3,6 +3,12 @@
* so it needs platform-specific support outside of the core.
*
* Copyright 2011 Jonathan Corbet cor...@lwn.net
+ *
+ * History:
+ * Support Soc Camera
+ * Support MIPI interface and Dual CCICs in Soc Camera mode
+ * Sep-2012: Libin Yang lby...@marvell.com
+ * Albert Wang twan...@marvell.com
*/
#include linux/kernel.h
#include linux/module.h
@@ -27,16 +33,14 @@
#include media/videobuf2-vmalloc.h
#include media/videobuf2-dma-contig.h
#include media/videobuf2-dma-sg.h
+#ifdef CONFIG_VIDEO_MRVL_SOC_CAMERA
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#endif
+#include mach/regs-apmu.h
#include mcam-core.h
-/*
- * Basic frame stats - to be deleted shortly
- */
-static int frames;
-static int singles;
-static int delivered;
-
#ifdef MCAM_MODE_VMALLOC
/*
* Internal DMA buffer management. Since the controller cannot do S/G I/O,
@@ -100,10 +104,50 @@ MODULE_PARM_DESC(buffer_mode,
#define CF_CONFIG_NEEDED 4 /* Must configure hardware */
#define CF_SINGLE_BUFFER 5 /* Running with a single buffer */
#define CF_SG_RESTART 6 /* SG restart needed */
+#define CF_FRAME_SOF0 7 /* Frame 0 started */
+#define CF_FRAME_SOF1 8
+#define CF_FRAME_SOF2 9
+#ifdef CONFIG_VIDEO_MRVL_SOC_CAMERA
+#define sensor_call(cam, o, f, args...) \
+ v4l2_subdev_call(soc_camera_to_subdev(cam-icd), o, f, ##args)
+#else
#define sensor_call(cam, o, f, args...) \
v4l2_subdev_call(cam-sensor, o, f, ##args)
+#endif
+#ifdef CONFIG_VIDEO_MRVL_SOC_CAMERA
+static const struct soc_mbus_pixelfmt mcam_formats[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = YUV422PACKED,
+ .bits_per_sample = 8,
+ .packing = SOC_MBUS_PACKING_2X8_PADLO,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV422P,
+ .name = YUV422PLANAR,
+ .bits_per_sample = 8,
+ .packing = SOC_MBUS_PACKING_2X8_PADLO,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .name = YUV420PLANAR,
+ .bits_per_sample = 12,
+ .packing = SOC_MBUS_PACKING_NONE,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_YVU420,
+ .name = YVU420PLANAR,
+ .bits_per_sample = 12,
+ .packing = SOC_MBUS_PACKING_NONE,
+ .order = SOC_MBUS_ORDER_LE,
+ },
+};
+#else
static struct mcam_format_struct {
__u8 *desc;
__u32 pixelformat;
@@ -147,6 +191,7 @@ static struct mcam_format_struct *mcam_find_format(u32
pixelformat)
/* Not found? Then return the first format. */
return mcam_formats;
}
+#endif
/*
* The default format we use until somebody says otherwise.
@@ -175,19 +220,6 @@ struct mcam_dma_desc {
u32 segment_len;
};
-/*
- * Our buffer type for working with videobuf2. Note that the vb2
- * developers have decreed that struct vb2_buffer must be at the
- * beginning of this structure.
- */
-struct mcam_vb_buffer {
- struct vb2_buffer vb_buf;
- struct list_head queue;
- struct mcam_dma_desc *dma_desc; /* Descriptor virtual address */
- dma_addr_t dma_desc_pa; /* Descriptor physical address */
- int dma_desc_nent; /* Number of mapped descriptors */
-};
-
static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
{
return container_of(vb, struct mcam_vb_buffer, vb_buf);
@@ -226,8 +258,10 @@ static void mcam_reset_buffers(struct mcam_camera *cam)
int i;
cam-next_buf = -1;
- for (i = 0; i cam-nbufs; i++)
+ for (i = 0; i cam-nbufs; i++) {
clear_bit(i, cam-flags);
+ clear_bit(CF_FRAME_SOF0 + i, cam-flags);
+ }
}
static inline int mcam_needs_config(struct mcam_camera *cam)
@@ -367,10 +401,10 @@ static void
[PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic mmp-driver
From: Libin Yang lby...@marvell.com This patch adds the support of Soc Camera on marvell-ccic mmp-driver. The Soc Camera mode does not compatible with current mode. Only one mode can be used at one time. To enable Soc Camera on mmp: In Device Drivers -- Multimedia support: select Cameras/video grabbers support Then in Video capture adapters -- V4L platform devices -- Camera support on Marvell MMP: select Marvell MMP camera driver based on SOC_CAMERA Also in Video capture adapters -- V4L platform devices: select SoC camera support select the relevant sensor in target platform Also add MIPI interface and dual CCICs support in Soc Camera mode. Signed-off-by: Albert Wang twan...@marvell.com Signed-off-by: Libin Yang lby...@marvell.com --- drivers/media/platform/Makefile |4 +- drivers/media/platform/marvell-ccic/Kconfig | 22 +++ drivers/media/platform/marvell-ccic/Makefile |1 + drivers/media/platform/marvell-ccic/mmp-driver.c | 253 +++-- include/media/mmp-camera.h| 13 ++ 5 files changed, 233 insertions(+), 60 deletions(-) diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index b7da9fa..ca60607 100755 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -146,9 +146,6 @@ obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o -obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/ -obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/ - obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/ @@ -182,6 +179,7 @@ obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o +obj-$(CONFIG_VIDEO_MARVELL_CCIC) += marvell-ccic/ obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o diff --git a/drivers/media/platform/marvell-ccic/Kconfig b/drivers/media/platform/marvell-ccic/Kconfig index bf739e3..6e3eaa0 100755 --- a/drivers/media/platform/marvell-ccic/Kconfig +++ b/drivers/media/platform/marvell-ccic/Kconfig @@ -1,23 +1,45 @@ +config VIDEO_MARVELL_CCIC + tristate +config VIDEO_MRVL_SOC_CAMERA + tristate + config VIDEO_CAFE_CCIC tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support depends on PCI I2C VIDEO_V4L2 select VIDEO_OV7670 select VIDEOBUF2_VMALLOC select VIDEOBUF2_DMA_CONTIG + select VIDEO_MARVELL_CCIC ---help--- This is a video4linux2 driver for the Marvell 88ALP01 integrated CMOS camera controller. This is the controller found on first- generation OLPC systems. +choice + prompt Camera support on Marvell MMP + depends on ARCH_MMP VIDEO_V4L2 + optional config VIDEO_MMP_CAMERA tristate Marvell Armada 610 integrated camera controller support depends on ARCH_MMP I2C VIDEO_V4L2 select VIDEO_OV7670 select I2C_GPIO select VIDEOBUF2_DMA_SG + select VIDEO_MARVELL_CCIC ---help--- This is a Video4Linux2 driver for the integrated camera controller found on Marvell Armada 610 application processors (and likely beyond). This is the controller found in OLPC XO 1.75 systems. +config VIDEO_MMP_SOC_CAMERA + bool Marvell MMP camera driver based on SOC_CAMERA + depends on VIDEO_DEV SOC_CAMERA ARCH_MMP VIDEO_V4L2 + select VIDEOBUF2_DMA_CONTIG + select VIDEO_MARVELL_CCIC + select VIDEO_MRVL_SOC_CAMERA + ---help--- + This is a Video4Linux2 driver for the Marvell Mobile Soc + PXA910/PXA688/PXA2128/PXA988 CCIC + (CMOS Camera Interface Controller) +endchoice diff --git a/drivers/media/platform/marvell-ccic/Makefile b/drivers/media/platform/marvell-ccic/Makefile index 05a792c..d6ffd16 100755 --- a/drivers/media/platform/marvell-ccic/Makefile +++ b/drivers/media/platform/marvell-ccic/Makefile @@ -2,5 +2,6 @@ obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o cafe_ccic-y := cafe-driver.o mcam-core.o obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera.o +obj-$(CONFIG_VIDEO_MMP_SOC_CAMERA) += mmp_camera.o mmp_camera-y := mmp-driver.o mcam-core.o diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c b/drivers/media/platform/marvell-ccic/mmp-driver.c index c4c17fe..afdd702 100755 --- a/drivers/media/platform/marvell-ccic/mmp-driver.c +++ b/drivers/media/platform/marvell-ccic/mmp-driver.c @@ -4,6 +4,12 @@ * * Copyright 2011 Jonathan Corbet cor...@lwn.net * + * History: + * Support Soc Camera + * Support MIPI interface and Dual CCICs in Soc Camera mode + * Sep-2012: Libin Yang lby...@marvell.com + * Albert Wang
[PATCH 4/4] [media] marvell-ccic: core: add 3 frame buffers support in DMA_CONTIG mode
This patch adds support of 3 frame buffers in DMA-contiguous mode.
In current DMA_CONTIG mode, only 2 frame buffers can be supported.
Actually, Marvell CCIC can support at most 3 frame buffers.
Currently 2 frame buffers mode will be used by default.
To use 3 frame buffers mode, can do:
define MAX_FRAME_BUFS 3
in mcam-core.h
Signed-off-by: Albert Wang twan...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 87
++
drivers/media/platform/marvell-ccic/mcam-core.h | 15 -
2 files changed, 74 insertions(+), 28 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 4adb1ca..a805246 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -228,7 +228,7 @@ static inline struct mcam_vb_buffer *vb_to_mvb(struct
vb2_buffer *vb)
/*
* Hand a completed buffer back to user space.
*/
-static void mcam_buffer_done(struct mcam_camera *cam, int frame,
+static void mcam_buffer_done(struct mcam_camera *cam, unsigned int frame,
struct vb2_buffer *vbuf)
{
vbuf-v4l2_buf.bytesused = cam-pix_format.sizeimage;
@@ -255,7 +255,7 @@ static void mcam_buffer_done(struct mcam_camera *cam, int
frame,
*/
static void mcam_reset_buffers(struct mcam_camera *cam)
{
- int i;
+ unsigned int i;
cam-next_buf = -1;
for (i = 0; i cam-nbufs; i++) {
@@ -306,7 +306,7 @@ static void mcam_ctlr_stop(struct mcam_camera *cam)
*/
static int mcam_alloc_dma_bufs(struct mcam_camera *cam, int loadtime)
{
- int i;
+ unsigned int i;
mcam_set_config_needed(cam, 1);
if (loadtime)
@@ -347,7 +347,7 @@ static int mcam_alloc_dma_bufs(struct mcam_camera *cam, int
loadtime)
static void mcam_free_dma_bufs(struct mcam_camera *cam)
{
- int i;
+ unsigned int i;
for (i = 0; i cam-nbufs; i++) {
dma_free_coherent(cam-dev, cam-dma_buf_size,
@@ -386,7 +386,7 @@ static void mcam_ctlr_dma_vmalloc(struct mcam_camera *cam)
static void mcam_frame_tasklet(unsigned long data)
{
struct mcam_camera *cam = (struct mcam_camera *) data;
- int i;
+ unsigned int i;
unsigned long flags;
struct mcam_vb_buffer *buf;
@@ -434,7 +434,7 @@ static int mcam_check_dma_buffers(struct mcam_camera *cam)
return 0;
}
-static void mcam_vmalloc_done(struct mcam_camera *cam, int frame)
+static void mcam_vmalloc_done(struct mcam_camera *cam, unsigned int frame)
{
tasklet_schedule(cam-s_tasklet);
}
@@ -471,20 +471,39 @@ static inline int mcam_check_dma_buffers(struct
mcam_camera *cam)
* space. In this way, we always have a buffer to DMA to and don't
* have to try to play games stopping and restarting the controller.
*/
-static void mcam_set_contig_buffer(struct mcam_camera *cam, int frame)
+static void mcam_set_contig_buffer(struct mcam_camera *cam, unsigned int frame)
{
struct mcam_vb_buffer *buf;
struct v4l2_pix_format *fmt = cam-pix_format;
unsigned long flags = 0;
spin_lock_irqsave(cam-list_lock, flags);
- /*
-* If there are no available buffers, go into single mode
-*/
if (list_empty(cam-buffers)) {
- buf = cam-vb_bufs[frame ^ 0x1];
- set_bit(CF_SINGLE_BUFFER, cam-flags);
- cam-frame_state.singles++;
+ /*
+* If there are no available buffers
+* go into single buffer mode
+*
+* If CCIC use Two Buffers mode
+* will use another remaining frame buffer
+* frame 0 - buf 1
+* frame 1 - buf 0
+*
+* If CCIC use Three Buffers mode
+* will use the 2rd remaining frame buffer
+* frame 0 - buf 2
+* frame 1 - buf 0
+* frame 2 - buf 1
+*/
+ buf = cam-vb_bufs[(frame + (MAX_FRAME_BUFS - 1))
+ % MAX_FRAME_BUFS];
+ if (cam-frame_state.tribufs == 0)
+ cam-frame_state.tribufs++;
+ else {
+ set_bit(CF_SINGLE_BUFFER, cam-flags);
+ cam-frame_state.singles++;
+ if (cam-frame_state.tribufs 2)
+ cam-frame_state.tribufs++;
+ }
} else {
/*
* OK, we have a buffer we can use.
@@ -493,17 +512,16 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, int frame)
queue);
list_del_init(buf-queue);
clear_bit(CF_SINGLE_BUFFER, cam-flags);
+ if (cam-frame_state.tribufs != (3 - MAX_FRAME_BUFS))
+ cam-frame_state.tribufs--;
}
Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Hey, Op 28-09-12 14:41, Maarten Lankhorst schreef: Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. The whole patch series is in my tree, I use stg so things might move around, do not use for merging currently: http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip It contains everything in here plus the patches for ttm to make it work, I use a old snapshot of drm-next + merge of nouveau as base. Description of what the parts do: Series to fix small api issues when moving over: drm/ttm: Remove cpu_writers related code drm/ttm: Add ttm_bo_is_reserved function drm/radeon: Use ttm_bo_is_reserved drm/vmwgfx: use ttm_bo_is_reserved drm/vmwgfx: remove use of fence_obj_args drm/ttm: remove sync_obj_arg drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup drm/ttm: remove sync_arg entirely drm/nouveau: unpin buffers before releasing to prevent lockdep warnings drm/nouveau: add reservation to nouveau_bo_vma_del drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Hey great, now we only have one user left for fence waiting before reserving, lets fix that and remove fence lock: ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before waiting, lets do it in the squash commit so we don't have to throw lock order around everywhere: drm/ttm: remove fence_lock -- Up to this point should be mergeable now Then we start working on lru_lock removal slightly, this means the lru list no longer is empty but can contain only reserved buffers: drm/ttm: do not check if list is empty in ttm_bo_force_list_clean drm/ttm: move reservations for ttm_bo_cleanup_refs -- Still mergeable up to this point, just fixes Patch series from this email: dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER fence: dma-buf cross-device synchronization (v9) seqno-fence: Hardware dma-buf implementation of fencing (v3) reservation: cross-device reservation support reservation: Add lockdep annotation and selftests Now hook it up to drm/ttm in a few steps: usage around reservations: drm/ttm: make ttm reservation calls behave like reservation calls drm/ttm: use dma_reservation api dma-buf: use reservations drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo then kill off the lru lock around reservation: drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: simplify ttm_eu_* The lru_lock removal patch removes the lock around lru_lock around the reservation, this will break the assumption that items on the lru list and swap list can always be reserved, and this gets patched up too. Is there any part in ttm you disagree with? I believe that this is all mergeable, the lru_lock removal patch could be moved to before the reservation parts, this might make merging easier, but I don't think there is any ttm part of the series that are wrong on a conceptual level. ~Maarten -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core
On Fri September 28 2012 15:47:20 Albert Wang wrote:
From: Libin Yang lby...@marvell.com
This patch adds the support of Soc Camera on marvell-ccic mcam-core.
The Soc Camera mode does not compatible with current mode.
Only one mode can be used at one time.
To use Soc Camera, CONFIG_VIDEO_MMP_SOC_CAMERA should be defined.
What's more, the platform driver should support Soc camera at the same time.
Also add MIPI interface and dual CCICs support in Soc Camera mode.
Signed-off-by: Albert Wang twan...@marvell.com
Signed-off-by: Libin Yang lby...@marvell.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 1034
++
drivers/media/platform/marvell-ccic/mcam-core.h | 126 +++-
2 files changed, 997 insertions(+), 163 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index ce2b7b4..4adb1ca 100755
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
...
+static int mcam_camera_querycap(struct soc_camera_host *ici,
+ struct v4l2_capability *cap)
+{
+ struct v4l2_dbg_chip_ident id;
+ struct mcam_camera *mcam = ici-priv;
+ struct soc_camera_device *icd = mcam-icd;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ int ret = 0;
+
+ cap-version = KERNEL_VERSION(0, 0, 5);
Don't fill in version. It's set to the kernel version automatically.
+ cap-capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
Please also set cap-device_caps. See the spec.
+ ret = v4l2_subdev_call(sd, core, g_chip_ident, id);
Yuck. Don't abuse this. g_chip_ident is for debugging purposes only.
+ if (ret 0) {
+ cam_err(mcam, %s %d\n, __func__, __LINE__);
+ return ret;
+ }
+
+ strcpy(cap-card, mcam-card_name);
+ strncpy(cap-driver, (const char *)(id.ident), 4);
No, the name of the driver is the name of this module: marvell_ccic.
It's *not* the name of the sensor driver.
+
+ return 0;
+}
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
[PATCH 2/2] drivers: media: video: Add support for Aptina ar0130 sensor
This driver adds basic support for Aptina ar0130 1.2M sensor. Changes for v2: 1: Include new test pattern control as pointed by Hans and Lad. 2: Remove soc_camera.h as suggested by Guennadi. 3: Change auto exposure control as pointed by Dan Rittersdorf. 4: Change incorrect return value as pointed by Nicolas. 5: Change crop and binning settings. Signed-off-by: Prashanth Subramanya sprasha...@aptina.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/ar0130.c | 1088 + drivers/media/video/ar0130_regs.h | 107 include/media/ar0130.h| 52 ++ include/media/v4l2-chip-ident.h |1 + 6 files changed, 1256 insertions(+) create mode 100644 drivers/media/video/ar0130.c create mode 100644 drivers/media/video/ar0130_regs.h create mode 100644 include/media/ar0130.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index c128fac..821c021 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -505,6 +505,13 @@ config VIDEO_VS6624 To compile this driver as a module, choose M here: the module will be called vs6624. +config VIDEO_AR0130 + tristate Aptina AR0130 support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + ---help--- + This is a Video4Linux2 sensor-level driver for the Aptina + ar0130 1.2 Mpixel camera. + config VIDEO_MT9M032 tristate MT9M032 camera sensor support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index b7da9fa..4f97e30 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_OV7670) += ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o +obj-$(CONFIG_VIDEO_AR0130) += ar0130.o obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o diff --git a/drivers/media/video/ar0130.c b/drivers/media/video/ar0130.c new file mode 100644 index 000..1fdbafa --- /dev/null +++ b/drivers/media/video/ar0130.c @@ -0,0 +1,1088 @@ +/* + * drivers/media/video/ar0130.c + * + * Aptina AR0130 sensor driver + * + * Copyright (C) 2012 Aptina Imaging + * + * Contributor Prashanth Subramanya sprasha...@aptina.com + * + * Based on MT9P031 driver + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include linux/delay.h +#include linux/device.h +#include linux/i2c.h +#include linux/log2.h +#include linux/pm.h +#include linux/slab.h +#include media/v4l2-subdev.h +#include linux/videodev2.h +#include linux/module.h + +#include media/ar0130.h +#include media/v4l2-chip-ident.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h +#include ar0130_regs.h + +#defineAR0130_ROW_START_MIN0 +#defineAR0130_ROW_START_MAX1280 +#defineAR0130_ROW_START_DEF0 +#defineAR0130_COLUMN_START_MIN 0 +#defineAR0130_COLUMN_START_MAX 960 +#defineAR0130_COLUMN_START_DEF 0 +#defineAR0130_WINDOW_HEIGHT_MIN360 +#defineAR0130_WINDOW_HEIGHT_MAX960 +#defineAR0130_WINDOW_HEIGHT_DEF960 +#defineAR0130_WINDOW_WIDTH_MIN 640 +#defineAR0130_WINDOW_WIDTH_MAX 1280 +#defineAR0130_WINDOW_WIDTH_DEF 1280 + +#define AR0130_VGA_WIDTH 640 +#define AR0130_VGA_HEIGHT 480 +#define AR0130_ENABLE 1 +#define AR0130_DISABLE 0 + +#define AR0130_CHIP_VERSION_REG0x3000 +#define AR0130_CHIP_ID 0x2402 +#define AR0130_RESET_REG 0x301A +#define AR0130_STREAM_ON 0x10DC +#define AR0130_STREAM_OFF 0x10D8 +#define AR0130_SEQ_PORT0x3086 +#define AR0130_SEQ_PORT_CTRL 0x3088 +#define AR0130_TEST_REG0x3070 +#defineAR0130_TEST_PATTERN_DISABLE 0x + +#define AR0130_DCDS_PROG_START_ADDR0x309E +#define AR0130_ADC_BITS_6_70x30E4 +#define AR0130_ADC_BITS_4_50x30E2 +#define
Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API
On Fri September 28 2012 14:43:32 Hans Verkuil wrote: Hi Antti, Mauro asked me to look into LNA as well, in particular how this could be done on the analog side as well. While reading through this patch I noticed that the new property was added to dtv_property_process_set, but not to dtv_property_process_get. Can you look into that and add 'get' support for this property? It's a sign of insanity when you start replying to your own email, but so be it :-) I've been thinking how this can be implemented in such a way that it works well in all the various board/tuner configurations. First, the property should be cached in dtv_frontend_properties, that way tuners with a built-in LNA can use it. The initial value should be AUTO, I guess. The property_process_set code changes to: case DTV_LNA: if (fe-ops.set_lna) r = fe-ops.set_lna(fe, tvp-u.data); if (!r) c-lna = tvp-u.data; break; Tuners can now check the c-lna value when set_params is called and take the appropriate steps if they have a built-in LNA. To be able to access the LNA from the V4L2 side you would need to add two new tuner ops in include/media/v4l2-subdev.h: int (*g_lna)(struct v4l2_subdev *sd, u32 *lna); int (*s_lna)(struct v4l2_subdev *sd, u32 lna); The tuner-core.c driver can implement these ops to get and set c-lna accordingly. A menu control would be needed to actually change the LNA. The code that handles that control would have to call a board-specific function if necessary (if the LNA is on the board), and call the tuner's s_lna op otherwise. The only question is whether the digital and analog APIs should share the same LNA setting or keep different LNA states for each. So if I call DTV_LNA to set the LNA, and then check the LNA control value from V4L2, should the two match? Or should we keep separate states and whenever you select digital or analog mode the LNA is updated with the corresponding LNA value for that mode. The latter is a bit more work (struct analog_parameters should probably be extended with an LNA value), but I do think it is a cleaner solution. I am not sure if the LNA work on the analog side should be done without having hardware that actually uses it, but at least the LNA support on the digital side should be done in such a way that it can be extended for analog as well. Anyway, I think this approach would work for analog LNA support. Comments are welcome! 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
[PATCH] tda18271-common: hold the I2C adapter during write transfers
The tda18271 datasheet says:
The image rejection calibration and RF tracking filter
calibration must be launched exactly as described in the
flowchart, otherwise bad calibration or even blocking of the
TDA18211HD can result making it impossible to communicate
via the I2C-bus.
(yeah, tda18271 refers there to tda18211 - likely a typo at their
datasheets)
That likely explains why sometimes tda18271 stops answering. That
is now happening more often on designs with drx-k chips, as the
firmware is now loaded asyncrousnly there.
While the above text doesn't explicitly tell that the I2C bus
couldn't be used by other devices during such initialization,
that seems to be a requirement there.
So, let's explicitly use the I2C lock there, avoiding I2C bus
share during those critical moments.
Compile-tested only. Please test.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/tuners/tda18271-common.c | 104 ++---
1 file changed, 71 insertions(+), 33 deletions(-)
diff --git a/drivers/media/tuners/tda18271-common.c
b/drivers/media/tuners/tda18271-common.c
index 221171e..18c77af 100644
--- a/drivers/media/tuners/tda18271-common.c
+++ b/drivers/media/tuners/tda18271-common.c
@@ -187,7 +187,8 @@ int tda18271_read_extended(struct dvb_frontend *fe)
return (ret == 2 ? 0 : ret);
}
-int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
+static int __tda18271_write_regs(struct dvb_frontend *fe, int idx, int len,
+ bool lock_i2c)
{
struct tda18271_priv *priv = fe-tuner_priv;
unsigned char *regs = priv-tda18271_regs;
@@ -198,7 +199,6 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx,
int len)
BUG_ON((len == 0) || (idx + len sizeof(buf)));
-
switch (priv-small_i2c) {
case TDA18271_03_BYTE_CHUNK_INIT:
max = 3;
@@ -214,7 +214,19 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx,
int len)
max = 39;
}
- tda18271_i2c_gate_ctrl(fe, 1);
+
+ /*
+* If lock_i2c is true, it will take the I2C bus for tda18271 private
+* usage during the entire write ops, as otherwise, bad things could
+* happen.
+* During device init, several write operations will happen. So,
+* tda18271_init_regs controls the I2C lock directly,
+* disabling lock_i2c here.
+*/
+ if (lock_i2c) {
+ tda18271_i2c_gate_ctrl(fe, 1);
+ i2c_lock_adapter(priv-i2c_props.adap);
+ }
while (len) {
if (max len)
max = len;
@@ -226,14 +238,17 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx,
int len)
msg.len = max + 1;
/* write registers */
- ret = i2c_transfer(priv-i2c_props.adap, msg, 1);
+ ret = __i2c_transfer(priv-i2c_props.adap, msg, 1);
if (ret != 1)
break;
idx += max;
len -= max;
}
- tda18271_i2c_gate_ctrl(fe, 0);
+ if (lock_i2c) {
+ i2c_unlock_adapter(priv-i2c_props.adap);
+ tda18271_i2c_gate_ctrl(fe, 0);
+ }
if (ret != 1)
tda_err(ERROR: idx = 0x%x, len = %d,
@@ -242,10 +257,16 @@ int tda18271_write_regs(struct dvb_frontend *fe, int idx,
int len)
return (ret == 1 ? 0 : ret);
}
+int tda18271_write_regs(struct dvb_frontend *fe, int idx, int len)
+{
+ return __tda18271_write_regs(fe, idx, len, true);
+}
+
/*-*/
-int tda18271_charge_pump_source(struct dvb_frontend *fe,
- enum tda18271_pll pll, int force)
+static int __tda18271_charge_pump_source(struct dvb_frontend *fe,
+enum tda18271_pll pll, int force,
+bool lock_i2c)
{
struct tda18271_priv *priv = fe-tuner_priv;
unsigned char *regs = priv-tda18271_regs;
@@ -255,9 +276,16 @@ int tda18271_charge_pump_source(struct dvb_frontend *fe,
regs[r_cp] = ~0x20;
regs[r_cp] |= ((force 1) 5);
- return tda18271_write_regs(fe, r_cp, 1);
+ return __tda18271_write_regs(fe, r_cp, 1, lock_i2c);
+}
+
+int tda18271_charge_pump_source(struct dvb_frontend *fe,
+ enum tda18271_pll pll, int force)
+{
+ return __tda18271_charge_pump_source(fe, pll, force, true);
}
+
int tda18271_init_regs(struct dvb_frontend *fe)
{
struct tda18271_priv *priv = fe-tuner_priv;
@@ -267,6 +295,13 @@ int tda18271_init_regs(struct dvb_frontend *fe)
i2c_adapter_id(priv-i2c_props.adap),
priv-i2c_props.addr);
+ /*
+* Don't let any other I2C transfer to happen at adapter during init,
+* as those could cause
Re: omap3isp: wrong image after resizer with mt9v034 sensor
Hi Laurent,
2012/9/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Enric,
On Friday 28 September 2012 10:21:56 Enric Balletbò i Serra wrote:
2012/9/28 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Thursday 27 September 2012 18:05:56 Enric Balletbò i Serra wrote:
2012/9/27 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Wednesday 26 September 2012 16:15:35 Enric Balletbò i Serra wrote:
2012/9/26 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Wednesday 26 September 2012 09:57:53 Enric Balletbò i Serra
wrote:
[snip]
You had reason. Checking the data lines of the camera bus with an
oscilloscope I see I had a problem, exactly in D8 /D9 data lines.
I'm curious, how have you fixed that ?
The board had a pull-down 4k7 resistor which I removed in these lines
(D8/D9). The board is prepared to accept sensors from 8 to 12 bits,
lines from D8 to D12 have a pull-down resistor to tie down the line by
default.
With the oscilloscope I saw that D8/D9 had problems to go to high
level like you said, then I checked the schematic and I saw these
resistors.
Now I can capture images but the color is still wrong, see the
following
image captured with pipeline SENSOR - CCDC OUTPUT
http://downloads.isee.biz/pub/files/patterns/img-01.pnm
Now the image was converted using :
./raw2rgbpnm -s 752x480 -f SGRBG10 img-01.bin
img-01.pnm
And the raw data can be found here:
http://downloads.isee.biz/pub/files/patterns/img-01.bin
Any idea where I can look ? Thanks.
Your sensors produces BGGR data if I'm not mistaken, not GRBG.
raw2rgbpnm doesn't support BGGR (yet), but the OMAP3 ISP preview
engine
can convert that to YUV since v3.5. Just make your sensor driver
expose
the right media bus format and configure the pipeline accordingly.
The datasheet (p.10,11) says that the Pixel Color Pattern is as
follows.
direction
n 4321
.. GB GB GB GB
.. RG RG RG RG
So seems you're right, if the first byte is on the right the sensor
produces BGGR. But for some reason the mt9v032 driver uses GRBG data.
You can change the Bayer pattern by moving the crop rectangle. That how
the mt9v032 driver ensures a GRBG pattern even though the first active
pixel in the sensor array is a blue one. As the MT9V034 first active
pixel
is located at different coordinates you will have to modify the crop
rectangle computation logic to get GRBG.
Please, could you explain how to do this ? I'm a newbie into image
sensors world :-)
Let's assume the following Bayer pattern (left to right and top to bottom
direction).
| 1 2 3 4 5 6 7 8 ...
--
1| G R G R G R G R ...
2| B G B G B G B G ...
3| G R G R G R G R ...
4| B G B G B G B G ...
5| G R G R G R G R ...
6| B G B G B G B G ...
7| G R G R G R G R ...
8| B G B G B G B G ...
.| ...
If you crop the (1,1)/4x4 rectangle from that sensor you will get
| 1 2 3 4
--
1| G R G R
2| B G B G
3| G R G R
4| B G B G
which is clearly a GRBG pattern. If you crop the (2,1)/4x4 rectangle you
will get
| 2 3 4 5
--
1| R G R G
2| G B G B
3| R G R G
4| G B G B
which is now a RGGB pattern. The pattern you get out of your sensor thus
depends on the crop rectangle position.
Many thanks for the explanation. I'm learning a lot with your explanations
:-)
Maybe is related with following lines which writes register 0x0D Read
Mode (p.26,27) and presumably flips row or column bytes (not sure
about this I need to check)
334 /* Configure the window size and row/column bin */
335 hratio = DIV_ROUND_CLOSEST(crop-width, format-width);
336 vratio = DIV_ROUND_CLOSEST(crop-height, format-height);
337
338 ret = mt9v032_write(client, MT9V032_READ_MODE,
339 (hratio - 1)
MT9V032_READ_MODE_ROW_BIN_SHIFT |
340 (vratio - 1)
MT9V032_READ_MODE_COLUMN_BIN_SHIFT);
Nonetheless, I changed the driver to configure for BGGR pattern. Using
the Sensor-CCDC-Preview-Resizer pipeline I captured the data with
yavta and converted using raw2rgbpnm program.
./raw2rgbpnm -s 752x480 -f UYVY img-01.uyvy img-01.pnm
and the result is
http://downloads.isee.biz/pub/files/patterns/img-02.pnm
http://downloads.isee.biz/pub/files/patterns/img-02.bin
The image looks better than older, not perfect, but better. The image
is only a bit yellowish. Could be this a hardware issue ? We are close
to ...
It's like a white balance issue. The OMAP3 ISP hardware doesn't perform
automatic white balance, you will need to implement an AWB algorithm in
software. You can have a
Re: [PATCH 4/5] reservation: cross-device reservation support
On 9/28/12 2:43 PM, Maarten Lankhorst wrote:
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the buffer.
Anything is done with the buffer should probably be rephrased, as
different members of the buffer struct
may be protected by different locks. It may not be practical or even
possible to
protect all buffer members with reservation.
Some followup patches are needed in ttm so the lru_lock is no longer
taken during the reservation step. This makes the lockdep annotation
patch a lot more useful, and the assumption that the lru lock protects
atomic removal off the lru list will fail soon, anyway.
As previously discussed, I'm unfortunately not prepared to accept
removal of the reserve-lru atomicity
into the TTM code at this point.
The current code is based on this assumption and removing it will end up
with
efficiencies, breaking the delayed delete code and probably a locking
nightmare when trying to write
new TTM code.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Documentation/DocBook/device-drivers.tmpl |2
drivers/base/Makefile |2
drivers/base/reservation.c| 285 +
include/linux/reservation.h | 179 ++
4 files changed, 467 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/reservation.c
create mode 100644 include/linux/reservation.h
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index ad14396..24e6e80 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -129,6 +129,8 @@ X!Edrivers/base/interface.c
!Edrivers/base/fence.c
!Iinclude/linux/fence.h
!Iinclude/linux/seqno-fence.h
+!Edrivers/base/reservation.c
+!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
/sect1
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 0026563..f6f731d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER) += firmware_class.o
obj-$(CONFIG_NUMA)+= node.o
diff --git a/drivers/base/reservation.c b/drivers/base/reservation.c
new file mode 100644
index 000..93e2d9f
--- /dev/null
+++ b/drivers/base/reservation.c
@@ -0,0 +1,285 @@
+/*
+ * Copyright (C) 2012 Canonical Ltd
+ *
+ * Based on bo.c which bears the following copyright notice,
+ * but is dual licensed:
+ *
+ * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+/*
+ * Authors: Thomas Hellstrom thellstrom-at-vmware-dot-com
+ */
+
+#include linux/fence.h
+#include linux/reservation.h
+#include linux/export.h
+#include linux/sched.h
+#include linux/slab.h
+
+atomic64_t reservation_counter = ATOMIC64_INIT(1);
+EXPORT_SYMBOL(reservation_counter);
+
+int
+object_reserve(struct reservation_object *obj, bool intr, bool no_wait,
+ reservation_ticket_t *ticket)
+{
+ int ret;
+ u64 sequence = ticket ? ticket-seqno : 1;
+ u64 oldseq;
+
+ while (unlikely(oldseq = atomic64_cmpxchg(obj-reserved, 0,
sequence))) {
+
+ /**
+
Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API
Em Fri, 28 Sep 2012 16:21:35 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Fri September 28 2012 14:43:32 Hans Verkuil wrote: Hi Antti, Mauro asked me to look into LNA as well, in particular how this could be done on the analog side as well. Thanks for that! While reading through this patch I noticed that the new property was added to dtv_property_process_set, but not to dtv_property_process_get. Can you look into that and add 'get' support for this property? It's a sign of insanity when you start replying to your own email, but so be it :-) :) I've been thinking how this can be implemented in such a way that it works well in all the various board/tuner configurations. First, the property should be cached in dtv_frontend_properties, that way tuners with a built-in LNA can use it. The initial value should be AUTO, I guess. The property_process_set code changes to: case DTV_LNA: if (fe-ops.set_lna) r = fe-ops.set_lna(fe, tvp-u.data); if (!r) c-lna = tvp-u.data; break; Tuners can now check the c-lna value when set_params is called and take the appropriate steps if they have a built-in LNA. To be able to access the LNA from the V4L2 side you would need to add two new tuner ops in include/media/v4l2-subdev.h: int (*g_lna)(struct v4l2_subdev *sd, u32 *lna); int (*s_lna)(struct v4l2_subdev *sd, u32 lna); The tuner-core.c driver can implement these ops to get and set c-lna accordingly. A menu control would be needed to actually change the LNA. The code that handles that control would have to call a board-specific function if necessary (if the LNA is on the board), and call the tuner's s_lna op otherwise. Makes sense. The only question is whether the digital and analog APIs should share the same LNA setting or keep different LNA states for each. So if I call DTV_LNA to set the LNA, and then check the LNA control value from V4L2, should the two match? Or should we keep separate states and whenever you select digital or analog mode the LNA is updated with the corresponding LNA value for that mode. The latter is a bit more work (struct analog_parameters should probably be extended with an LNA value), but I do think it is a cleaner solution. I think they both should share the same LNA state, as this depends on the physical connection (e. g. if the antenna has LNA; if the signal reception is weak or strong with that particular antenna). I am not sure if the LNA work on the analog side should be done without having hardware that actually uses it, but at least the LNA support on the digital side should be done in such a way that it can be extended for analog as well. There are several saa7134 hardware with LNA support. I have one of such boards here, although never needed to dig into the LNA stuff on it. Anyway, I think this approach would work for analog LNA support. Comments are welcome! 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 4/5] reservation: cross-device reservation support
Op 28-09-12 17:29, Thomas Hellström schreef: On 9/28/12 2:43 PM, Maarten Lankhorst wrote: This adds support for a generic reservations framework that can be hooked up to ttm and dma-buf and allows easy sharing of reservations across devices. The idea is that a dma-buf and ttm object both will get a pointer to a struct reservation_object, which has to be reserved before anything is done with the buffer. Anything is done with the buffer should probably be rephrased, as different members of the buffer struct may be protected by different locks. It may not be practical or even possible to protect all buffer members with reservation. Agreed. Some followup patches are needed in ttm so the lru_lock is no longer taken during the reservation step. This makes the lockdep annotation patch a lot more useful, and the assumption that the lru lock protects atomic removal off the lru list will fail soon, anyway. As previously discussed, I'm unfortunately not prepared to accept removal of the reserve-lru atomicity into the TTM code at this point. The current code is based on this assumption and removing it will end up with efficiencies, breaking the delayed delete code and probably a locking nightmare when trying to write new TTM code. The lru lock removal patch fixed the delayed delete code, it really is not different from the current situation. In fact it is more clear without the guarantee what various parts are trying to protect. Nothing prevents you from holding the lru_lock while trylocking, leaving that guarantee intact for that part. Can you really just review the patch and tell me where it breaks and/or makes the code unreadable? See my preemptive reply to patch 1/5 for details. I would prefer you followup there. :-) ~Maarten -- 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: tda18271 driver power consumption
On 09/28/2012 02:43 PM, Mauro Carvalho Chehab wrote: Em Thu, 27 Sep 2012 17:58:24 -0400 Michael Krufky mkru...@linuxtv.org escreveu: On Thu, Sep 27, 2012 at 5:38 PM, Antti Palosaari cr...@iki.fi wrote: On 09/28/2012 12:20 AM, Michael Krufky wrote: Mike, There is other problem too. PCTV 520e, which is Em28xx + DRX-K + TDA18271, fails to attach tuner now. Tuner is wired behind DRX-K I2C bus. TDA18271 driver does very much I/O during attach and I2C error is raised during attach now. Earlier it worked as DRX-K firmware was downloaded before tuner was attached, but now both DRX-K fw download and tuner attach happens same time leading that error. Why is the DRX-K firmware downloading at the same time as tuner attach? Shouldn't the demod attach be finished before the tuner attach begins? Michael, What happens is that udev changes forced drivers to load firmware asynchronously, as, otherwise, udev won't load any firmware at all. Also, there's no warranty that the firmware will be loaded on 2 seconds or so (Anti's hack were to add a 2 seconds wait after drxk atttach, to wait for firmware load). IMHO whole current DRX-K FW is broken by design. 1) if fw is not really needed it should not be loaded on attach() instead first use case at .init() 2) if fw is needed then it must be loaded and wait chip is up and running and after that return from attach() When you done it asynchronously like that, there is big you hit more problems depending on hardware configuration etc. I explained that earlier too. But lets take more real world example. There is USB DVB-S device. USB-bridge needs first firmware in order to offer I2C adapter. We need USB-bridge I2C-adapter to probe demodulator which sits on bridge I2C-bus. After demodulator is found we need to download firmware fir demodulator in order to find out tuner. Tuner sits behind demod I2C-bus. OK, download fw and start demod = get access for demod I2C-bus. Then probe used tuner. Download FW for tuner in order to get access for tuner GPIOs which are in that case controlled by tuner firmware. Finally there is LNB voltage controller which is controlled by tuner GPIO. We ask tuner firmware to disable LNB voltage supply. Quite worst possible scenario, but highly possible. And it cannot be performed until firmware are loaded for each chip one by one. The only place this kind asynchronous hack is allowed is bridge driver - leaving the rest as those are. And my real opinion is that this kind of functionality does not belong to drivers at all but somewhere more lower levels like USB/PCI core routines. What I suspect is that tda18271 init is being interruped in the middle, by the drxk firmware load. If this is the case, the solution is clean and quick: just use the new i2c_lock_adapter() way to lock the I2C bus to tda18271 during the critical part of the code where the register init happens. 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
Re: [PATCH] usb id addition for Terratec Cinergy T Stick Dual rev. 2
I will NACK that initially because that USB ID already used by AF9015 driver. You have to explain / study what happens when AF9015 driver claims that device same time. Hi Antti With the Cinergy stick alone, dvb_usb_af9015 is predictably loaded, but doesn't prevent dvb_usb_it913x from working nicely. If an afatech 9015 stick is connected, such as an AverTV Volar Black HD (A850), it will be recognized and doesn't affect the other device. *But* it runs into trouble if the two devices were connected at bootup, or if the Cinergy stick is inserted after the other one : --- [1.264018] usb 2-1: new high speed USB device using ehci_hcd and address 2 [1.382487] usb 2-1: New USB device found, idVendor=0ccd, idProduct=0099 [1.382490] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1.382492] usb 2-1: Product: DVB-T TV Stick [1.382494] usb 2-1: Manufacturer: ITE Technologies, Inc. [1.385073] input: ITE Technologies, Inc. DVB-T TV Stick as /devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.1/input/input1 [1.385147] generic-usb 0003:0CCD:0099.0001: input,hidraw0: USB HID v1.01 Keyboard [ITE Technologies, Inc. DVB-T TV Stick] on usb-:00:1d.7-1 input1 [5.045527] usbcore: registered new interface driver dvb_usb_it913x [5.147276] it913x: Chip Version=01 Chip Type=9135 [5.147524] it913x: Firmware Version 33684956 [5.148649] it913x: Remote HID mode NOT SUPPORTED [5.149024] it913x: Dual mode=3 Tuner Type=0 [5.149028] usb 2-1: dvb_usbv2: found a 'ITE 9135(9006) Generic' in warm state [5.149077] usb 2-1: dvb_usbv2: will pass the complete MPEG2 transport stream to the software demuxer [5.149307] DVB: registering new adapter (ITE 9135(9006) Generic) [5.174907] usb 1-4: dvb_usbv2: downloading firmware from file 'dvb-usb-af9015.fw' [5.241934] usb 1-4: dvb_usbv2: found a 'AverMedia AVerTV Volar Black HD (A850)' in warm state [5.614827] usb 1-4: dvb_usbv2: will pass the complete MPEG2 transport stream to the software demuxer [5.614866] DVB: registering new adapter (AverMedia AVerTV Volar Black HD (A850)) [5.710026] af9013: firmware version 4.95.0.0 [5.712151] DVB: registering adapter 1 frontend 0 (Afatech AF9013)... [5.813139] MXL5005S: Attached at address 0xc6 [5.818896] usb 1-4: dvb_usbv2: 'AverMedia AVerTV Volar Black HD (A850)' successfully initialized and connected [7.266161] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110 [7.266247] it913x-fe: ADF table value :00 [9.267200] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110 [ 11.267153] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110 [ 13.267250] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110 [ 15.267089] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110 [ 17.267162] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110 [ 19.267139] usb 2-1: dvb_usbv2: 2nd usb_bulk_msg() failed=-110 [ 19.267218] it913x-fe: Crystal Frequency :1200 Adc Frequency :2025 ADC X2: 01 [ 19.267296] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' error while loading driver (-19) [ 19.267472] usb 2-1: dvb_usbv2: 'ITE 9135(9006) Generic' successfully deinitialized and disconnected --- I'm unfortunately not able to rewrite the driver, but I'm willing to provide any information about the device to help its correct identification. Here is what lsusb yields : --- Bus 002 Device 003: ID 0ccd:0099 TerraTec Electronic GmbH Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x0099 bcdDevice2.00 iManufacturer 1 ITE Technologies, Inc. iProduct2 DVB-T TV Stick iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 71 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer
Error when doing build of media modules: WARNING: snd_tea575x_init [drivers/media/radio/radio-shark.ko] undefined!
Just giving a proper subject -- Forwarded message -- From: Marcos Souza marcos.souza@gmail.com Date: 2012/9/28 Subject: Build To: linux-media@vger.kernel.org, linux-ker...@vger.kernel.org Hi media guys, After try to build the media drivers with some radios enabled, I got this error: marcos@tux:/mnt/dados/gitroot/linux$ make M=drivers/media Building modules, stage 2. MODPOST 21 modules WARNING: snd_tea575x_init [drivers/media/radio/radio-shark.ko] undefined! WARNING: snd_tea575x_exit [drivers/media/radio/radio-shark.ko] undefined! WARNING: snd_tea575x_init [drivers/media/radio/radio-maxiradio.ko] undefined! WARNING: snd_tea575x_exit [drivers/media/radio/radio-maxiradio.ko] undefined! I saw that there is a EXPORT_SYMBOL of these functions in the file sound/i2c/other/tea575x-tuner.c But, I don't know how to find this... Can someone show me how can I fix this? Thanks since now! -- Att, Marcos Paulo de Souza Acadêmico de Ciencia da Computação - FURB - SC Github: https://github.com/marcosps/ Uma vida sem desafios é uma vida sem razão A life without challenges, is a non reason life -- Att, Marcos Paulo de Souza Acadêmico de Ciencia da Computação - FURB - SC Github: https://github.com/marcosps/ Uma vida sem desafios é uma vida sem razão A life without challenges, is a non reason life -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API
On Fri September 28 2012 17:30:05 Mauro Carvalho Chehab wrote: Em Fri, 28 Sep 2012 16:21:35 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Fri September 28 2012 14:43:32 Hans Verkuil wrote: Hi Antti, Mauro asked me to look into LNA as well, in particular how this could be done on the analog side as well. Thanks for that! While reading through this patch I noticed that the new property was added to dtv_property_process_set, but not to dtv_property_process_get. Can you look into that and add 'get' support for this property? It's a sign of insanity when you start replying to your own email, but so be it :-) :) I've been thinking how this can be implemented in such a way that it works well in all the various board/tuner configurations. First, the property should be cached in dtv_frontend_properties, that way tuners with a built-in LNA can use it. The initial value should be AUTO, I guess. The property_process_set code changes to: case DTV_LNA: if (fe-ops.set_lna) r = fe-ops.set_lna(fe, tvp-u.data); if (!r) c-lna = tvp-u.data; break; Tuners can now check the c-lna value when set_params is called and take the appropriate steps if they have a built-in LNA. To be able to access the LNA from the V4L2 side you would need to add two new tuner ops in include/media/v4l2-subdev.h: int (*g_lna)(struct v4l2_subdev *sd, u32 *lna); int (*s_lna)(struct v4l2_subdev *sd, u32 lna); The tuner-core.c driver can implement these ops to get and set c-lna accordingly. A menu control would be needed to actually change the LNA. The code that handles that control would have to call a board-specific function if necessary (if the LNA is on the board), and call the tuner's s_lna op otherwise. Makes sense. The only question is whether the digital and analog APIs should share the same LNA setting or keep different LNA states for each. So if I call DTV_LNA to set the LNA, and then check the LNA control value from V4L2, should the two match? Or should we keep separate states and whenever you select digital or analog mode the LNA is updated with the corresponding LNA value for that mode. The latter is a bit more work (struct analog_parameters should probably be extended with an LNA value), but I do think it is a cleaner solution. I think they both should share the same LNA state, as this depends on the physical connection (e. g. if the antenna has LNA; if the signal reception is weak or strong with that particular antenna). I am not sure if the LNA work on the analog side should be done without having hardware that actually uses it, but at least the LNA support on the digital side should be done in such a way that it can be extended for analog as well. There are several saa7134 hardware with LNA support. I have one of such boards here, although never needed to dig into the LNA stuff on it. I'll wait until Antti makes the necessary changes on the digital side, after that I'll see if I can make a patch for the analog part, and post that. There is an outside chance that I have a board with an LNA as well: for ivtv there were issues with a Samsung TCPN 2121P30A tuner where the LNA had to be turned on or off manually (it should have been automatic but due to a hardware bug that didn't work). This was never supported in ivtv, but this would make a good test case. The only problem is that I don't know if I still have that card or if I gave it to Andy. I think it went to him, actually. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qv4l2-bug / libv4lconvert API issue
Hi, Am 27.09.2012 21:41, schrieb Hans de Goede: Hi, On 09/27/2012 03:20 PM, Frank Schäfer wrote: snip What you've found is a qv4l2 bug (do you have the latest version?) Of course, I'm using the latest developer version. Even if this is just a qv4l2-bug: how do you want to fix it without removing the format selction feature ? Well, if qv4l2 can only handle rgb24 data, then it should gray out the format selection (fixing it at rgb24) when not in raw mode. So you say just remove this feature from qv4l2. I prefer fixing the library / API instead. v4lconvert_convert should only be called with src_fmt and dest_fmt parameters which are the result of a v4lconvert_try_format call, which clearly is not the case here! Why ? Because our library code is broken ? ;) Is this important restriction documented somewhere ? one is supposed to either use libv4l2, or do raw device access and then call libv4lconvert directly. Even when using libv4lconvert only, multiple frame conversions are still causing the same trouble. True, but doing multiple conversions on one frame is just crazy ... Well, I would say not necessary in most cases. But I can certainly think of use cases (other than what qv4l2 does). At least it should be possible and I think this is what application programmers expect when using a conversion function from a library. Hans, first of all, I would like to say that my intention is not to savage your work. I know API design and maintanance is very difficult and you are doing a great job. Things like this just happen and we have to make the best out of it. I will gladly admit that since libv4lconvert has organically grown things like flipping and software processing, the API is no longer ideal :) So let's improve it ! :) But saying that libv4l2 and libv4lconvert can't be used at the same (although they are separate public libraries) and that v4lconvert_convert() may only be called once per frame seems to me like a - I would say weird - reinterpretation of the API... I don't think this is what applications currently expect (qv4l2 doesn't ;) ) and at least this would need public clarification. Using the 2 at the same time never was the intention libv4lconvert lies *beneath* libv4l2 in the stack. Yeah, sure. Using them both at the same time would be like using some high level file io API, while at the same making lowlevel seek / read / write calls on the underlying fd and then expecting things to behave consistently. 00.9% of all apps should (and do) use the highlevel libv4l2 API. Some testing / developer apps like qv4l2 use libv4lconvert directly. The problem here is, that we actually have TWO high level APIs which interact in a - let's call it unfortunate - way. This interaction is not clear for the users (due to the transparent processing stuff) and it doesn't match not what users expect. But I think we can fix it and gain some nice extra features as a bonus. And I must admit that I've considered simple making the libv4lconvert API private at times. :D That would certainly make things consistent ;) So let's see if there is a possibility to fix the issue by improving the libraries without breaking the API. What about the following solution: - make v4lconvert_convert_pixfmt() and v4lconvert_crop() public functions and fix qv4l2 to use them instead of v4lconvert_convert() - also make the flip and rotation functions (v4lconvert_flip(), v4lconvert_rotate90()) publicly available That would need some careful review of their API's but after that yes that should be doable. - modify libv4l2 to call v4lconvert_convert_pixfmt() and the flip+rotation+crop functions instead of v4lconvert_convert() - fix v4lconvert_convert() to not do transparent image flipping/rotation (means = call v4lconvert_convert_pixfmt() and v4lconvert_crop() only). Erm, no, have you looked at v4lconvert_convert it does a lot of magic with figuring out how much intermediate buffers it needs (skipping steps where possible), caches those buffers rather then re-alloc them every frame, etc. Making it do less means loosing some chances for optimization, and frankly it works well. I don't see why we would need some do some stuff but not all function when we also offer all the separate steps for users who want them. Did you notice the mail I've sent a few minutes later ? ;) I agree, we have to keep it as is but should mark it as deprecated. Also I still consider the rotate 90 for pac7302 part of the pixfmt conversion, this is something specific to how these cameras encode the picture, not a generic thing. Yes, but why not make it a generic feature ? Would be nice to have. (ever had a webcam with a clamp socket ?) But this is just about a side effect, lets concentrate on the main issue. For API-clean-up: - create a copy of (the fixed) v4lconvert_convert() called something like v4lconvert_convert_crop() - declare v4lconvert_convert() as
Re: [git:v4l-dvb/for_v3.7] [media] add LNA support for DVB API
On 09/28/2012 08:07 PM, Hans Verkuil wrote: On Fri September 28 2012 17:30:05 Mauro Carvalho Chehab wrote: Em Fri, 28 Sep 2012 16:21:35 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Fri September 28 2012 14:43:32 Hans Verkuil wrote: Hi Antti, Mauro asked me to look into LNA as well, in particular how this could be done on the analog side as well. Thanks for that! While reading through this patch I noticed that the new property was added to dtv_property_process_set, but not to dtv_property_process_get. Can you look into that and add 'get' support for this property? It's a sign of insanity when you start replying to your own email, but so be it :-) :) I've been thinking how this can be implemented in such a way that it works well in all the various board/tuner configurations. First, the property should be cached in dtv_frontend_properties, that way tuners with a built-in LNA can use it. The initial value should be AUTO, I guess. The property_process_set code changes to: case DTV_LNA: if (fe-ops.set_lna) r = fe-ops.set_lna(fe, tvp-u.data); if (!r) c-lna = tvp-u.data; break; Tuners can now check the c-lna value when set_params is called and take the appropriate steps if they have a built-in LNA. To be able to access the LNA from the V4L2 side you would need to add two new tuner ops in include/media/v4l2-subdev.h: int (*g_lna)(struct v4l2_subdev *sd, u32 *lna); int (*s_lna)(struct v4l2_subdev *sd, u32 lna); The tuner-core.c driver can implement these ops to get and set c-lna accordingly. A menu control would be needed to actually change the LNA. The code that handles that control would have to call a board-specific function if necessary (if the LNA is on the board), and call the tuner's s_lna op otherwise. Makes sense. The only question is whether the digital and analog APIs should share the same LNA setting or keep different LNA states for each. So if I call DTV_LNA to set the LNA, and then check the LNA control value from V4L2, should the two match? Or should we keep separate states and whenever you select digital or analog mode the LNA is updated with the corresponding LNA value for that mode. The latter is a bit more work (struct analog_parameters should probably be extended with an LNA value), but I do think it is a cleaner solution. I think they both should share the same LNA state, as this depends on the physical connection (e. g. if the antenna has LNA; if the signal reception is weak or strong with that particular antenna). I am not sure if the LNA work on the analog side should be done without having hardware that actually uses it, but at least the LNA support on the digital side should be done in such a way that it can be extended for analog as well. There are several saa7134 hardware with LNA support. I have one of such boards here, although never needed to dig into the LNA stuff on it. I'll wait until Antti makes the necessary changes on the digital side, after that I'll see if I can make a patch for the analog part, and post that. There is an outside chance that I have a board with an LNA as well: for ivtv there were issues with a Samsung TCPN 2121P30A tuner where the LNA had to be turned on or off manually (it should have been automatic but due to a hardware bug that didn't work). This was never supported in ivtv, but this would make a good test case. The only problem is that I don't know if I still have that card or if I gave it to Andy. I think it went to him, actually. Hans, your changes moving lna to property cache is fine for my eyes. I can change it if you wish, but maybe Sunday or next week I dropped get operation originally as I wanted to keep workload small on that time. Also there was some other design issues, like one I selected AUTO as minimum possible value to leave space for extending possible values (both attenuation and gain). For now it is just on/off, but there is existing LNAs having more gain levels, not to mention VGAs and LNAs integrated to RF-tuners. Other design issue was units. Gains are measured as units of decibels, but I decided to use device specific steps instead of making some mechanism to enumerate supported gain levels. Here is some discussion behind that LNA. http://www.spinics.net/lists/linux-media/msg50132.html http://www.spinics.net/lists/linux-media/msg50133.html http://www.spinics.net/lists/linux-media/msg50139.html http://blog.palosaari.fi/2012/07/patch-rfc-add-lna-support-for-dvb-api.html 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
