Re: Am dying of breast cancer
She sure is gone now; have no pity... Love Jens -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.7] adv7604: sync with the latest Cisco internal code
Hi Mauro, These patches are for 3.7: they fix a number of bugs that were fixed in the internal Cisco tree since I posted the initial adv7604 driver. This pull request contains the same code as the RFC patches: http://www.mail-archive.com/linux-media@vger.kernel.org/msg53949.html Regards, Hans The following changes since commit d92462401dde1effa04a51d0a15000e6246d2a43: [media] v4l2-ioctl: fix W=1 warnings (2012-10-07 10:19:50 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git adv for you to fetch changes up to 59d24d5e73d30301c6f978b7f5608c8beb12ca8c: adv7604: restart STDI once if format is not found (2012-10-16 15:14:27 +0200) Hans Verkuil (4): adv7604: cleanup references adv7604: Replace prim_mode by mode adv7604: use presets where possible. adv7604: restart STDI once if format is not found drivers/media/i2c/adv7604.c | 377 - include/media/adv7604.h | 21 --- 2 files changed, 282 insertions(+), 116 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero
On Thu, Oct 25, 2012 at 19:30:58, Valkeinen, Tomi wrote: On 2012-03-09 10:03, Hiremath, Vaibhav wrote: On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote: Hi Archit, On Wednesday 07 March 2012 14:31:16 Archit Taneja wrote: The omap_vout driver tries to set the DSS overlay_info using set_overlay_info() when the physical address for the overlay is still not configured. This happens in omap_vout_probe() and vidioc_s_fmt_vid_out(). The calls to omapvid_init(which internally calls set_overlay_info()) are removed from these functions. They don't need to be called as the omap_vout_device struct anyway maintains the overlay related changes made. Also, remove the explicit call to set_overlay_info() in vidioc_streamon(), this was used to set the paddr, this isn't needed as omapvid_init() does the same thing later. These changes are required as the DSS2 driver since 3.3 kernel doesn't let you set the overlay info with paddr as 0. Signed-off-by: Archit Taneja arc...@ti.com Thanks for the patch. This seems to fix memory corruption that would result in sysfs-related crashes such as [ 31.279541] [ cut here ] [ 31.284423] WARNING: at fs/sysfs/file.c:343 sysfs_open_file+0x70/0x1f8() [ 31.291503] missing sysfs attribute operations for kobject: (null) [ 31.298004] Modules linked in: mt9p031 aptina_pll omap3_isp [ 31.303924] [c0018260] (unwind_backtrace+0x0/0xec) from [c0034488] (warn_slowpath_common+0x4c/0x64) [ 31.313812] [c0034488] (warn_slowpath_common+0x4c/0x64) from [c0034520] (warn_slowpath_fmt+0x2c/0x3c) [ 31.323913] [c0034520] (warn_slowpath_fmt+0x2c/0x3c) from [c01219bc] (sysfs_open_file+0x70/0x1f8) [ 31.333618] [c01219bc] (sysfs_open_file+0x70/0x1f8) from [c00ccc94] (__dentry_open+0x1f8/0x30c) [ 31.343139] [c00ccc94] (__dentry_open+0x1f8/0x30c) from [c00cce58] (nameidata_to_filp+0x50/0x5c) [ 31.352752] [c00cce58] (nameidata_to_filp+0x50/0x5c) from [c00db4c0] (do_last+0x55c/0x6a0) [ 31.361999] [c00db4c0] (do_last+0x55c/0x6a0) from [c00db6bc] (path_openat+0xb8/0x37c) [ 31.370605] [c00db6bc] (path_openat+0xb8/0x37c) from [c00dba60] (do_filp_open+0x30/0x7c) [ 31.379486] [c00dba60] (do_filp_open+0x30/0x7c) from [c00cc904] (do_sys_open+0xd8/0x170) [ 31.388366] [c00cc904] (do_sys_open+0xd8/0x170) from [c0012760] (ret_fast_syscall+0x0/0x3c) [ 31.397552] ---[ end trace 13639ab74f345d7e ]--- Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks Laurent for testing this patch. Please push it to v3.3 :-) Will send a pull request today itself. Vaibhav, I don't see this crash fix in 3.3, 3.4, 3.5, 3.6 nor in 3.7-rc. Are you still maintaining the omap v4l2 driver? Can you finally push this fix? Tomi, Sorry for delayed response. Laurent, Can you pull up this patch into your next pull request? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674.
Hi Mauro, On 25 October 2012 18:18, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 25 Oct 2012 15:24:49 +0200 javier Martin javier.mar...@vista-silicon.com escreveu: Hi Mauro, do you have any problems with this series? It didn't apply here, maybe due to its dependency from your previous ov7670 (v3) series. You have to apply this series first. Then the other one. From my side, feel free to rebase them and re-submit. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework.
Hi Mauro, On 25 October 2012 17:50, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Javier, Em Thu, 25 Oct 2012 15:27:08 +0200 javier Martin javier.mar...@vista-silicon.com escreveu: Hi Mauro, Jon, any more issues related with this series? Patch doesn't apply anymore: patching file drivers/media/i2c/ov7670.c Hunk #2 succeeded at 191 (offset -32 lines). Hunk #3 succeeded at 220 (offset -35 lines). Hunk #4 succeeded at 1062 (offset -153 lines). Hunk #5 succeeded at 1091 (offset -153 lines). Hunk #6 succeeded at 1127 (offset -153 lines). Hunk #7 succeeded at 1147 (offset -153 lines). Hunk #8 succeeded at 1195 (offset -153 lines). Hunk #9 succeeded at 1211 (offset -153 lines). Hunk #10 succeeded at 1237 (offset -153 lines). Hunk #11 succeeded at 1255 (offset -153 lines). Hunk #12 succeeded at 1351 (offset -153 lines). Hunk #13 FAILED at 1605. Hunk #14 FAILED at 1616. Hunk #15 succeeded at 1434 (offset -189 lines). 2 out of 15 hunks FAILED -- rejects in file drivers/media/i2c/ov7670.c Could you please rebase it? I tried to force its merge, but it seemed that the conflicts are not that trivial, so I prefer if you could do it and test if everything still applies. You need to apply the series in the following order: Firstly: [PATCH v2 0/5] media: ov7670: driver cleanup and support for ov7674. Secondly: [PATCH v3 0/4] ov7670: migrate this sensor and its users to ctrl framework. This shouldn't cause any troubles. Otherwise, please let me know. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Hi Ohad, On Friday 26 October 2012 07:50:56 Ohad Ben-Cohen wrote: On Thu, Oct 25, 2012 at 11:39 PM, Tony Lindgren t...@atomide.com wrote: Joerg and Ohad, do you have any opinions on this? I agree that there's some merit in having a separate header file for IOVMM, since it's a different layer from the IOMMU API. But in reality it's tightly coupled with OMAP's IOMMU, and ideally it really should go away and be replaced with the DMA API. For this reason, and for the fact that anyway there's only a single user for it (omap3isp) and there will never be any more, maybe we shouldn't pollute include/linux anymore. Anyone volunteering to remove IOVMM and adapt omap3isp to the DMA API instead ? ;) That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2, adding DT support, moving to the common clock framework (when that will be available for the OMAP3), supporting missing V4L2 features, ... All this in my spare time of course, otherwise it wouldn't be fun, would it ? ;-) I would also like to move the tidspbridge to the DMA API, but I think we'll need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an intermediate step would allow splitting patches in reviewable chunks. I know it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a temporary nuisance to make the leap easier. -- 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 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Hi Laurent, On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2, adding DT support, moving to the common clock framework (when that will be available for the OMAP3), supporting missing V4L2 features, ... All this in my spare time of course, otherwise it wouldn't be fun, would it ? ;-) Hmm, seems like a short to-do list ;) I would also like to move the tidspbridge to the DMA API, but I think we'll need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an intermediate step would allow splitting patches in reviewable chunks. I know it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a temporary nuisance to make the leap easier. Since tidspbridge is in staging I guess it's not a problem, though it sounds to me like using the correct API in the first place is going to make less churn. Thanks, Ohad. -- 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 FOR 3.7] Samsung media drivers fixes
On 10/25/2012 08:59 PM, Sylwester Nawrocki wrote: On 10/25/2012 06:46 PM, Mauro Carvalho Chehab wrote: Em Thu, 25 Oct 2012 18:01:17 +0200 Sylwester Nawrockis.nawro...@samsung.com escreveu: Hi Mauro, please pull following fixes for v3.7-rc. The following changes since commit 1fdead8ad31d3aa833bc37739273fcde89ace93c: [media] m5mols: Add missing #includelinux/sizes.h (2012-10-10 08:17:16 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_fixes_for_v3.7 for you to fetch changes up to df79eb9e19331685e509d62112972b3c35569f0b: s5p-fimc: Fix potential NULL pointer dereference (2012-10-25 16:08:12 +0200) Jesper Juhl (1): s5p-tv: don't include linux/version.h in mixer_video.c Sachin Kamat (5): s5p-mfc: Fix compilation warning exynos-gsc: Fix compilation warning s5p-mfc: Make 'clk_ref' static in s5p_mfc_pm.c s5p-fimc: Make 'fimc_pipeline_s_stream' function static s5p-fimc: Fix potential NULL pointer dereference Shaik Ameer Basha (3): exynos-gsc: change driver compatible string exynos-gsc: fix variable type in gsc_m2m_device_run() s5p-fimc: fix variable type in fimc_device_run() Sylwester Nawrocki (4): s5p-fimc: Don't ignore return value of vb2_queue_init() s5p-csis: Select S5P_SETUP_MIPIPHY s5p-fimc: Add missing new line character s5p-fimc: Fix platform entities registration Only a few of the above seems to be material for -rc: s5p-fimc: Fix potential NULL pointer dereference (59 seconds ago) s5p-fimc: Fix platform entities registration (60 seconds ago) s5p-csis: Select S5P_SETUP_MIPIPHY (60 seconds ago) s5p-fimc: Don't ignore return value of vb2_queue_init() (61 seconds ago) The other ones are warnings/sparse warnings and cleanups. I'll be applying only the 4 above patches for 3.7, adding the other ones for 3.8. I've noticed s5p-fimc: Fix platform entities registration will cause a race condition. Can you please drop entirely these two patches from the 3.7 queue: s5p-fimc: Fix potential NULL pointer dereference (59 seconds ago) s5p-fimc: Fix platform entities registration (60 seconds ago) ? Alternatively I can send a subsequent follow up patch. Sorry for mixing them up. Except those 4, exynos-gsc: change driver compatible string really needs to go in 3.7. Bootloaders will be supplying an FDT node for this device with compatible string samsung,exynos5-gsc, not samsung,exynos5250-gsc. In case this patch is applied only starting from 3.8, kernels 3.7, where the GScaler driver was first added, will have broken support for this device. Hence this patch should be considered as a real bug fix. For those embedded systems it might not be a big deal, since it rarely happens pure mainline kernel is used for production. But in principle it's better to apply that patch, to avoid mess where different kernels require different compatible string. This would mean an ABI breakage. -- 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
AVerTV Hybrid Express Slim HC81R
Hello! I want add support for this tuner in the linux. At this moment I successfully add receiving analog video (no sound..) But I have lot a questions: Where I can found documentation/datasheet about CX23885? What is vmux and amux? - Video/Audio channels descriptions? And others.. -- 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 TRIVIAL for 3.7] Documentation: fix outdated statement re. v4l2
Fix tense used for describing struct v4l2_fh as it has been added a while ago. Signed-off-by: Nicolas Thery nicolas.th...@st.com --- Documentation/video4linux/v4l2-framework.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 32bfe92..0a1ef67 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -68,8 +68,7 @@ Structure of the framework The framework closely resembles the driver structure: it has a v4l2_device struct for the device instance data, a v4l2_subdev struct to refer to sub-device instances, the video_device struct stores V4L2 device node data -and in the future a v4l2_fh struct will keep track of filehandle instances -(this is not yet implemented). +and the v4l2_fh struct keeps track of filehandle instances. The V4L2 framework also optionally integrates with the media framework. If a driver sets the struct v4l2_device mdev field, sub-devices and video nodes -- 1.7.11.3-- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] dvb: or51211: apply pr_fmt and use pr_* macros instead of printk
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/dvb-frontends/or51211.c | 94 +++--
1 file changed, 43 insertions(+), 51 deletions(-)
diff --git a/drivers/media/dvb-frontends/or51211.c
b/drivers/media/dvb-frontends/or51211.c
index 1af997e..9db8008 100644
--- a/drivers/media/dvb-frontends/or51211.c
+++ b/drivers/media/dvb-frontends/or51211.c
@@ -42,11 +42,11 @@
#include dvb_frontend.h
#include or51211.h
+#define pr_fmt(fmt)KBUILD_MODNAME : %s: fmt, __func__
+
static int debug;
#define dprintk(args...) \
- do { \
- if (debug) printk(KERN_DEBUG or51211: args); \
- } while (0)
+ do { if (debug) pr_debug(args); } while (0)
static u8 run_buf[] = {0x7f,0x01};
static u8 cmd_buf[] = {0x04,0x01,0x50,0x80,0x06}; // ATSC
@@ -80,8 +80,7 @@ static int i2c_writebytes (struct or51211_state* state, u8
reg, const u8 *buf,
msg.buf = (u8 *)buf;
if ((err = i2c_transfer (state-i2c, msg, 1)) != 1) {
- printk(KERN_WARNING or51211: i2c_writebytes error
- (addr %02x, err == %i)\n, reg, err);
+ pr_warn(error (addr %02x, err == %i)\n, reg, err);
return -EREMOTEIO;
}
@@ -98,8 +97,7 @@ static int i2c_readbytes(struct or51211_state *state, u8 reg,
u8 *buf, int len)
msg.buf = buf;
if ((err = i2c_transfer (state-i2c, msg, 1)) != 1) {
- printk(KERN_WARNING or51211: i2c_readbytes error
- (addr %02x, err == %i)\n, reg, err);
+ pr_warn(error (addr %02x, err == %i)\n, reg, err);
return -EREMOTEIO;
}
@@ -118,11 +116,11 @@ static int or51211_load_firmware (struct dvb_frontend* fe,
/* Get eprom data */
tudata[0] = 17;
if (i2c_writebytes(state,0x50,tudata,1)) {
- printk(KERN_WARNING or51211:load_firmware error eprom addr\n);
+ pr_warn(error eprom addr\n);
return -1;
}
if (i2c_readbytes(state,0x50,tudata[145],192)) {
- printk(KERN_WARNING or51211: load_firmware error eprom\n);
+ pr_warn(error eprom\n);
return -1;
}
@@ -136,32 +134,32 @@ static int or51211_load_firmware (struct dvb_frontend* fe,
state-config-reset(fe);
if (i2c_writebytes(state,state-config-demod_address,tudata,585)) {
- printk(KERN_WARNING or51211: load_firmware error 1\n);
+ pr_warn(error 1\n);
return -1;
}
msleep(1);
if (i2c_writebytes(state,state-config-demod_address,
fw-data[393],8125)) {
- printk(KERN_WARNING or51211: load_firmware error 2\n);
+ pr_warn(error 2\n);
return -1;
}
msleep(1);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: load_firmware error 3\n);
+ pr_warn(error 3\n);
return -1;
}
/* Wait at least 5 msec */
msleep(10);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: load_firmware error 4\n);
+ pr_warn(error 4\n);
return -1;
}
msleep(10);
- printk(or51211: Done.\n);
+ pr_info(Done.\n);
return 0;
};
@@ -173,14 +171,14 @@ static int or51211_setmode(struct dvb_frontend* fe, int
mode)
state-config-setmode(fe, mode);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: setmode error 1\n);
+ pr_warn(error 1\n);
return -1;
}
/* Wait at least 5 msec */
msleep(10);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: setmode error 2\n);
+ pr_warn(error 2\n);
return -1;
}
@@ -196,7 +194,7 @@ static int or51211_setmode(struct dvb_frontend* fe, int
mode)
* normal +/-150kHz Carrier acquisition range
*/
if (i2c_writebytes(state,state-config-demod_address,cmd_buf,3)) {
- printk(KERN_WARNING or51211: setmode error 3\n);
+ pr_warn(error 3\n);
return -1;
}
@@ -206,14 +204,14 @@ static int or51211_setmode(struct dvb_frontend* fe, int
mode)
rec_buf[3] = 0x00;
msleep(20);
if (i2c_writebytes(state,state-config-demod_address,rec_buf,3)) {
- printk(KERN_WARNING or51211: setmode error 5\n);
+ pr_warn(error 5\n);
}
msleep(3);
if (i2c_readbytes(state,state-config-demod_address,rec_buf[10],2)) {
- printk(KERN_WARNING or51211: setmode error 6);
+ pr_warn(error 6\n);
Re: [RESEND-PATCH] media:davinci: clk - {prepare/unprepare} for common clk
On 10/25/2012 09:12 AM, Prabhakar Lad wrote:
Hi Murali,
Thanks for the patch. I'll queue this patch for 3.8.
On Mon, Oct 22, 2012 at 9:06 PM, Murali Karicheri m-kariche...@ti.com wrote:
As a first step towards migrating davinci platforms to use common clock
framework, replace all instances of clk_enable() with clk_prepare_enable()
and clk_disable() with clk_disable_unprepare().
Also fixes some issues related to clk clean up in the driver
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Acked-by: Lad, Prabhakar prabhakar@ti.com
Tested-by: Lad, Prabhakar prabhakar@ti.com
Regards,
--Prabhakar
---
rebased to v3.7-rc1
drivers/media/platform/davinci/dm355_ccdc.c |8 ++--
drivers/media/platform/davinci/dm644x_ccdc.c | 16 ++--
drivers/media/platform/davinci/isif.c|5 -
drivers/media/platform/davinci/vpbe.c| 10 +++---
drivers/media/platform/davinci/vpif.c|8
5 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c
b/drivers/media/platform/davinci/dm355_ccdc.c
index ce0e413..030950d 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -1003,7 +1003,7 @@ static int __devinit dm355_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.mclk);
goto fail_nomap;
}
- if (clk_enable(ccdc_cfg.mclk)) {
+ if (clk_prepare_enable(ccdc_cfg.mclk)) {
status = -ENODEV;
goto fail_mclk;
}
@@ -1014,7 +1014,7 @@ static int __devinit dm355_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.sclk);
goto fail_mclk;
}
- if (clk_enable(ccdc_cfg.sclk)) {
+ if (clk_prepare_enable(ccdc_cfg.sclk)) {
status = -ENODEV;
goto fail_sclk;
}
@@ -1034,8 +1034,10 @@ static int __devinit dm355_ccdc_probe(struct
platform_device *pdev)
printk(KERN_NOTICE %s is registered with vpfe.\n, ccdc_hw_dev.name);
return 0;
fail_sclk:
+ clk_disable_unprepare(ccdc_cfg.sclk);
clk_put(ccdc_cfg.sclk);
fail_mclk:
+ clk_disable_unprepare(ccdc_cfg.mclk);
clk_put(ccdc_cfg.mclk);
fail_nomap:
iounmap(ccdc_cfg.base_addr);
@@ -1050,6 +1052,8 @@ static int dm355_ccdc_remove(struct platform_device *pdev)
{
struct resource *res;
+ clk_disable_unprepare(ccdc_cfg.sclk);
+ clk_disable_unprepare(ccdc_cfg.mclk);
clk_put(ccdc_cfg.mclk);
clk_put(ccdc_cfg.sclk);
iounmap(ccdc_cfg.base_addr);
diff --git a/drivers/media/platform/davinci/dm644x_ccdc.c
b/drivers/media/platform/davinci/dm644x_ccdc.c
index ee7942b..0215ab6 100644
--- a/drivers/media/platform/davinci/dm644x_ccdc.c
+++ b/drivers/media/platform/davinci/dm644x_ccdc.c
@@ -994,7 +994,7 @@ static int __devinit dm644x_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.mclk);
goto fail_nomap;
}
- if (clk_enable(ccdc_cfg.mclk)) {
+ if (clk_prepare_enable(ccdc_cfg.mclk)) {
status = -ENODEV;
goto fail_mclk;
}
@@ -1005,7 +1005,7 @@ static int __devinit dm644x_ccdc_probe(struct
platform_device *pdev)
status = PTR_ERR(ccdc_cfg.sclk);
goto fail_mclk;
}
- if (clk_enable(ccdc_cfg.sclk)) {
+ if (clk_prepare_enable(ccdc_cfg.sclk)) {
status = -ENODEV;
goto fail_sclk;
}
@@ -1013,8 +1013,10 @@ static int __devinit dm644x_ccdc_probe(struct
platform_device *pdev)
printk(KERN_NOTICE %s is registered with vpfe.\n, ccdc_hw_dev.name);
return 0;
fail_sclk:
+ clk_disable_unprepare(ccdc_cfg.sclk);
clk_put(ccdc_cfg.sclk);
fail_mclk:
+ clk_disable_unprepare(ccdc_cfg.mclk);
clk_put(ccdc_cfg.mclk);
fail_nomap:
iounmap(ccdc_cfg.base_addr);
@@ -1029,6 +1031,8 @@ static int dm644x_ccdc_remove(struct platform_device
*pdev)
{
struct resource *res;
+ clk_disable_unprepare(ccdc_cfg.mclk);
+ clk_disable_unprepare(ccdc_cfg.sclk);
clk_put(ccdc_cfg.mclk);
clk_put(ccdc_cfg.sclk);
iounmap(ccdc_cfg.base_addr);
@@ -1046,8 +1050,8 @@ static int dm644x_ccdc_suspend(struct device *dev)
/* Disable CCDC */
ccdc_enable(0);
/* Disable both master and slave clock */
- clk_disable(ccdc_cfg.mclk);
- clk_disable(ccdc_cfg.sclk);
+ clk_disable_unprepare(ccdc_cfg.mclk);
+ clk_disable_unprepare(ccdc_cfg.sclk);
return 0;
}
@@ -1055,8 +1059,8 @@ static int dm644x_ccdc_suspend(struct device *dev)
static int dm644x_ccdc_resume(struct device *dev)
{
/* Enable both master and slave clock */
- clk_enable(ccdc_cfg.mclk);
-
Re: [PATCHv10 08/26] v4l: vb2-dma-contig: add support for scatterlist in userptr mode
Hi Tomasz, On Wed, Oct 10, 2012 at 7:46 AM, Tomasz Stanislawski t.stanisl...@samsung.com wrote: This patch introduces usage of dma_map_sg to map memory behind a userspace pointer to a device as dma-contiguous mapping. Perhaps I'm missing something, but I don't understand the purpose of this patch. If the device can do DMA SG, why use videobuf2-dma-contig and not videobuf2-dma-sg? What would be the difference design-wise between them if this patch is merged? -- Best regards, Pawel Osciak -- 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 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Ohad Ben-Cohen o...@wizery.com [121026 02:56]: Hi Laurent, On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2, adding DT support, moving to the common clock framework (when that will be available for the OMAP3), supporting missing V4L2 features, ... All this in my spare time of course, otherwise it wouldn't be fun, would it ? ;-) Hmm, seems like a short to-do list ;) Sounds Laurent will take care of it :) I would also like to move the tidspbridge to the DMA API, but I think we'll need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an intermediate step would allow splitting patches in reviewable chunks. I know it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a temporary nuisance to make the leap easier. Since tidspbridge is in staging I guess it's not a problem, though it sounds to me like using the correct API in the first place is going to make less churn. Not related to these patches, but also sounds like we may need to drop some staging/tidspbridge code to be able to move forward with the ARM common zImage plans. See the [GIT PULL] omap plat header removal for v3.8 merge window, part1 thread for more info. 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
[PATCH 1/1] media: Entities with sink pads must have at least one enabled link
If an entity has sink pads, at least one of them must be connected to
another pad with an enabled link. If a driver with multiple sink pads has
more strict requirements the check should be done in the driver itself.
Just requiring one sink pad is connected with an enabled link is enough
API-wise: entities with sink pads with only disabled links should not be
allowed to stream in the first place, but also in a different operation mode
a device might require only one of its pads connected with an active link.
If an entity has an ability to function as a source entity another logical
entity connected to the aforementioned one should be used for the purpose.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/media-entity.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index e1cd132..8846ea7 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -227,6 +227,7 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
media_entity_graph_walk_start(graph, entity);
while ((entity = media_entity_graph_walk_next(graph))) {
+ bool has_sink = false, active_sink = false;
unsigned int i;
entity-stream_count++;
@@ -243,18 +244,27 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
for (i = 0; i entity-num_links; i++) {
struct media_link *link = entity-links[i];
+ /* Are we the sink or not? */
+ if (link-sink-entity != entity)
+ continue;
+
+ has_sink = true;
+
/* Is this pad part of an enabled link? */
if (!(link-flags MEDIA_LNK_FL_ENABLED))
continue;
- /* Are we the sink or not? */
- if (link-sink-entity != entity)
- continue;
+ active_sink = true;
ret = entity-ops-link_validate(link);
if (ret 0 ret != -ENOIOCTLCMD)
goto error;
}
+
+ if (has_sink !active_sink) {
+ ret = -EPIPE;
+ goto error;
+ }
}
mutex_unlock(mdev-graph_mutex);
--
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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Oct 26 19:00:27 CEST 2012 git hash:01aea0bfd8dfa8bc868df33904461984bb10a87a gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
Fushicai usbtv007 - anybody working on a driver for it?
Hello everybody. This post is not meant as the flame starter, nor is it I DEMAND kind of post - I just would like to know if I can expect support for Fushicai usbtv007 chipset anytime soon :) (or at all). This chipset is used in some EasyCap grabber clones, as described on the bottom of this page: http://linuxtv.org/wiki/index.php/Easycap#USBTV007_EasyCAP Thanks in advance. Best regards. -- 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
