Re: [PATCH -next] [media] mt9v022: fix potential NULL pointer dereference in mt9v022_probe()
On Wed, 28 Nov 2012 21:56:15 -0500
Wei Yongjun weiyj...@gmail.com wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
The dereference to 'icl' should be moved below the NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/i2c/soc_camera/mt9v022.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/soc_camera/mt9v022.c
b/drivers/media/i2c/soc_camera/mt9v022.c
index d40a885..7509802 100644
--- a/drivers/media/i2c/soc_camera/mt9v022.c
+++ b/drivers/media/i2c/soc_camera/mt9v022.c
@@ -875,7 +875,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;
+ struct mt9v022_platform_data *pdata;
int ret;
if (!icl) {
@@ -893,6 +893,7 @@ static int mt9v022_probe(struct i2c_client *client,
if (!mt9v022)
return -ENOMEM;
+ pdata = icl-priv;
v4l2_i2c_subdev_init(mt9v022-subdev, client, mt9v022_subdev_ops);
v4l2_ctrl_handler_init(mt9v022-hdl, 6);
v4l2_ctrl_new_std(mt9v022-hdl, mt9v022_ctrl_ops,
--
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: mem2mem: make reference to struct m2m_ops in the core const
The mem2mem core doesn't change struct m2m_ops, provided by the driver,
make references to it const.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/v4l2-core/v4l2-mem2mem.c |4 ++--
include/media/v4l2-mem2mem.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 3ac8358..e4ff65d 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -62,7 +62,7 @@ struct v4l2_m2m_dev {
struct list_headjob_queue;
spinlock_t job_spinlock;
- struct v4l2_m2m_ops *m2m_ops;
+ const struct v4l2_m2m_ops *m2m_ops;
};
static struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx *m2m_ctx,
@@ -506,7 +506,7 @@ EXPORT_SYMBOL(v4l2_m2m_mmap);
*
* Usually called from driver's probe() function.
*/
-struct v4l2_m2m_dev *v4l2_m2m_init(struct v4l2_m2m_ops *m2m_ops)
+struct v4l2_m2m_dev *v4l2_m2m_init(const struct v4l2_m2m_ops *m2m_ops)
{
struct v4l2_m2m_dev *m2m_dev;
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 131cc4a..bec13da 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -122,7 +122,7 @@ unsigned int v4l2_m2m_poll(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
int v4l2_m2m_mmap(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
struct vm_area_struct *vma);
-struct v4l2_m2m_dev *v4l2_m2m_init(struct v4l2_m2m_ops *m2m_ops);
+struct v4l2_m2m_dev *v4l2_m2m_init(const struct v4l2_m2m_ops *m2m_ops);
void v4l2_m2m_release(struct v4l2_m2m_dev *m2m_dev);
struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct v4l2_m2m_dev *m2m_dev,
--
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: [GIT PULL] soc-camera + VEU for 3.8
Hi Mauro On Thu, 22 Nov 2012, Mauro Carvalho Chehab wrote: Em Thu, 22 Nov 2012 11:41:05 -0200 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Wed, 31 Oct 2012 13:01:19 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu: Hi Mauro Please pull driver updates for 3.8. Apart from usual soc-camera development this pull request also includes a new VEU MEM2MEM driver. The following changes since commit 016e804df1632fa99b1d96825df4c0db075ac196: media: sh_vou: fix const cropping related warnings (2012-10-31 11:35:51 +0100) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.8 for you to fetch changes up to 223916e1817ce458e947a5f99026ee7d05acaa66: media: add a VEU MEM2MEM format conversion and scaling driver (2012-10-31 12:54:58 +0100) Anatolij Gustschin (4): V4L: soc_camera: allow reading from video device if supported mt9v022: add v4l2 controls for blanking mt9v022: support required register settings in snapshot mode mt9v022: set y_skip_top field to zero as default Frank SchÀfer (1): ov2640: add support for V4L2_MBUS_FMT_YUYV8_2X8, V4L2_MBUS_FMT_RGB565_2X8_BE Guennadi Liakhovetski (1): media: add a VEU MEM2MEM format conversion and scaling driver Shawn Guo (1): media: mx1_camera: mark the driver BROKEN arch/arm/mach-pxa/pcm990-baseboard.c |6 + drivers/media/i2c/soc_camera/mt9v022.c | 88 ++- drivers/media/i2c/soc_camera/ov2640.c | 49 +- drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile|2 + drivers/media/platform/sh_veu.c| 1264 Applied, thanks! Please submit a MAINTAINERS entry for this new driver. Hmm... there are also some new warnings introduced by it (compiled on x86_64): drivers/media/platform/sh_veu.c: In function 'sh_veu_process': drivers/media/platform/sh_veu.c:269:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat] drivers/media/platform/sh_veu.c:276:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat] drivers/media/platform/sh_veu.c: In function 'sh_veu_probe': drivers/media/platform/sh_veu.c:1199:2: warning: passing argument 1 of 'v4l2_m2m_init' discards 'const' qualifier from pointer target type [enabled by default] In file included from drivers/media/platform/sh_veu.c:27:0: include/media/v4l2-mem2mem.h:125:22: note: expected 'struct v4l2_m2m_ops *' but argument is of type 'const struct v4l2_m2m_ops *' I'll just drop media: add a VEU MEM2MEM format conversion and scaling driver and wait for a warning-free version with a MAINTAINERS entry patch series. They are there, because the following my patch of 11.09 https://patchwork.kernel.org/patch/1437601/ hasn't been applied. It is for the core, so, I'm not pulling it via my tree. I actually thought, I'd forgotten to post it, so, I just re-sent it, sorry. Could you apply it, please? I'm currently preparing a last 3.8 pull request for soc-camera, I'll include this sh-veu driver there again too. 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] gspca - ov534: Fix the light frequency filter
Hi Jean-Francois, Antonio Ospite,
Could it be that you're both right, and that the register
Jean-Francois suggest is used (0x13) and uses in his patch
is for enabling / disabling the light-freq filter, where
as the register which were used before this patch
(0x2a, 0x2b) are used to select the light frequency to
filter for?
That would explain everything the 2 50 / 60 hz testers are
seeing. This assumes that reg 0x13 has the filter always
enabled before the patch, and the code before the patch
simply changes the filter freq to such a value it
effectively disables the filter for 50 Hz. This also
assumes that the default values in 0x2a and 0x2b are
valid for 60hz, which explains why Jean Francois' patch
works for 60 Hz, so with all this combined we should
have all pieces of the puzzle ...
Anyone wants to do a patch to prove I'm right (or wrong :)
?
Regards,
Hans
On 11/23/2012 07:12 PM, Jean-Francois Moine wrote:
On Fri, 23 Nov 2012 18:09:09 +0100
Antonio Ospite osp...@studenti.unina.it wrote:
On Thu, 22 Nov 2012 12:46:52 +0100
[snip]
Jean-Francois Moine moin...@free.fr wrote:
This patch was done thanks to the documentation of the right
OmniVision sensors.
In the datasheet I have for ov772x, bit[6] of register 0x13 is described
as:
Bit[6]: AEC - Step size limit
0: Step size is limited to vertical blank
1: Unlimited step size
Right, but I don't use the bit 6, it is the bit 5:
+ sccb_reg_write(gspca_dev, 0x13, /* auto */
+ sccb_reg_read(gspca_dev, 0x13) | 0x20);
which is described as:
Bit[5]: Banding filter ON/OFF
And the patch makes Light Frequency _NOT_ work with the PS3 eye (based
on ov772x).
What does the ov767x datasheet say?
Quite the same thing:
Bit[5]: Banding filter ON/OFF - In order to turn ON the banding
filter, BD50ST (0x9D) or BD60ST (0x9E) must be set to a
non-zero value.
0: OFF
1: ON
(the registers 9d and 9e are non zero for the ov767x in ov534.c)
Maybe we should use the new values only when
sd-sensor == SENSOR_OV767x
What sensor does Alexander's webcam use?
He has exactly the same webcam as yours: 1415:2000 (ps eye) with
sensor ov772x.
Note: The light frequency filter is either off or automatic.
The application will see either off or 50Hz only.
Tested-by: alexander calderon fabianp...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/ov534.c
+++ b/drivers/media/usb/gspca/ov534.c
@@ -1038,13 +1038,12 @@
{
struct sd *sd = (struct sd *) gspca_dev;
drivers/media/usb/gspca/ov534.c: In function ‘setlightfreq’:
drivers/media/usb/gspca/ov534.c:1039:13: warning: unused variable ‘sd’
[-Wunused-variable]
Thanks.
Well, here is one of the last message I received from Alexander (in
fact, his first name is Fabian):
Thanks for all your help, it is very kind of you, I used the code below,the
60 Hz filter appear to work even at 100fps, but when I used 125 fps it
didnt work :( , i guess it is something of detection speed. If you have any
other idea I'll be very thankful.
Sincerely Fabian Calderon
So, how may we advance?
--
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 0/2] omap_vout: remove cpu_is_* uses
On 2012-11-28 17:13, Laurent Pinchart wrote: Hi Tomi, On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote: Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based on current omapdss master branch, which has the omapdss version code. The omapdss version code is queued for v3.8. I'm not sure which is the best way to handle these patches due to the dependency to omapdss. The easiest option is to merge these for 3.9. There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP dependency in the omap_vout driver. I'm not going to touch that, as it doesn't look as trivial as this cpu_is_* removal, and I don't have much knowledge of the omap_vout driver. Compiled, but not tested. Tested on a Beagleboard-xM. Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks. The patches depend on unmerged OMAP DSS patches. Would you like to push this series through linuxtv or through your DSS tree ? The later might be easier, depending on when the required DSS patches will hit mainline. The DSS patches will be merged for 3.8. I can take this via the omapdss tree, as there probably won't be any conflicts with other v4l2 stuff. Or, we can just delay these until 3.9. These patches remove omap platform dependencies, helping the effort to get common ARM kernel. However, as there's still the VRFB code in the omap_vout driver, the dependency remains. Thus, in way, these patches alone don't help anything, and we could delay these for 3.9 and hope that omap_vout_vrfb.c gets converted also for that merge window. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses
Hi Tomi, On Thursday 29 November 2012 11:30:28 Tomi Valkeinen wrote: On 2012-11-28 17:13, Laurent Pinchart wrote: On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote: Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based on current omapdss master branch, which has the omapdss version code. The omapdss version code is queued for v3.8. I'm not sure which is the best way to handle these patches due to the dependency to omapdss. The easiest option is to merge these for 3.9. There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP dependency in the omap_vout driver. I'm not going to touch that, as it doesn't look as trivial as this cpu_is_* removal, and I don't have much knowledge of the omap_vout driver. Compiled, but not tested. Tested on a Beagleboard-xM. Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks. The patches depend on unmerged OMAP DSS patches. Would you like to push this series through linuxtv or through your DSS tree ? The later might be easier, depending on when the required DSS patches will hit mainline. The DSS patches will be merged for 3.8. I can take this via the omapdss tree, as there probably won't be any conflicts with other v4l2 stuff. Or, we can just delay these until 3.9. These patches remove omap platform dependencies, helping the effort to get common ARM kernel. However, as there's still the VRFB code in the omap_vout driver, the dependency remains. Thus, in way, these patches alone don't help anything, and we could delay these for 3.9 and hope that omap_vout_vrfb.c gets converted also for that merge window. OK, I'll queue them for v3.9 then. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
[PATCH 2/2] media: sh_mobile_ceu_camera: use managed memory and resource allocations
Use managed allocations to simplify error handling and clean up paths.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
.../platform/soc_camera/sh_mobile_ceu_camera.c | 32 +--
1 files changed, 9 insertions(+), 23 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 bf66cb4..27eeca1 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -2088,15 +2088,13 @@ static int __devinit sh_mobile_ceu_probe(struct
platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (!res || (int)irq = 0) {
dev_err(pdev-dev, Not enough CEU platform resources.\n);
- err = -ENODEV;
- goto exit;
+ return -ENODEV;
}
- pcdev = kzalloc(sizeof(*pcdev), GFP_KERNEL);
+ pcdev = devm_kzalloc(pdev-dev, sizeof(*pcdev), GFP_KERNEL);
if (!pcdev) {
dev_err(pdev-dev, Could not allocate pcdev\n);
- err = -ENOMEM;
- goto exit;
+ return -ENOMEM;
}
INIT_LIST_HEAD(pcdev-capture);
@@ -2105,19 +2103,17 @@ static int __devinit sh_mobile_ceu_probe(struct
platform_device *pdev)
pcdev-pdata = pdev-dev.platform_data;
if (!pcdev-pdata) {
- err = -EINVAL;
dev_err(pdev-dev, CEU platform data not set.\n);
- goto exit_kfree;
+ return -EINVAL;
}
pcdev-max_width = pcdev-pdata-max_width ? : 2560;
pcdev-max_height = pcdev-pdata-max_height ? : 1920;
- base = ioremap_nocache(res-start, resource_size(res));
+ base = devm_request_and_ioremap(pdev-dev, res);
if (!base) {
- err = -ENXIO;
dev_err(pdev-dev, Unable to ioremap CEU registers.\n);
- goto exit_kfree;
+ return -ENXIO;
}
pcdev-irq = irq;
@@ -2133,16 +2129,15 @@ static int __devinit sh_mobile_ceu_probe(struct
platform_device *pdev)
DMA_MEMORY_EXCLUSIVE);
if (!err) {
dev_err(pdev-dev, Unable to declare CEU memory.\n);
- err = -ENXIO;
- goto exit_iounmap;
+ return -ENXIO;
}
pcdev-video_limit = resource_size(res);
}
/* request irq */
- err = request_irq(pcdev-irq, sh_mobile_ceu_irq, IRQF_DISABLED,
- dev_name(pdev-dev), pcdev);
+ err = devm_request_irq(pdev-dev, pcdev-irq, sh_mobile_ceu_irq,
+ IRQF_DISABLED, dev_name(pdev-dev), pcdev);
if (err) {
dev_err(pdev-dev, Unable to register CEU interrupt.\n);
goto exit_release_mem;
@@ -2246,15 +2241,9 @@ exit_free_ctx:
vb2_dma_contig_cleanup_ctx(pcdev-alloc_ctx);
exit_free_clk:
pm_runtime_disable(pdev-dev);
- free_irq(pcdev-irq, pcdev);
exit_release_mem:
if (platform_get_resource(pdev, IORESOURCE_MEM, 1))
dma_release_declared_memory(pdev-dev);
-exit_iounmap:
- iounmap(base);
-exit_kfree:
- kfree(pcdev);
-exit:
return err;
}
@@ -2267,10 +2256,8 @@ static int __devexit sh_mobile_ceu_remove(struct
platform_device *pdev)
soc_camera_host_unregister(soc_host);
pm_runtime_disable(pdev-dev);
- free_irq(pcdev-irq, pcdev);
if (platform_get_resource(pdev, IORESOURCE_MEM, 1))
dma_release_declared_memory(pdev-dev);
- iounmap(pcdev-base);
vb2_dma_contig_cleanup_ctx(pcdev-alloc_ctx);
if (csi2_pdev csi2_pdev-dev.driver) {
struct module *csi2_drv = csi2_pdev-dev.driver-owner;
@@ -2279,7 +2266,6 @@ static int __devexit sh_mobile_ceu_remove(struct
platform_device *pdev)
platform_device_put(csi2_pdev);
module_put(csi2_drv);
}
- kfree(pcdev);
return 0;
}
--
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/2] media: sh_mobile_csi2: use managed memory and resource allocations
Use managed allocations to simplify error handling and clean up paths.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/platform/soc_camera/sh_mobile_csi2.c | 23 +++
1 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/soc_camera/sh_mobile_csi2.c
b/drivers/media/platform/soc_camera/sh_mobile_csi2.c
index 0528650..c573be7 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_csi2.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_csi2.c
@@ -318,23 +318,16 @@ static __devinit int sh_csi2_probe(struct platform_device
*pdev)
return -EINVAL;
}
- priv = kzalloc(sizeof(struct sh_csi2), GFP_KERNEL);
+ priv = devm_kzalloc(pdev-dev, sizeof(struct sh_csi2), GFP_KERNEL);
if (!priv)
return -ENOMEM;
priv-irq = irq;
- if (!request_mem_region(res-start, resource_size(res), pdev-name)) {
- dev_err(pdev-dev, CSI2 register region already claimed\n);
- ret = -EBUSY;
- goto ereqreg;
- }
-
- priv-base = ioremap(res-start, resource_size(res));
+ priv-base = devm_request_and_ioremap(pdev-dev, res);
if (!priv-base) {
- ret = -ENXIO;
dev_err(pdev-dev, Unable to ioremap CSI2 registers.\n);
- goto eremap;
+ return -ENXIO;
}
priv-pdev = pdev;
@@ -357,11 +350,7 @@ static __devinit int sh_csi2_probe(struct platform_device
*pdev)
return 0;
esdreg:
- iounmap(priv-base);
-eremap:
- release_mem_region(res-start, resource_size(res));
-ereqreg:
- kfree(priv);
+ platform_set_drvdata(pdev, NULL);
return ret;
}
@@ -369,14 +358,10 @@ ereqreg:
static __devexit int sh_csi2_remove(struct platform_device *pdev)
{
struct sh_csi2 *priv = platform_get_drvdata(pdev);
- struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
v4l2_device_unregister_subdev(priv-subdev);
pm_runtime_disable(pdev-dev);
- iounmap(priv-base);
- release_mem_region(res-start, resource_size(res));
platform_set_drvdata(pdev, NULL);
- kfree(priv);
return 0;
}
--
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] MAINTAINERS: add entries for sh_veu and sh_vou V4L2 drivers
sh_vou might be better described by Odd Fixes, but mark it Maintained for now. sh_veu is a new driver and might see some development in the future. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- MAINTAINERS | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9fba9ed..c20199e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6719,6 +6719,20 @@ M: Robin Holt h...@sgi.com S: Maintained F: drivers/misc/sgi-xp/ +SH_VEU V4L2 MEM2MEM DRIVER +M: Guennadi Liakhovetski g.liakhovet...@gmx.de +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/platform/sh_veu.c +F: include/media/sh_veu.h + +SH_VOU V4L2 OUTPUT DRIVER +M: Guennadi Liakhovetski g.liakhovet...@gmx.de +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/platform/sh_vou.c +F: include/media/sh_vou.h + SIMPLE FIRMWARE INTERFACE (SFI) M: Len Brown l...@kernel.org L: sfi-de...@simplefirmware.org -- 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 v3 0/9] Media Controller capture driver for DM365
On Wednesday 28 November 2012 16:12:00 Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com For staging, and provided that all parties involved understand that an API compatibility layer with the existing drivers/media/platform/davinci/ driver (called the existing driver) will need to be provided when this media controller aware driver will move out of staging to drivers/media/ and replace the existing driver, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Mauro/Greg, The below series of patches have gone through good amount of reviews, and agreed by Laurent, Hans and Sakari to be part of the staging tree. I am combining the patchs with the pull request so we can get them into the 3.8 kernel. Please pull these patches.If you want a seperate pull request, please let me know. This patch set adds media controller based capture driver for DM365. This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. Also, the core functionality of the driver comes from the arago vpfe capture driver of which the isif capture was based on V4L2, with other drivers like ipipe, ipipeif and Resizer. Changes for v2: 1: Migrated the driver for videobuf2 usage pointed Hans. 2: Changed the design as pointed by Laurent, Exposed one more subdevs ipipeif and split the resizer subdev into three subdevs. 3: Rearrganed the patch sequence and changed the commit messages. 4: Changed the file architecture as pointed by Laurent. Changes for v3: 1: Rebased on staging. 2: Seprated out patches which would go into staging. The following changes since commit c6c22955f80f2db9614b01fe5a3d1cfcd8b3d848: [media] dma-mapping: fix dma_common_get_sgtable() conditional compilation (2012-11-27 09:42:31 -0200) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git vpfe_driver_staging Manjunath Hadli (9): davinci: vpfe: add v4l2 capture driver with media interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: dm365: add IPIPEIF driver based on media framework davinci: vpfe: dm365: add ISIF driver based on media framework davinci: vpfe: dm365: add IPIPE support for media controller driver davinci: vpfe: dm365: add IPIPE hardware layer support davinci: vpfe: dm365: resizer driver based on media framework davinci: vpfe: dm365: add build infrastructure for capture driver davinci: vpfe: Add documentation and TODO drivers/staging/media/Kconfig |2 + drivers/staging/media/Makefile |1 + drivers/staging/media/davinci_vpfe/Kconfig |9 + drivers/staging/media/davinci_vpfe/Makefile|3 + drivers/staging/media/davinci_vpfe/TODO| 34 + .../staging/media/davinci_vpfe/davinci-vpfe-mc.txt | 154 ++ .../staging/media/davinci_vpfe/davinci_vpfe_user.h | 1290 drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 1863 + drivers/staging/media/davinci_vpfe/dm365_ipipe.h | 179 ++ .../staging/media/davinci_vpfe/dm365_ipipe_hw.c| 1048 ++ .../staging/media/davinci_vpfe/dm365_ipipe_hw.h| 559 ++ drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 1071 ++ drivers/staging/media/davinci_vpfe/dm365_ipipeif.h | 233 +++ .../media/davinci_vpfe/dm365_ipipeif_user.h| 93 + drivers/staging/media/davinci_vpfe/dm365_isif.c| 2104 + drivers/staging/media/davinci_vpfe/dm365_isif.h| 203 ++ .../staging/media/davinci_vpfe/dm365_isif_regs.h | 294 +++ drivers/staging/media/davinci_vpfe/dm365_resizer.c | 1999 + drivers/staging/media/davinci_vpfe/dm365_resizer.h | 244 +++ drivers/staging/media/davinci_vpfe/vpfe.h | 86 + .../staging/media/davinci_vpfe/vpfe_mc_capture.c | 740 +++ .../staging/media/davinci_vpfe/vpfe_mc_capture.h | 97 + drivers/staging/media/davinci_vpfe/vpfe_video.c| 1620 +++ drivers/staging/media/davinci_vpfe/vpfe_video.h| 155 ++ 24 files changed, 14081 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/media/davinci_vpfe/Kconfig create mode 100644 drivers/staging/media/davinci_vpfe/Makefile create mode 100644 drivers/staging/media/davinci_vpfe/TODO create mode 100644 drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt create mode 100644 drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.c create mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.h create mode 100644
Re: [PATCH v2 0/4] media: mx2_camera: Remove i.mx25 and clean up.
Hi Javier On Tue, 30 Oct 2012, Javier Martin wrote: Changes since v1: - Remove i.MX25 support in the Kconfig file too in patch 1. [PATCH v2 1/4] media: mx2_camera: Remove i.mx25 support. [PATCH v2 2/4] media: mx2_camera: Add image size HW limits. [PATCH v2 3/4] media: mx2_camera: Remove 'buf_cleanup' callback. [PATCH v2 4/4] media: mx2_camera: Remove buffer states. Now that Fabio has confirmed, that the driver is working on i.MX25, we don't need to remove support for it. So, patch 1 is dropped, patch 2 I adjusted to be i.MX27-specific, patch also cannot be applied if i.MX25 is kept, patch 4 cannot be used either, becuase the buffer state is actually checked on i.MX25. It might be possible to remove or simplify it still, but that would require a different patch. 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
[GIT PULL] 3.7 soc-camera fixes
Hi Mauro Please, push these 3 fixes for 3.7. The following changes since commit e9296e89b85604862bd9ec2d54dc43edad775c0d: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-11-28 21:54:07 -0800) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git 3.7-rc7-fixes Anatolij Gustschin (1): soc_camera: fix VIDIOC_S_CROP ioctl Cyril Roelandt (1): mx2_camera: use GFP_ATOMIC under spin lock. Guennadi Liakhovetski (1): media: sh-vou: fix compiler warnings drivers/media/platform/sh_vou.c|7 --- drivers/media/platform/soc_camera/mx2_camera.c |2 +- drivers/media/platform/soc_camera/soc_camera.c |2 ++ 3 files changed, 7 insertions(+), 4 deletions(-) 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
[GIT PULL] soc-camera for 3.8 second lot
Hi Mauro Most these patches have been posted a while ago, they include the sh_veu mem2mem driver - unchanged from the previous pull request, but this time I'm also including the mem2mem core patch, that's needed to make sh_veu compile without warnings. Also including an update to MAINTAINERS and to soc-camera documentation. The following changes since commit d8658bca2e5696df2b6c69bc5538f8fe54e4a01e: [media] omap3isp: Replace cpu_is_omap3630() with ISP revision check (2012-11-28 10:54:46 -0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.8-set_2 Guennadi Liakhovetski (9): media: mem2mem: make reference to struct m2m_ops in the core const media: add a VEU MEM2MEM format conversion and scaling driver media: soc-camera: use managed devm_regulator_bulk_get() media: sh-mobile-ceu-camera: runtime PM suspending doesn't have to be synchronous media: soc-camera: update documentation media: soc-camera: remove superfluous JPEG checking media: sh_mobile_csi2: use managed memory and resource allocations media: sh_mobile_ceu_camera: use managed memory and resource allocations MAINTAINERS: add entries for sh_veu and sh_vou V4L2 drivers Javier Martin (1): media: mx2_camera: Add image size HW limits. Documentation/video4linux/soc-camera.txt | 146 ++-- MAINTAINERS| 14 + drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile|2 + drivers/media/platform/sh_veu.c| 1264 drivers/media/platform/soc_camera/mx2_camera.c |8 +- .../platform/soc_camera/sh_mobile_ceu_camera.c | 36 +- drivers/media/platform/soc_camera/sh_mobile_csi2.c | 23 +- drivers/media/platform/soc_camera/soc_camera.c |7 +- drivers/media/platform/soc_camera/soc_mediabus.c |6 - drivers/media/v4l2-core/v4l2-mem2mem.c |4 +- include/media/v4l2-mem2mem.h |2 +- 12 files changed, 1390 insertions(+), 131 deletions(-) create mode 100644 drivers/media/platform/sh_veu.c 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 v3 0/9] Media Controller capture driver for DM365
Em Thu, 29 Nov 2012 08:43:36 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Wed November 28 2012 20:30:21 Greg Kroah-Hartman wrote: On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote: On Wed November 28 2012 18:22:48 Greg Kroah-Hartman wrote: On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote: Em Wed, 28 Nov 2012 12:56:10 +0100 Hans Verkuil hansv...@cisco.com escreveu: On Wed 28 November 2012 12:45:37 Dan Carpenter wrote: I wish people wouldn't submit big patches right before the merge window opens... :/ It's better to let it sit in linux-next for a couple weeks so people can mess with it a bit. It's been under review for quite some time now, and the main change since the last posted version is that this is now moved to staging/media. So it is not yet ready for prime time, but we do want it in to simplify the last remaining improvements needed to move it to drivers/media. last remaining improvements? I didn't review the patchset, but the TODO list seems to have several pending stuff there: +- User space interface refinement +- Controls should be used when possible rather than private ioctl +- No enums should be used +- Use of MC and V4L2 subdev APIs when applicable +- Single interface header might suffice +- Current interface forces to configure everything at once +- Get rid of the dm365_ipipe_hw.[ch] layer +- Active external sub-devices defined by link configuration; no strcmp + needed +- More generic platform data (i2c adapters) +- The driver should have no knowledge of possible external subdevs; see + struct vpfe_subdev_id +- Some of the hardware control should be refactorede +- Check proper serialisation (through mutexes and spinlocks) +- Names that are visible in kernel global namespace should have a common + prefix (or a few) From the above comments, both Kernelspace and Userspace APIs require lots of work. And that's why it is in staging. Should a long TODO list now suddenly prevent staging from being used? In Barcelona we discussed this and the only requirement we came up was was that it should compile. Yes, that's all I care about in staging, but as I stated, I don't maintain drivers/staging/media/ that area is under Mauro's control (MAINTAINERS even says this), and I'm a bit leery of going against the wishes of an existing subsystem maintainer for adding staging drivers that tie into their subsystem. On my understanding, this is not a normal staging driver for some unsupported hardware. It is a driver that is meant to replace an existing driver, whose plans is to implement a different, userspace-incompatible API set than the existing one. In other words, merging it as-is would give the false impression that only solving the TODO items would be enough to promote it. However, the main criteria for a replacement driver is to not cause any regression. So, a compatibility layer and compatibility tests that warrants this is a requirement (eventually using the libv4l's LD_PRELOAD approach). So, if the ones working on the driver are also willing to work on the needed compatibility bits, I'm ok on merging it at staging; if not, there's no sense on spending everybody's time on something that will be discarded on a few kernel cycles. So, the main discussion here is not about merging it at staging or not; is to be sure that, once it got merged, the right things will be addressed, in order to allow it to replace the existing driver. Of course, Dan's request is valid; pushing it right now at -next will give only a week for the others to review a big driver. So, better to delay it. In any case, there are already 400+ patches on my queue that arrived before these late-submitted patch series. So, it would be delayed anyway to the next cycle, due to the very high volume of pending stuff there, and to his late submission. So, in summary: Prabhakar/Manju: If you'll be committed to make sure that no regressions will happen when this driver will be promoted and replace the existing driver, please update the TODO to point that the compatibility bits is needed. I'll then merge it after the end of the merge window. 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 v3 0/9] Media Controller capture driver for DM365
Hi Mauro, On Thursday 29 November 2012 04:09 PM, Mauro Carvalho Chehab wrote: Em Thu, 29 Nov 2012 08:43:36 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On Wed November 28 2012 20:30:21 Greg Kroah-Hartman wrote: On Wed, Nov 28, 2012 at 08:18:20PM +0100, Hans Verkuil wrote: On Wed November 28 2012 18:22:48 Greg Kroah-Hartman wrote: On Wed, Nov 28, 2012 at 10:18:02AM -0200, Mauro Carvalho Chehab wrote: Em Wed, 28 Nov 2012 12:56:10 +0100 Hans Verkuil hansv...@cisco.com escreveu: On Wed 28 November 2012 12:45:37 Dan Carpenter wrote: I wish people wouldn't submit big patches right before the merge window opens... :/ It's better to let it sit in linux-next for a couple weeks so people can mess with it a bit. It's been under review for quite some time now, and the main change since the last posted version is that this is now moved to staging/media. So it is not yet ready for prime time, but we do want it in to simplify the last remaining improvements needed to move it to drivers/media. last remaining improvements? I didn't review the patchset, but the TODO list seems to have several pending stuff there: +- User space interface refinement +- Controls should be used when possible rather than private ioctl +- No enums should be used +- Use of MC and V4L2 subdev APIs when applicable +- Single interface header might suffice +- Current interface forces to configure everything at once +- Get rid of the dm365_ipipe_hw.[ch] layer +- Active external sub-devices defined by link configuration; no strcmp + needed +- More generic platform data (i2c adapters) +- The driver should have no knowledge of possible external subdevs; see + struct vpfe_subdev_id +- Some of the hardware control should be refactorede +- Check proper serialisation (through mutexes and spinlocks) +- Names that are visible in kernel global namespace should have a common + prefix (or a few) From the above comments, both Kernelspace and Userspace APIs require lots of work. And that's why it is in staging. Should a long TODO list now suddenly prevent staging from being used? In Barcelona we discussed this and the only requirement we came up was was that it should compile. Yes, that's all I care about in staging, but as I stated, I don't maintain drivers/staging/media/ that area is under Mauro's control (MAINTAINERS even says this), and I'm a bit leery of going against the wishes of an existing subsystem maintainer for adding staging drivers that tie into their subsystem. On my understanding, this is not a normal staging driver for some unsupported hardware. It is a driver that is meant to replace an existing driver, whose plans is to implement a different, userspace-incompatible API set than the existing one. In other words, merging it as-is would give the false impression that only solving the TODO items would be enough to promote it. However, the main criteria for a replacement driver is to not cause any regression. So, a compatibility layer and compatibility tests that warrants this is a requirement (eventually using the libv4l's LD_PRELOAD approach). So, if the ones working on the driver are also willing to work on the needed compatibility bits, I'm ok on merging it at staging; if not, there's no sense on spending everybody's time on something that will be discarded on a few kernel cycles. So, the main discussion here is not about merging it at staging or not; is to be sure that, once it got merged, the right things will be addressed, in order to allow it to replace the existing driver. Of course, Dan's request is valid; pushing it right now at -next will give only a week for the others to review a big driver. So, better to delay it. In any case, there are already 400+ patches on my queue that arrived before these late-submitted patch series. So, it would be delayed anyway to the next cycle, due to the very high volume of pending stuff there, and to his late submission. So, in summary: Prabhakar/Manju: If you'll be committed to make sure that no regressions will happen when this driver will be promoted and replace the existing driver, please update the TODO to point that the compatibility bits is needed. Sure Mauro. All this long wait to get into the mainline would be for nothing if we do not go ahead and make the necessary changes you want us to do to get to the media folder. We will update the TODO patch and resend the series. I'll then merge it after the end of the merge window. thank you very much. Regards, Mauro Thanks and Regards, -Manju -- 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
[Q]: Tevii S480 higher DVB-S2 symbol rate
Hi all, a quick question about the tevii S480: I need to tune to a transponder which does DVB-S2 45MS/s (QPSK). I have a dying TBS 6921 which was able to sustain this rate flawlessly, but the spec of the S480 seems to indicate that it should do it also, but I'd like to know if someone has actually tested it already. Moreover if someone could comment on reliability. TIA Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT FIXES FOR 3.8] Various USB webcam fixes
Hi Mauro, Please pull from my tree for some assorted USB webcam fixes for 3.8 The following changes since commit d8658bca2e5696df2b6c69bc5538f8fe54e4a01e: [media] omap3isp: Replace cpu_is_omap3630() with ISP revision check (2012-11-28 10:54:46 -0200) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.8 for you to fetch changes up to 325b64b6cb9090c1bc7cda5444f84b2c00acf926: Documentation/media: Remove docs for obsoleted and removed v4l1 drivers (2012-11-29 11:29:48 +0100) Hans de Goede (3): gspca-pac207: Add a led_invert module parameter stk-webcam: Add an upside down dmi table, and add the Asus G1 to it Documentation/media: Remove docs for obsoleted and removed v4l1 drivers Jean-François Moine (1): gspca - stv06xx: Fix a regression with the bridge/sensor vv6410 Documentation/video4linux/et61x251.txt | 315 Documentation/video4linux/ibmcam.txt | 323 Documentation/video4linux/m5602.txt | 12 - Documentation/video4linux/ov511.txt | 288 -- Documentation/video4linux/se401.txt | 54 --- Documentation/video4linux/stv680.txt | 53 --- Documentation/video4linux/w9968cf.txt| 458 --- Documentation/video4linux/zc0301.txt | 270 - drivers/media/usb/gspca/pac207.c | 32 +- drivers/media/usb/gspca/stv06xx/stv06xx_vv6410.c | 4 + drivers/media/usb/stkwebcam/stk-webcam.c | 56 ++- 11 files changed, 76 insertions(+), 1789 deletions(-) delete mode 100644 Documentation/video4linux/et61x251.txt delete mode 100644 Documentation/video4linux/ibmcam.txt delete mode 100644 Documentation/video4linux/m5602.txt delete mode 100644 Documentation/video4linux/ov511.txt delete mode 100644 Documentation/video4linux/se401.txt delete mode 100644 Documentation/video4linux/stv680.txt delete mode 100644 Documentation/video4linux/w9968cf.txt delete mode 100644 Documentation/video4linux/zc0301.txt Thanks 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] gspca - stv06xx: Fix a regression with the bridge/sensor vv6410
Hi,
Thanks for the patch I've added this to my tree, and it is part
of the pull-request I just send to Mauro for 3.8
Regards,
Hans
On 11/22/2012 12:59 PM, Jean-Francois Moine wrote:
From: Jean-François Moine moin...@free.fr
Setting the H and V flip controls at webcam connection time prevents
the webcam to work correctly.
This patch checks if the webcam is streaming before setting the flips.
It does not set the flips (nor other controls) at webcam start time.
Tested-by: Philippe ROUBACH philippe.roub...@free.fr
Signed-off-by: Jean-François Moine moin...@free.fr
--- a/drivers/media/usb/gspca/stv06xx/stv06xx_vv6410.c
+++ b/drivers/media/usb/gspca/stv06xx/stv06xx_vv6410.c
@@ -52,9 +52,13 @@
switch (ctrl-id) {
case V4L2_CID_HFLIP:
+ if (!gspca_dev-streaming)
+ return 0;
err = vv6410_set_hflip(gspca_dev, ctrl-val);
break;
case V4L2_CID_VFLIP:
+ if (!gspca_dev-streaming)
+ return 0;
err = vv6410_set_vflip(gspca_dev, ctrl-val);
break;
case V4L2_CID_GAIN:
--
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: 093a:2460 Webcam (Pixart PAC207BCA) - inverted LED logic
Hi, On 11/22/2012 04:27 PM, Yuri Glushkov wrote: [1.] One line summary of the problem: 093a:2460 Webcam (Pixart PAC207BCA) - inverted LED logic [2.] Full description of the problem/report: The LED on this webcam is always turned on when connected to USB, unless some application uses it - the behavior that is opposite to what is expected. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/525959 The problem persists on all versions of Ubuntu I've tested. I've a webcam with the same usb-id where the LED is not inverted, so I'm afraid that it is impossible to tell from the driver side if the led is inverted or not. Therefor I've written a patch for the gspca_pac207 driver which adds a led_invert module parameter, when you set this to 1, it will invert the turning on/off of the led. You can find the patch for this here: http://git.linuxtv.org/hgoede/gspca.git/commitdiff/8806976535f7da2ed1d93bc1230d68e5ca1acd9d This patch should make it into 3.8. 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: ivtv driver inputs randomly block
Hi Brian, See my comments below. On Wed, Nov 28, 2012 at 8:19 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: On 12-11-28 08:13 AM, Ezequiel Garcia wrote: Try again with modprobe ivtv ivtv_debug=10 OK. Happened again. The kernel log for the whole day since starting the module with debug this morning can be found at http://brian.interlinx.bc.ca/ivtv-dmesg.txt.bz2. Associated with that log there was a successful recording from 09:00:00 until 10:00:00 then another successful recording from 14:00:00 until 15:00:00 and then failed recordings starting at 15:00:00 until 18:00:00. The log cuts off just short of 18:00:00 but there's nothing different about the pattern from the end of the log until 18:00:04 from the previous 3 hours or so. It seems that the problem lies in amongst the start of these lines from the log, as my best guess: Nov 28 15:00:05 cmurrell kernel: [868297.536049] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 15:00:07 cmurrell kernel: [868300.039324] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 15:00:07 cmurrell kernel: [868300.039330] ivtv0: info: close stopping capture Nov 28 15:00:07 cmurrell kernel: [868300.039334] ivtv0: info: Stop Capture Nov 28 15:00:09 cmurrell kernel: [868302.140151] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 28 15:00:09 cmurrell kernel: [868302.148093] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 28 15:00:09 cmurrell kernel: [868302.148101] ivtv0: info: Start encoder stream encoder MPG Nov 28 15:00:09 cmurrell kernel: [868302.188580] ivtv0: info: Setup VBI API header 0xbd03 pkts 1 buffs 4 ln 24 sz 1456 Nov 28 15:00:09 cmurrell kernel: [868302.188655] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 28 15:00:09 cmurrell kernel: [868302.191952] ivtv0: info: PGM Index at 0x00180150 with 400 elements Nov 28 15:00:10 cmurrell kernel: [868302.544052] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 15:00:12 cmurrell kernel: [868305.047260] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 15:00:12 cmurrell kernel: [868305.047265] ivtv0: info: close stopping capture Nov 28 15:00:12 cmurrell kernel: [868305.047270] ivtv0: info: Stop Capture ... FWIW, the recording software here is MythTV completely up to date on the 0.25-fixes branch. Thoughts? Mmm, the log shows this repeating pattern: --- Nov 28 17:54:46 cmurrell kernel: [878779.229702] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 28 17:54:46 cmurrell kernel: [878779.233129] ivtv0: info: PGM Index at 0x00180150 with 400 elements Nov 28 17:54:47 cmurrell kernel: [878779.556039] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 17:54:49 cmurrell kernel: [878782.059204] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 17:54:49 cmurrell kernel: [878782.059209] ivtv0: info: close stopping capture Nov 28 17:54:49 cmurrell kernel: [878782.059214] ivtv0: info: Stop Capture Nov 28 17:54:51 cmurrell kernel: [878784.156135] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 28 17:54:51 cmurrell kernel: [878784.166157] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 28 17:54:51 cmurrell kernel: [878784.166165] ivtv0: info: Start encoder stream encoder MPG --- And from 15:00 to 18:00 recording fails? Perhaps it would make sense to restart application upon driver failure, now that output is more verbose. Regards, Ezequiel PS: Please don't drop linux-media list from Cc -- 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: Available and supported DVB-C USB device
On 11/29/2012 03:27 AM, P. van Gaans wrote: I'm living in The Netherlands and am looking for a DVB-C USB device that's available, supported and (preferably) affordable. Devices that are available and affordable would appear to be the Delock DVB-C USB stick (which I can't find a whole lot about) and the MSI DigiVox mini Trio. According to a message on the mailinglist from 2010 by Matthias Larisch: I recently bought a DigiVox Trio by MSI. This card contains the following chips: nxp tda18271hdc2 (tuner) micronas drx 3926ka3 (demodulator, 3in1) em2884 atmlh946 64c (eeprom) micronas avf 4910ba1 so it is comparable to the Terratec Cinergy HTC USB XS HD and the TerraTec H5. Back in 2010 it didn't work, but I've noticed the EM2884 and Micronas DRX 3926K (maybe not the same?) and TDA18271HDC2 do work in the PCTV QuatroStick nano. (http://linuxtv.org/wiki/index.php/DVB-C_USB_Devices) So perhaps the MSI could also work? Or maybe someone has suggestions for a suitable device. Most of the devices on the wiki page are sadly either unavailable or very expensive. Best regards, Pim I prefer to look Anysee, PCTV and Hauppauge models. There is not very many DVB-C USB devices available and even less which are supported on Linux. 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: ivtv driver inputs randomly block
On Thu, 2012-11-29 at 12:29 -0300, Ezequiel Garcia wrote: Hi Brian, See my comments below. On Wed, Nov 28, 2012 at 8:19 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: On 12-11-28 08:13 AM, Ezequiel Garcia wrote: Try again with modprobe ivtv ivtv_debug=10 OK. Happened again. The kernel log for the whole day since starting the module with debug this morning can be found at http://brian.interlinx.bc.ca/ivtv-dmesg.txt.bz2. Associated with that log there was a successful recording from 09:00:00 until 10:00:00 then another successful recording from 14:00:00 until 15:00:00 and then failed recordings starting at 15:00:00 until 18:00:00. The log cuts off just short of 18:00:00 but there's nothing different about the pattern from the end of the log until 18:00:04 from the previous 3 hours or so. It seems that the problem lies in amongst the start of these lines from the log, as my best guess: Nov 28 15:00:05 cmurrell kernel: [868297.536049] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 15:00:07 cmurrell kernel: [868300.039324] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 15:00:07 cmurrell kernel: [868300.039330] ivtv0: info: close stopping capture Nov 28 15:00:07 cmurrell kernel: [868300.039334] ivtv0: info: Stop Capture Nov 28 15:00:09 cmurrell kernel: [868302.140151] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 28 15:00:09 cmurrell kernel: [868302.148093] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 28 15:00:09 cmurrell kernel: [868302.148101] ivtv0: info: Start encoder stream encoder MPG Nov 28 15:00:09 cmurrell kernel: [868302.188580] ivtv0: info: Setup VBI API header 0xbd03 pkts 1 buffs 4 ln 24 sz 1456 Nov 28 15:00:09 cmurrell kernel: [868302.188655] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 28 15:00:09 cmurrell kernel: [868302.191952] ivtv0: info: PGM Index at 0x00180150 with 400 elements Nov 28 15:00:10 cmurrell kernel: [868302.544052] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 15:00:12 cmurrell kernel: [868305.047260] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 15:00:12 cmurrell kernel: [868305.047265] ivtv0: info: close stopping capture Nov 28 15:00:12 cmurrell kernel: [868305.047270] ivtv0: info: Stop Capture ... FWIW, the recording software here is MythTV completely up to date on the 0.25-fixes branch. Thoughts? Mmm, the log shows this repeating pattern: --- Nov 28 17:54:46 cmurrell kernel: [878779.229702] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 28 17:54:46 cmurrell kernel: [878779.233129] ivtv0: info: PGM Index at 0x00180150 with 400 elements Nov 28 17:54:47 cmurrell kernel: [878779.556039] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 17:54:49 cmurrell kernel: [878782.059204] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 17:54:49 cmurrell kernel: [878782.059209] ivtv0: info: close stopping capture Nov 28 17:54:49 cmurrell kernel: [878782.059214] ivtv0: info: Stop Capture Nov 28 17:54:51 cmurrell kernel: [878784.156135] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 28 17:54:51 cmurrell kernel: [878784.166157] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 28 17:54:51 cmurrell kernel: [878784.166165] ivtv0: info: Start encoder stream encoder MPG --- And from 15:00 to 18:00 recording fails? Perhaps it would make sense to restart application upon driver failure, now that output is more verbose. Hi Ezequiel, Nope. IIRC, that's just MythTV timing-out, closing the device node, and reopening the device node, in attempt to make things work again. Hi Brian, I haven't checked the log you provided yet, but you'll likely need to set the module debug flags a little more verbose. /sbin/modinfo ivtv | less [...] parm: debug:Debug level (bitmask). Default: 0 1/0x0001: warning 2/0x0002: info 4/0x0004: mailbox 8/0x0008: ioctl 16/0x0010: file 32/0x0020: dma 64/0x0040: irq 128/0x0080: decoder 256/0x0100: yuv 512/0x0200: i2c 1024/0x0400: high volume [..] So maybe as root # echo 0x07f /sys/module/ivtv/parameters/debug until the problem appears. Then once you experience the problem change it to high volume # echo 0x47f /sys/module/ivtv/parameters/debug You may want to also get a baseline of what a good capture looks like using high volume debugging. Be aware that high volume debugging will fill up your logs and degrade performance a little, so you don't want to normally use high volume debugging. Regards, Ezequiel PS: Please don't drop linux-media list from Cc +1 The ideas or interest of one individual often spurs that of others. Regards, Andy -- To
Re: ivtv driver inputs randomly block
On 12-11-29 10:29 AM, Ezequiel Garcia wrote: Hi Brian, Hi Garcia, Mmm, the log shows this repeating pattern: --- Nov 28 17:54:46 cmurrell kernel: [878779.229702] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 28 17:54:46 cmurrell kernel: [878779.233129] ivtv0: info: PGM Index at 0x00180150 with 400 elements Nov 28 17:54:47 cmurrell kernel: [878779.556039] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=0, flags=0 Nov 28 17:54:49 cmurrell kernel: [878782.059204] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 28 17:54:49 cmurrell kernel: [878782.059209] ivtv0: info: close stopping capture Nov 28 17:54:49 cmurrell kernel: [878782.059214] ivtv0: info: Stop Capture Nov 28 17:54:51 cmurrell kernel: [878784.156135] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 28 17:54:51 cmurrell kernel: [878784.166157] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 28 17:54:51 cmurrell kernel: [878784.166165] ivtv0: info: Start encoder stream encoder MPG Yes, as I indicated. And from 15:00 to 18:00 recording fails? Yes. Perhaps it would make sense to restart application upon driver failure, now that output is more verbose. Meaning what exactly? Restart MythTV? How would I restart MythTV when the failure occurs? Do you mean like having a daemon watching dmesg that restarts MythTV when this happens? That's a very ugly hack-around that will have negative side effects per below... This failure doesn't necessarily affect all tuners at the same time so I would potentially be restarting MythTV while other tuners are recording, interrupting good recordings to fix one tuner which is having a problem. I am sure you would agree that this is not really a suitable work-around, yes? PS: Please don't drop linux-media list from Cc I don't think I did. All of my messages have been copied to the list, albeit I post them through gmane rather than posting to the list directly since I read via gmane and am not a direct subscriber to the list. Most lists will disallow postings by non-subscribers. I know vger.kernel.org does allow posting by non-subscribers on at least some of their lists but I am not aware of it being a site-wide policy or not so to be on the safe side I just let gmane post it to the list. Perhaps you got the copy I CC'd to you directly before you got the copy that went to the list via gmane. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: ivtv driver inputs randomly block
On 12-11-29 10:50 AM, Andy Walls wrote: Hi Ezequiel, Nope. IIRC, that's just MythTV timing-out, closing the device node, and reopening the device node, in attempt to make things work again. Seems a very reasonable explanation. Hi Brian, Hi Andy, I haven't checked the log you provided yet, but you'll likely need to set the module debug flags a little more verbose. OK. /sbin/modinfo ivtv | less [...] parm: debug:Debug level (bitmask). Default: 0 1/0x0001: warning 2/0x0002: info 4/0x0004: mailbox 8/0x0008: ioctl 16/0x0010: file 32/0x0020: dma 64/0x0040: irq 128/0x0080: decoder 256/0x0100: yuv 512/0x0200: i2c 1024/0x0400: high volume [..] So maybe as root # echo 0x07f /sys/module/ivtv/parameters/debug until the problem appears. Then once you experience the problem change it to high volume Will waiting for MythTV to report an error, such as: MPEGRec(/dev/video1): Device error detected be too late to turn up debugging or should that be sufficient enough timing? Although, MythTV seems to report that error at the end of every recording so I'm not sure how I will filter out the false reports -- unless I write a smarter (i.e. than a single line match) log watcher. Anyway, that's my problem, not yours. :-) # echo 0x47f /sys/module/ivtv/parameters/debug You may want to also get a baseline of what a good capture looks like using high volume debugging. Just did that. Reduced to 0x07f after about a minute and 23 seconds. Be aware that high volume debugging will fill up your logs and degrade performance a little, so you don't want to normally use high volume debugging. Indeed, it's quite verbose. +1 The ideas or interest of one individual often spurs that of others. Indeed, I always keep list replies on list and as I mentioned to Ezequiel (sorry Ezequiel, I got your name wrong on my previous post. my apologies) and I am seeing the copies -- but through gmane. I don't see the copies on the spincs.net archive. I suspect there is a lag at gmane posting to the list. In any case, I have CC'd this one directly to the list @vger.kernel.org and will just hope it has an open posting policy. Cheers and thanks much! b. signature.asc Description: OpenPGP digital signature
[GIT PULL FOR 3.8] exynos-gsc driver updates
Hi Mauro, The following changes since commit d8658bca2e5696df2b6c69bc5538f8fe54e4a01e: [media] omap3isp: Replace cpu_is_omap3630() with ISP revision check (2012-11-28 10:54:46 -0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung exynos_gsc_v3.8 for you to fetch changes up to db40d9baead29e1e0efdfbd9e4f03d0f65457bdf: exynos-gsc: modify number of output/capture buffers (2012-11-29 11:49:59 +0100) Sachin Kamat (3): exynos-gsc: Fix checkpatch warning in gsc-m2m.c exynos-gsc: Rearrange error messages for valid prints exynos-gsc: Use devm_clk_get() Shaik Ameer Basha (3): exynos-gsc: Adding tiled multi-planar format to G-Scaler exynos-gsc: propagate timestamps from src to dst buffers exynos-gsc: modify number of output/capture buffers Sylwester Nawrocki (1): exynos-gsc: Correct the clock handling drivers/media/platform/exynos-gsc/gsc-core.c | 48 ++ drivers/media/platform/exynos-gsc/gsc-core.h |5 +++ drivers/media/platform/exynos-gsc/gsc-m2m.c | 22 +++- drivers/media/platform/exynos-gsc/gsc-regs.c |6 4 files changed, 50 insertions(+), 31 deletions(-) --- 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 0/2] omap_vout: remove cpu_is_* uses
* Laurent Pinchart laurent.pinch...@ideasonboard.com [121129 01:37]: Hi Tomi, On Thursday 29 November 2012 11:30:28 Tomi Valkeinen wrote: On 2012-11-28 17:13, Laurent Pinchart wrote: On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote: Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based on current omapdss master branch, which has the omapdss version code. The omapdss version code is queued for v3.8. I'm not sure which is the best way to handle these patches due to the dependency to omapdss. The easiest option is to merge these for 3.9. There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP dependency in the omap_vout driver. I'm not going to touch that, as it doesn't look as trivial as this cpu_is_* removal, and I don't have much knowledge of the omap_vout driver. Compiled, but not tested. Tested on a Beagleboard-xM. Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks. The patches depend on unmerged OMAP DSS patches. Would you like to push this series through linuxtv or through your DSS tree ? The later might be easier, depending on when the required DSS patches will hit mainline. The DSS patches will be merged for 3.8. I can take this via the omapdss tree, as there probably won't be any conflicts with other v4l2 stuff. Or, we can just delay these until 3.9. These patches remove omap platform dependencies, helping the effort to get common ARM kernel. However, as there's still the VRFB code in the omap_vout driver, the dependency remains. Thus, in way, these patches alone don't help anything, and we could delay these for 3.9 and hope that omap_vout_vrfb.c gets converted also for that merge window. OK, I'll queue them for v3.9 then. Please rather queue the cpu_is_omap removal to v3.8 so I can remove plat/cpu.h for omap2+. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses
Hi Tony, On Thursday 29 November 2012 08:29:27 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [121129 01:37]: On Thursday 29 November 2012 11:30:28 Tomi Valkeinen wrote: On 2012-11-28 17:13, Laurent Pinchart wrote: On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote: Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based on current omapdss master branch, which has the omapdss version code. The omapdss version code is queued for v3.8. I'm not sure which is the best way to handle these patches due to the dependency to omapdss. The easiest option is to merge these for 3.9. There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP dependency in the omap_vout driver. I'm not going to touch that, as it doesn't look as trivial as this cpu_is_* removal, and I don't have much knowledge of the omap_vout driver. Compiled, but not tested. Tested on a Beagleboard-xM. Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks. The patches depend on unmerged OMAP DSS patches. Would you like to push this series through linuxtv or through your DSS tree ? The later might be easier, depending on when the required DSS patches will hit mainline. The DSS patches will be merged for 3.8. I can take this via the omapdss tree, as there probably won't be any conflicts with other v4l2 stuff. Or, we can just delay these until 3.9. These patches remove omap platform dependencies, helping the effort to get common ARM kernel. However, as there's still the VRFB code in the omap_vout driver, the dependency remains. Thus, in way, these patches alone don't help anything, and we could delay these for 3.9 and hope that omap_vout_vrfb.c gets converted also for that merge window. OK, I'll queue them for v3.9 then. Please rather queue the cpu_is_omap removal to v3.8 so I can remove plat/cpu.h for omap2+. In that case the patches should go through the DSS tree. Mauro, are you fine with that ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Media Controller capture driver for DM365
Em Thu, 29 Nov 2012 18:15:39 +0530 Manjunath Hadli manjunath.ha...@ti.com escreveu: So, in summary: Prabhakar/Manju: If you'll be committed to make sure that no regressions will happen when this driver will be promoted and replace the existing driver, please update the TODO to point that the compatibility bits is needed. Sure Mauro. All this long wait to get into the mainline would be for nothing if we do not go ahead and make the necessary changes you want us to do to get to the media folder. We will update the TODO patch and resend the series. Ok, thank you! 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: ivtv driver inputs randomly block
Hi Brian, On Thu, Nov 29, 2012 at 12:53 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: [...] I am sure you would agree that this is not really a suitable work-around, yes? I meant doing that just as a debug trial to know if maybe MythTV was doing something wrong. Andy already answered explaining this shouldn't be the case. In fact now that Andy is helping you, you'll get far better help from him than from me. PS: Please don't drop linux-media list from Cc [...] Perhaps you got the copy I CC'd to you directly before you got the copy that went to the list via gmane. Well, this very mail I'm answering appears as being sent to me alone. However, the mail can be found on mail-archive so it must be something in the way I got it. Never mind. Thanks, Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses
Em Thu, 29 Nov 2012 17:39:45 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Hi Tony, On Thursday 29 November 2012 08:29:27 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [121129 01:37]: On Thursday 29 November 2012 11:30:28 Tomi Valkeinen wrote: On 2012-11-28 17:13, Laurent Pinchart wrote: On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote: Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based on current omapdss master branch, which has the omapdss version code. The omapdss version code is queued for v3.8. I'm not sure which is the best way to handle these patches due to the dependency to omapdss. The easiest option is to merge these for 3.9. There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP dependency in the omap_vout driver. I'm not going to touch that, as it doesn't look as trivial as this cpu_is_* removal, and I don't have much knowledge of the omap_vout driver. Compiled, but not tested. Tested on a Beagleboard-xM. Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks. The patches depend on unmerged OMAP DSS patches. Would you like to push this series through linuxtv or through your DSS tree ? The later might be easier, depending on when the required DSS patches will hit mainline. The DSS patches will be merged for 3.8. I can take this via the omapdss tree, as there probably won't be any conflicts with other v4l2 stuff. Or, we can just delay these until 3.9. These patches remove omap platform dependencies, helping the effort to get common ARM kernel. However, as there's still the VRFB code in the omap_vout driver, the dependency remains. Thus, in way, these patches alone don't help anything, and we could delay these for 3.9 and hope that omap_vout_vrfb.c gets converted also for that merge window. OK, I'll queue them for v3.9 then. Please rather queue the cpu_is_omap removal to v3.8 so I can remove plat/cpu.h for omap2+. In that case the patches should go through the DSS tree. Mauro, are you fine with that ? Sure. For both patches: Acked-by: Mauro Carvalho Chehab mche...@redhat.com 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 0/2] omap_vout: remove cpu_is_* uses
On 2012-11-29 19:05, Mauro Carvalho Chehab wrote: Em Thu, 29 Nov 2012 17:39:45 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Please rather queue the cpu_is_omap removal to v3.8 so I can remove plat/cpu.h for omap2+. In that case the patches should go through the DSS tree. Mauro, are you fine with that ? Sure. For both patches: Acked-by: Mauro Carvalho Chehab mche...@redhat.com Okay, thanks, I'll apply them to omapdss tree. Tomi signature.asc Description: OpenPGP digital signature
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Thu Nov 29 19:00:10 CET 2012 git hash:d8658bca2e5696df2b6c69bc5538f8fe54e4a01e 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: ERRORS 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: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS linux-3.5-i686: ERRORS linux-3.6-i686: ERRORS linux-3.7-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: ERRORS linux-3.6-x86_64: ERRORS linux-3.7-rc1-x86_64: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The 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: em28xx: msi Digivox ATSC board id [0db0:8810]
Am 29.11.2012 03:15, schrieb Antti Palosaari: On 11/29/2012 04:05 AM, Matthew Gyurgyik wrote: On 11/28/2012 05:55 PM, Antti Palosaari wrote: Very, very, good pics and sniffs!! From the sniff you could see I2C addresses 50 (a0 1) eeprom 0e (1c 1) demod 60 (c0 1) tuner EM2874, USB-bridge, clocked at 12MHz, crystal on other side of PCB. There is also 32k serial eeprom for EM2874. This large serial eeprom means (very likely) it uses custom firmware which is downloaded from the eeprom. LGDT3305, demodulator, clocked at 25MHz. Serial TS used between EM2874 and LGDT3305. TDA18271HDC2 is tuner, clocked at 16MHz. Traditional IF used between tuner and demod. IR receiver is near antenna, which is a little bit long wires to connect to the EM2874, looks weird but no harm. Main GPIO sequence is that one: 000255: 06 ms 000990 ms c0 00 00 00 80 00 01 00 ff 000256: 04 ms 000994 ms 40 00 00 00 80 00 01 00 fe 000257: 06 ms 001000 ms c0 00 00 00 80 00 01 00 fe 000258: 04 ms 001004 ms 40 00 00 00 80 00 01 00 be 000259: 000139 ms 001143 ms c0 00 00 00 80 00 01 00 be 000260: 05 ms 001148 ms 40 00 00 00 80 00 01 00 fe There is some more GPIOs later, just test with trial and error to find out all GPIOs. Making that device working should be quite easy! There is a little change for proprietary firmware for EM2874 which does some nasty things, but that is very very unlikely. Do we know any devices with a real proprietary firmware ?? I'm not talking about custom USB ID, endpoint configuration and minor stuff like this... regards Antti Thanks for the information. That is way over my head. Is there same basic reading someone could recommend so I can start to understand the basics of all this? In the mean time, I'm willing to do any testing necessary. Maybe I could give hour or two for that if you could make tests I ask? If someone else would like to hack with it, I am very happy too. Frank? Seems like we have all we need, right ? A TDA18271 driver seems to be in place, what about the LGDT3305 demodulator ? I can try to put the puzzle together, but not before weekend. Matthew, stay tuned but be patient. ;) Regards, Frank regards Antti -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] stv0900: Multistream support
Multistream support for stv0900. For Netup Dual S2 CI with STV0900BAC/AAC.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/dvb-frontends/stv0900_core.c
b/drivers/media/dvb-frontends/stv0900_core.c
index b551ca3..0fb34e1 100644
--- a/drivers/media/dvb-frontends/stv0900_core.c
+++ b/drivers/media/dvb-frontends/stv0900_core.c
@@ -1558,6 +1558,27 @@ static int stv0900_status(struct stv0900_internal *intp,
return locked;
}
+static int stv0900_set_mis(struct stv0900_internal *intp,
+ enum fe_stv0900_demod_num demod, int mis)
+{
+ enum fe_stv0900_error error = STV0900_NO_ERROR;
+
+ dprintk(%s\n, __func__);
+
+ if (mis 0 || mis 255) {
+ dprintk(Disable MIS filtering\n);
+ stv0900_write_bits(intp, FILTER_EN, 0);
+ } else {
+ dprintk(Enable MIS filtering - %d\n, mis);
+ stv0900_write_bits(intp, FILTER_EN, 1);
+ stv0900_write_reg(intp, ISIENTRY, mis);
+ stv0900_write_reg(intp, ISIBITENA, 0xff);
+ }
+
+ return error;
+}
+
+
static enum dvbfe_search stv0900_search(struct dvb_frontend *fe)
{
struct stv0900_state *state = fe-demodulator_priv;
@@ -1578,6 +1599,8 @@ static enum dvbfe_search stv0900_search(struct
dvb_frontend *fe)
if (state-config-set_ts_params)
state-config-set_ts_params(fe, 0);
+ stv0900_set_mis(intp, demod, c-stream_id);
+
p_result.locked = FALSE;
p_search.path = demod;
p_search.frequency = c-frequency;
@@ -1935,6 +1958,9 @@ struct dvb_frontend *stv0900_attach(const struct
stv0900_config *config,
if (err_stv0900)
goto error;
+ if (state-internal-chip_id = 0x30)
+ state-frontend.ops.info.caps |= FE_CAN_MULTISTREAM;
+
break;
default:
goto error;
diff --git a/drivers/media/dvb-frontends/stv0900_reg.h
b/drivers/media/dvb-frontends/stv0900_reg.h
index 731afe9..511ed2a 100644
--- a/drivers/media/dvb-frontends/stv0900_reg.h
+++ b/drivers/media/dvb-frontends/stv0900_reg.h
@@ -3446,8 +3446,11 @@ extern s32 shiftx(s32 x, int demod, s32 shift);
#define R0900_P1_PDELCTRL1 0xf550
#define PDELCTRL1 REGx(R0900_P1_PDELCTRL1)
#define F0900_P1_INV_MISMASK 0xf5500080
+#define INV_MISMASK FLDx(F0900_P1_INV_MISMASK)
#define F0900_P1_FILTER_EN 0xf5500020
+#define FILTER_EN FLDx(F0900_P1_FILTER_EN)
#define F0900_P1_EN_MIS00 0xf552
+#define EN_MIS00 FLDx(F0900_P1_EN_MIS00)
#define F0900_P1_ALGOSWRST 0xf551
#define ALGOSWRST FLDx(F0900_P1_ALGOSWRST)
--
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] stv0900: Multistream support
Hi Evgeny,
On Thu, Nov 29, 2012 at 4:27 PM, CrazyCat crazyca...@yandex.ru wrote:
Multistream support for stv0900. For Netup Dual S2 CI with STV0900BAC/AAC.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/dvb-frontends/stv0900_core.c
b/drivers/media/dvb-frontends/stv0900_core.c
index b551ca3..0fb34e1 100644
--- a/drivers/media/dvb-frontends/stv0900_core.c
+++ b/drivers/media/dvb-frontends/stv0900_core.c
@@ -1558,6 +1558,27 @@ static int stv0900_status(struct stv0900_internal
*intp,
return locked;
}
+static int stv0900_set_mis(struct stv0900_internal *intp,
+ enum fe_stv0900_demod_num demod, int mis)
+{
+ enum fe_stv0900_error error = STV0900_NO_ERROR;
+
+ dprintk(%s\n, __func__);
+
Mmm, that's a pretty useless printk, IMHO.
If someone wants to trace a driver it's better to use ftrace, again IMHO.
+ if (mis 0 || mis 255) {
+ dprintk(Disable MIS filtering\n);
+ stv0900_write_bits(intp, FILTER_EN, 0);
+ } else {
+ dprintk(Enable MIS filtering - %d\n, mis);
+ stv0900_write_bits(intp, FILTER_EN, 1);
+ stv0900_write_reg(intp, ISIENTRY, mis);
+ stv0900_write_reg(intp, ISIBITENA, 0xff);
+ }
+
+ return error;
What's the point in returning an error if you don't use set it and
don't use it below?
I believe you can have this function return void.
+}
+
+
static enum dvbfe_search stv0900_search(struct dvb_frontend *fe)
{
struct stv0900_state *state = fe-demodulator_priv;
@@ -1578,6 +1599,8 @@ static enum dvbfe_search stv0900_search(struct
dvb_frontend *fe)
if (state-config-set_ts_params)
state-config-set_ts_params(fe, 0);
+ stv0900_set_mis(intp, demod, c-stream_id);
+
p_result.locked = FALSE;
p_search.path = demod;
p_search.frequency = c-frequency;
@@ -1935,6 +1958,9 @@ struct dvb_frontend *stv0900_attach(const struct
stv0900_config *config,
if (err_stv0900)
goto error;
+ if (state-internal-chip_id = 0x30)
+ state-frontend.ops.info.caps |= FE_CAN_MULTISTREAM;
+
break;
default:
goto error;
diff --git a/drivers/media/dvb-frontends/stv0900_reg.h
b/drivers/media/dvb-frontends/stv0900_reg.h
index 731afe9..511ed2a 100644
--- a/drivers/media/dvb-frontends/stv0900_reg.h
+++ b/drivers/media/dvb-frontends/stv0900_reg.h
@@ -3446,8 +3446,11 @@ extern s32 shiftx(s32 x, int demod, s32 shift);
#define R0900_P1_PDELCTRL1 0xf550
#define PDELCTRL1 REGx(R0900_P1_PDELCTRL1)
#define F0900_P1_INV_MISMASK 0xf5500080
+#define INV_MISMASK FLDx(F0900_P1_INV_MISMASK)
#define F0900_P1_FILTER_EN 0xf5500020
+#define FILTER_EN FLDx(F0900_P1_FILTER_EN)
#define F0900_P1_EN_MIS00 0xf552
+#define EN_MIS00 FLDx(F0900_P1_EN_MIS00)
#define F0900_P1_ALGOSWRST 0xf551
#define ALGOSWRST FLDx(F0900_P1_ALGOSWRST)
--
Thanks,
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: msi Digivox ATSC board id [0db0:8810]
On 11/29/2012 09:28 PM, Frank Schäfer wrote: Am 29.11.2012 03:15, schrieb Antti Palosaari: On 11/29/2012 04:05 AM, Matthew Gyurgyik wrote: On 11/28/2012 05:55 PM, Antti Palosaari wrote: Very, very, good pics and sniffs!! From the sniff you could see I2C addresses 50 (a0 1) eeprom 0e (1c 1) demod 60 (c0 1) tuner EM2874, USB-bridge, clocked at 12MHz, crystal on other side of PCB. There is also 32k serial eeprom for EM2874. This large serial eeprom means (very likely) it uses custom firmware which is downloaded from the eeprom. LGDT3305, demodulator, clocked at 25MHz. Serial TS used between EM2874 and LGDT3305. TDA18271HDC2 is tuner, clocked at 16MHz. Traditional IF used between tuner and demod. IR receiver is near antenna, which is a little bit long wires to connect to the EM2874, looks weird but no harm. Main GPIO sequence is that one: 000255: 06 ms 000990 ms c0 00 00 00 80 00 01 00 ff 000256: 04 ms 000994 ms 40 00 00 00 80 00 01 00 fe 000257: 06 ms 001000 ms c0 00 00 00 80 00 01 00 fe 000258: 04 ms 001004 ms 40 00 00 00 80 00 01 00 be 000259: 000139 ms 001143 ms c0 00 00 00 80 00 01 00 be 000260: 05 ms 001148 ms 40 00 00 00 80 00 01 00 fe There is some more GPIOs later, just test with trial and error to find out all GPIOs. Making that device working should be quite easy! There is a little change for proprietary firmware for EM2874 which does some nasty things, but that is very very unlikely. Do we know any devices with a real proprietary firmware ?? I'm not talking about custom USB ID, endpoint configuration and minor stuff like this... I am not aware any such em28xx device. Default firmware seems to be just enough for most cases. Normally there is 2k eeprom which is used to store some basic configuration information, USB IDs and some other properties. I don't know how much expensive 32k eeprom is than 2k eeprom, but one possibility is also it is just used because they have had a lot of spare 32k eeproms to waste... regards Antti Thanks for the information. That is way over my head. Is there same basic reading someone could recommend so I can start to understand the basics of all this? In the mean time, I'm willing to do any testing necessary. Maybe I could give hour or two for that if you could make tests I ask? If someone else would like to hack with it, I am very happy too. Frank? Seems like we have all we need, right ? A TDA18271 driver seems to be in place, what about the LGDT3305 demodulator ? I can try to put the puzzle together, but not before weekend. Matthew, stay tuned but be patient. ;) Good! Yes, there is existing drivers for all the used chips. Just make correct device profile (and hope there is no any nasty custom fw things). 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: ivtv driver inputs randomly block
On 12-11-29 10:50 AM, Andy Walls wrote: until the problem appears. I'm afraid I didn't notice the problem until about 40m into the recording bug given that MythTV is in a loop repeatedly opening the card and trying to use it perhaps the high volume even 40 minutes into the recording is useful. Then once you experience the problem change it to high volume # echo 0x47f /sys/module/ivtv/parameters/debug It seems to be a loop of: Nov 29 14:39:47 cmurrell kernel: [953479.593771] ivtv0: file: Encoder poll Nov 29 14:39:47 cmurrell kernel: [953479.594127] ivtv0: ioctl: V4L2_ENC_CMD_STOP Nov 29 14:39:47 cmurrell kernel: [953479.594131] ivtv0: file: close() of encoder MPG Nov 29 14:39:47 cmurrell kernel: [953479.594134] ivtv0: info: close stopping capture Nov 29 14:39:47 cmurrell kernel: [953479.594137] ivtv0: info: Stop Capture Nov 29 14:39:47 cmurrell kernel: [953479.594142] ivtv0: mb: MB Call: CX2341X_ENC_STOP_CAPTURE Nov 29 14:39:49 cmurrell kernel: [953481.592013] ivtv0: warn: encoder MPG: EOS interrupt not received! stopping anyway. Nov 29 14:39:49 cmurrell kernel: [953481.592021] ivtv0: warn: encoder MPG: waited 2000 ms. Nov 29 14:39:49 cmurrell kernel: [953481.692036] ivtv0: mb: MB Call: CX2341X_ENC_STOP_CAPTURE Nov 29 14:39:49 cmurrell kernel: [953481.692138] ivtv0 encoder MPG: VIDIOC_ENCODER_CMD cmd=1, flags=1 Nov 29 14:39:49 cmurrell kernel: [953481.692161] ivtv0: file: close encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692165] ivtv0: file: close() of encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692208] ivtv0: file: open encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692211] ivtv0: mb: MB Call: CX2341X_ENC_PING_FW Nov 29 14:39:49 cmurrell kernel: [953481.692272] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692348] ivtv0: ioctl: V4L2_ENC_CMD_START Nov 29 14:39:49 cmurrell kernel: [953481.692352] ivtv0: info: Start encoder stream encoder MPG Nov 29 14:39:49 cmurrell kernel: [953481.692356] ivtv0: mb: MB Call: CX2341X_ENC_SET_DMA_BLOCK_SIZE Nov 29 14:39:49 cmurrell kernel: [953481.692359] ivtv0: mb: MB Call: CX2341X_ENC_SET_VERT_CROP_LINE Nov 29 14:39:49 cmurrell kernel: [953481.692422] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692485] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692553] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692617] ivtv0: mb: MB Call: CX2341X_ENC_MISC Nov 29 14:39:49 cmurrell kernel: [953481.692684] ivtv0: mb: MB Call: CX2341X_ENC_SET_PLACEHOLDER Nov 29 14:39:49 cmurrell kernel: [953481.692688] ivtv0: mb: MB Call: CX2341X_ENC_SET_NUM_VSYNC_LINES Nov 29 14:39:49 cmurrell kernel: [953481.692691] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.718739] ivtv0: info: Setup VBI API header 0xbd03 pkts 1 buffs 4 ln 24 sz 1456 Nov 29 14:39:49 cmurrell kernel: [953481.718746] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_CONFIG Nov 29 14:39:49 cmurrell kernel: [953481.718830] ivtv0: info: Setup VBI start 0x002fea04 frames 4 fpi 1 Nov 29 14:39:49 cmurrell kernel: [953481.718834] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.718906] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.718978] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719052] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719126] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719196] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719269] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719352] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719445] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719522] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719592] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719662] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719732] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719807] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719893] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.719967] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.720060] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.720144] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49 cmurrell kernel: [953481.720213] ivtv0: mb: MB Call: CX2341X_ENC_SET_VBI_LINE Nov 29 14:39:49
[PATCH 6/6] ie6xx_wdt: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
CHECK drivers/watchdog/ie6xx_wdt.c
CC [M] drivers/watchdog/ie6xx_wdt.o
Building modules, stage 2.
MODPOST 43 modules
LD [M] drivers/watchdog/ie6xx_wdt.ko
Cc: Alexander Stein alexander.st...@systec-electronic.com
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/watchdog/ie6xx_wdt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/ie6xx_wdt.c b/drivers/watchdog/ie6xx_wdt.c
index e24ef6a..f2d6573 100644
--- a/drivers/watchdog/ie6xx_wdt.c
+++ b/drivers/watchdog/ie6xx_wdt.c
@@ -82,7 +82,7 @@ MODULE_PARM_DESC(resetmode,
static struct {
unsigned short sch_wdtba;
- struct spinlock unlock_sequence;
+ spinlock_t unlock_sequence;
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
#endif
--
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/6] brcmfmac: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com spinlock_t should always be used. LD drivers/net/wireless/brcm80211/built-in.o CHECK drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o CHECK drivers/net/wireless/brcm80211/brcmfmac/fwil.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/fwil.o CHECK drivers/net/wireless/brcm80211/brcmfmac/fweh.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/fweh.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_cdc.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_common.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.o CHECK drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.o CHECK drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.o CHECK drivers/net/wireless/brcm80211/brcmfmac/usb.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/usb.o CHECK drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.c CC [M] drivers/net/wireless/brcm80211/brcmfmac/dhd_dbg.o LD [M] drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.o LD drivers/net/wireless/brcm80211/brcmsmac/built-in.o CHECK drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1311:6: warning: context imbalance in 'brcms_down' - unexpected unlock drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c:1598:6: warning: context imbalance in 'brcms_rfkill_set_hw_state' - unexpected unlock CC [M] drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.o CHECK drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/ucode_loader.o CHECK drivers/net/wireless/brcm80211/brcmsmac/ampdu.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/ampdu.o CHECK drivers/net/wireless/brcm80211/brcmsmac/antsel.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/antsel.o CHECK drivers/net/wireless/brcm80211/brcmsmac/channel.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/channel.o CHECK drivers/net/wireless/brcm80211/brcmsmac/main.c drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:36: warning: Initializer entry defined twice drivers/net/wireless/brcm80211/brcmsmac/main.c:6246:43: also defined here CC [M] drivers/net/wireless/brcm80211/brcmsmac/main.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy_shim.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy_shim.o CHECK drivers/net/wireless/brcm80211/brcmsmac/pmu.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/pmu.o CHECK drivers/net/wireless/brcm80211/brcmsmac/rate.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/rate.o CHECK drivers/net/wireless/brcm80211/brcmsmac/stf.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/stf.o CHECK drivers/net/wireless/brcm80211/brcmsmac/aiutils.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/aiutils.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c:3313:46: warning: cast truncates bits from constant value (7fff becomes 7fff) CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:17688:47: warning: cast truncates bits from constant value (7fff becomes 7fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:18187:53: warning: cast truncates bits from constant value (3fff becomes 3fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:21160:36: warning: cast truncates bits from constant value (3fff becomes 3fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:23321:35: warning: cast truncates bits from constant value (7fff becomes 7fff) drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.c:28343:44: warning: cast truncates bits from constant value (1fff becomes 1fff) CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phy_n.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.c CC [M] drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_n.o CHECK drivers/net/wireless/brcm80211/brcmsmac/phy/phy_qmath.c CC [M]
[PATCH 2/6] i915: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com spinlock_t should always be used. LD drivers/gpu/drm/i915/built-in.o CHECK drivers/gpu/drm/i915/i915_drv.c CC [M] drivers/gpu/drm/i915/i915_drv.o CHECK drivers/gpu/drm/i915/i915_dma.c CC [M] drivers/gpu/drm/i915/i915_dma.o CHECK drivers/gpu/drm/i915/i915_irq.c CC [M] drivers/gpu/drm/i915/i915_irq.o CHECK drivers/gpu/drm/i915/i915_debugfs.c drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression CC [M] drivers/gpu/drm/i915/i915_debugfs.o CHECK drivers/gpu/drm/i915/i915_suspend.c CC [M] drivers/gpu/drm/i915/i915_suspend.o CHECK drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/i915_gem.c:3703:14:expected unsigned int [unsigned] [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3703:14:got restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: = drivers/gpu/drm/i915/i915_gem.c:3706:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3706:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |= drivers/gpu/drm/i915/i915_gem.c:3707:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3707:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types) drivers/gpu/drm/i915/i915_gem.c:3711:39:expected restricted gfp_t [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3711:39:got unsigned int [unsigned] [usertype] mask CC [M] drivers/gpu/drm/i915/i915_gem.o CHECK drivers/gpu/drm/i915/i915_gem_context.c CC [M] drivers/gpu/drm/i915/i915_gem_context.o CHECK drivers/gpu/drm/i915/i915_gem_debug.c CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CHECK drivers/gpu/drm/i915/i915_gem_evict.c CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CHECK drivers/gpu/drm/i915/i915_gem_execbuffer.c CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CHECK drivers/gpu/drm/i915/i915_gem_gtt.c CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CHECK drivers/gpu/drm/i915/i915_gem_stolen.c CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CHECK drivers/gpu/drm/i915/i915_gem_tiling.c CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CHECK drivers/gpu/drm/i915/i915_sysfs.c CC [M] drivers/gpu/drm/i915/i915_sysfs.o CHECK drivers/gpu/drm/i915/i915_trace_points.c CC [M] drivers/gpu/drm/i915/i915_trace_points.o CHECK drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder versus drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe versus drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_display.o CHECK drivers/gpu/drm/i915/intel_crt.c CC [M] drivers/gpu/drm/i915/intel_crt.o CHECK drivers/gpu/drm/i915/intel_lvds.c CC [M] drivers/gpu/drm/i915/intel_lvds.o CHECK drivers/gpu/drm/i915/intel_bios.c drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces) drivers/gpu/drm/i915/intel_bios.c:706:60:expected struct vbt_header *vbt drivers/gpu/drm/i915/intel_bios.c:706:60:got void [noderef] asn:2*vbt drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_bios.c:726:42:expected void const *noident drivers/gpu/drm/i915/intel_bios.c:726:42:got unsigned char [noderef] [usertype] asn:2* drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression CC [M] drivers/gpu/drm/i915/intel_bios.o CHECK drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static? drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe versus drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_ddi.o drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’: drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this
[PATCH 3/6] s5p-fimc: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-fimc/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; modules will have no dependencies and modversions.
LD drivers/media/platform/s5p-fimc/built-in.o
Building modules, stage 2.
MODPOST 0 modules
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media@vger.kernel.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/media/platform/s5p-fimc/mipi-csis.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 4c961b1..86c8775 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -187,7 +187,7 @@ struct csis_state {
const struct csis_pix_format *csis_fmt;
struct v4l2_mbus_framefmt format;
- struct spinlock slock;
+ spinlock_t slock;
struct csis_pktbuf pkt_buf;
struct s5pcsis_event events[S5PCSIS_NUM_EVENTS];
};
--
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/6] s5p-jpeg: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-jpeg
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; modules will have no dependencies and modversions.
Building modules, stage 2.
MODPOST 0 modules
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media@vger.kernel.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/media/platform/s5p-jpeg/jpeg-core.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.h
b/drivers/media/platform/s5p-jpeg/jpeg-core.h
index 022b9b9..8a4013e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.h
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.h
@@ -62,7 +62,7 @@
*/
struct s5p_jpeg {
struct mutexlock;
- struct spinlock slock;
+ spinlock_t slock;
struct v4l2_device v4l2_dev;
struct video_device *vfd_encoder;
--
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 0/6] drivers: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com Turns out a few drivers have strayed away from using the spinlock_t typedef and decided to use struct spinlock directly. This series converts these drivers to use spinlock_t. Each change has been compile tested with allmodconfig and sparse checked. Driver developers may want to look at the compile error output / sparse error report supplied in each commit log, in particular brcmfmac and i915, there are quite a few things that are not related to this change that the developers can clean up / fix. Luis R. Rodriguez (6): ux500: convert struct spinlock to spinlock_t i915: convert struct spinlock to spinlock_t s5p-fimc: convert struct spinlock to spinlock_t s5p-jpeg: convert struct spinlock to spinlock_t brcmfmac: convert struct spinlock to spinlock_t ie6xx_wdt: convert struct spinlock to spinlock_t drivers/crypto/ux500/cryp/cryp.h |4 ++-- drivers/crypto/ux500/hash/hash_alg.h |4 ++-- drivers/gpu/drm/i915/i915_drv.h|4 ++-- drivers/media/platform/s5p-fimc/mipi-csis.c|2 +- drivers/media/platform/s5p-jpeg/jpeg-core.h|2 +- drivers/net/wireless/brcm80211/brcmfmac/fweh.h |2 +- drivers/watchdog/ie6xx_wdt.c |2 +- 7 files changed, 10 insertions(+), 10 deletions(-) -- 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/6] ux500: convert struct spinlock to spinlock_t
From: Luis R. Rodriguez mcg...@do-not-panic.com
spinlock_t should always be used.
I was unable to build test with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 M=drivers/crypto/ux500/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; modules will have no dependencies and modversions.
LD drivers/crypto/ux500/built-in.o
Building modules, stage 2.
MODPOST 0 modules
Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Reported-by: Hauke Mehrtens ha...@hauke-m.de
Signed-off-by: Luis R. Rodriguez mcg...@do-not-panic.com
---
drivers/crypto/ux500/cryp/cryp.h |4 ++--
drivers/crypto/ux500/hash/hash_alg.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp.h b/drivers/crypto/ux500/cryp/cryp.h
index 14cfd05..ba324b2 100644
--- a/drivers/crypto/ux500/cryp/cryp.h
+++ b/drivers/crypto/ux500/cryp/cryp.h
@@ -236,12 +236,12 @@ struct cryp_device_data {
struct clk *clk;
struct regulator *pwr_regulator;
int power_status;
- struct spinlock ctx_lock;
+ spinlock_t ctx_lock;
struct cryp_ctx *current_ctx;
struct klist_node list_node;
struct cryp_dma dma;
bool power_state;
- struct spinlock power_state_spinlock;
+ spinlock_t power_state_spinlock;
bool restore_dev_ctx;
};
diff --git a/drivers/crypto/ux500/hash/hash_alg.h
b/drivers/crypto/ux500/hash/hash_alg.h
index cd9351c..0183f5e 100644
--- a/drivers/crypto/ux500/hash/hash_alg.h
+++ b/drivers/crypto/ux500/hash/hash_alg.h
@@ -363,10 +363,10 @@ struct hash_device_data {
struct hash_register __iomem*base;
struct klist_node list_node;
struct device *dev;
- struct spinlock ctx_lock;
+ spinlock_t ctx_lock;
struct hash_ctx *current_ctx;
boolpower_state;
- struct spinlock power_state_lock;
+ spinlock_t power_state_lock;
struct regulator*regulator;
struct clk *clk;
boolrestore_dev_state;
--
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 2/6] i915: convert struct spinlock to spinlock_t
On Thu, Nov 29, 2012 at 12:45:06PM -0800, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@do-not-panic.com spinlock_t should always be used. LD drivers/gpu/drm/i915/built-in.o CHECK drivers/gpu/drm/i915/i915_drv.c CC [M] drivers/gpu/drm/i915/i915_drv.o CHECK drivers/gpu/drm/i915/i915_dma.c CC [M] drivers/gpu/drm/i915/i915_dma.o CHECK drivers/gpu/drm/i915/i915_irq.c CC [M] drivers/gpu/drm/i915/i915_irq.o CHECK drivers/gpu/drm/i915/i915_debugfs.c drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression CC [M] drivers/gpu/drm/i915/i915_debugfs.o CHECK drivers/gpu/drm/i915/i915_suspend.c CC [M] drivers/gpu/drm/i915/i915_suspend.o CHECK drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/i915_gem.c:3703:14:expected unsigned int [unsigned] [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3703:14:got restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: = drivers/gpu/drm/i915/i915_gem.c:3706:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3706:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |= drivers/gpu/drm/i915/i915_gem.c:3707:22:left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3707:22:right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types) drivers/gpu/drm/i915/i915_gem.c:3711:39:expected restricted gfp_t [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3711:39:got unsigned int [unsigned] [usertype] mask CC [M] drivers/gpu/drm/i915/i915_gem.o CHECK drivers/gpu/drm/i915/i915_gem_context.c CC [M] drivers/gpu/drm/i915/i915_gem_context.o CHECK drivers/gpu/drm/i915/i915_gem_debug.c CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CHECK drivers/gpu/drm/i915/i915_gem_evict.c CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CHECK drivers/gpu/drm/i915/i915_gem_execbuffer.c CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CHECK drivers/gpu/drm/i915/i915_gem_gtt.c CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CHECK drivers/gpu/drm/i915/i915_gem_stolen.c CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CHECK drivers/gpu/drm/i915/i915_gem_tiling.c CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CHECK drivers/gpu/drm/i915/i915_sysfs.c CC [M] drivers/gpu/drm/i915/i915_sysfs.o CHECK drivers/gpu/drm/i915/i915_trace_points.c CC [M] drivers/gpu/drm/i915/i915_trace_points.o CHECK drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder versus drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe versus drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_display.o CHECK drivers/gpu/drm/i915/intel_crt.c CC [M] drivers/gpu/drm/i915/intel_crt.o CHECK drivers/gpu/drm/i915/intel_lvds.c CC [M] drivers/gpu/drm/i915/intel_lvds.o CHECK drivers/gpu/drm/i915/intel_bios.c drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces) drivers/gpu/drm/i915/intel_bios.c:706:60:expected struct vbt_header *vbt drivers/gpu/drm/i915/intel_bios.c:706:60:got void [noderef] asn:2*vbt drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_bios.c:726:42:expected void const *noident drivers/gpu/drm/i915/intel_bios.c:726:42:got unsigned char [noderef] [usertype] asn:2* drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression CC [M] drivers/gpu/drm/i915/intel_bios.o CHECK drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static? drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe versus drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_ddi.o
Re: [PATCH] [media] v4l: Add mt9v034 sensor driver
Hi Enric,
In general this driver looks good to me. However it seems you're
using it together with the omap3isp driver. Likely Laurent and Sakari
may have some comments on that.
Just one thing I'm unsure about, please see below.
On 10/05/2012 12:34 PM, Enric Balletbo i Serra wrote:
From: Enric Balletbo i Serraeballe...@iseebcn.com
The MT9V034 is a parallel wide VGA sensor from Aptina (formerly Micron)
controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports binning and
cropping, and the gain, auto gain, exposure, auto exposure and test
pattern controls.
The following patch is based on the MT9V032 driver from Laurent Pinchart
and was tested on IGEP tech based boards with custom expansion board with
MT9V034 sensor.
Signed-off-by: Enric Balletbo i Serraeballe...@iseebcn.com
---
drivers/media/i2c/Kconfig | 10 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/mt9v034.c | 834 +++
include/media/mt9v034.h | 15 +
4 files changed, 860 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/i2c/mt9v034.c
create mode 100644 include/media/mt9v034.h
...
+static int mt9v034_enum_frame_size(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ if (fse-index= 8 || fse-code != V4L2_MBUS_FMT_SBGGR10_1X10)
+ return -EINVAL;
+
+ fse-min_width = MT9V034_WINDOW_WIDTH_DEF / fse-index;
+ fse-max_width = fse-min_width;
+ fse-min_height = MT9V034_WINDOW_HEIGHT_DEF / fse-index;
+ fse-max_height = fse-min_height;
+
+ return 0;
+}
Have you actually tested VIDIOC_SUBDEV_ENUM_FRAME_SIZE ioctl with the index
field set to 0 ? Shouldn't (fse-index + 1) be used as a denominator
instead ?
--
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] [media] rtl28xxu: add Terratec Cinergy T Stick RC rev 3
This just adds the usbid to the rtl28xxu driver, that's all that's
needed to make the stick work for DVB.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -162,6 +162,7 @@
#define USB_PID_TERRATEC_CINERGY_T_USB_XE_REV2 0x0069
#define USB_PID_TERRATEC_CINERGY_T_STICK 0x0093
#define USB_PID_TERRATEC_CINERGY_T_STICK_RC0x0097
+#define USB_PID_TERRATEC_CINERGY_T_STICK_RC_REV3 0x00d3
#define USB_PID_TERRATEC_CINERGY_T_STICK_DUAL_RC 0x0099
#define USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV10x00a9
#define USB_PID_TWINHAN_VP7041_COLD0x3201
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1340,6 +1340,8 @@ static const struct usb_device_id rtl28x
rtl2832u_props, NOXON DAB/DAB+ USB dongle, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV2,
rtl2832u_props, NOXON DAB/DAB+ USB dongle (rev 2), NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_RC_REV3,
+ rtl2832u_props, Terratec Cinergy T Stick RC (rev 3), NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
--
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] rtl28xxu: add Terratec Cinergy T Stick RC rev 3
On 11/29/2012 10:52 PM, Juergen Lock wrote:
This just adds the usbid to the rtl28xxu driver, that's all that's
needed to make the stick work for DVB.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -162,6 +162,7 @@
#define USB_PID_TERRATEC_CINERGY_T_USB_XE_REV20x0069
#define USB_PID_TERRATEC_CINERGY_T_STICK 0x0093
#define USB_PID_TERRATEC_CINERGY_T_STICK_RC 0x0097
+#define USB_PID_TERRATEC_CINERGY_T_STICK_RC_REV3 0x00d3
#define USB_PID_TERRATEC_CINERGY_T_STICK_DUAL_RC 0x0099
#define USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV1 0x00a9
#define USB_PID_TWINHAN_VP7041_COLD 0x3201
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1340,6 +1340,8 @@ static const struct usb_device_id rtl28x
rtl2832u_props, NOXON DAB/DAB+ USB dongle, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV2,
rtl2832u_props, NOXON DAB/DAB+ USB dongle (rev 2), NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_RC_REV3,
+ rtl2832u_props, Terratec Cinergy T Stick RC (rev 3), NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
--
That patch is already applied!
Due to that, nack. It is non-relevant.
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] gspca - ov534: Fix the light frequency filter
On Thu, 29 Nov 2012 10:25:19 +0100 Hans de Goede hdego...@redhat.com wrote: Hi Jean-Francois, Antonio Ospite, Could it be that you're both right, and that the register Jean-Francois suggest is used (0x13) and uses in his patch is for enabling / disabling the light-freq filter, where as the register which were used before this patch (0x2a, 0x2b) are used to select the light frequency to filter for? I too thought about something along this line after looking in the OV7670 Implementation Guide: there is a relationship between the banding filter and the maximum exposure, and the latter is somewhat related to dummy lines/pixels. So this would make sense. That would explain everything the 2 50 / 60 hz testers are seeing. This assumes that reg 0x13 has the filter always enabled before the patch, and the code before the patch simply changes the filter freq to such a value it effectively disables the filter for 50 Hz. This also assumes that the default values in 0x2a and 0x2b are valid for 60hz, which explains why Jean Francois' patch works for 60 Hz, so with all this combined we should have all pieces of the puzzle ... Anyone wants to do a patch to prove I'm right (or wrong :) ? I contacted Fabian Alexander Calderon off-list using the email address in the tested-by line in the patch sent by Jean-Francois, I am waiting for a reply from him. I can cook something which uses register 0x13 and still makes the filter apply on 50Hz, but I'll test for an actual test before submitting it. Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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] rtl28xxu: add Terratec Cinergy T Stick RC rev 3
On Thu, Nov 29, 2012 at 11:21:38PM +0200, Antti Palosaari wrote:
On 11/29/2012 10:52 PM, Juergen Lock wrote:
This just adds the usbid to the rtl28xxu driver, that's all that's
needed to make the stick work for DVB.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -162,6 +162,7 @@
#define USB_PID_TERRATEC_CINERGY_T_USB_XE_REV20x0069
#define USB_PID_TERRATEC_CINERGY_T_STICK 0x0093
#define USB_PID_TERRATEC_CINERGY_T_STICK_RC 0x0097
+#define USB_PID_TERRATEC_CINERGY_T_STICK_RC_REV3 0x00d3
#define USB_PID_TERRATEC_CINERGY_T_STICK_DUAL_RC 0x0099
#define USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV1 0x00a9
#define USB_PID_TWINHAN_VP7041_COLD 0x3201
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1340,6 +1340,8 @@ static const struct usb_device_id rtl28x
rtl2832u_props, NOXON DAB/DAB+ USB dongle, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK_REV2,
rtl2832u_props, NOXON DAB/DAB+ USB dongle (rev 2), NULL) },
+ { DVB_USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_RC_REV3,
+ rtl2832u_props, Terratec Cinergy T Stick RC (rev 3), NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
--
That patch is already applied!
Due to that, nack. It is non-relevant.
Heh, whoops, even better! :)
Thanx,
Juergen
--
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: em28xx: msi Digivox ATSC board id [0db0:8810]
On 11/29/2012 02:28 PM, Frank Schäfer wrote: Matthew, stay tuned but be patient. ;) Regards, Frank Sure thing, just let me know what you need me to do! -- 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] stv0900: Multistream support
Yes, really useless :) Need remove it:) 29.11.2012, 21:41, Ezequiel Garcia elezegar...@gmail.com: Mmm, that's a pretty useless printk, IMHO. If someone wants to trace a driver it's better to use ftrace, again IMHO. -- 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] v4l: Add mt9v034 sensor driver
Hi Enric, Thanks for the patch. Below are few comments. On Fri, Oct 5, 2012 at 4:04 PM, Enric Balletbo i Serra eballe...@gmail.com wrote: From: Enric Balletbo i Serra eballe...@iseebcn.com The MT9V034 is a parallel wide VGA sensor from Aptina (formerly Micron) controlled through I2C. The driver creates a V4L2 subdevice. It currently supports binning and cropping, and the gain, auto gain, exposure, auto exposure and test pattern controls. The following patch is based on the MT9V032 driver from Laurent Pinchart and was tested on IGEP tech based boards with custom expansion board with MT9V034 sensor. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- drivers/media/i2c/Kconfig | 10 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v034.c | 834 +++ include/media/mt9v034.h | 15 + 4 files changed, 860 insertions(+), 0 deletions(-) create mode 100644 drivers/media/i2c/mt9v034.c create mode 100644 include/media/mt9v034.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 0e0793a..c35efda 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -475,6 +475,16 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V034 + tristate Micron MT9V034 sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT + ---help--- + This is a Video4Linux2 sensor-level driver for the Micron + MT9V034 752x480 CMOS sensor. The MT9V034 is a 1/3-inch + wide-VGA format CMOS active-pixel digital image sensor with + TrueSNAP gobal shutter and high dynamic range (HDR) operation. + config VIDEO_TCM825X tristate TCM825x camera sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 4a270f7..9d4c417 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o +obj-$(CONFIG_VIDEO_MT9V034) += mt9v034.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o diff --git a/drivers/media/i2c/mt9v034.c b/drivers/media/i2c/mt9v034.c new file mode 100644 index 000..7bbfeb6 --- /dev/null +++ b/drivers/media/i2c/mt9v034.c @@ -0,0 +1,834 @@ +/* + * Driver for MT9V034 CMOS Image Sensor from Micron + * + * Copyright (C) 2012, Enric Balletbo eballe...@iseebcn.com + * + * Based on the MT9V032 driver, + * + * Copyright (C) 2010, Laurent Pinchart laurent.pinch...@ideasonboard.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. + */ + +#include linux/delay.h +#include linux/i2c.h +#include linux/log2.h +#include linux/mutex.h +#include linux/slab.h +#include linux/videodev2.h +#include linux/v4l2-mediabus.h +#include linux/module.h + Can you sort it alphabetically ? But left to you. +#include media/mt9v034.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#define MT9V034_PIXEL_ARRAY_HEIGHT 499 +#define MT9V034_PIXEL_ARRAY_WIDTH 809 + +#define MT9V034_SYSCLK_FREQ_DEF2660 + +#define MT9V034_CHIP_VERSION 0x00 +#defineMT9V034_CHIP_ID_REV10x1324 +#define MT9V034_COLUMN_START 0x01 +#defineMT9V034_COLUMN_START_MIN1 +#defineMT9V034_COLUMN_START_DEF1 +#defineMT9V034_COLUMN_START_MAX752 +#define MT9V034_ROW_START 0x02 +#defineMT9V034_ROW_START_MIN 4 +#defineMT9V034_ROW_START_DEF 4 +#defineMT9V034_ROW_START_MAX 482 +#define MT9V034_WINDOW_HEIGHT 0x03 +#defineMT9V034_WINDOW_HEIGHT_MIN 1 +#defineMT9V034_WINDOW_HEIGHT_DEF 480 +#defineMT9V034_WINDOW_HEIGHT_MAX 480 +#define MT9V034_WINDOW_WIDTH 0x04 +#defineMT9V034_WINDOW_WIDTH_MIN1 +#defineMT9V034_WINDOW_WIDTH_DEF752 +#defineMT9V034_WINDOW_WIDTH_MAX752 +#define MT9V034_HORIZONTAL_BLANKING0x05 +#define
