Re: [PATCH v4] [media] vivi: Teach it to tune FPS
On Fri, Nov 16, 2012 at 01:46:58PM -0200, Mauro Carvalho Chehab wrote:
Em 16-11-2012 11:38, Hans Verkuil escreveu:
On Wed November 7 2012 12:30:01 Kirill Smelkov wrote:
[...]
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 37d0af8..5d1b374 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -65,8 +65,11 @@ MODULE_PARM_DESC(vid_limit, capture memory limit in
megabytes);
/* Global font descriptor */
static const u8 *font8x16;
-/* default to NTSC timeperframe */
-static const struct v4l2_fract TPF_DEFAULT = {.numerator = 1001,
.denominator = 3};
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+ tpf_min = {.numerator = 1, .denominator = UINT_MAX}, /*
1/infty */
+ tpf_max = {.numerator = UINT_MAX, .denominator = 1}, /*
infty */
I understand your reasoning here, but I wouldn't go with UINT_MAX here.
Something like
1/1000 tpf (or 1 ms) up to 86400/1 tpf (or once a day). With UINT_MAX I am
afraid we
might hit application errors when they manipulate these values. The shortest
time
between frames is 1 ms anyway.
It's the only comment I have, it looks good otherwise.
As those will be a arbitrary values, I suggest to declare a macro for it at
the
beginning of vivi.c file, with some comment explaining the rationale of the
choose,
and what else needs to be changed, if this changes (e. g. less than 1ms would
require
changing the image generation logic, to avoid producing frames with equal
content).
Maybe something like this? (please note, I'm not a good text writer. If
this needs adjustment please help me shape the text up)
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index 5d1b374..45b8a81 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -36,6 +36,18 @@
#define VIVI_MODULE_NAME vivi
+/* Maximum allowed frame rate
+ *
+ * Vivi will allow setting timeperframe in [1/FPS_MAX - FPS_MAX/1] range.
+ *
+ * Ideally FPS_MAX should be infinity, i.e. practically UINT_MAX, but that
+ * might hit application errors when they manipulate these values.
+ *
+ * Besides, for tpf 1ms image-generation logic should be changed, to avoid
+ * producing frames with equal content.
+ */
+#define FPS_MAX 1000
+
#define MAX_WIDTH 1920
#define MAX_HEIGHT 1200
@@ -67,8 +79,8 @@ static const u8 *font8x16;
/* timeperframe: min/max and default */
static const struct v4l2_fract
- tpf_min = {.numerator = 1, .denominator = UINT_MAX}, /*
1/infty */
- tpf_max = {.numerator = UINT_MAX, .denominator = 1}, /*
infty */
+ tpf_min = {.numerator = 1, .denominator = FPS_MAX}, /*
~1/infty */
+ tpf_max = {.numerator = FPS_MAX,.denominator = 1}, /*
~infty */
tpf_default = {.numerator = 1001, .denominator = 3}; /*
NTSC */
#define dprintk(dev, level, fmt, arg...) \
--
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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi.
Just have time to test. I apologize for delay.
I'd like to squash all the s3c-camif patches before sending upstream,
if you don't mind. And to add your Signed-off at the final patch.
Ok. Squash.
I might have introduced bugs in the image effects handling, hopefully
there is none. I couldn't test it though. Could you test that on your
side with s3c64xx ?
Got some error. Seems effect updated only when I set new CrCb value.
Seems it's incorrect:
case V4L2_CID_COLORFX:
if (camif-ctrl_colorfx_cbcr-is_new) {
camif-colorfx = camif-ctrl_colorfx-val;
/* Set Cb, Cr */
switch (ctrl-val) {
case V4L2_COLORFX_SEPIA:
camif-ctrl_colorfx_cbcr-val = 0x7391;
break;
case V4L2_COLORFX_SET_CBCR: /* noop */
break;
default:
/* for V4L2_COLORFX_BW and others */
camif-ctrl_colorfx_cbcr-val = 0x8080;
}
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
break;
Moving camif-colorfx = camif-ctrl_colorfx-val; out of condition
fixes the problem, but setting CrCb value control affect all effects
(sepia and BW), not only V4L2_COLORFX_SET_CBCR. Seems condition should
be removed and colorfx value should be checked set on every effect
change.
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index ceab03a..9c01f4f 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1526,19 +1526,17 @@ static int s3c_camif_subdev_s_ctrl(struct
v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_COLORFX:
- if (camif-ctrl_colorfx_cbcr-is_new) {
- camif-colorfx = camif-ctrl_colorfx-val;
- /* Set Cb, Cr */
- switch (ctrl-val) {
- case V4L2_COLORFX_SEPIA:
- camif-ctrl_colorfx_cbcr-val = 0x7391;
- break;
- case V4L2_COLORFX_SET_CBCR: /* noop */
- break;
- default:
- /* for V4L2_COLORFX_BW and others */
- camif-ctrl_colorfx_cbcr-val = 0x8080;
- }
+ camif-colorfx = camif-ctrl_colorfx-val;
+ /* Set Cb, Cr */
+ switch (ctrl-val) {
+ case V4L2_COLORFX_SEPIA:
+ camif-ctrl_colorfx_cbcr-val = 0x7391;
+ break;
+ case V4L2_COLORFX_SET_CBCR: /* noop */
+ break;
+ default:
+ /* for V4L2_COLORFX_BW and others */
+ camif-ctrl_colorfx_cbcr-val = 0x8080;
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
With this modification got another issue: set CRCB effect, set CRCB
value, set BW effect, set CRCB effect back cause CRCB-value to be
reseted to default 0x8080. Is it correct?
--
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
Linux DVB Explained..
Hi Mau, I have started documenting a HOWTO on making a linuxDVB device and would like to know what the following is used for struct dvb_demux : This has a start_feed and a stop feed. What feed is this? ... the RAW 188 byte packets from the device perhaps? What is the main purpose of this structure? struct dmx_demux : This structure holds the frontend device struct and contains the .fops for read/write. Is this the main interface when using the /dev/dvb/adapterX/demux ? /dvr? So far... adapter = dvb_register_adapter() : Register a new DVB device adapter (called once) dvb_dmx_init(dvbdemux); // Called once per Demux chain? dvb_dmxdev_init(); // Called once per demux chain ? same as above --- The hardware I am using has 6 TS data inputs, 4 tuners (linked to TS inputs) and hardware PID filters and I am trying to establish the relationship of dmx and dmxdev. Any clarification is most welcome Best Regards, Richard -- 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: Linux DVB Explained..
Apologies Mauro, I accidentailly bumped the 'Send' whilst typing your name. The message is addressed to Mauro and All, On 17 November 2012 13:35, Richard tuxbox.g...@gmail.com wrote: Hi Mau, I have started documenting a HOWTO on making a linuxDVB device and would like to know what the following is used for struct dvb_demux : This has a start_feed and a stop feed. What feed is this? ... the RAW 188 byte packets from the device perhaps? What is the main purpose of this structure? struct dmx_demux : This structure holds the frontend device struct and contains the .fops for read/write. Is this the main interface when using the /dev/dvb/adapterX/demux ? /dvr? So far... adapter = dvb_register_adapter() : Register a new DVB device adapter (called once) dvb_dmx_init(dvbdemux); // Called once per Demux chain? dvb_dmxdev_init(); // Called once per demux chain ? same as above --- The hardware I am using has 6 TS data inputs, 4 tuners (linked to TS inputs) and hardware PID filters and I am trying to establish the relationship of dmx and dmxdev. Any clarification is most welcome Best Regards, Richard To add more queries, What is the purpose of dmx_frontend and dvb_frontend The word 'frontend' seems to be sending me in a loop. Its usually FE-Tuner-Demod-PID Filter- TS Data so I am at a loss where dmx_frontend goes Richard -- 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: S3C244X/S3C64XX SoC camera host interface driver questions
Hi,
On 11/17/2012 01:07 PM, Andrey Gusakov wrote:
Hi.
Just have time to test. I apologize for delay.
No problem, thanks for the feedback.
I'd like to squash all the s3c-camif patches before sending upstream,
if you don't mind. And to add your Signed-off at the final patch.
Ok. Squash.
I might have introduced bugs in the image effects handling, hopefully
there is none. I couldn't test it though. Could you test that on your
side with s3c64xx ?
Got some error. Seems effect updated only when I set new CrCb value.
Seems it's incorrect:
case V4L2_CID_COLORFX:
if (camif-ctrl_colorfx_cbcr-is_new) {
Uh, copy/paste error, this should have been
if (camif-ctrl_colorfx-is_new) {
camif-colorfx = camif-ctrl_colorfx-val;
/* Set Cb, Cr */
switch (ctrl-val) {
case V4L2_COLORFX_SEPIA:
camif-ctrl_colorfx_cbcr-val = 0x7391;
break;
case V4L2_COLORFX_SET_CBCR: /* noop */
break;
default:
/* for V4L2_COLORFX_BW and others */
camif-ctrl_colorfx_cbcr-val = 0x8080;
}
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
break;
Moving camif-colorfx = camif-ctrl_colorfx-val; out of condition
fixes the problem, but setting CrCb value control affect all effects
(sepia and BW), not only V4L2_COLORFX_SET_CBCR. Seems condition should
be removed and colorfx value should be checked set on every effect
change.
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index ceab03a..9c01f4f 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1526,19 +1526,17 @@ static int s3c_camif_subdev_s_ctrl(struct
v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_COLORFX:
- if (camif-ctrl_colorfx_cbcr-is_new) {
- camif-colorfx = camif-ctrl_colorfx-val;
- /* Set Cb, Cr */
- switch (ctrl-val) {
- case V4L2_COLORFX_SEPIA:
- camif-ctrl_colorfx_cbcr-val = 0x7391;
- break;
- case V4L2_COLORFX_SET_CBCR: /* noop */
- break;
- default:
- /* for V4L2_COLORFX_BW and others */
- camif-ctrl_colorfx_cbcr-val = 0x8080;
- }
+ camif-colorfx = camif-ctrl_colorfx-val;
+ /* Set Cb, Cr */
+ switch (ctrl-val) {
+ case V4L2_COLORFX_SEPIA:
+ camif-ctrl_colorfx_cbcr-val = 0x7391;
+ break;
+ case V4L2_COLORFX_SET_CBCR: /* noop */
+ break;
+ default:
+ /* for V4L2_COLORFX_BW and others */
+ camif-ctrl_colorfx_cbcr-val = 0x8080;
}
camif-colorfx_cb = camif-ctrl_colorfx_cbcr-val 0xff;
camif-colorfx_cr = camif-ctrl_colorfx_cbcr-val 8;
With this modification got another issue: set CRCB effect, set CRCB
value, set BW effect, set CRCB effect back cause CRCB-value to be
reseted to default 0x8080. Is it correct?
We could do better. The control values are already cached twice - in
struct v4l2_ctrl and struct camif_dev.
It seems more intuitive to save CB/CR coefficients for V4L2_COLORFX_SET_CBCR
and then restore them as needed. There is probably not much use of letting
user space know that the driver uses CBCR for V4L2_COLORFX_SEPIA and
V4L2_COLORFX_BW internally.
I propose change as below, it includes disabling the control for SoCs that
don't support it and a fixed cbcr order, to match documentation:
V4L2_CID_COLORFX_CBCR integer Determines the Cb and Cr coefficients for
V4L2_COLORFX_SET_CBCR color effect. Bits [7:0] of the supplied 32 bit
value are
interpreted as Cr component, bits [15:8] as Cb component and bits
[31:16] must
be zero.
I have pushed it all to the testing/s3c-camif branch. Please let me know
if you find any further issues.
-8---
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c
b/drivers/media/platform/s3c-camif/camif-capture.c
index 6401fdb..b52cc59 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -1520,22 +1520,22 @@ static int s3c_camif_subdev_s_ctrl(struct
v4l2_ctrl *ctrl)
switch (ctrl-id) {
case V4L2_CID_COLORFX:
- if (camif-ctrl_colorfx_cbcr-is_new)
Re: [PATCH RFC v3 1/3] V4L: Add driver for S3C244X/S3C64XX SoC series camera interface
Hi Hans,
On 11/16/2012 02:45 PM, Hans Verkuil wrote:
Hi Sylwester,
Just one comment, see below...
On Thu November 15 2012 23:05:13 Sylwester Nawrocki wrote:
This patch adds V4L2 driver for Samsung S3C244X/S3C64XX SoC series
camera interface. The driver exposes a subdev device node for CAMIF
pixel resolution and crop control and two video capture nodes - for
the codec and preview data paths. It has been tested on Mini2440
(s3c2440) and Mini6410 (s3c6410) board with gstreamer and mplayer.
Signed-off-by: Sylwester Nawrockisylvester.nawro...@gmail.com
Signed-off-by: Tomasz Figatomasz.f...@gmail.com
---
...
+static int s3c_camif_streamon(struct file *file, void *priv,
+ enum v4l2_buf_type type)
+{
+ struct camif_vp *vp = video_drvdata(file);
+ struct camif_dev *camif = vp-camif;
+ struct media_entity *sensor =camif-sensor.sd-entity;
+ int ret;
+
+ pr_debug([vp%d]\n, vp-id);
+
+ if (type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ if (vp-owner vp-owner != priv)
+ return -EBUSY;
+
+ if (s3c_vp_active(vp))
+ return 0;
+
+ ret = media_entity_pipeline_start(sensor, camif-m_pipeline);
+ if (ret 0)
+ return ret;
+
+ ret = camif_pipeline_validate(camif);
+ if (ret 0) {
+ media_entity_pipeline_stop(sensor);
+ return ret;
+ }
+
+ return vb2_streamon(vp-vb_queue, type);
+}
+
+static int s3c_camif_streamoff(struct file *file, void *priv,
+ enum v4l2_buf_type type)
+{
+ struct camif_vp *vp = video_drvdata(file);
+ struct camif_dev *camif = vp-camif;
+ int ret;
+
+ pr_debug([vp%d]\n, vp-id);
+
+ if (type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ if (vp-owner vp-owner != priv)
+ return -EBUSY;
+
+ ret = vb2_streamoff(vp-vb_queue, type);
+ if (ret == 0)
+ media_entity_pipeline_stop(camif-sensor.sd-entity);
+ return ret;
+}
+
+static int s3c_camif_reqbufs(struct file *file, void *priv,
+struct v4l2_requestbuffers *rb)
+{
+ struct camif_vp *vp = video_drvdata(file);
+ int ret;
+
+ pr_debug([vp%d] rb count: %d, owner: %p, priv: %p\n,
+vp-id, rb-count, vp-owner, priv);
+
+ if (vp-owner vp-owner != priv)
+ return -EBUSY;
+
+ if (rb-count)
+ rb-count = max_t(u32, CAMIF_REQ_BUFS_MIN, rb-count);
+ else
+ vp-owner = NULL;
+
+ ret = vb2_reqbufs(vp-vb_queue, rb);
+ if (!ret) {
+ vp-reqbufs_count = rb-count;
+ if (vp-owner == NULL rb-count 0)
+ vp-owner = priv;
+ }
+
+ return ret;
+}
+
+static int s3c_camif_querybuf(struct file *file, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct camif_vp *vp = video_drvdata(file);
+ return vb2_querybuf(vp-vb_queue, buf);
+}
+
+static int s3c_camif_qbuf(struct file *file, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct camif_vp *vp = video_drvdata(file);
+
+ pr_debug([vp%d]\n, vp-id);
+
+ if (vp-owner vp-owner != priv)
+ return -EBUSY;
+
+ return vb2_qbuf(vp-vb_queue, buf);
+}
+
+static int s3c_camif_dqbuf(struct file *file, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct camif_vp *vp = video_drvdata(file);
+
+ pr_debug([vp%d] sequence: %d\n, vp-id, vp-frame_sequence);
+
+ if (vp-owner vp-owner != priv)
+ return -EBUSY;
+
+ return vb2_dqbuf(vp-vb_queue, buf, file-f_flags O_NONBLOCK);
+}
+
+static int s3c_camif_create_bufs(struct file *file, void *priv,
+struct v4l2_create_buffers *create)
+{
+ struct camif_vp *vp = video_drvdata(file);
+ int ret;
+
+ if (vp-owner vp-owner != priv)
+ return -EBUSY;
+
+ create-count = max_t(u32, 1, create-count);
+ ret = vb2_create_bufs(vp-vb_queue, create);
+
+ if (!ret vp-owner == NULL)
+ vp-owner = priv;
+
+ return ret;
+}
+
+static int s3c_camif_prepare_buf(struct file *file, void *priv,
+struct v4l2_buffer *b)
+{
+ struct camif_vp *vp = video_drvdata(file);
+ return vb2_prepare_buf(vp-vb_queue, b);
+}
+
Are you aware of the vb2 ioctl helper functions I've added? See
videobuf2-core.h,
at the end.
Yes, I just chose not to introduce these helpers now, to make any
back-porting
of this driver to older kernels easier.
They can probably replace some of these ioctls. It's something you can do later
in a separate patch, so this isn't blocking as far as I am concerned. It's just
a hint.
Thanks, I'll see which ones can be replaced. But I would prefer to make it
a separate patch for subsequent kernel
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Nov 17 19:00:21 CET 2012 git hash:2c4e11b7c15af70580625657a154ea7ea70b8c76 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] [media] atmel-isi: Update error check for unsigned variables
On Fri, 16 Nov 2012, Tushar Behera wrote:
Checking ' 0' for unsigned variables always returns false. For error
codes, use IS_ERR_VALUE() instead.
Wouldn't just changing irq type to int also work? I think that would
be a more straight-forward solution. If however there are strong arguments
against that, I'm fine with this fix too.
Thanks
Guennadi
CC: Mauro Carvalho Chehab mche...@infradead.org
CC: linux-media@vger.kernel.org
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/media/platform/soc_camera/atmel-isi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 6274a91..5bd65df 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -1020,7 +1020,7 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
irq = platform_get_irq(pdev, 0);
- if (irq 0) {
+ if (IS_ERR_VALUE(irq)) {
ret = irq;
goto err_req_irq;
}
--
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
---
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
[PATCH] [media] soc_camera: mx2_camera: Constify v4l2_crop
From: Fabio Estevam fabio.este...@freescale.com
Since commit 4f996594ce ([media] v4l2: make vidioc_s_crop const), set_crop
should receive a 'const struct v4l2_crop *' argument type.
Adapt to this new format and get rid of the following build warning:
drivers/media/platform/soc_camera/mx2_camera.c:1529: warning: initialization
from incompatible pointer type
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/media/platform/soc_camera/mx2_camera.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index e575ae8..5fc3319 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -1131,15 +1131,15 @@ 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_rect rect = a-c;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct v4l2_mbus_framefmt mf;
int ret;
- soc_camera_limit_side(rect-left, rect-width, 0, 2, 4096);
- soc_camera_limit_side(rect-top, rect-height, 0, 2, 4096);
+ soc_camera_limit_side(rect.left, rect.width, 0, 2, 4096);
+ soc_camera_limit_side(rect.top, rect.height, 0, 2, 4096);
ret = v4l2_subdev_call(sd, video, s_crop, a);
if (ret 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] [media] soc_camera: mx3_camera: Constify v4l2_crop
Since commit 4f996594ce ([media] v4l2: make vidioc_s_crop const), set_crop
should receive a 'const struct v4l2_crop *' argument type.
Adapt to this new format and get rid of the following build warning:
drivers/media/platform/soc_camera/mx3_camera.c:1134: warning: initialization
from incompatible pointer type
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/media/platform/soc_camera/mx3_camera.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index 64d39b1..ae04395 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -799,17 +799,17 @@ 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_rect rect = a-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);
struct v4l2_mbus_framefmt mf;
int ret;
- soc_camera_limit_side(rect-left, rect-width, 0, 2, 4096);
- soc_camera_limit_side(rect-top, rect-height, 0, 2, 4096);
+ soc_camera_limit_side(rect.left, rect.width, 0, 2, 4096);
+ soc_camera_limit_side(rect.top, rect.height, 0, 2, 4096);
ret = v4l2_subdev_call(sd, video, s_crop, a);
if (ret 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
