[PATCH] [media] atmel_isi: allocate memory to store the isi platform data.
This patch fix the bug: ISI driver's platform data became invalid when isi
platform data's attribution is __initdata.
If the isi platform data is passed as __initdata. Then we need store it in
driver allocated memory. otherwise when we use it out of the probe() function,
then the isi platform data is invalid.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ec3f6a0..dc0fdec 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -926,6 +926,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
clk_put(isi-mck);
clk_unprepare(isi-pclk);
clk_put(isi-pclk);
+ kfree(isi-pdata);
kfree(isi);
return 0;
@@ -968,8 +969,15 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
goto err_alloc_isi;
}
+ isi-pdata = kzalloc(sizeof(struct isi_platform_data), GFP_KERNEL);
+ if (!isi-pdata) {
+ ret = -ENOMEM;
+ dev_err(pdev-dev, Can't allocate isi platform data!\n);
+ goto err_alloc_isi_pdata;
+ }
+ memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
+
isi-pclk = pclk;
- isi-pdata = pdata;
isi-active = NULL;
spin_lock_init(isi-lock);
init_waitqueue_head(isi-vsync_wq);
@@ -1073,6 +1081,8 @@ err_set_mck_rate:
err_clk_prepare_mck:
clk_put(isi-mck);
err_clk_get:
+ kfree(isi-pdata);
+err_alloc_isi_pdata:
kfree(isi);
err_alloc_isi:
clk_unprepare(pclk);
--
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: v4l2-ctrls: add control for dpcm predictor
From: Lad, Prabhakar prabhakar@ti.com
add V4L2_CID_DPCM_PREDICTOR control of type menu, which
determines the dpcm predictor. The predictor can be either
simple or advanced.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.
drivers/media/v4l2-core/v4l2-ctrls.c |9 +
include/linux/videodev2.h|5 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6a2ee7..2d7bc15 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -425,6 +425,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Gray,
NULL,
};
+ static const char * const dpcm_predictor[] = {
+ Simple Predictor,
+ Advanced Predictor,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +507,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DPCM_PREDICTOR:
+ return dpcm_predictor;
default:
return NULL;
@@ -732,6 +739,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IMAGE_PROC_CLASS: return Image Processing
Controls;
case V4L2_CID_LINK_FREQ:return Link Frequency;
case V4L2_CID_PIXEL_RATE: return Pixel Rate;
+ case V4L2_CID_DPCM_PREDICTOR: return DPCM Predictor;
default:
return NULL;
@@ -832,6 +840,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DPCM_PREDICTOR:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 6d6dfa7..4edb941 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2000,6 +2000,11 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
+#define V4L2_CID_DPCM_PREDICTOR
(V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
+enum v4l2_dpcm_predictor {
+ V4L2_DPCM_PREDICTOR_SIMPLE = 0,
+ V4L2_DPCM_PREDICTOR_ADVANCE = 1,
+};
/*
* T U N I N G
--
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
Re: [PATCH] media: v4l2-ctrls: add control for dpcm predictor
Hi Prabhakar, On 08/29/2012 02:31 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar@ti.com add V4L2_CID_DPCM_PREDICTOR control of type menu, which determines the dpcm predictor. The predictor can be either simple or advanced. Thanks for the patch. I was expecting to find some information about this new control in its DocBook documentation, but this part seems to be missing here. :) Could you please add relevant entries in Documentation/DocBook/media/v4l/controls.xml as well ? -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: v4l2-ctrls: add control for dpcm predictor
Hi Sylwester, On Wednesday 29 August 2012 06:13 PM, Sylwester Nawrocki wrote: Hi Prabhakar, On 08/29/2012 02:31 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar@ti.com add V4L2_CID_DPCM_PREDICTOR control of type menu, which determines the dpcm predictor. The predictor can be either simple or advanced. Thanks for the patch. I was expecting to find some information about this new control in its DocBook documentation, but this part seems to be missing here. :) Could you please add relevant entries in Documentation/DocBook/media/v4l/controls.xml as well ? Thanks for the catch :) I'll add it for v2. Thanks and Regards, --Prabhakar -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: v4l2-ctrls: add control for dpcm predictor
Hi Prabhakar,
Thanks for the patch.
On Wed, Aug 29, 2012 at 06:01:07PM +0530, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
add V4L2_CID_DPCM_PREDICTOR control of type menu, which
determines the dpcm predictor. The predictor can be either
simple or advanced.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.
drivers/media/v4l2-core/v4l2-ctrls.c |9 +
include/linux/videodev2.h|5 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6a2ee7..2d7bc15 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -425,6 +425,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Gray,
NULL,
};
+ static const char * const dpcm_predictor[] = {
+ Simple Predictor,
+ Advanced Predictor,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +507,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DPCM_PREDICTOR:
+ return dpcm_predictor;
default:
return NULL;
@@ -732,6 +739,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IMAGE_PROC_CLASS: return Image Processing
Controls;
case V4L2_CID_LINK_FREQ:return Link Frequency;
case V4L2_CID_PIXEL_RATE: return Pixel Rate;
+ case V4L2_CID_DPCM_PREDICTOR: return DPCM Predictor;
default:
return NULL;
@@ -832,6 +840,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DPCM_PREDICTOR:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 6d6dfa7..4edb941 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2000,6 +2000,11 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
+#define V4L2_CID_DPCM_PREDICTOR
(V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
+enum v4l2_dpcm_predictor {
+ V4L2_DPCM_PREDICTOR_SIMPLE = 0,
+ V4L2_DPCM_PREDICTOR_ADVANCE = 1,
+};
s/ADVANCE/ADVANCED/ perhaps?
To add to Sylwester's comment on the documentation, I think this control
belongs to the image processing controls class.
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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] davinci: vpfe: Add documentation
Hi Sakari,
On Thu, Aug 16, 2012 at 9:53 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Manju,
On Thu, Aug 09, 2012 at 09:13:52AM +0530, Manjunath Hadli wrote:
Hi Sakari,
Thank you for the comments.
Thanks for the graphs!
On Thursday 02 August 2012 05:37 AM, Sakari Ailus wrote:
Hi Manju,
Thanks for the patch.
Please make sure these patches reach linux-media next time. If they do
not,
it severely limits the number of potential reviewers. I don't know
why, but
the original patch isn't on linux-media even if the list was cc'd.
Dropping linux-kernel from cc.
Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
Documentation/video4linux/davinci-vpfe-mc.txt | 263
+
1 files changed, 263 insertions(+), 0 deletions(-)
create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
b/Documentation/video4linux/davinci-vpfe-mc.txt
new file mode 100644
index 000..968194f
--- /dev/null
+++ b/Documentation/video4linux/davinci-vpfe-mc.txt
@@ -0,0 +1,263 @@
+Davinci Video processing Front End (VPFE) driver
+
+Copyright (C) 2012 Texas Instruments Inc
+
+Contacts: Manjunath Hadli manjunath.ha...@ti.com
+
+Introduction
+
+
+This file documents the Texas Instruments Davinci Video processing
Front End
+(VPFE) driver located under drivers/media/video/davinci. The
original driver
+exists for Davinci VPFE, which is now being changed to Media Controller
+Framework.
+
+Currently the driver has been successfully used on the following
version of Davinci:
+
+DM365/DM368
+
+The driver implements V4L2, Media controller and v4l2_subdev
interfaces.
+Sensor, lens and flash drivers using the v4l2_subdev interface in
the kernel
+are supported.
+
+
+Split to subdevs
+
+
+The Davinic VPFE is split into V4L2 subdevs, each of the blocks
inside the VPFE
+having one subdev to represent it. Each of the subdevs provide a
V4L2 subdev
+interface to userspace.
+
+DAVINCI CCDC
+DAVINCI PREVIEWER
+DAVINCI RESIZER
+DAVINCI AEW
+DAVINCI AF
+
+Each possible link in the VPFE is modeled by a link in the Media
controller
+interface. For an example program see [1].
+
+
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports
standard V4L2
+IOCTLs and controls where possible and practical. Much of the
functions provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+Sets/Gets the parameters required by the previewer module
+Parameter:
+/**
+ * struct prev_module_param- structure to configure preview modules
+ * @version: Version of the preview module
+ * @len: Length of the module config structure
+ * @module_id: Module id
+ * @param: pointer to module config parameter.
+ */
+struct prev_module_param {
+char version[IMP_MAX_NAME_SIZE];
+unsigned short len;
+unsigned short module_id;
+void *param;
+};
In addition to what Laurent commented on this, could the version
information be passed in struct media_entity_desc instead?
I plan to leave out the version.
As a general comment, it's a bad idea to design an API that allows
passing
blobs, especially when the expected size of the blobs isn't known. That
really equals to asking for trouble.
That said, I know this is an area where complete documentation is acarce,
but I think that at least the memory layout of the current blob pointers
should be visible in the struct definitions whenever possible. See
e.g. the
OMAP 3 ISP driver.
I have proposed using a union of structures instead of the void blob.
I also saw the OMAP implementation, and they are pointers (but not void).
To me the union approach looks better as it keeps the architecture
intact and does not necessitate an
explicit copy_from_user. Which of these ways do you suggest?
I would suggest to use the approach taken in the OMAP 3 ISP driver as it has
one obvious advantage over the union of pointers: it makes it possible to
perform atomic changes to the configuration.
However, changes to configuration done through controls and the private
IOCTL can never be atomic as they're done using a different IOCTL. This is
something that will require some work at the API level in the future.
I'm fine with both union of struct pointers
Re: [PATCH] media: v4l2-ctrls: add control for dpcm predictor
Hi Sakari,
Thanks for the review.
On Wed, Aug 29, 2012 at 7:51 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Prabhakar,
Thanks for the patch.
On Wed, Aug 29, 2012 at 06:01:07PM +0530, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
add V4L2_CID_DPCM_PREDICTOR control of type menu, which
determines the dpcm predictor. The predictor can be either
simple or advanced.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.
drivers/media/v4l2-core/v4l2-ctrls.c |9 +
include/linux/videodev2.h|5 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6a2ee7..2d7bc15 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -425,6 +425,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Gray,
NULL,
};
+ static const char * const dpcm_predictor[] = {
+ Simple Predictor,
+ Advanced Predictor,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +507,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DPCM_PREDICTOR:
+ return dpcm_predictor;
default:
return NULL;
@@ -732,6 +739,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IMAGE_PROC_CLASS: return Image Processing
Controls;
case V4L2_CID_LINK_FREQ:return Link Frequency;
case V4L2_CID_PIXEL_RATE: return Pixel Rate;
+ case V4L2_CID_DPCM_PREDICTOR: return DPCM Predictor;
default:
return NULL;
@@ -832,6 +840,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DPCM_PREDICTOR:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 6d6dfa7..4edb941 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2000,6 +2000,11 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ
(V4L2_CID_IMAGE_PROC_CLASS_BASE + 1)
#define V4L2_CID_PIXEL_RATE
(V4L2_CID_IMAGE_PROC_CLASS_BASE + 2)
+#define V4L2_CID_DPCM_PREDICTOR
(V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
+enum v4l2_dpcm_predictor {
+ V4L2_DPCM_PREDICTOR_SIMPLE = 0,
+ V4L2_DPCM_PREDICTOR_ADVANCE = 1,
+};
s/ADVANCE/ADVANCED/ perhaps?
Ok I'll make it ADVANCED.
To add to Sylwester's comment on the documentation, I think this control
belongs to the image processing controls class.
I have added it as part of image processing control class itself
(#define V4L2_CID_DPCM_PREDICTOR (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)),
I'll include the same in documentation as well.
Thanks and Regards,
--Prabhakar Lad
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--
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] atmel_isi: allocate memory to store the isi platform data.
Hello,
On 2012-08-29 12:11, Josh Wu wrote:
This patch fix the bug: ISI driver's platform data became invalid when isi
platform data's attribution is __initdata.
If the isi platform data is passed as __initdata. Then we need store it in
driver allocated memory. otherwise when we use it out of the probe()
function, then the isi platform data is invalid.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ec3f6a0..dc0fdec 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -926,6 +926,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
clk_put(isi-mck);
clk_unprepare(isi-pclk);
clk_put(isi-pclk);
+ kfree(isi-pdata);
Not needed if you use devm_kzalloc(). See below.
kfree(isi);
return 0;
@@ -968,8 +969,15 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
goto err_alloc_isi;
}
+ isi-pdata = kzalloc(sizeof(struct isi_platform_data), GFP_KERNEL);
+ if (!isi-pdata) {
+ ret = -ENOMEM;
+ dev_err(pdev-dev, Can't allocate isi platform data!\n);
+ goto err_alloc_isi_pdata;
+ }
+ memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
+
It is more idiomatic to use sizeof(*isi-pdata) in kzalloc() and memcpy() calls
to be resilient to future type changes.
You may also want to use dev_kzalloc() which frees memory automagically on
driver detach.
isi-pclk = pclk;
- isi-pdata = pdata;
isi-active = NULL;
spin_lock_init(isi-lock);
init_waitqueue_head(isi-vsync_wq);
@@ -1073,6 +1081,8 @@ err_set_mck_rate:
err_clk_prepare_mck:
clk_put(isi-mck);
err_clk_get:
+ kfree(isi-pdata);
+err_alloc_isi_pdata:
kfree(isi);
err_alloc_isi:
clk_unprepare(pclk);
Best regards,
Nicolas--
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] atmel_isi: allocate memory to store the isi platform data.
Hi,
On 08/29/2012 12:11 PM, Josh Wu wrote:
This patch fix the bug: ISI driver's platform data became invalid
when isi platform data's attribution is __initdata.
If the isi platform data is passed as __initdata. Then we need store
it in driver allocated memory. otherwise when we use it out of the
probe() function, then the isi platform data is invalid.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ec3f6a0..dc0fdec 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -926,6 +926,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
clk_put(isi-mck);
clk_unprepare(isi-pclk);
clk_put(isi-pclk);
+ kfree(isi-pdata);
kfree(isi);
return 0;
@@ -968,8 +969,15 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
goto err_alloc_isi;
}
+ isi-pdata = kzalloc(sizeof(struct isi_platform_data), GFP_KERNEL);
+ if (!isi-pdata) {
+ ret = -ENOMEM;
+ dev_err(pdev-dev, Can't allocate isi platform data!\n);
+ goto err_alloc_isi_pdata;
+ }
+ memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
+
Why not just embed struct isi_platform_data in struct atmel_isi and drop this
another kzalloc() ?
Then you could simply do isi-pdata = *pdata.
Also, is this going to work when this driver is build and as a module
and its loading is deferred past system booting ? At that time the driver's
platform data may be well discarded. You may wan't to duplicate it on the
running boards in board code with kmemdup() or something.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] atmel_isi: allocate memory to store the isi platform data.
On Wed, 29 Aug 2012, Sylwester Nawrocki wrote:
Hi,
On 08/29/2012 12:11 PM, Josh Wu wrote:
This patch fix the bug: ISI driver's platform data became invalid
when isi platform data's attribution is __initdata.
If the isi platform data is passed as __initdata. Then we need store
it in driver allocated memory. otherwise when we use it out of the
probe() function, then the isi platform data is invalid.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ec3f6a0..dc0fdec 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -926,6 +926,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
clk_put(isi-mck);
clk_unprepare(isi-pclk);
clk_put(isi-pclk);
+ kfree(isi-pdata);
kfree(isi);
return 0;
@@ -968,8 +969,15 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
goto err_alloc_isi;
}
+ isi-pdata = kzalloc(sizeof(struct isi_platform_data), GFP_KERNEL);
+ if (!isi-pdata) {
+ ret = -ENOMEM;
+ dev_err(pdev-dev, Can't allocate isi platform data!\n);
+ goto err_alloc_isi_pdata;
+ }
+ memcpy(isi-pdata, pdata, sizeof(struct isi_platform_data));
+
Why not just embed struct isi_platform_data in struct atmel_isi and drop this
another kzalloc() ?
Then you could simply do isi-pdata = *pdata.
Also, is this going to work when this driver is build and as a module
and its loading is deferred past system booting ? At that time the driver's
platform data may be well discarded.
Right, it will be gone, I think.
You may wan't to duplicate it on the
running boards in board code with kmemdup() or something.
How about removing __initdata from board code?
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: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
Hi, On Fri, Aug 10, 2012 at 4:57 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: [Snip] diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h new file mode 100644 index 000..e0ceddd --- /dev/null +++ b/include/linux/dma-fence.h @@ -0,0 +1,124 @@ +/* + * Fence mechanism for dma-buf to allow for asynchronous dma access + * + * Copyright (C) 2012 Texas Instruments + * Author: Rob Clark rob.cl...@linaro.org + * + * 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 __DMA_FENCE_H__ +#define __DMA_FENCE_H__ + +#include linux/err.h +#include linux/list.h +#include linux/wait.h +#include linux/list.h Duplicated include. Regards, Francesco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/4] V4L2: Vendor specific media bus formats/ frame size control
Hi Nicolas, On Mon, Aug 27, 2012 at 05:48:43PM +0200, Nicolas THERY wrote: Hello, On 2012-08-23 11:51, Sylwester Nawrocki wrote: This patch series introduces new image source class control - V4L2_CID_FRAMESIZE and vendor or device specific media bus format section. There was already a discussion WRT handling interleaved image data [1]. I'm not terribly happy with those vendor specific media bus formats but I couldn't find better solution that would comply with the V4L2 API concepts and would work reliably. What about Sakari's Frame format descriptors RFC[1] that would allow to describe arbitrary pixel code combinations and provide required information (virtual channel and data type) to the CSI receiver driver for configuring the hardware? I we'll need to continue that work as well, unfortunately I've had higher priority things to do. Still, getting that right is complex and will take time. The V4L2 pixel format for this sensor will likely be a hardware-specific one for quite a while: this sensor in question sends several frames in different formats of a single image at once which doesn't match to V4L2's pixel format configuration that assumes a single format. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Aug 29 19:00:18 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 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: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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 RFC 0/4] V4L2: Vendor specific media bus formats/ frame size control
Hi Nicolas, On 08/27/2012 05:48 PM, Nicolas THERY wrote: Hello, On 2012-08-23 11:51, Sylwester Nawrocki wrote: This patch series introduces new image source class control - V4L2_CID_FRAMESIZE and vendor or device specific media bus format section. There was already a discussion WRT handling interleaved image data [1]. I'm not terribly happy with those vendor specific media bus formats but I couldn't find better solution that would comply with the V4L2 API concepts and would work reliably. What about Sakari's Frame format descriptors RFC[1] that would allow to describe arbitrary pixel code combinations and provide required information (virtual channel and data type) to the CSI receiver driver for configuring the hardware? Thanks for reminding about this. The Frame format descriptors would not necessarily solve the main problem which I tried to address in this RFC. The sensor in question uses single MIPI-CSI data type frame as a container for multiple data planes, e.g. JPEG compressed stream interleaved with YUV image data, some optional padding and a specific metadata describing the interleaved image data. There is no MIPI-CSI2 virtual channel or data type interleaving. Everything is transferred on single VC and single DT. Such a frames need sensor specific S/W algorithm do extract each component. So it didn't look like the frame descriptors would be helpful here, since all this needs to be mapped to a single fourcc. Not sure if defining a binary blob fourcc and retrieving frame format information by some other means would have been a way to go. I also had some patches adopting design from Sakari's RFC, for the case where in addition to the above frame format there was captured a copy of meta-data, (as in the frame footer) send on separate DT (Embedded Data). And this was mapped to 2-planar V4L2 pixel format. Even then I used a sensor specific media bus code. In the end of the day I switched to a single-planar format as it had all what's needed to decode the data. And the were some H/W limitations on using additional DT. The frame format descriptors might be worth to work on, but this doesn't look like a solution to my problem and it is going to take some time to get it right, as Sakari pointed out. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v3 Add support to Avermedia Twinstar double tuner in af9035
This patch add support to the Avermedia Twinstar double tuner in the af9035
driver. Version 3 of the patch.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -upr linux/drivers/media/dvb-frontends/af9033.c
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c 2012-08-29
16:00:52.020523899 +0200
@@ -326,6 +326,18 @@ static int af9033_init(struct dvb_fronte
goto err;
}
+ if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+ ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+ if (ret 0)
+ goto err;
+ }
+
state-bandwidth_hz = 0; /* force to program all parameters */
return 0;
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.c 2012-08-29 13:07:57.299884405
+0200
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
- set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable 3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
@@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
- ret = mxl5007t_soft_reset(state);
- if (mxl_fail(ret))
- goto fail;
+ if (!state-config-no_reset) {
+ ret = mxl5007t_soft_reset(state);
+ if (mxl_fail(ret))
+ goto fail;
+ }
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +888,11 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
- ret = mxl5007t_get_chip_id(state);
+ if (!state-config-no_probe)
+ ret = mxl5007t_get_chip_id(state);
+
+ ret = mxl5007t_write_reg(state, 0x04,
+ state-config-loop_thru_enable);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h 2012-08-14 05:45:22.0
+0200
+++ linux.new/drivers/media/tuners/mxl5007t.h 2012-08-25 19:38:19.990920623
+0200
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
- unsigned int loop_thru_enable:1;
+ unsigned int loop_thru_enable:2;
unsigned int clk_out_enable:1;
+ unsigned int no_probe:1;
+ unsigned int no_reset:1;
};
#if defined(CONFIG_MEDIA_TUNER_MXL5007T) ||
(defined(CONFIG_MEDIA_TUNER_MXL5007T_MODULE) defined(MODULE))
diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
--- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-16 05:45:24.0
+0200
+++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2012-08-29
19:20:00.862523903 +0200
@@ -209,10 +209,14 @@ static int af9035_i2c_master_xfer(struct
if (msg[0].len 40 || msg[1].len 40) {
/* TODO: correct limits 40 */
ret = -EOPNOTSUPP;
- } else if (msg[0].addr == state-af9033_config[0].i2c_addr) {
+ } else if ((msg[0].addr == state-af9033_config[0].i2c_addr) ||
+ (msg[0].addr == state-af9033_config[1].i2c_addr)) {
/* integrated demod */
u32 reg = msg[0].buf[0] 16 | msg[0].buf[1] 8 |
msg[0].buf[2];
+ if (state-af9033_config[1].i2c_addr
+ (msg[0].addr == state-af9033_config[1].i2c_addr))
+ reg |= 0x10;
ret = af9035_rd_regs(d, reg, msg[1].buf[0],
msg[1].len);
} else {
@@ -220,8 +224,9 @@ static int af9035_i2c_master_xfer(struct
u8 buf[5 + msg[0].len];
struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
