[GIT PATCHES FOR 3.4] gspca for_v3.4
Hi Mauro, This set includes the patch http://patchwork.linuxtv.org/patch/9494. The following changes since commit 632fba4d012458fd5fedc678fb9b0f8bc59ceda2: [media] cx25821: Add a card definition for No brand cards that have: subvendor = 0x subdevice = 0x (2012-03-08 12:42:28 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.4 for you to fetch changes up to 898b0fd6218c7012a1b73e3bf7a7c60fd578c0a6: gspca - sn9c20x: Cleanup source (2012-03-19 08:55:16 +0100) Jean-François Moine (12): gspca - zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support gspca - zc3xx: Lack of register 08 value for sensor cs2102k gspca - sn9c20x: Fix loss of frame start gspca - sn9c20x: Use the new video control mechanism gspca - sn9c20x: Propagate USB errors to higher level gspca - sn9c20x: Add a delay after Omnivision sensor reset gspca - sn9c20x: Add the JPEG compression quality control gspca - sn9c20x: Optimize the code of write sequences gspca - sn9c20x: Greater delay in case of sensor no response gspca - sn9c20x: Add automatic JPEG compression mechanism gspca - sn9c20x: Simplify register write for capture start/stop gspca - sn9c20x: Cleanup source Jose Alberto Reguero (1): gspca - ov534_9: Add brightness to OmniVision 5621 sensor drivers/media/video/gspca/ov534_9.c | 49 ++- drivers/media/video/gspca/sn9c20x.c | 1138 --- drivers/media/video/gspca/zc3xx.c | 47 ++- 3 files changed, 582 insertions(+), 652 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit 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 Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36
-
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file
*file, void *fh,
/* set default crop and win */
omap_vout_new_format(vout-pix,vout-fbuf,vout-crop,vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file,
void *fh, enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl,info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl,info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
Have you checked for build warnings? I am getting build warnings
CC drivers/media/video/omap/omap_vout.o
CC drivers/media/video/omap/omap_voutlib.o
CC drivers/media/video/omap/omap_vout_vrfb.o
drivers/media/video/omap/omap_vout.c: In function 'vidioc_streamon':
drivers/media/video/omap/omap_vout.c:1619:25: warning: unused variable
'ovid'
drivers/media/video/omap/omap_vout.c:1615:15: warning: unused variable
'j'
LD drivers/media/video/omap/omap-vout.o
LD drivers/media/video/omap/built-in.o
Can you fix this and submit the next version?
I applied the patch on the current mainline kernel, it doesn't give any
build warnings. Even after applying the patch, 'j and ovid' are still
used in vidioc_streamon().
Can you check if it was applied correctly?
Archit,
I could able to trace what's going on here,
I am using v4l_for_linus branch, which has one missing patch,
commit aaa874a985158383c4b394c687c716ef26288741
Author: Tomi Valkeinen tomi.valkei...@ti.com
Date: Tue Nov 15 16:37:53 2011 +0200
OMAPDSS: APPLY: rewrite overlay enable/disable
So, I do not have below changes,
@@ -1686,6 +1681,16 @@ static int vidioc_streamon(struct file *file, void *fh,
enum v4l2_buf_type i)
if (ret)
v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
+ for (j = 0; j ovid-num_overlays; j++) {
+ struct omap_overlay *ovl = ovid-overlays[j];
+
+ if (ovl-manager ovl-manager-device) {
+ ret = ovl-enable(ovl);
+ if (ret)
+ goto streamon_err1;
+ }
+ }
+
This explains why I am seeing these warnings. Let me give pull request based on
master branch.
Thanks,
Vaibhav
Regards,
Archit
Will fix this and submit.
Archit
Thanks,
Vaibhav
/* First save the configuration in ovelray structure */
ret = omapvid_init(vout, addr);
if (ret)
@@ -2071,11 +2050,12 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
}
video_set_drvdata(vfd, vout);
- /* Configure the overlay structure */
- ret = omapvid_init(vid_dev-vouts[k], 0);
- if (!ret)
- goto success;
+ dev_info(pdev-dev, : registered and initialized
+ video device %d\n, vfd-minor);
+ if (k == (pdev-num_resources - 1))
+ return 0;
+ continue;
error2:
if (vout-vid_info.rotation_type == VOUT_ROT_VRFB)
omap_vout_release_vrfb(vout);
@@ -2085,12 +2065,6 @@ error1:
error:
kfree(vout);
return ret;
-
-success:
- dev_info(pdev-dev, : registered and initialized
- video device %d\n, vfd-minor);
- if (k == (pdev-num_resources
Re: DVB-S2 multistream support
Dear all, I decided to post a patch against the TBS drivers for all those who want to experiment with the very preliminary base-band demultiplexer until I have a repository to properly host this stuff. Currently it only works for the TBS 6925 card. The bb-dmx was created for Linux v3.3, so the patch also contains some changes that made it into Linux since TBS driver release v18. You can get the TBS source code via this direct link (I know there's a newer version but the patch is against the old driver package): http://www.tbsdtv.com/download/document/common/tbs-linux-drivers_v18.zip And then you can download the bb-dmx patch from here: http://www.cosy.sbg.ac.at/~cpraehaus/download/tbs_v18_bb-dmx_2012-03-19.patch.gz Tuning and configuration of the card is as normal, notice however that the card is currently put in base-band data mode irrespective of any configuration. This means that you probably wont be able to receive DVB-S. To test the bb-dmx support, there is a patch against dvbsnoop 1.4.5. You can get the source from the SF site: http://dvbsnoop.sourceforge.net/ and the patch from here: http://www.cosy.sbg.ac.at/~cpraehaus/download/dvbsnoop-1.4.50_bb-dmx_2012-03-19.patch Usage: dvbsnoop -s bb ISI (receive bbframes from ISI) dvbsnoop -s bb -tsraw (receive everything) Sorry, its still all very experimental and DVB-S2 specific, but I'd be happy to get feedback from those interested. Thanks and kind regards, Christian. Am 15.03.2012 um 10:40 schrieb Christian Prähauser: Dear all, First, thanks for your interest in this functionality. I think the modifications are in a shape where they begin to be useful for others. Currently I'm (still) trying to get some GIT repo where I can host the whole stuff. Thank you all for your support, testing will indeed by important after the first version is in the wild :-). I definitely want to keep this going and be sure that I tell you as soon as the code can be accessed. Kind regards, Christian. Am 13.03.2012 um 16:47 schrieb Bob W: Hi Konstantin, all work to support BBFrames in the Linux kernel is done by Christian - in fact it's a long lost work from 5 years ago: http://www.linuxtv.org/pipermail/linux-dvb/2007-December/022217.html yep, I have followed the history back... and like Christian said, the old repo is nolonger working. :( and i hope it won't be lost again. i just encouraged Christian that his work is important and there are people interested in it - you're one such example. so, i offered Christian to help him with i can. i guess more people appreciating what his doing and encourage him will give him better motivation to release the code to the public. however, i guess the delay is more, because it's not easy and it requires time to prepare the code for initial public release and that's why the delay. so, i don't have Christian's code and i'm eager as you're to be able to try it out, but we need to be patient. i'm sure that after there is some public release and repository more people will be interested to contribute to that work. best regards, konstantin Agreed, I understand the pressure of releasing publicly. Once released, the nit picking begins.. lol. I will keep watch on the list. Christian, if you want an extra tester to help yah, count me in. I'll help also with what I can. Bob -- 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 --- Dipl.-Ing. Christian Praehauser cpraeh...@cosy.sbg.ac.at || //\\//\\ || Multimedia Communications Group, ||// \/ \\|| Department of Computer Sciences, University of Salzburg http://www.cosy.sbg.ac.at/~cpraehaus/ http://www.network-research.org/ http://www.uni-salzburg.at/ -- 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 --- Dipl.-Ing. Christian Praehauser cpraeh...@cosy.sbg.ac.at || //\\//\\ || Multimedia Communications Group, ||// \/ \\|| Department of Computer Sciences, University of Salzburg http://www.cosy.sbg.ac.at/~cpraehaus/ http://www.network-research.org/ http://www.uni-salzburg.at/ -- 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] dib0700: Return -EINTR and unlock mutex if locking attempts fails.
Can anyone please review it ?
regards
Santosh
On Fri, Mar 16, 2012 at 6:15 PM, santosh nayak
santoshprasadna...@gmail.com wrote:
From: Santosh Nayak santoshprasadna...@gmail.com
In 'dib0700_i2c_xfer_new()' and 'dib0700_i2c_xfer_legacy()'
we are taking two locks:
1. i2c_mutex
2. usb_mutex
If attempt to take 'usb_mutex' lock fails then the previously taken
lock 'i2c_mutex' should be unlocked and -EINTR should be return so
that caller can take appropriate action.
If locking attempt was interrupted by a signal then
we should return -EINTR. At present we are returning '0' for
such scenarios which is wrong.
Signed-off-by: Santosh Nayak santoshprasadna...@gmail.com
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 070e82a..1a6ddbc 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -32,7 +32,7 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
@@ -118,7 +118,7 @@ int dib0700_set_gpio(struct dvb_usb_device *d, enum
dib07x0_gpios gpio, u8 gpio_
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_GPIO;
@@ -139,7 +139,7 @@ static int dib0700_set_usb_xfer_len(struct dvb_usb_device
*d, u16 nb_ts_packets)
if (st-fw_version = 0x10201) {
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_USB_XFER_LEN;
@@ -228,7 +228,8 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
st-buf[0] = REQUEST_NEW_I2C_WRITE;
st-buf[1] = msg[i].addr 1;
@@ -274,7 +275,8 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
return -EAGAIN;
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
for (i = 0; i num; i++) {
@@ -369,7 +371,7 @@ static int dib0700_set_clock(struct dvb_usb_device *d, u8
en_pll,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_CLOCK;
@@ -401,7 +403,7 @@ int dib0700_set_i2c_speed(struct dvb_usb_device *d, u16
scl_kHz)
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_I2C_PARAM;
@@ -561,7 +563,7 @@ int dib0700_streaming_ctrl(struct dvb_usb_adapter *adap,
int onoff)
if (mutex_lock_interruptible(adap-dev-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_ENABLE_VIDEO;
@@ -611,7 +613,7 @@ int dib0700_change_protocol(struct rc_dev *rc, u64
rc_type)
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_RC;
--
1.7.4.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
build errors in radio subsystem
I just got a kernel update that doesn't work for my PCTV 290e's so I pulled and build the media_build tree and got the below errors which I also got a week ago when I did the same after the previous kernel update and I'm just reporting this without knowing how often errors are fixed or for help if something is wrong at my end. The errors went away after I inserted include of slab.h in those files. /media_build/v4l/radio-isa.c:246:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] /media_build/v4l/radio-aztech.c:72:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-rtrack2.c:46:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-typhoon.c:76:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-terratec.c:57:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-aimslab.c:67:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-zoltrix.c:80:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-gemtek.c:183:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-trust.c:57:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] -- 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] dib0700: Return -EINTR and unlock mutex if locking attempts fails.
Hello,
I agree with the patch. But you could also add:
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 1a6ddbc..a271203 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -178,7 +178,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Ensure nobody else hits the i2c bus while we're sending our
sequence of messages, (such as the remote control thread) */
if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ return -EINTR;
for (i = 0; i num; i++) {
if (i == 0) {
@@ -272,7 +272,7 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
int i,len;
if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ return -EINTR;
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
mutex_unlock(d-i2c_mutex);
regards,
Olivier
From: santosh prasad nayak [santoshprasadna...@gmail.com]
Sent: Monday, March 19, 2012 9:47 AM
To: mche...@infradead.org
Cc: Olivier GRENIE; pboettc...@kernellabs.com; flor...@mickler.org;
gre...@linuxfoundation.org; linux-media@vger.kernel.org
Subject: Re: [PATCH] [media] dib0700: Return -EINTR and unlock mutex if locking
attempts fails.
Can anyone please review it ?
regards
Santosh
On Fri, Mar 16, 2012 at 6:15 PM, santosh nayak
santoshprasadna...@gmail.com wrote:
From: Santosh Nayak santoshprasadna...@gmail.com
In 'dib0700_i2c_xfer_new()' and 'dib0700_i2c_xfer_legacy()'
we are taking two locks:
1. i2c_mutex
2. usb_mutex
If attempt to take 'usb_mutex' lock fails then the previously taken
lock 'i2c_mutex' should be unlocked and -EINTR should be return so
that caller can take appropriate action.
If locking attempt was interrupted by a signal then
we should return -EINTR. At present we are returning '0' for
such scenarios which is wrong.
Signed-off-by: Santosh Nayak santoshprasadna...@gmail.com
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 070e82a..1a6ddbc 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -32,7 +32,7 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
@@ -118,7 +118,7 @@ int dib0700_set_gpio(struct dvb_usb_device *d, enum
dib07x0_gpios gpio, u8 gpio_
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_GPIO;
@@ -139,7 +139,7 @@ static int dib0700_set_usb_xfer_len(struct dvb_usb_device
*d, u16 nb_ts_packets)
if (st-fw_version = 0x10201) {
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_USB_XFER_LEN;
@@ -228,7 +228,8 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
st-buf[0] = REQUEST_NEW_I2C_WRITE;
st-buf[1] = msg[i].addr 1;
@@ -274,7 +275,8 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
return -EAGAIN;
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
for (i = 0; i num; i++) {
@@ -369,7 +371,7 @@ static int dib0700_set_clock(struct dvb_usb_device *d, u8
en_pll,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_CLOCK;
@@ -401,7 +403,7 @@ int dib0700_set_i2c_speed(struct dvb_usb_device *d, u16
scl_kHz)
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could
Re: [Linaro-mm-sig] [PATCH 4/4] dma-buf: document fd flags and O_CLOEXEC requirement
On Sun, Mar 18, 2012 at 11:34 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Otherwise subsystems will get this wrong and end up with and second export ioctl with the flag and O_CLOEXEC support added. Its not actually dma_buf_export that takes the O_CLOEXEC flag its dma_buf_fd I'm not sure how blindly we should be passing flags in from userspace to these, like O_NONBLOCK or perms flags. Dave. -- 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] dib0700: Return -EINTR and unlock mutex if locking attempts fails.
From: Santosh Nayak santoshprasadna...@gmail.com
In 'dib0700_i2c_xfer_new()' and 'dib0700_i2c_xfer_legacy()'
we are taking two locks:
1. i2c_mutex
2. usb_mutex
If attempt to take 'usb_mutex' lock fails then the previously taken
lock 'i2c_mutex' should be unlocked and -EINTR should be returned so
that caller can take appropriate action.
If locking attempt was interrupted by a signal then
we should return -EINTR. At present we are returning '0' for
such scenarios which is wrong.
Replace -EAGAIN by -EINTR as a return type for the the scenario
where locking attempt was interrupted by signal.
Signed-off-by: Santosh Nayak santoshprasadna...@gmail.com
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 070e82a..a271203 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -32,7 +32,7 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
@@ -118,7 +118,7 @@ int dib0700_set_gpio(struct dvb_usb_device *d, enum
dib07x0_gpios gpio, u8 gpio_
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_GPIO;
@@ -139,7 +139,7 @@ static int dib0700_set_usb_xfer_len(struct dvb_usb_device
*d, u16 nb_ts_packets)
if (st-fw_version = 0x10201) {
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_USB_XFER_LEN;
@@ -178,7 +178,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Ensure nobody else hits the i2c bus while we're sending our
sequence of messages, (such as the remote control thread) */
if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ return -EINTR;
for (i = 0; i num; i++) {
if (i == 0) {
@@ -228,7 +228,8 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
st-buf[0] = REQUEST_NEW_I2C_WRITE;
st-buf[1] = msg[i].addr 1;
@@ -271,10 +272,11 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
int i,len;
if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ return -EINTR;
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
for (i = 0; i num; i++) {
@@ -369,7 +371,7 @@ static int dib0700_set_clock(struct dvb_usb_device *d, u8
en_pll,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_CLOCK;
@@ -401,7 +403,7 @@ int dib0700_set_i2c_speed(struct dvb_usb_device *d, u16
scl_kHz)
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_I2C_PARAM;
@@ -561,7 +563,7 @@ int dib0700_streaming_ctrl(struct dvb_usb_adapter *adap,
int onoff)
if (mutex_lock_interruptible(adap-dev-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_ENABLE_VIDEO;
@@ -611,7 +613,7 @@ int dib0700_change_protocol(struct rc_dev *rc, u64 rc_type)
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_RC;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] dib0700: Return -EINTR and unlock mutex if locking attempts fails.
Hi Olivier,
Included your suggestion and sent a new patch.
Please review it.
regards
Santosh
On Mon, Mar 19, 2012 at 3:58 PM, Olivier GRENIE
olivier.gre...@parrot.com wrote:
Hello,
I agree with the patch. But you could also add:
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 1a6ddbc..a271203 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -178,7 +178,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Ensure nobody else hits the i2c bus while we're sending our
sequence of messages, (such as the remote control thread) */
if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ return -EINTR;
for (i = 0; i num; i++) {
if (i == 0) {
@@ -272,7 +272,7 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
int i,len;
if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
+ return -EINTR;
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
mutex_unlock(d-i2c_mutex);
regards,
Olivier
From: santosh prasad nayak [santoshprasadna...@gmail.com]
Sent: Monday, March 19, 2012 9:47 AM
To: mche...@infradead.org
Cc: Olivier GRENIE; pboettc...@kernellabs.com; flor...@mickler.org;
gre...@linuxfoundation.org; linux-media@vger.kernel.org
Subject: Re: [PATCH] [media] dib0700: Return -EINTR and unlock mutex if
locking attempts fails.
Can anyone please review it ?
regards
Santosh
On Fri, Mar 16, 2012 at 6:15 PM, santosh nayak
santoshprasadna...@gmail.com wrote:
From: Santosh Nayak santoshprasadna...@gmail.com
In 'dib0700_i2c_xfer_new()' and 'dib0700_i2c_xfer_legacy()'
we are taking two locks:
1. i2c_mutex
2. usb_mutex
If attempt to take 'usb_mutex' lock fails then the previously taken
lock 'i2c_mutex' should be unlocked and -EINTR should be return so
that caller can take appropriate action.
If locking attempt was interrupted by a signal then
we should return -EINTR. At present we are returning '0' for
such scenarios which is wrong.
Signed-off-by: Santosh Nayak santoshprasadna...@gmail.com
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 070e82a..1a6ddbc 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -32,7 +32,7 @@ int dib0700_get_version(struct dvb_usb_device *d, u32
*hwversion,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
ret = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev, 0),
@@ -118,7 +118,7 @@ int dib0700_set_gpio(struct dvb_usb_device *d, enum
dib07x0_gpios gpio, u8 gpio_
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_GPIO;
@@ -139,7 +139,7 @@ static int dib0700_set_usb_xfer_len(struct
dvb_usb_device *d, u16 nb_ts_packets)
if (st-fw_version = 0x10201) {
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
st-buf[0] = REQUEST_SET_USB_XFER_LEN;
@@ -228,7 +228,8 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter
*adap, struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
st-buf[0] = REQUEST_NEW_I2C_WRITE;
st-buf[1] = msg[i].addr 1;
@@ -274,7 +275,8 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
return -EAGAIN;
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ mutex_unlock(d-i2c_mutex);
+ return -EINTR;
}
for (i = 0; i num; i++) {
@@ -369,7 +371,7 @@ static int dib0700_set_clock(struct dvb_usb_device *d,
u8 en_pll,
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ return -EINTR;
}
[PATCH] [media] s5p-jpeg: Make the output format setting conditional
S5P-JPEG IP on Exynos4210 SoC supports YCbCr422 and YCbCr420 as decoded output formats. But the driver used to fix the output format as YCbCr422. This is now made conditional depending upon the requested output format. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/video/s5p-jpeg/jpeg-core.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/s5p-jpeg/jpeg-core.c b/drivers/media/video/s5p-jpeg/jpeg-core.c index 1105a87..ee78fb2 100644 --- a/drivers/media/video/s5p-jpeg/jpeg-core.c +++ b/drivers/media/video/s5p-jpeg/jpeg-core.c @@ -957,7 +957,10 @@ static void s5p_jpeg_device_run(void *priv) jpeg_rst_int_enable(jpeg-regs, true); jpeg_data_num_int_enable(jpeg-regs, true); jpeg_final_mcu_num_int_enable(jpeg-regs, true); - jpeg_outform_raw(jpeg-regs, S5P_JPEG_RAW_OUT_422); + if (ctx-cap_q.fmt-fourcc == V4L2_PIX_FMT_YUYV) + jpeg_outform_raw(jpeg-regs, S5P_JPEG_RAW_OUT_422); + else + jpeg_outform_raw(jpeg-regs, S5P_JPEG_RAW_OUT_420); jpeg_jpgadr(jpeg-regs, src_addr); jpeg_imgadr(jpeg-regs, dst_addr); } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero
On Monday 19 March 2012 02:15 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit 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 Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36
-
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file
*file, void *fh,
/* set default crop and win */
omap_vout_new_format(vout-pix,vout-fbuf,vout-crop,vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file,
void *fh, enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl,info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl,info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
Have you checked for build warnings? I am getting build warnings
CC drivers/media/video/omap/omap_vout.o
CC drivers/media/video/omap/omap_voutlib.o
CC drivers/media/video/omap/omap_vout_vrfb.o
drivers/media/video/omap/omap_vout.c: In function 'vidioc_streamon':
drivers/media/video/omap/omap_vout.c:1619:25: warning: unused variable
'ovid'
drivers/media/video/omap/omap_vout.c:1615:15: warning: unused variable
'j'
LD drivers/media/video/omap/omap-vout.o
LD drivers/media/video/omap/built-in.o
Can you fix this and submit the next version?
I applied the patch on the current mainline kernel, it doesn't give any
build warnings. Even after applying the patch, 'j and ovid' are still
used in vidioc_streamon().
Can you check if it was applied correctly?
Archit,
I could able to trace what's going on here,
I am using v4l_for_linus branch, which has one missing patch,
commit aaa874a985158383c4b394c687c716ef26288741
Author: Tomi Valkeinentomi.valkei...@ti.com
Date: Tue Nov 15 16:37:53 2011 +0200
OMAPDSS: APPLY: rewrite overlay enable/disable
So, I do not have below changes,
@@ -1686,6 +1681,16 @@ static int vidioc_streamon(struct file *file, void *fh,
enum v4l2_buf_type i)
if (ret)
v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
+ for (j = 0; j ovid-num_overlays; j++) {
+ struct omap_overlay *ovl = ovid-overlays[j];
+
+ if (ovl-manager ovl-manager-device) {
+ ret = ovl-enable(ovl);
+ if (ret)
+ goto streamon_err1;
+ }
+ }
+
This explains why I am seeing these warnings. Let me give pull request based on
master branch.
Okay. Thanks for looking into this.
Archit
Thanks,
Vaibhav
Regards,
Archit
Will fix this and submit.
Archit
Thanks,
Vaibhav
/* First save the configuration in ovelray structure */
ret = omapvid_init(vout, addr);
if (ret)
@@ -2071,11 +2050,12 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
}
video_set_drvdata(vfd, vout);
- /* Configure the overlay structure */
- ret = omapvid_init(vid_dev-vouts[k], 0);
- if (!ret)
- goto success;
+ dev_info(pdev-dev, : registered and initialized
+ video device %d\n, vfd-minor);
+ if (k == (pdev-num_resources - 1))
+ return 0;
+ continue;
error2:
if (vout-vid_info.rotation_type == VOUT_ROT_VRFB)
omap_vout_release_vrfb(vout);
@@ -2085,12 +2065,6 @@ error1:
error:
kfree(vout);
return ret;
-
-success:
- dev_info(pdev-dev, : registered and initialized
- video device %d\n, vfd-minor);
- if (k == (pdev-num_resources - 1))
- return 0;
}
return -ENODEV;
--
1.7.5.4
--
To unsubscribe from this list: send the line
[REGRESSION][PATCH] Fix kernel 3.3 DVB-S support
Kernel 3.3 breaks DVB-S reception on the
Hauppauge WinTV Nova HD-S2 and similar
cards.
The attached patch fixes this problem.
cu,
knut
From 10934b412eb30fa815bad392b120eb9b83fe4ab5 Mon Sep 17 00:00:00 2001
From: Knut Petersen knut_peter...@t-online.de
Date: Mon, 19 Mar 2012 13:31:24 +0100
Subject: [PATCH] Fix DVB-S regression caused by a missing initialization
commit 7e0722215a510921cbb73ab4c37477d4dcb91bf8 killed
struct dvb_frontend_parameters and introduced bool re_tune
instead, but the patch missed that re_tune needs an
initialization here (previously the same effect was
reached by the params = NULL).
This patch fixes broken DVB-S support for the Hauppauge
WinTV Nova HD-S2 and similar hardware in kernel 3.3.
Signed-off-by: Knut Petersen knut_peter...@t-online.de
---
drivers/media/dvb/dvb-core/dvb_frontend.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index fbbe545..a9602e0 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -650,6 +650,7 @@ restart:
switch (algo) {
case DVBFE_ALGO_HW:
dprintk(%s: Frontend ALGO = DVBFE_ALGO_HW\n, __func__);
+re_tune = false;
if (fepriv-state FESTATE_RETUNE) {
dprintk(%s: Retune requested, FESTATE_RETUNE\n, __func__);
--
1.7.9.2
Re: [PATCH] Various nits, fixes and hacks for mantis CA support on SMP
Em 27-02-2012 22:03, Steinar H. Gunderson escreveu: Hi, This patch, against 3.3-rc4, is basically a conglomerate of patches that together seem to make CA support on mantis working and stable, even on SMP systems. A conglomerate of patches can't be applied upstream. Instead, you should be sending us a patch series, preserving the original author/signed-off-by for each one, if the patches were nod written by you, and add your Signed-off-by: at the end of each patch. Regards, Mauro (I'm using a Terratec Cinergy DVB-S2 card with a Conax CAM, with mumudvb as userspace.) There are a few fixes from this mailing list and some of my own; the end result is too ugly to include, and there are still things I don't understand at all, but I hope it can be useful for some. Below is the list of what the patch does: - I've followed the instructions from some post on this mailing list to enable CAM support in the first place (mantis_set_direction move to mantis_pci.c, uncomment mantis_ca_init). - The MANTIS_GPIF_STATUS fix from http://patchwork.linuxtv.org/patch/8776/. Not that it seems to change a lot for me, but it makes sense. - I've fixed a ton of SMP-related bugs. Basically a lot of the members of mantis_ca were accessed from several threads without a mutex, which is a big no-no; I've mostly changed to using atomic operations here, although I also added some locks were it made sense (e.g. when resetting the CAM). The ca_lock is replaced by a more general int_stat_lock, which ideally is held when banging on MANTIS_INT_STAT. (I have no hardware documentation, so I'm afraid I don't really know the specifics here.) - mantis_hif_write_wait() would never clear MANTIS_SBUF_OPDONE_BIT, leading to a lot of operations never actually waiting for the callback. I've added many such fixes, as well as debugging output when the bit is in a surprising state (e.g., MANTIS_SBUF_OPDONE_BIT set before the beginning of an operation, where it really should be cleared). - Some operations check for timeout by testing if wait_event_timeout() return -ERESTARTSYS. However, wait_event_timeout() can can never do this; the return value for timeout is zero. I've fixed this (well, I seemingly forgot one; have to do that in the next version :-) ). Unfortunately, this make the problems in the next point a _lot_ worse, since timeouts are now actually percolated up the stack. - As others have noticed, sometimes, especially during DMA transfers, the IRQ0 flag is never properly set and thus reads never return. (The typical case for this is when we've just done a write and the en50221 thread is waiting for the CAM status word to signal STATUSREG_DA; if this doesn't happen in a reasonable amount of time, the upstream libdvben50221.so will report errors back to mumudvb.) I have no idea why this happens more often on SMP systems than on UMP systems, but they really seem to do. I haven't found any reasonable workaround for reliable polling either, so I'm making a hack -- if there's nothing returned in two milliseconds, the read is simply assumed to have completed. This is an unfortunate hack, but in practice it's identical to the previous behavior except with a shorter timeout. - A hack to fix a mutex issue in the DVB layer; dvb_usercopy(), which is called on all ioctls, not only copies data to and from userspace, but also takes a lock on the file descriptor, which means that only one ioctl can run at a time. This means that if one thread of mumudvb is busy trying to get, say, the SNR from the frontend (which can hang due to the issue above), the CAM thread's ioctl(fd, CA_GET_SLOT_INFO, ...) will hang, even though it doesn't need to communicate with the hardware at all. This obviously requires a better fix, but I don't know the generic DVB layer well enough to say what it is. Maybe it's some sort of remnant of from when all ioctl()s took the BKL. Note that on UMP kernels without preemption, mutex_lock is to the best of my knowledge a no-op, so these delay issues would not show up on non-SMP. - Tiny cleanups: Removed some unused mmread()s and structure members. Some debugging messages have been made more specific or clearer (e.g. reads say what address they're from, the I2C subsystem reports if there were any timeouts, the interrupt handler properly clears the RISC status word so it isn't shown as Unknown). I'm still not happy with the bit-banging on the I2C interface (as opposed to dealing with it in the interrupt handler); I long suspected it for causing the IRQ0 problems, especially as they seem to have a sort-of similar issue with I2CDONE/I2CRACk never being set, but it seem the DMA transfers is really what causes it somehow, so I've left it alone. Anyway, if there are specific pieces people want me to split out for mainline,
Re: [PATCH] Various nits, fixes and hacks for mantis CA support on SMP
On Mon, Mar 19, 2012 at 11:05:10AM -0300, Mauro Carvalho Chehab wrote: A conglomerate of patches can't be applied upstream. Instead, you should be sending us a patch series, preserving the original author/signed-off-by for each one, if the patches were nod written by you, and add your Signed-off-by: at the end of each patch. This is true. I was, however, mainly looking for feedback -- it seems there is very little interest, though. /* Steinar */ -- Homepage: http://www.sesse.net/ -- 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] Various nits, fixes and hacks for mantis CA support on SMP
Steinar H. Gunderson sgunder...@bigfoot.com writes: On Mon, Mar 19, 2012 at 11:05:10AM -0300, Mauro Carvalho Chehab wrote: A conglomerate of patches can't be applied upstream. Instead, you should be sending us a patch series, preserving the original author/signed-off-by for each one, if the patches were nod written by you, and add your Signed-off-by: at the end of each patch. This is true. I was, however, mainly looking for feedback -- it seems there is very little interest, though. The user base is too small to get any feedback without getting the patches into mainline. I suggest you submit the parts you'd like to use yourself. That's the only way to get them tested. I do have two mantis cards, but I don't have any CAM and I don't have access to any DVB-C signal anymore. So that's why I didn't provide any feedback despite being historically interested in this driver. Bjørn -- 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: build errors in radio subsystem
On 03/19/2012 02:45 AM, Claus Olesen wrote: I just got a kernel update that doesn't work for my PCTV 290e's so I pulled and build the media_build tree and got the below errors which I also got a week ago when I did the same after the previous kernel update and I'm just reporting this without knowing how often errors are fixed or for help if something is wrong at my end. The errors went away after I inserted include of slab.h in those files. Mauro, Please merge Hans's media-isa patch from Feb. 29. Subject: [PATCH] Add missing slab.h to fix linux-next compile errors Thanks. /media_build/v4l/radio-isa.c:246:3: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration] /media_build/v4l/radio-aztech.c:72:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-rtrack2.c:46:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-typhoon.c:76:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-terratec.c:57:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-aimslab.c:67:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-zoltrix.c:80:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-gemtek.c:183:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] media_build/v4l/radio-trust.c:57:9: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] -- -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement
Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. v2: Fixup the function name and caution exporters to limit the flags to only O_CLOEXEC. Noted by Dave Airlie. Cc: Dave Airlie airl...@gmail.com Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- Documentation/dma-buf-sharing.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 9f3aeef..a6d4c37 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -319,6 +319,12 @@ Miscellaneous notes - Any exporters or users of the dma-buf buffer sharing framework must have a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. +- To avoid the wrath of userspace library writers exporting subsystems must have + a flag parameter in the ioctl that creates the dma-buf fd which needs to + support at least the O_CLOEXEC fd flag. This needs to be passed in the flag + parameter of dma_buf_fd. Without any other reasons applying it is recommended + that exporters limit the flags passed to dma_buf_fd to only O_CLOEXEC. + References: [1] struct dma_buf_ops in include/linux/dma-buf.h [2] All interfaces mentioned above defined in include/linux/dma-buf.h -- 1.7.7.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] [media] s5p-jpeg: Make the output format setting conditional
Hello, On March 19, 2012 12:35 PM Sachin Kamat wrote: Subject: [PATCH] [media] s5p-jpeg: Make the output format setting conditional S5P-JPEG IP on Exynos4210 SoC supports YCbCr422 and YCbCr420 as decoded output formats. But the driver used to fix the output format as YCbCr422. This is now made conditional depending upon the requested output format. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/video/s5p-jpeg/jpeg-core.c |5 - snip This has already been submitted and been pulled by Mauro: http://git.linuxtv.org/media_tree.git/commit/fb6f8c0269644a19ee5e9bd6db080b3 64ab28ea7 Andrzej -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma-buf: document fd flags and O_CLOEXEC requirement
On Mon, Mar 19, 2012 at 04:41:55PM +0100, Daniel Vetter wrote: Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. v2: Fixup the function name and caution exporters to limit the flags to only O_CLOEXEC. Noted by Dave Airlie. Cc: Dave Airlie airl...@gmail.com Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- Documentation/dma-buf-sharing.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 9f3aeef..a6d4c37 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -319,6 +319,12 @@ Miscellaneous notes - Any exporters or users of the dma-buf buffer sharing framework must have a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. +- To avoid the wrath of userspace library writers exporting subsystems must have + a flag parameter in the ioctl that creates the dma-buf fd which needs to + support at least the O_CLOEXEC fd flag. This needs to be passed in the flag + parameter of dma_buf_fd. Without any other reasons applying it is recommended + that exporters limit the flags passed to dma_buf_fd to only O_CLOEXEC. Difficult to parse. Needs more punctuation. -- Ville Syrjälä Intel OTC -- 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] get_dvb_firmware: add dvb-demod-drxk-pctv.fw
Firmware for the PCTV QuatroStick nano (520e).
Signed-off-by: Antti Palosaari cr...@iki.fi
---
Documentation/dvb/get_dvb_firmware | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index d1d4a17..fbb2411 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -28,7 +28,8 @@ use IO::Handle;
opera1, cx231xx, cx18, cx23885, pvrusb2, mpc718,
af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
lme2510c_s7395_old, drxk, drxk_terratec_h5,
- drxk_hauppauge_hvr930c, tda10071, it9135, it9137);
+ drxk_hauppauge_hvr930c, tda10071, it9135, it9137,
+ drxk_pctv);
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -730,6 +731,23 @@ sub tda10071 {
$fwfile;
}
+sub drxk_pctv {
+my $sourcefile = PCTV_460e_reference.zip;
+my $url =
ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%20330e%20800e/;;
+my $hash = 4403de903bf2593464c8d74bbc200a57;
+my $fwfile = dvb-demod-drxk-pctv.fw;
+my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
+
+checkstandard();
+
+wgetfile($sourcefile, $url . $sourcefile);
+verify($sourcefile, $hash);
+unzip($sourcefile, $tmpdir);
+extract($tmpdir/PCTV\ 70e\ 80e\ 100e\ 320e\ 330e\ 800e/32\
bit/emOEM.sys, 0x72b80, 42692, $fwfile);
+
+$fwfile;
+}
+
# ---
# Utilities
--
1.7.7.6
--
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] em28xx: support for 2013:0251 PCTV QuatroStick nano (520e)
Hardware is based of:
Empia EM2884
Micronas DRX 3926K
NXP TDA18271HDC2
... + analog parts.
Analog is not supported currently. Only DVB-T and DVB-C.
There seems to be still problems for locking DVB-C channels which have
strong signal. Attenuator helps. I think it is demodulator IF/RF AGC
issue. Lets fix it later. Patches are welcome.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/video/em28xx/em28xx-cards.c | 28 +++
drivers/media/video/em28xx/em28xx-dvb.c | 52 +
drivers/media/video/em28xx/em28xx.h |1 +
3 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index d5c9613..a65d479 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -364,6 +364,20 @@ static struct em28xx_reg_seq maxmedia_ub425_tc[] = {
{-1, -1,-1, -1},
};
+/* 2013:0251 PCTV QuatroStick nano (520e)
+ * GPIO_2: decoder reset, 0=active
+ * GPIO_4: decoder suspend, 0=active
+ * GPIO_6: demod reset, 0=active
+ * GPIO_7: LED, 1=active
+ */
+static struct em28xx_reg_seq pctv_520e[] = {
+ {EM2874_R80_GPIO, 0x10, 0xff, 100},
+ {EM2874_R80_GPIO, 0x14, 0xff, 100}, /* GPIO_2 = 1 */
+ {EM2874_R80_GPIO, 0x54, 0xff, 050}, /* GPIO_6 = 1 */
+ {EM2874_R80_GPIO, 0xd4, 0xff, 000}, /* GPIO_7 = 1 */
+ { -1, -1, -1, -1},
+};
+
/*
* Board definitions
*/
@@ -1930,6 +1944,18 @@ struct em28xx_board em28xx_boards[] = {
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ /* 2013:0251 PCTV QuatroStick nano (520e)
+* Empia EM2884 + Micronas DRX 3926K + NXP TDA18271HDC2 */
+ [EM2884_BOARD_PCTV_520E] = {
+ .name = PCTV QuatroStick nano (520e),
+ .tuner_type= TUNER_ABSENT,
+ .tuner_gpio= pctv_520e,
+ .has_dvb = 1,
+ .ir_codes = RC_MAP_PINNACLE_PCTV_HD,
+ .i2c_speed = EM2874_I2C_SECONDARY_BUS_SELECT |
+ EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_400_KHZ,
+ },
};
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
@@ -2083,6 +2109,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2860_BOARD_EASYCAP },
{ USB_DEVICE(0x1b80, 0xe425),
.driver_info = EM2874_BOARD_MAXMEDIA_UB425_TC },
+ { USB_DEVICE(0x2013, 0x0251),
+ .driver_info = EM2884_BOARD_PCTV_520E },
{ },
};
MODULE_DEVICE_TABLE(usb, em28xx_id_table);
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index 0b3e301..398d713 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -331,6 +331,13 @@ struct drxk_config maxmedia_ub425_tc_drxk = {
.no_i2c_bridge = 1,
};
+struct drxk_config pctv_520e_drxk = {
+ .adr = 0x29,
+ .single_master = 1,
+ .microcode_name = dvb-demod-drxk-pctv.fw,
+ .chunk_size = 58,
+};
+
static int drxk_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct em28xx_dvb *dvb = fe-sec_priv;
@@ -464,6 +471,33 @@ static void terratec_h5_init(struct em28xx *dev)
em28xx_gpio_set(dev, terratec_h5_end);
};
+static void pctv_520e_init(struct em28xx *dev)
+{
+ /*
+* Init TDA8295(?) analog demodulator. Looks like I2C traffic to
+* digital demodulator and tuner are routed via TDA8295.
+*/
+ int i;
+ struct {
+ unsigned char r[4];
+ int len;
+ } regs[] = {
+ {{ 0x06, 0x02, 0x00, 0x31 }, 4},
+ {{ 0x01, 0x02 }, 2},
+ {{ 0x01, 0x02, 0x00, 0xc6 }, 4},
+ {{ 0x01, 0x00 }, 2},
+ {{ 0x01, 0x00, 0xff, 0xaf }, 4},
+ {{ 0x01, 0x00, 0x03, 0xa0 }, 4},
+ {{ 0x01, 0x00 }, 2},
+ {{ 0x01, 0x00, 0x73, 0xaf }, 4},
+ };
+
+ dev-i2c_client.addr = 0x82 1; /* 0x41 */
+
+ for (i = 0; i ARRAY_SIZE(regs); i++)
+ i2c_master_send(dev-i2c_client, regs[i].r, regs[i].len);
+};
+
static int em28xx_mt352_terratec_xs_init(struct dvb_frontend *fe)
{
/* Values extracted from a USB trace of the Terratec Windows driver */
@@ -965,6 +999,24 @@ static int em28xx_dvb_init(struct em28xx *dev)
driver version\n);
break;
+ case EM2884_BOARD_PCTV_520E:
+ pctv_520e_init(dev);
+
+ /* attach demodulator */
+ dvb-fe[0] = dvb_attach(drxk_attach, pctv_520e_drxk,
+ dev-i2c_adap);
+
+ if (dvb-fe[0]) {
+ /* attach tuner */
+
[Q] ov7670: green line in VGA resolution
Hi, I am currently testing an ov7670 sensor against my mx2_camera.c soc-camera driver. Everything works as expected with the exception of a green vertical line of about 6-7 pixels width that appears on the left side of the image. I suspect the problem is related to the fact that this sensor has an array of 656 x 488 pixels but only 640 x 480 are active. The datasheet available from Omnivision (Version 1.4, August 21, 2006) is not clear about how to configure the sensor not to show non active pixels but I could find the following patch which addresses a similar problem for QVGA: http://kernel.ubuntu.com/git?p=bradf/backup.ubuntu-maverick/.git;a=commitdiff;h=e4182762eaf3c80b2f5c8d1d373409d7c2843579;hp=e770cc1e35a3f11cffd1f38f52060e3e38b4fbf7 But I don't know how these values can be extrapolated to the VGA case. Has anybody found the same issue? 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] RFC: dma-buf: userspace mmap support
If the API was to also be used for synchronization it would have to include an atomic prepare multiple ioctl which blocked until all the buffers listed by the application were available. In the same Too slow already. You are now serializing stuff while what we want to do really is nobody_else_gets_buffers_next([list]) on available(buffer) dispatch_work(buffer) so that you can maximise parallelism without allowing deadlocks. If you've got a high memory bandwith and 8+ cores the 'stop everything' model isn't great. This might be a good argument for keeping synchronization and cache maintenance separate, though even ignoring synchronization I would think being able to issue cache maintenance operations for multiple buffers in a single ioctl might present some small efficiency gains. However as Rob points out, CPU access is already in slow/legacy territory. Dangerous assumption. I do think they should be separate. For one it makes the case of synchronization needed but hardware cache management much easier to split cleanly. Assuming CPU access is slow/legacy reflects a certain model of relatively slow CPU and accelerators where falling off the acceleration path is bad. On a higher end processor falling off the acceleration path isn't a performance matter so much as a power concern. KDS we differentiated jobs which needed exclusive access to a buffer and jobs which needed shared access to a buffer. Multiple jobs could access a buffer at the same time if those jobs all Makes sense as it's a reader/writer lock and it reflects MESI/MOESI caching and cache policy in some hardware/software assists. display controller will be reading the front buffer, but the GPU might also need to read that front buffer. So perhaps adding read-only read-write access flags to prepare could also be interpreted as shared exclusive accesses, if we went down this route for synchronization that is. :-) mmap includes read/write info so probably using that works out. It also means that you have the stuff mapped in a way that will bus error or segfault anyone who goofs rather than give them the usual 'deep weirdness' behaviour you get with mishandling of caching bits. Alan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support
On 03/19/2012 05:56 PM, Alan Cox wrote: display controller will be reading the front buffer, but the GPU might also need to read that front buffer. So perhaps adding read-only read-write access flags to prepare could also be interpreted as shared exclusive accesses, if we went down this route for synchronization that is.:-) mmap includes read/write info so probably using that works out. It also means that you have the stuff mapped in a way that will bus error or segfault anyone who goofs rather than give them the usual 'deep weirdness' behaviour you get with mishandling of caching bits. Alan mmap only give you this info at time of mmap call. prepare/finish would give you this info for each CPU access to the buffer (assuming mmap lasts multiple frames). Which means that you can optimize and have zero cache syncs for frames where CPU doesn't touch the buffer at all. If you use mmap info, then you would be forced to sync cache before each GPU access to the buffer. For example sub texture updates in glyph caches. They will only rarely change, so you don't want to sync CPU cache each time buffer is used in GPU, just because mmap says CPU has write access. /Marcus -- 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]NEXT:drivers:staging:media Fix comments and some typos in staging/media/*
Em 16-03-2012 13:08, Justin P. Mattock escreveu: On 03/16/2012 09:06 AM, Justin P. Mattock wrote: On 03/16/2012 08:58 AM, Greg KH wrote: On Fri, Mar 16, 2012 at 04:45:03PM +0100, Jiri Kosina wrote: On Fri, 16 Mar 2012, Justin P. Mattock wrote: before I forget about this patch, what was the status of this one? As previously announced multiple times, I am ignoring patches that go to drivers/staging and letting Greg pick them up if he wants to. Greg, if you want to have this changed, just let me know. No, no objection from me, but patches to drivers/staging/media/ do not go through me, please see the MAINTAINERS file for the owner of those (hint, it's Mauro...) thanks, greg k-h ahh!! I got it now.. your in charge of the staging tree but for each branch there is an owner(I thought to just send to greg KH and thats it) adding Mauro to the Cc's so he can view the patch, then on any other patch I send to staging I will send it to the maintainer then the rest as follows with a cc's. Thanks for the help on this. Justin P. Mattock and of course pressed send without the Maintainer on it.. duh! I'm applying it on my tree. Thanks! Mauro Justin P. Mattock -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [media] dib9000: implement error handling for DibAcquireLock
Em 06-03-2012 18:08, Alexey Khoroshilov escreveu:
DibAcquireLock() is implemented as mutex_lock_interruptible()
but the driver does not handle unsuccessful locking.
As a result it may lead to unlock of an unheld mutex.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/dvb/frontends/dib9000.c | 115
++---
1 files changed, 91 insertions(+), 24 deletions(-)
diff --git a/drivers/media/dvb/frontends/dib9000.c
b/drivers/media/dvb/frontends/dib9000.c
index d96b6a1..80848b4 100644
--- a/drivers/media/dvb/frontends/dib9000.c
+++ b/drivers/media/dvb/frontends/dib9000.c
@@ -33,7 +33,7 @@ struct i2c_device {
/* lock */
#define DIB_LOCK struct mutex
-#define DibAcquireLock(lock) do { if (mutex_lock_interruptible(lock) 0)
dprintk(could not get the lock); } while (0)
+#define DibAcquireLock(lock) mutex_lock_interruptible(lock)
#define DibReleaseLock(lock) mutex_unlock(lock)
#define DibInitLock(lock) mutex_init(lock)
#define DibFreeLock(lock)
It will likely be better to remove all those macros, as they just make the
driver code harder to review.
I'll apply this patch, as it fixes a bug, but it would be great if you
could send us a patch to get rid of those macros.
Thanks,
Mauro
@@ -446,7 +446,10 @@ static int dib9000_risc_mem_read(struct dib9000_state
*state, u8 cmd, u8 * b, u1
if (!state-platform.risc.fw_is_running)
return -EIO;
- DibAcquireLock(state-platform.risc.mem_lock);
+ if (DibAcquireLock(state-platform.risc.mem_lock) 0) {
+ dprintk(could not get the lock);
+ return -EINTR;
+ }
dib9000_risc_mem_setup(state, cmd | 0x80);
dib9000_risc_mem_read_chunks(state, b, len);
DibReleaseLock(state-platform.risc.mem_lock);
@@ -459,7 +462,10 @@ static int dib9000_risc_mem_write(struct dib9000_state
*state, u8 cmd, const u8
if (!state-platform.risc.fw_is_running)
return -EIO;
- DibAcquireLock(state-platform.risc.mem_lock);
+ if (DibAcquireLock(state-platform.risc.mem_lock) 0) {
+ dprintk(could not get the lock);
+ return -EINTR;
+ }
dib9000_risc_mem_setup(state, cmd);
dib9000_risc_mem_write_chunks(state, b, m-size);
DibReleaseLock(state-platform.risc.mem_lock);
@@ -531,7 +537,10 @@ static int dib9000_mbx_send_attr(struct dib9000_state
*state, u8 id, u16 * data,
if (!state-platform.risc.fw_is_running)
return -EINVAL;
- DibAcquireLock(state-platform.risc.mbx_if_lock);
+ if (DibAcquireLock(state-platform.risc.mbx_if_lock) 0) {
+ dprintk(could not get the lock);
+ return -EINTR;
+ }
tmp = MAX_MAILBOX_TRY;
do {
size = dib9000_read_word_attr(state, 1043, attr) 0xff;
@@ -593,7 +602,10 @@ static u8 dib9000_mbx_read(struct dib9000_state *state,
u16 * data, u8 risc_id,
if (!state-platform.risc.fw_is_running)
return 0;
- DibAcquireLock(state-platform.risc.mbx_if_lock);
+ if (DibAcquireLock(state-platform.risc.mbx_if_lock) 0) {
+ dprintk(could not get the lock);
+ return 0;
+ }
if (risc_id == 1)
mc_base = 16;
else
@@ -701,7 +713,10 @@ static int dib9000_mbx_process(struct dib9000_state
*state, u16 attr)
if (!state-platform.risc.fw_is_running)
return -1;
- DibAcquireLock(state-platform.risc.mbx_lock);
+ if (DibAcquireLock(state-platform.risc.mbx_lock) 0) {
+ dprintk(could not get the lock);
+ return -1;
+ }
if (dib9000_mbx_count(state, 1, attr)) /* 1=RiscB */
ret = dib9000_mbx_fetch_to_cache(state, attr);
@@ -1178,7 +1193,10 @@ static int dib9000_fw_get_channel(struct dvb_frontend
*fe)
struct dibDVBTChannel *ch;
int ret = 0;
- DibAcquireLock(state-platform.risc.mem_mbx_lock);
+ if (DibAcquireLock(state-platform.risc.mem_mbx_lock) 0) {
+ dprintk(could not get the lock);
+ return -EINTR;
+ }
if (dib9000_fw_memmbx_sync(state, FE_SYNC_CHANNEL) 0) {
ret = -EIO;
goto error;
@@ -1660,7 +1678,10 @@ static int dib9000_fw_component_bus_xfer(struct
i2c_adapter *i2c_adap, struct i2
p[12] = 0;
}
- DibAcquireLock(state-platform.risc.mem_mbx_lock);
+ if (DibAcquireLock(state-platform.risc.mem_mbx_lock) 0) {
+ dprintk(could not get the lock);
+ return 0;
+ }
dib9000_risc_mem_write(state, FE_MM_W_COMPONENT_ACCESS, p);
@@ -1768,7 +1789,10 @@ int dib9000_fw_pid_filter_ctrl(struct dvb_frontend
*fe, u8 onoff)
return 0;
}
- DibAcquireLock(state-demod_lock);
+ if (DibAcquireLock(state-demod_lock) 0) {
+
Re: [Q] ov7670: green line in VGA resolution
On Mon, 19 Mar 2012 17:27:06 +0100 javier Martin javier.mar...@vista-silicon.com wrote: I suspect the problem is related to the fact that this sensor has an array of 656 x 488 pixels but only 640 x 480 are active. The datasheet available from Omnivision (Version 1.4, August 21, 2006) is not clear about how to configure the sensor not to show non active pixels but I could find the following patch which addresses a similar problem for QVGA: Interesting...nobody ever sent that patch anywhere where I've seen it. Anyway, the ov7670 datasheet is not clear on much of anything, and the things it *is* clear on are likely to be wrong. The comment in the patch makes it clear how this was worked out, anyway: empirically determined. Unless you can get through to the one person at OmniVision who knows how this sensor actually works, the best that can be done is to mess with the values for the window. That's often done at both the sensor and the controller level - if you look at the Marvell controller, you'll see window tweaking there too. jon -- 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] dib0700: unlock mutexes on error paths
Em 07-03-2012 16:21, Alexey Khoroshilov escreveu:
dib0700_i2c_xfer [_new and _legacy] leave i2c_mutex locked on error paths.
The patch adds appropriate unlocks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/dvb/dvb-usb/dib0700_core.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 070e82a..8ec22c4 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -228,7 +228,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ break;
A break here doesn't sound the right thing to do.
}
st-buf[0] = REQUEST_NEW_I2C_WRITE;
st-buf[1] = msg[i].addr 1;
@@ -270,11 +270,14 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
struct dib0700_state *st = d-priv;
int i,len;
- if (mutex_lock_interruptible(d-i2c_mutex) 0)
+ if (mutex_lock_interruptible(d-i2c_mutex) 0) {
+ err(could not acquire lock);
return -EAGAIN;
+ }
if (mutex_lock_interruptible(d-usb_mutex) 0) {
+ mutex_unlock(d-i2c_mutex);
err(could not acquire lock);
- return 0;
+ return -EAGAIN;
}
for (i = 0; i num; i++) {
--
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
media_build: how can I test older drivers?
To find the responsible patch for a regression, I need to test older drivers. (1, 3 or 6 months ago) How can I do this with media_build? I don't really understand how the build script works. It seems that it doesn't use the current media_tree.git, but loads instead a driver snapshot (http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2) which is at the moment from March 9. Can I simply change the name of the link for the bz2-package in linux/Makefile? -- 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 FOR 3.4] rtl28xxu: dynamic USB ID support
DVB USB core refuses to load driver when current USB ID
does not match IDs on driver table. Due to that dynamic
IDs does not work. Replace reference design ID by dynamic
ID in .probe() in order to get it working.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/dvb-usb/rtl28xxu.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/rtl28xxu.c
b/drivers/media/dvb/dvb-usb/rtl28xxu.c
index 8f4736a..4e69e9d 100644
--- a/drivers/media/dvb/dvb-usb/rtl28xxu.c
+++ b/drivers/media/dvb/dvb-usb/rtl28xxu.c
@@ -909,6 +909,8 @@ static int rtl28xxu_probe(struct usb_interface *intf,
int ret, i;
int properties_count = ARRAY_SIZE(rtl28xxu_properties);
struct dvb_usb_device *d;
+ struct usb_device *udev;
+ bool found;
deb_info(%s: interface=%d\n, __func__,
intf-cur_altsetting-desc.bInterfaceNumber);
@@ -916,6 +918,29 @@ static int rtl28xxu_probe(struct usb_interface *intf,
if (intf-cur_altsetting-desc.bInterfaceNumber != 0)
return 0;
+ /* Dynamic USB ID support. Replaces first device ID with current one .*/
+ udev = interface_to_usbdev(intf);
+
+ for (i = 0, found = false; i ARRAY_SIZE(rtl28xxu_table) - 1; i++) {
+ if (rtl28xxu_table[i].idVendor ==
+ le16_to_cpu(udev-descriptor.idVendor)
+ rtl28xxu_table[i].idProduct ==
+ le16_to_cpu(udev-descriptor.idProduct)) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found) {
+ deb_info(%s: using dynamic ID %04x:%04x\n, __func__,
+ le16_to_cpu(udev-descriptor.idVendor),
+ le16_to_cpu(udev-descriptor.idProduct));
+ rtl28xxu_properties[0].devices[0].warm_ids[0]-idVendor =
+ le16_to_cpu(udev-descriptor.idVendor);
+ rtl28xxu_properties[0].devices[0].warm_ids[0]-idProduct =
+ le16_to_cpu(udev-descriptor.idProduct);
+ }
+
for (i = 0; i properties_count; i++) {
ret = dvb_usb_device_init(intf, rtl28xxu_properties[i],
THIS_MODULE, d, adapter_nr);
--
1.7.7.6
--
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] dib0700: unlock mutexes on error paths
On Mon, 19 Mar 2012 14:47:54 -0300, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 07-03-2012 16:21, Alexey Khoroshilov escreveu:
dib0700_i2c_xfer [_new and _legacy] leave i2c_mutex locked on error
paths.
The patch adds appropriate unlocks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/dvb/dvb-usb/dib0700_core.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 070e82a..8ec22c4 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -228,7 +228,7 @@ static int dib0700_i2c_xfer_new(struct
i2c_adapter *adap, struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ break;
A break here doesn't sound the right thing to do.
I am sorry, but I did not catch the issue.
The break is almost equivalent to another one a few lines below that
happens when usb_control_msg() fails.
Could you please clarify the problem?
--
Alexey
--
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] dib9000: get rid of Dib*Lock macros
The patch replaces Dib*Lock macros with direct calls to mutex functions
as soon as they just make the driver code harder to review
(per request of Mauro).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/dvb/frontends/dib9000.c | 128 +++--
1 files changed, 58 insertions(+), 70 deletions(-)
diff --git a/drivers/media/dvb/frontends/dib9000.c
b/drivers/media/dvb/frontends/dib9000.c
index 80848b4..953102f 100644
--- a/drivers/media/dvb/frontends/dib9000.c
+++ b/drivers/media/dvb/frontends/dib9000.c
@@ -31,13 +31,6 @@ struct i2c_device {
u8 *i2c_write_buffer;
};
-/* lock */
-#define DIB_LOCK struct mutex
-#define DibAcquireLock(lock) mutex_lock_interruptible(lock)
-#define DibReleaseLock(lock) mutex_unlock(lock)
-#define DibInitLock(lock) mutex_init(lock)
-#define DibFreeLock(lock)
-
struct dib9000_pid_ctrl {
#define DIB9000_PID_FILTER_CTRL 0
#define DIB9000_PID_FILTER 1
@@ -82,11 +75,11 @@ struct dib9000_state {
} fe_mm[18];
u8 memcmd;
- DIB_LOCK mbx_if_lock; /* to protect read/write
operations */
- DIB_LOCK mbx_lock; /* to protect the whole mailbox
handling */
+ struct mutex mbx_if_lock; /* to protect
read/write operations */
+ struct mutex mbx_lock; /* to protect the whole mailbox
handling */
- DIB_LOCK mem_lock; /* to protect the memory
accesses */
- DIB_LOCK mem_mbx_lock; /* to protect the memory-based
mailbox */
+ struct mutex mem_lock; /* to protect the memory
accesses */
+ struct mutex mem_mbx_lock; /* to protect the
memory-based mailbox */
#define MBX_MAX_WORDS (256 - 200 - 2)
#define DIB9000_MSG_CACHE_SIZE 2
@@ -108,7 +101,7 @@ struct dib9000_state {
struct i2c_msg msg[2];
u8 i2c_write_buffer[255];
u8 i2c_read_buffer[255];
- DIB_LOCK demod_lock;
+ struct mutex demod_lock;
u8 get_frontend_internal;
struct dib9000_pid_ctrl pid_ctrl[10];
s8 pid_ctrl_index; /* -1: empty list; -2: do not use the list */
@@ -446,13 +439,13 @@ static int dib9000_risc_mem_read(struct dib9000_state
*state, u8 cmd, u8 * b, u1
if (!state-platform.risc.fw_is_running)
return -EIO;
- if (DibAcquireLock(state-platform.risc.mem_lock) 0) {
+ if (mutex_lock_interruptible(state-platform.risc.mem_lock) 0) {
dprintk(could not get the lock);
return -EINTR;
}
dib9000_risc_mem_setup(state, cmd | 0x80);
dib9000_risc_mem_read_chunks(state, b, len);
- DibReleaseLock(state-platform.risc.mem_lock);
+ mutex_unlock(state-platform.risc.mem_lock);
return 0;
}
@@ -462,13 +455,13 @@ static int dib9000_risc_mem_write(struct dib9000_state
*state, u8 cmd, const u8
if (!state-platform.risc.fw_is_running)
return -EIO;
- if (DibAcquireLock(state-platform.risc.mem_lock) 0) {
+ if (mutex_lock_interruptible(state-platform.risc.mem_lock) 0) {
dprintk(could not get the lock);
return -EINTR;
}
dib9000_risc_mem_setup(state, cmd);
dib9000_risc_mem_write_chunks(state, b, m-size);
- DibReleaseLock(state-platform.risc.mem_lock);
+ mutex_unlock(state-platform.risc.mem_lock);
return 0;
}
@@ -537,7 +530,7 @@ static int dib9000_mbx_send_attr(struct dib9000_state
*state, u8 id, u16 * data,
if (!state-platform.risc.fw_is_running)
return -EINVAL;
- if (DibAcquireLock(state-platform.risc.mbx_if_lock) 0) {
+ if (mutex_lock_interruptible(state-platform.risc.mbx_if_lock) 0) {
dprintk(could not get the lock);
return -EINTR;
}
@@ -584,7 +577,7 @@ static int dib9000_mbx_send_attr(struct dib9000_state
*state, u8 id, u16 * data,
ret = (u8) dib9000_write_word_attr(state, 1043, 1 14, attr);
out:
- DibReleaseLock(state-platform.risc.mbx_if_lock);
+ mutex_unlock(state-platform.risc.mbx_if_lock);
return ret;
}
@@ -602,7 +595,7 @@ static u8 dib9000_mbx_read(struct dib9000_state *state, u16
* data, u8 risc_id,
if (!state-platform.risc.fw_is_running)
return 0;
- if (DibAcquireLock(state-platform.risc.mbx_if_lock) 0) {
+ if (mutex_lock_interruptible(state-platform.risc.mbx_if_lock) 0) {
dprintk(could not get the lock);
return 0;
}
@@ -643,7 +636,7 @@ static u8 dib9000_mbx_read(struct dib9000_state *state, u16
* data, u8 risc_id,
/* Update register nb_mes_in_TX */
dib9000_write_word_attr(state, 1028 + mc_base, 1 14, attr);
- DibReleaseLock(state-platform.risc.mbx_if_lock);
+ mutex_unlock(state-platform.risc.mbx_if_lock);
Re: nuvoton-cir on Intel DH67CL
On Wed, Mar 14, 2012 at 10:32:43PM +0100, Steffen Barszus wrote: On Wed, 14 Mar 2012 16:41:01 -0400 Jarod Wilson ja...@redhat.com wrote: On Wed, Mar 14, 2012 at 07:10:37AM +0100, Steffen Barszus wrote: Hi ! I'm using above board which has a nuvoton-cir onboard (as most Intel Media boards) - It shows itself as NTN0530. The remote function works without a problem (loaded RC6 MCE keytable). What doesn't work is wake from S3 and wake from S5. There are some rumors that installing Windows 7 and corresponding drivers has a positive effect (for some it seems to be enough to do it one time, others need to redo this from time to time (power loss?). This leads me to believe, that some hardware initialization is missing. I'm about to try latest linux-media tree next days, but i believe there hasn't been any change on this driver. My questions: - any idea of what i should look at ? - any change on the driver i could try ? - *IF* i go to install Win7 and drivers - anything i could to to help tracking down what this does in order to make the driver work out of the box on linux ? As a lot of Sandy Bridge Boards to have this chip lately - it would be nice if this could just work or is my impression, that this is a general problem in this hardware wrong ? My only nuvoton hardware works perfectly w/resume via IR after commit 3198ed161c9be9bbd15bb2e9c22561248cac6e6a, but its possible what you've got is a newer hardware variant with some slightly different registers to tweak. What does the driver identify your chip as in dmesg? I'm on Linux 3.2.0-18-generic #29-Ubuntu SMP (Ubuntu Precise) As of commit 362d3a3a9592598cef1d3e211ad998eb844dc5f3, the driver will bind to anything with the PNP ID of NTN0530, but will spew a warning in dmesg if its not an explicitly recognized chip. From dmesg it seems to be fine. [0.553258] system 00:02: [io 0x0290-0x029f] has been reserved [0.553261] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active) [0.553504] pnp 00:03: [io 0x0240-0x024f] [0.553513] pnp 00:03: [irq 3] [0.553515] pnp 00:03: [io 0x0250-0x025f] [0.553534] pnp 00:03: Plug and Play ACPI device, IDs NTN0530 (active) [0.553544] pnp 00:04: [dma 4] [0.553545] pnp 00:04: [io 0x-0x000f] [0.553547] pnp 00:04: [io 0x0081-0x0083] [0.553549] pnp 00:04: [io 0x0087] [0.553550] pnp 00:04: [io 0x0089-0x008b] [0.553552] pnp 00:04: [io 0x008f] [0.553553] pnp 00:04: [io 0x00c0-0x00df] Anything to be activated to wakeup on S3/S5 ? I.e. the key to wake it up ? I'm using RC6 remote - operation as already said is without any issues, just not wakeup. It occurs to me that the box I've got had Windows on it at one point, and its possible wake via IR works only because someone set a wake key pattern under Windows. And that your box doesn't wake, because it hasn't had a wake key pattern set yet. We don't have any UI for setting a wake key pattern just yet... (Or if we do, I'm just not familiar with it). -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement
From: Rob Clark r...@ti.com Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. Signed-off-by: Rob Clark r...@ti.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- Updated version of Daniel's original documentation patch with (hopefully) improved wording, and a better description of the motivation. Documentation/dma-buf-sharing.txt | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 225f96d..3b51134 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -223,6 +223,24 @@ Miscellaneous notes: - Any exporters or users of the dma-buf buffer sharing framework must have a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. +- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set + on the file descriptor. This is not just a resource leak, but a + potential security hole. It could give the newly exec'd application + access to buffers, via the leaked fd, to which it should otherwise + not be permitted access. + + The problem with doing this via a separate fcntl() call, versus doing it + atomically when the fd is created, is that this is inherently racy in a + multi-threaded app[3]. The issue is made worse when it is library code + opening/creating the file descriptor, as the application may not even be + aware of the fd's. + + To avoid this problem, userspace must have a way to request O_CLOEXEC + flag be set when the dma-buf fd is created. So any API provided by + the exporting driver to create a dmabuf fd must provide a way to let + userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). + References: [1] struct dma_buf_ops in include/linux/dma-buf.h [2] All interfaces mentioned above defined in include/linux/dma-buf.h +[3] https://lwn.net/Articles/236486/ -- 1.7.5.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: [GIT PULL FOR v3.4] V4L2 subdev and sensor control changes and SMIA++ driver
Em 11-03-2012 13:56, Sakari Ailus escreveu: Hi Mauro, This patchset adds - Integer menu controls, - Selection IOCTL for subdevs, - Sensor control improvements, - link_validate() media entity and V4L2 subdev pad ops, - OMAP 3 ISP driver improvements, - SMIA++ sensor driver and - Other V4L2 and media improvements (see individual patches) The previous patchset can be found here: URL:http://www.spinics.net/lists/linux-media/msg45052.html Compared to the patchset, I've dropped the rm-696 camera board code and will submit it through linux-omap later on. Other changes done to address review comments have been also done --- see the URL above for details. The following changes since commit 632fba4d012458fd5fedc678fb9b0f8bc59ceda2: [media] cx25821: Add a card definition for No brand cards that have: subvendor = 0x subdevice = 0x (2012-03-08 12:42:28 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.4 Jesper Juhl (1): adp1653: Remove unneeded include of version.h Laurent Pinchart (3): omap3isp: Prevent pipelines that contain a crashed entity from starting omap3isp: Fix crash caused by subdevs now having a pointer to devnodes omap3isp: Fix frame number propagation Sakari Ailus (37): v4l: Introduce integer menu controls v4l: Document integer menu controls vivi: Add an integer menu test control v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs v4l: vdev_to_v4l2_subdev() should have return type struct v4l2_subdev * v4l: Check pad number in get try pointer functions v4l: Support s_crop and g_crop through s/g_selection v4l: Add subdev selections documentation: svg and dia files v4l: Add subdev selections documentation This patch broke docbook compilation: HTMLDocumentation/DocBook/media_api.html warning: failed to load external entity /home/v4l/v4l/patchwork/Documentation/DocBook/vidioc-subdev-g-selection.xml /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser error : Failure to process entity sub-subdev-g-selection size configured using sub-subdev-g-selection; and ^ /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser error : Entity 'sub-subdev-g-selection' not defined size configured using sub-subdev-g-selection; and ^ /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:468: parser error : chunk is not well balanced ^ /home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : Failure to process entity sub-dev-subdev section id=subdev sub-dev-subdev; /section ^ /home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : Entity 'sub-dev-subdev' not defined section id=subdev sub-dev-subdev; /section ^ /usr/bin/xmlto: line 568: 3232 Segmentation fault /usr/bin/xsltproc --nonet --xinclude --param passivetex.extensions '1' -o /tmp/xmlto.J0M0go/media_api.proc /tmp/xmlto-xsl.GKa5kH /home/v4l/v4l/patchwork/Documentation/DocBook/media_api.xml /bin/cp: cannot stat `*.*htm*': No such file or directory make[1]: *** [Documentation/DocBook/media_api.html] Error 1 make: *** [htmldocs] Error 2 Please fix. Regards, Mauro v4l: Mark VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP obsolete v4l: Image source control class v4l: Image processing control class v4l: Document raw bayer 4CC codes v4l: Add DPCM compressed raw bayer pixel formats media: Add link_validate() op to check links to the sink pad v4l: Improve sub-device documentation for pad ops v4l: Implement v4l2_subdev_link_validate() v4l: Allow changing control handler lock omap3isp: Support additional in-memory compressed bayer formats omap3isp: Move definitions required by board code under include/media. omap3: add definition for CONTROL_CAMERA_PHY_CTRL omap3isp: Move setting constaints above media_entity_pipeline_start omap3isp: Assume media_entity_pipeline_start may fail omap3isp: Add lane configuration to platform data omap3isp: Collect entities that are part of the pipeline omap3isp: Add information on external subdev to struct isp_pipeline omap3isp: Introduce isp_video_check_external_subdevs() omap3isp: Use external rate instead of vpcfg omap3isp: Default link validation for ccp2, csi2, preview and resizer omap3isp: Move CCDC link validation to ccdc_link_validate() omap3isp: Configure CSI-2 phy based on platform data omap3isp: Add resizer data rate configuration to resizer_link_validate omap3isp: Find source pad from external entity smiapp: Generic SMIA++/SMIA PLL calculator
Re: [PATCH v1] i.MX35-PDK: Add Camera support
Em 13-03-2012 12:05, Alex Gershgorin escreveu:
In i.MX35-PDK, OV2640 camera is populated on the
personality board. This camera is registered as a subdevice via soc-camera
interface.
Signed-off-by: Alex Gershgorin al...@meprolight.com
Patch doesn't apply over v3.3:
patching file arch/arm/mach-imx/mach-mx35_3ds.c
Hunk #3 FAILED at 149.
Hunk #4 succeeded at 126 with fuzz 1 (offset -55 lines).
Hunk #5 FAILED at 323.
Hunk #6 succeeded at 277 (offset -57 lines).
Hunk #7 succeeded at 293 (offset -57 lines).
2 out of 7 hunks FAILED -- saving rejects to file
arch/arm/mach-imx/mach-mx35_3ds.c.rej
arch/arm/mach-imx/mach-mx35_3ds.c | 87 ++
---
arch/arm/mach-imx/mach-mx35_3ds.c | 96
+
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c
b/arch/arm/mach-imx/mach-mx35_3ds.c
index 0af6c9c..a7dd8e6 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -4,6 +4,11 @@
*
* Author: Fabio Estevam fabio.este...@freescale.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
+ * Modified from i.MX31 3-Stack Development System
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -34,6 +39,7 @@
#include asm/mach/arch.h
#include asm/mach/time.h
#include asm/mach/map.h
+#include asm/memblock.h
#include mach/hardware.h
#include mach/common.h
@@ -41,6 +47,8 @@
#include mach/irqs.h
#include mach/3ds_debugboard.h
+#include media/soc_camera.h
+
#include devices-imx35.h
#define EXPIO_PARENT_INT gpio_to_irq(IMX_GPIO_NR(1, 1))
@@ -120,6 +128,83 @@ static iomux_v3_cfg_t mx35pdk_pads[] = {
/* I2C1 */
MX35_PAD_I2C1_CLK__I2C1_SCL,
MX35_PAD_I2C1_DAT__I2C1_SDA,
+ /* CSI */
+ MX35_PAD_TX1__IPU_CSI_D_6,
+ MX35_PAD_TX0__IPU_CSI_D_7,
+ MX35_PAD_CSI_D8__IPU_CSI_D_8,
+ MX35_PAD_CSI_D9__IPU_CSI_D_9,
+ MX35_PAD_CSI_D10__IPU_CSI_D_10,
+ MX35_PAD_CSI_D11__IPU_CSI_D_11,
+ MX35_PAD_CSI_D12__IPU_CSI_D_12,
+ MX35_PAD_CSI_D13__IPU_CSI_D_13,
+ MX35_PAD_CSI_D14__IPU_CSI_D_14,
+ MX35_PAD_CSI_D15__IPU_CSI_D_15,
+ MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC,
+ MX35_PAD_CSI_MCLK__IPU_CSI_MCLK,
+ MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK,
+ MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC,
+};
+
+/*
+ * Camera support
+*/
+static phys_addr_t mx3_camera_base __initdata;
+#define MX35_3DS_CAMERA_BUF_SIZE SZ_8M
+
+static const struct mx3_camera_pdata mx35_3ds_camera_pdata __initconst = {
+ .flags = MX3_CAMERA_DATAWIDTH_8,
+ .mclk_10khz = 2000,
+};
+
+static int __init imx35_3ds_init_camera(void)
+{
+ int dma, ret = -ENOMEM;
+ struct platform_device *pdev =
+ imx35_alloc_mx3_camera(mx35_3ds_camera_pdata);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ if (!mx3_camera_base)
+ goto err;
+
+ dma = dma_declare_coherent_memory(pdev-dev,
+ mx3_camera_base, mx3_camera_base,
+ MX35_3DS_CAMERA_BUF_SIZE,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+
+ if (!(dma DMA_MEMORY_MAP))
+ goto err;
+
+ ret = platform_device_add(pdev);
+ if (ret)
+err:
+ platform_device_put(pdev);
+
+ return ret;
+}
+
+static const struct ipu_platform_data mx35_3ds_ipu_data __initconst = {
+ .irq_base = MXC_IPU_IRQ_START,
+};
+
+static struct i2c_board_info mx35_3ds_i2c_camera = {
+ I2C_BOARD_INFO(ov2640, 0x30),
+};
+
+static struct soc_camera_link iclink_ov2640 = {
+ .bus_id = 0,
+ .board_info = mx35_3ds_i2c_camera,
+ .i2c_adapter_id = 0,
+ .power = NULL,
+};
+
+static struct platform_device mx35_3ds_ov2640 = {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
+ .platform_data = iclink_ov2640,
+ },
};
static int mx35_3ds_otg_init(struct platform_device *pdev)
@@ -204,6 +289,9 @@ static void __init mx35_3ds_init(void)
pr_warn(Init of the debugboard failed, all
devices on the debugboard are unusable.\n);
imx35_add_imx_i2c0(mx35_3ds_i2c0_data);
+ imx35_add_ipu_core(mx35_3ds_ipu_data);
+ platform_device_register(mx35_3ds_ov2640);
+ imx35_3ds_init_camera();
}
static void __init mx35pdk_timer_init(void)
@@ -215,6 +303,13 @@ struct sys_timer mx35pdk_timer = {
.init = mx35pdk_timer_init,
};
+static void __init mx35_3ds_reserve(void)
+{
+ /* reserve MX35_3DS_CAMERA_BUF_SIZE bytes for mx3-camera */
+ mx3_camera_base =
Re: A second easycap driver implementation
Hi Mauro,
On 3/7/12, Mauro Carvalho Chehab mche...@redhat.com wrote:
The usage of saa711x is simple. All you need to do is to implement
an I2C bus at your easycap driver, load the module, and then, redirect
any demod ioctl call to the I2C bus, like:
static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *norm)
{
struct em28xx_fh *fh = priv;
struct em28xx *dev = fh-dev;
intrc;
rc = check_dev(dev);
if (rc 0)
return rc;
v4l2_device_call_all(dev-v4l2_dev, 0, video, querystd, norm);
return 0;
}
An I2C device has an address that needs to be send through the I2C
bus.
The saa711x devices use one of the I2C addresses below:
static unsigned short saa711x_addrs[] = {
0x4a 1, 0x48 1, /* SAA7111, SAA7111A and SAA7113 */
0x42 1, 0x40 1, /* SAA7114, SAA7115 and SAA7118 */
I2C_CLIENT_END };
I made my easycap driver use saa7115 driver to detect its saa7113 chip.
It wasn't so hard after some head scratching.
The problem is now modprobe is taking too long, mainly because saa7115 does
some probing.
I was thinking (since we already discussed deferring stuff to a workqueue):
Would it be problematic (in any fashion) to do add the i2c sub device
v4l2_i2c_new_subdev(dev-v4l2_dev, dev-i2c_adap,
saa7115_auto, 0, saa711x_addrs);
in a workqueue, (in the same way modules are loaded in workqueues)?
I think not, since we won't call i2c directly, but rather through
v4l2_device_call_all(), right?
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 RESEND] usb: gadget/uvc: Remove non-required locking from 'uvc_queue_next_buffer' routine
Em 19-03-2012 00:58, Bhupesh SHARMA escreveu: Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Thursday, March 15, 2012 6:17 AM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org; spear-devel Subject: Re: [PATCH RESEND] usb: gadget/uvc: Remove non-required locking from 'uvc_queue_next_buffer' routine Hi Bhupesh, Thank you for the patch. ... This should probably go in through the USB tree. ... For sure, as this stuff doesn't belong to drivers/media ;) 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 v1] i.MX35-PDK: Add Camera support
Em 19-03-2012 19:03, Mauro Carvalho Chehab escreveu:
Em 13-03-2012 12:05, Alex Gershgorin escreveu:
In i.MX35-PDK, OV2640 camera is populated on the
personality board. This camera is registered as a subdevice via soc-camera
interface.
Signed-off-by: Alex Gershgorin al...@meprolight.com
Patch doesn't apply over v3.3:
Sorry, the previous version of this patch didn't apply. This compiles OK.
Sorry for the mess.
Anyway, it should be applied via arm subtree.
Regards,
Mauro
patching file arch/arm/mach-imx/mach-mx35_3ds.c
Hunk #3 FAILED at 149.
Hunk #4 succeeded at 126 with fuzz 1 (offset -55 lines).
Hunk #5 FAILED at 323.
Hunk #6 succeeded at 277 (offset -57 lines).
Hunk #7 succeeded at 293 (offset -57 lines).
2 out of 7 hunks FAILED -- saving rejects to file
arch/arm/mach-imx/mach-mx35_3ds.c.rej
arch/arm/mach-imx/mach-mx35_3ds.c | 87
++
---
arch/arm/mach-imx/mach-mx35_3ds.c | 96
+
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c
b/arch/arm/mach-imx/mach-mx35_3ds.c
index 0af6c9c..a7dd8e6 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -4,6 +4,11 @@
*
* Author: Fabio Estevam fabio.este...@freescale.com
*
+ * Copyright (C) 2011 Meprolight, Ltd.
+ * Alex Gershgorin al...@meprolight.com
+ *
+ * Modified from i.MX31 3-Stack Development System
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -34,6 +39,7 @@
#include asm/mach/arch.h
#include asm/mach/time.h
#include asm/mach/map.h
+#include asm/memblock.h
#include mach/hardware.h
#include mach/common.h
@@ -41,6 +47,8 @@
#include mach/irqs.h
#include mach/3ds_debugboard.h
+#include media/soc_camera.h
+
#include devices-imx35.h
#define EXPIO_PARENT_INTgpio_to_irq(IMX_GPIO_NR(1, 1))
@@ -120,6 +128,83 @@ static iomux_v3_cfg_t mx35pdk_pads[] = {
/* I2C1 */
MX35_PAD_I2C1_CLK__I2C1_SCL,
MX35_PAD_I2C1_DAT__I2C1_SDA,
+/* CSI */
+MX35_PAD_TX1__IPU_CSI_D_6,
+MX35_PAD_TX0__IPU_CSI_D_7,
+MX35_PAD_CSI_D8__IPU_CSI_D_8,
+MX35_PAD_CSI_D9__IPU_CSI_D_9,
+MX35_PAD_CSI_D10__IPU_CSI_D_10,
+MX35_PAD_CSI_D11__IPU_CSI_D_11,
+MX35_PAD_CSI_D12__IPU_CSI_D_12,
+MX35_PAD_CSI_D13__IPU_CSI_D_13,
+MX35_PAD_CSI_D14__IPU_CSI_D_14,
+MX35_PAD_CSI_D15__IPU_CSI_D_15,
+MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC,
+MX35_PAD_CSI_MCLK__IPU_CSI_MCLK,
+MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK,
+MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC,
+};
+
+/*
+ * Camera support
+*/
+static phys_addr_t mx3_camera_base __initdata;
+#define MX35_3DS_CAMERA_BUF_SIZE SZ_8M
+
+static const struct mx3_camera_pdata mx35_3ds_camera_pdata __initconst = {
+.flags = MX3_CAMERA_DATAWIDTH_8,
+.mclk_10khz = 2000,
+};
+
+static int __init imx35_3ds_init_camera(void)
+{
+int dma, ret = -ENOMEM;
+struct platform_device *pdev =
+imx35_alloc_mx3_camera(mx35_3ds_camera_pdata);
+
+if (IS_ERR(pdev))
+return PTR_ERR(pdev);
+
+if (!mx3_camera_base)
+goto err;
+
+dma = dma_declare_coherent_memory(pdev-dev,
+mx3_camera_base, mx3_camera_base,
+MX35_3DS_CAMERA_BUF_SIZE,
+DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+
+if (!(dma DMA_MEMORY_MAP))
+goto err;
+
+ret = platform_device_add(pdev);
+if (ret)
+err:
+platform_device_put(pdev);
+
+return ret;
+}
+
+static const struct ipu_platform_data mx35_3ds_ipu_data __initconst = {
+.irq_base = MXC_IPU_IRQ_START,
+};
+
+static struct i2c_board_info mx35_3ds_i2c_camera = {
+I2C_BOARD_INFO(ov2640, 0x30),
+};
+
+static struct soc_camera_link iclink_ov2640 = {
+.bus_id = 0,
+.board_info = mx35_3ds_i2c_camera,
+.i2c_adapter_id = 0,
+.power = NULL,
+};
+
+static struct platform_device mx35_3ds_ov2640 = {
+.name = soc-camera-pdrv,
+.id = 0,
+.dev= {
+.platform_data = iclink_ov2640,
+},
};
static int mx35_3ds_otg_init(struct platform_device *pdev)
@@ -204,6 +289,9 @@ static void __init mx35_3ds_init(void)
pr_warn(Init of the debugboard failed, all
devices on the debugboard are unusable.\n);
imx35_add_imx_i2c0(mx35_3ds_i2c0_data);
+imx35_add_ipu_core(mx35_3ds_ipu_data);
+platform_device_register(mx35_3ds_ov2640);
+imx35_3ds_init_camera();
}
static void __init mx35pdk_timer_init(void)
@@ -215,6 +303,13 @@ struct sys_timer mx35pdk_timer = {
.init = mx35pdk_timer_init,
};
Re: [PATCH 1/2] [media] dib0700: Drop useless check when remote key is pressed
Em 13-03-2012 14:57, Devin Heitmueller escreveu: On Tue, Mar 13, 2012 at 1:50 PM, Jean Delvare kh...@linux-fr.org wrote: struct dvb_usb_device *d can never be NULL so don't waste time checking for this. Rationale: the urb's context is set when usb_fill_bulk_urb() is called in dib0700_rc_setup(), and never changes after that. d is dereferenced unconditionally in dib0700_rc_setup() so it can't be NULL or the driver would crash right away. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Devin Heitmueller dheitmuel...@kernellabs.com --- Devin, am I missing something? I think this was just a case of defensive coding where I didn't want to dereference something without validating the pointer first (out of fear that it got called through some other code path that I didn't consider). --- linux-3.3-rc7.orig/drivers/media/dvb/dvb-usb/dib0700_core.c 2012-03-13 11:09:13.0 +0100 +++ linux-3.3-rc7/drivers/media/dvb/dvb-usb/dib0700_core.c 2012-03-13 18:37:05.785953845 +0100 @@ -677,9 +677,6 @@ static void dib0700_rc_urb_completion(st u8 toggle; deb_info(%s()\n, __func__); -if (d == NULL) -return; - Well, usb_free_urb() is not called when d == NULL, so, if this condition ever happens, it will keep URB's allocated. Anyway, if struct dvb_usb_device *d is NULL, the driver has something very wrong happening on it, and nothing will work on it. I agree with Jean: it is better to just remove this code there. Yet, I'd be more happy if Jean's patch could check first if the status is below 0, in order to prevent a possible race condition at device disconnect. 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: A second easycap driver implementation
Em 19-03-2012 19:05, Ezequiel García escreveu:
Hi Mauro,
On 3/7/12, Mauro Carvalho Chehab mche...@redhat.com wrote:
The usage of saa711x is simple. All you need to do is to implement
an I2C bus at your easycap driver, load the module, and then, redirect
any demod ioctl call to the I2C bus, like:
static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *norm)
{
struct em28xx_fh *fh = priv;
struct em28xx *dev = fh-dev;
intrc;
rc = check_dev(dev);
if (rc 0)
return rc;
v4l2_device_call_all(dev-v4l2_dev, 0, video, querystd, norm);
return 0;
}
An I2C device has an address that needs to be send through the I2C
bus.
The saa711x devices use one of the I2C addresses below:
static unsigned short saa711x_addrs[] = {
0x4a 1, 0x48 1, /* SAA7111, SAA7111A and SAA7113 */
0x42 1, 0x40 1, /* SAA7114, SAA7115 and SAA7118 */
I2C_CLIENT_END };
I made my easycap driver use saa7115 driver to detect its saa7113 chip.
It wasn't so hard after some head scratching.
Good!
The problem is now modprobe is taking too long, mainly because saa7115 does
some probing.
I was thinking (since we already discussed deferring stuff to a workqueue):
Would it be problematic (in any fashion) to do add the i2c sub device
v4l2_i2c_new_subdev(dev-v4l2_dev, dev-i2c_adap,
saa7115_auto, 0, saa711x_addrs);
in a workqueue, (in the same way modules are loaded in workqueues)?
I think not, since we won't call i2c directly, but rather through
v4l2_device_call_all(), right?
It would likely work. I would add some locking maybe at open or at ioctl
level, to prevent calling the device while the init doesn't finish.
Regards,
Mauro
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 v1] i.MX35-PDK: Add Camera support
On Mon, Mar 19, 2012 at 07:17:27PM -0300, Mauro Carvalho Chehab wrote: Em 19-03-2012 19:03, Mauro Carvalho Chehab escreveu: Em 13-03-2012 12:05, Alex Gershgorin escreveu: In i.MX35-PDK, OV2640 camera is populated on the personality board. This camera is registered as a subdevice via soc-camera interface. Signed-off-by: Alex Gershgorin al...@meprolight.com Patch doesn't apply over v3.3: Sorry, the previous version of this patch didn't apply. This compiles OK. Sorry for the mess. Anyway, it should be applied via arm subtree. It's scheduled there. I should have responded with an applied message. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v1] i.MX35-PDK: Add Camera support
Hi Sascha, On Mon, Mar 19, 2012 at 7:37 PM, Sascha Hauer s.ha...@pengutronix.de wrote: It's scheduled there. I should have responded with an applied message. Please apply this one too: http://patchwork.ozlabs.org/patch/144942/ Otherwise camera device cannot register. -- 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 v1] i.MX35-PDK: Add Camera support
On Mon, Mar 19, 2012 at 07:43:32PM -0300, Fabio Estevam wrote: Hi Sascha, On Mon, Mar 19, 2012 at 7:37 PM, Sascha Hauer s.ha...@pengutronix.de wrote: It's scheduled there. I should have responded with an applied message. Please apply this one too: http://patchwork.ozlabs.org/patch/144942/ Will do. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: media_build: how can I test older drivers?
Em 19-03-2012 15:18, Martin Dauskardt escreveu: To find the responsible patch for a regression, I need to test older drivers. (1, 3 or 6 months ago) How can I do this with media_build? I don't really understand how the build script works. It seems that it doesn't use the current media_tree.git, but loads instead a driver snapshot (http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2) which is at the moment from March 9. In a matter of fact, it supports several different modes of work. The default one is to download a tarball. If you use: $ ./build.sh --main-git it will download a copy of the main tree, and compile using it as a reference. Yet, bisecting is not trivial. You'll need to run git bisect under the subdir where the tree was copied. Also, the compilation may fail, due to the backport patches, that won't be synchronized, especially if you're using an old Kernel that requires lots of backport patches to compile/work, as the backport patches always consider the very latest version of the media_tree. If you want to bisect, it is likely easier to clone the media_tree and bisect on it directly. Can I simply change the name of the link for the bz2-package in linux/Makefile? 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
[PATCH] dma-buf: add support for kernel cpu access
Big differences to other contenders in the field (like ion) is
that this also supports highmem, so we have to split up the cpu
access from the kernel side into a prepare and a kmap step.
Prepare is allowed to fail and should do everything required so that
the kmap calls can succeed (like swapin/backing storage allocation,
flushing, ...).
More in-depth explanations will follow in the follow-up documentation
patch.
Changes in v2:
- Clear up begin_cpu_access confusion noticed by Sumit Semwal.
- Don't automatically fallback from the _atomic variants to the
non-atomic variants. The _atomic callbacks are not allowed to
sleep, so we want exporters to make this decision explicit. The
function signatures are explicit, so simpler exporters can still
use the same function for both.
- Make the unmap functions optional. Simpler exporters with permanent
mappings don't need to do anything at unmap time.
Changes in v3:
- Adjust the WARN_ON checks for the new -ops functions as suggested
by Rob Clark and Sumit Semwal.
- Rebased on top of latest dma-buf-next git.
Changes in v4:
- Fixup a missing - in a return -EINVAL; statement.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/base/dma-buf.c | 124 ++-
include/linux/dma-buf.h | 59 ++
2 files changed, 182 insertions(+), 1 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 5641b9c..07cbbc6 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -80,7 +80,9 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
if (WARN_ON(!priv || !ops
|| !ops-map_dma_buf
|| !ops-unmap_dma_buf
- || !ops-release)) {
+ || !ops-release
+ || !ops-kmap_atomic
+ || !ops-kmap)) {
return ERR_PTR(-EINVAL);
}
@@ -284,3 +286,123 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
direction);
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
+
+
+/**
+ * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from
the
+ * cpu in the kernel context. Calls begin_cpu_access to allow exporter-specific
+ * preparations. Coherency is only guaranteed in the specified range for the
+ * specified access direction.
+ * @dma_buf: [in]buffer to prepare cpu access for.
+ * @start: [in]start of range for cpu access.
+ * @len: [in]length of range for cpu access.
+ * @direction: [in]length of range for cpu access.
+ *
+ * Can return negative error values, returns 0 on success.
+ */
+int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
+enum dma_data_direction direction)
+{
+ int ret = 0;
+
+ if (WARN_ON(!dmabuf))
+ return -EINVAL;
+
+ if (dmabuf-ops-begin_cpu_access)
+ ret = dmabuf-ops-begin_cpu_access(dmabuf, start, len,
direction);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
+
+/**
+ * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the
+ * cpu in the kernel context. Calls end_cpu_access to allow exporter-specific
+ * actions. Coherency is only guaranteed in the specified range for the
+ * specified access direction.
+ * @dma_buf: [in]buffer to complete cpu access for.
+ * @start: [in]start of range for cpu access.
+ * @len: [in]length of range for cpu access.
+ * @direction: [in]length of range for cpu access.
+ *
+ * This call must always succeed.
+ */
+void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
+ enum dma_data_direction direction)
+{
+ WARN_ON(!dmabuf);
+
+ if (dmabuf-ops-end_cpu_access)
+ dmabuf-ops-end_cpu_access(dmabuf, start, len, direction);
+}
+EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
+
+/**
+ * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address
+ * space. The same restrictions as for kmap_atomic and friends apply.
+ * @dma_buf: [in]buffer to map page from.
+ * @page_num: [in]page in PAGE_SIZE units to map.
+ *
+ * This call must always succeed, any necessary preparations that might fail
+ * need to be done in begin_cpu_access.
+ */
+void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num)
+{
+ WARN_ON(!dmabuf);
+
+ return dmabuf-ops-kmap_atomic(dmabuf, page_num);
+}
+EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
+
+/**
+ * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
+ * @dma_buf: [in]buffer to unmap page from.
+ * @page_num: [in]page in PAGE_SIZE units to unmap.
+ * @vaddr: [in]kernel space pointer obtained from dma_buf_kmap_atomic.
+ *
+ * This call must always succeed.
+ */
+void
Re: [PATCH v1] i.MX35-PDK: Add Camera support
Em 19-03-2012 19:37, Sascha Hauer escreveu: On Mon, Mar 19, 2012 at 07:17:27PM -0300, Mauro Carvalho Chehab wrote: Em 19-03-2012 19:03, Mauro Carvalho Chehab escreveu: Em 13-03-2012 12:05, Alex Gershgorin escreveu: In i.MX35-PDK, OV2640 camera is populated on the personality board. This camera is registered as a subdevice via soc-camera interface. Signed-off-by: Alex Gershgorin al...@meprolight.com Patch doesn't apply over v3.3: Sorry, the previous version of this patch didn't apply. This compiles OK. Sorry for the mess. Anyway, it should be applied via arm subtree. It's scheduled there. I should have responded with an applied message. Ok, thanks! 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: cx88: all radio tuners using xc2028 or xc4000 tuner and radio should have radio_type UNSET
Hi Miroslav, After applying an update and installing the most recent V4L drivers the radio is not working again. It appears that not all your patches have been included in the current media build and the patches can not be successfully applied. 2011/12/23 Andrew Goff goff...@gmail.com Thanks Miroslav, your patches fixed the problems with my leadtek 1800H card. Radio now works again and tunes to the correct frequency. On 17/12/2011 11:55 AM, Miroslav Slugeň wrote: Fix radio for cx88 driver. -- 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 v3.4] V4L2 subdev and sensor control changes and SMIA++ driver
Hi Mauro, On Mon, Mar 19, 2012 at 06:47:28PM -0300, Mauro Carvalho Chehab wrote: Em 11-03-2012 13:56, Sakari Ailus escreveu: Hi Mauro, This patchset adds - Integer menu controls, - Selection IOCTL for subdevs, - Sensor control improvements, - link_validate() media entity and V4L2 subdev pad ops, - OMAP 3 ISP driver improvements, - SMIA++ sensor driver and - Other V4L2 and media improvements (see individual patches) The previous patchset can be found here: URL:http://www.spinics.net/lists/linux-media/msg45052.html Compared to the patchset, I've dropped the rm-696 camera board code and will submit it through linux-omap later on. Other changes done to address review comments have been also done --- see the URL above for details. The following changes since commit 632fba4d012458fd5fedc678fb9b0f8bc59ceda2: [media] cx25821: Add a card definition for No brand cards that have: subvendor = 0x subdevice = 0x (2012-03-08 12:42:28 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.4 Jesper Juhl (1): adp1653: Remove unneeded include of version.h Laurent Pinchart (3): omap3isp: Prevent pipelines that contain a crashed entity from starting omap3isp: Fix crash caused by subdevs now having a pointer to devnodes omap3isp: Fix frame number propagation Sakari Ailus (37): v4l: Introduce integer menu controls v4l: Document integer menu controls vivi: Add an integer menu test control v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs v4l: vdev_to_v4l2_subdev() should have return type struct v4l2_subdev * v4l: Check pad number in get try pointer functions v4l: Support s_crop and g_crop through s/g_selection v4l: Add subdev selections documentation: svg and dia files v4l: Add subdev selections documentation This patch broke docbook compilation: HTMLDocumentation/DocBook/media_api.html warning: failed to load external entity /home/v4l/v4l/patchwork/Documentation/DocBook/vidioc-subdev-g-selection.xml /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser error : Failure to process entity sub-subdev-g-selection size configured using sub-subdev-g-selection; and ^ /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:310: parser error : Entity 'sub-subdev-g-selection' not defined size configured using sub-subdev-g-selection; and ^ /home/v4l/v4l/patchwork/Documentation/DocBook/dev-subdev.xml:468: parser error : chunk is not well balanced ^ /home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : Failure to process entity sub-dev-subdev section id=subdev sub-dev-subdev; /section ^ /home/v4l/v4l/patchwork/Documentation/DocBook/v4l2.xml:476: parser error : Entity 'sub-dev-subdev' not defined section id=subdev sub-dev-subdev; /section ^ /usr/bin/xmlto: line 568: 3232 Segmentation fault /usr/bin/xsltproc --nonet --xinclude --param passivetex.extensions '1' -o /tmp/xmlto.J0M0go/media_api.proc /tmp/xmlto-xsl.GKa5kH /home/v4l/v4l/patchwork/Documentation/DocBook/media_api.xml /bin/cp: cannot stat `*.*htm*': No such file or directory make[1]: *** [Documentation/DocBook/media_api.html] Error 1 make: *** [htmldocs] Error 2 Please fix. I'm pretty sure it compiles for me --- I just tested it myself on a different machine. Do you think you could possibly have e.g. old Documentation/DocBook/media-entities.tmpl in your tree? This file sometimes isn't getting rebuilt even when it would be needed to. Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] em28xx: support for 2304:0242 PCTV QuatroStick (510e)
This patch should be applied after the PATCH 2/2] em28xx: support for 2013:0251 PCTV QuatroStick nano (520e) patchset. It is mostly copy/paste of the 520e code with setting GPIO7 removed (no LED light). I've worked on just released vanilla linux-3.3.0 kernel, so there may be 1/2 lines offset to the internal working source, but most of the code should apply cleanly. I was able to get the DVB-C working (tuned and watched TV). Haven't tested DVB-T (no signal atm). Here is a log of the `dmsg` when detecting my device. [ 1197.735520] em28xx: New device Pinnacle Systems PCTV 510e @ 480 Mbps (2304:0242, interface 0, class 0) [ 1197.735525] em28xx: Audio Vendor Class interface 0 found [ 1197.735527] em28xx: Video interface 0 found [ 1197.735530] em28xx: DVB interface 0 found [ 1197.735588] em28xx #0: chip ID is em2884 [ 1198.030970] em28xx #0: Identified as PCTV QuatroStick (510e) (card=85) [ 1198.053727] Registered IR keymap rc-pinnacle-pctv-hd [ 1198.053829] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1a.7/usb1/1-4/rc/rc0/input10 [ 1198.053933] rc0: em28xx IR (em28xx #0) as /devices/pci:00/:00:1a.7/usb1/1-4/rc/rc0 [ 1198.054591] em28xx #0: Config register raw data: 0xb7 [ 1198.054595] em28xx #0: I2S Audio (5 sample rates) [ 1198.054598] em28xx #0: No AC97 audio processor [ 1198.071627] em28xx #0: v4l2 driver version 0.1.3 [ 1198.093354] em28xx #0: V4L2 video device registered as video1 [ 1198.093382] usbcore: registered new interface driver em28xx [ 1198.097021] em28xx-audio.c: probing for em28xx Audio Vendor Class [ 1198.097026] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 1198.097028] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab [ 1198.097721] Em28xx: Initialized (Em28xx Audio Extension) extension [ 1198.116227] drxk: status = 0x039260d9 [ 1198.116233] drxk: detected a drx-3926k, spin A1, xtal 20.250 MHz [ 1199.570712] DRXK driver version 0.9.4300 [ 1199.585694] drxk: frontend initialized. [ 1199.588100] tda18271 2-0060: creating new instance [ 1199.597682] TDA18271HD/C2 detected @ 2-0060 [ 1199.935489] DVB: registering new adapter (em28xx #0) [ 1199.935495] DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... [ 1199.936048] em28xx #0: Successfully loaded em28xx-dvb [ 1199.936054] Em28xx: Initialized (Em28xx dvb Extension) extension Special thanks to everybody who worked on the code and to Antti Palosaari and Devin Heitmueller who provided essential support on irc. Best Regards Ivan Kalvachev iive pctv510e.patch Description: Binary data
Re: reading config parameters of omap3-isp subdevs
Hi Michael, On Friday 16 March 2012 15:06:15 Michael Jones wrote: Hi all, I am playing around with some parameters in the previewer on the ISP. With ioctl VIDIOC_OMAP3ISP_PRV_CFG I am able to write the various parameters but what I'm missing is a way to read them. For example, I have no way to adjust only coef2 in 'struct omap3isp_prev_wbal' while leaving the others unchanged. If I could first read the whole omap3isp_prev_wbal structure, then I could change just the things I want to change. This seems like it would be common functionality for such ioctls. I didn't find any previous discussion related to this. I could imagine either adding a r/w flag to 'struct omap3isp_prev_update_config' or adding a new ioctl entirely. I think I would prefer the r/w flag. Feedback? I noticed that other ISP subdevs have similar ioctls. Perhaps a similar thing would be useful there, but right now I'm only looking at the previewer. Adding a R/W bit to the flag argument should indeed work. However, I'm wondering what your use case for reading parameters back is. The preview engine parameter structures seem pretty-much self-contained to me, I'm not sure it would make sense to only modify one of the parameters. -- 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 01/22] mt2063: trivial change
Em 14-02-2012 19:47, linu...@stefanringel.de escreveu:
From: Stefan Ringel linu...@stefanringel.de
Signed-off-by: Stefan Ringel linu...@stefanringel.de
---
drivers/media/common/tuners/mt2063.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 0ed9091..872e9c0 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -1,12 +1,13 @@
/*
- * Driver for mt2063 Micronas tuner
+ * Driver for microtune mt2063 tuner
*
* Copyright (c) 2011 Mauro Carvalho Chehab mche...@redhat.com
+ * Copyright (c) 2012 Stefan Ringel linu...@stefanringel.de
*
* This driver came from a driver originally written by:
- * Henry Wang henry.w...@azurewave.com
+ * Henry Wang henry.w...@azurewave.com
* Made publicly available by Terratec, at:
- *
http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz
+ *
http://linux.terratec.de/files/TERRATEC_H7/20110323_TERRATEC_H7_Linux.tar.gz
* The original driver's license is GPL, as declared with MODULE_LICENSE()
*
* This program is free software; you can redistribute it and/or modify
@@ -29,13 +30,14 @@
static unsigned int debug;
module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, Set Verbosity level);
+MODULE_PARM_DESC(debug, Set debug level);
-#define dprintk(level, fmt, arg...) do { \
-if (debug = level) \
- printk(KERN_DEBUG mt2063 %s: fmt, __func__, ## arg); \
-} while (0)
+/* debug level
+ * 0 don't debug
+ * 1 called functions without i2c comunications
+ * 2 additional calculating, result etc.
+ * 3 maximum debug information
A */ is missing here.
/* positive error codes used internally */
@@ -60,6 +62,10 @@ if (debug = level)
\
* check against this version number to make sure that
* it matches the version that the tuner driver knows about.
*/
+#define dprintk(level, fmt, arg...) do { \
+if (debug = level) \
+ printk(KERN_DEBUG mt2063 %s: fmt, __func__, ##arg); \
+} while (0)
/* DECT Frequency Avoidance */
#define MT2063_DECT_AVOID_US_FREQS 0x0001
@@ -2305,3 +2311,4 @@ EXPORT_SYMBOL_GPL(tuner_MT2063_ClearPowerMaskBits);
MODULE_AUTHOR(Mauro Carvalho Chehab mche...@redhat.com);
MODULE_DESCRIPTION(MT2063 Silicon tuner);
MODULE_LICENSE(GPL);
+MODULE_VERSION(0.2);
--
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 03/22] mt2063: add hybrid
Em 14-02-2012 19:47, linu...@stefanringel.de escreveu:
From: Stefan Ringel linu...@stefanringel.de
Signed-off-by: Stefan Ringel linu...@stefanringel.de
Patch is broken:
drivers/media/common/tuners/mt2063.c:365:1: error: expected identifier or ‘(’
before ‘{’ token
drivers/media/common/tuners/mt2063.c:367:4: error: expected identifier or ‘(’
before ‘else’
drivers/media/common/tuners/mt2063.c:369:1: error: expected identifier or ‘(’
before ‘}’ token
drivers/media/common/tuners/mt2063.c:371:1: error: expected identifier or ‘(’
before ‘{’ token
drivers/media/common/tuners/mt2063.c:287:12: warning: ‘mt2063_setreg’ defined
but not used [-Wunused-function]
drivers/media/common/tuners/mt2063.c:308:12: warning: ‘mt2063_read’ defined but
not used [-Wunused-function]
drivers/media/common/tuners/mt2063.c:355:12: warning: ‘MT2063_Sleep’ defined
but not used [-Wunused-function]
---
drivers/media/common/tuners/mt2063.c | 57
+++---
1 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index 9f3a546..d5a9dd9 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -32,6 +32,8 @@ static unsigned int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Set debug level);
+static DEFINE_MUTEX(mt2063_list_mutex);
+static LIST_HEAD(hybrid_tuner_instance_list);
/* debug level
* 0 don't debug
@@ -2247,29 +2249,48 @@ static struct dvb_tuner_ops mt2063_ops = {
};
struct dvb_frontend *mt2063_attach(struct dvb_frontend *fe,
-struct mt2063_config *config,
-struct i2c_adapter *i2c)
+ struct mt2063_config *config,
+ struct i2c_adapter *i2c)
{
struct mt2063_state *state = NULL;
+ int instance, ret;
+
+ dprintk(1, \n);
+
+ mutex_lock(mt2063_list_mutex);
+
+ instance = hybrid_tuner_request_state(struct mt2063_state, state,
+ hybrid_tuner_instance_list,
+ i2c, config-tuner_address,
+ mt2063);
+
+ switch(instance) {
+ case 0:
+ goto fail;
+ case 1:
+ /* new instance */
+ state-i2c = i2c;
+ state-i2c_addr = config-tuner_address;
+ /* find chip */
+ mutex_init(state-lock);
+ state-frontend = fe;
+ if (ret 0)
+ goto fail;
+ fe-tuner_priv = state;
+ fe-ops.tuner_ops = mt2063_ops;
+ break;
+ default:
+ fe-tuner_priv = state;
+ fe-ops.tuner_ops = mt2063_ops;
+ break;
+ }
+ mutex_unlock(mt2063_list_mutex);
- dprintk(2, \n);
-
- state = kzalloc(sizeof(struct mt2063_state), GFP_KERNEL);
- if (state == NULL)
- goto error;
-
- state-config = config;
- state-i2c = i2c;
- state-frontend = fe;
- state-reference = config-refclock / 1000; /* kHz */
- fe-tuner_priv = state;
- fe-ops.tuner_ops = mt2063_ops;
-
- printk(KERN_INFO %s: Attaching MT2063\n, __func__);
return fe;
-error:
- kfree(state);
+fail:
+ hybrid_tuner_release_state(state);
+ mutex_unlock(mt2063_list_mutex);
return NULL;
}
EXPORT_SYMBOL_GPL(mt2063_attach);
--
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 04/22] mt2063: remove dect
Em 14-02-2012 19:47, linu...@stefanringel.de escreveu:
From: Stefan Ringel linu...@stefanringel.de
Signed-off-by: Stefan Ringel linu...@stefanringel.de
Patch is also broken: it introduces some weird stuff there. Even after removing
it,
still doesn't compile:
drivers/media/common/tuners/mt2063.c: In function ‘MT2063_ChooseFirstIF’:
drivers/media/common/tuners/mt2063.c:398:26: error: array type has incomplete
element type
drivers/media/common/tuners/mt2063.c:429:7: error: implicit declaration of
function ‘floor’ [-Werror=implicit-function-declaration]
drivers/media/common/tuners/mt2063.c:433:7: error: implicit declaration of
function ‘ceil’ [-Werror=implicit-function-declaration]
drivers/media/common/tuners/mt2063.c:398:26: warning: unused variable ‘zones’
[-Wunused-variable]
cc1: some warnings being treated as errors
---
drivers/media/common/tuners/mt2063.c | 190
--
1 files changed, 0 insertions(+), 190 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index d5a9dd9..a79e4ef 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -363,200 +363,17 @@ static int MT2063_Sleep(struct dvb_frontend *fe)
return 0;
}
-/*
- * Microtune spur avoidance
- */
-
-/* Implement ceiling, floor functions. */
-#define ceil(n, d) (((n) 0) ? (-((-(n))/(d))) : (n)/(d) + ((n)%(d) != 0))
-#define floor(n, d) (((n) 0) ? (-((-(n))/(d))) - ((n)%(d) != 0) : (n)/(d))
-
-struct MT2063_FIFZone_t {
- s32 min_;
- s32 max_;
-};
-
-static struct MT2063_ExclZone_t *InsertNode(struct MT2063_AvoidSpursData_t
- *pAS_Info,
- struct MT2063_ExclZone_t *pPrevNode)
{
- struct MT2063_ExclZone_t *pNode;
- dprintk(2, \n);
-
- /* Check for a node in the free list */
- if (pAS_Info-freeZones != NULL) {
- /* Use one from the free list */
- pNode = pAS_Info-freeZones;
- pAS_Info-freeZones = pNode-next_;
} else {
- /* Grab a node from the array */
- pNode = pAS_Info-MT2063_ExclZones[pAS_Info-nZones];
- }
-
- if (pPrevNode != NULL) {
- pNode-next_ = pPrevNode-next_;
- pPrevNode-next_ = pNode;
- } else {/* insert at the beginning of the list */
-
- pNode-next_ = pAS_Info-usedZones;
- pAS_Info-usedZones = pNode;
- }
-
- pAS_Info-nZones++;
- return pNode;
-}
-
-static struct MT2063_ExclZone_t *RemoveNode(struct MT2063_AvoidSpursData_t
- *pAS_Info,
- struct MT2063_ExclZone_t *pPrevNode,
- struct MT2063_ExclZone_t
- *pNodeToRemove)
-{
- struct MT2063_ExclZone_t *pNext = pNodeToRemove-next_;
-
- dprintk(2, \n);
-
- /* Make previous node point to the subsequent node */
- if (pPrevNode != NULL)
- pPrevNode-next_ = pNext;
-
- /* Add pNodeToRemove to the beginning of the freeZones */
- pNodeToRemove-next_ = pAS_Info-freeZones;
- pAS_Info-freeZones = pNodeToRemove;
-
- /* Decrement node count */
- pAS_Info-nZones--;
-
- return pNext;
-}
-
-/*
- * MT_AddExclZone()
- *
- * Add (and merge) an exclusion zone into the list.
- * If the range (f_min, f_max) is totally outside the
- * 1st IF BW, ignore the entry.
- * If the range (f_min, f_max) is negative, ignore the entry.
- */
-static void MT2063_AddExclZone(struct MT2063_AvoidSpursData_t *pAS_Info,
-u32 f_min, u32 f_max)
-{
- struct MT2063_ExclZone_t *pNode = pAS_Info-usedZones;
- struct MT2063_ExclZone_t *pPrev = NULL;
- struct MT2063_ExclZone_t *pNext = NULL;
-
- dprintk(2, \n);
-
- /* Check to see if this overlaps the 1st IF filter */
- if ((f_max (pAS_Info-f_if1_Center - (pAS_Info-f_if1_bw / 2)))
- (f_min (pAS_Info-f_if1_Center + (pAS_Info-f_if1_bw / 2)))
- (f_min f_max)) {
- /*
- *12 3 4 56
- *
- * New entry: |---||--| |--||-||---||--|
- *or oror or or
- * Existing: |--| |--| |--||---| |-| |--|
- */
-
- /* Check for our place in the list */
- while ((pNode != NULL) (pNode-max_ f_min)) {
- pPrev = pNode;
- pNode = pNode-next_;
- }
-
- if ((pNode != NULL) (pNode-min_ f_max)) {
- /* Combine me with pNode */
- if (f_min pNode-min_)
-
Re: [PATCH 05/22] mt2063: remove spurcheck
Em 14-02-2012 19:47, linu...@stefanringel.de escreveu:
From: Stefan Ringel linu...@stefanringel.de
Can't test this patches (or latter patches in this series), as it depends on the
previous changes.
Please fix the patches. Each patch should individually compile. This is an
upstream
requirement, to avoid breaking disect. It is also a need for me to check what
patches on this series may be breaking support for az6007.
Thanks,
Mauro
Signed-off-by: Stefan Ringel linu...@stefanringel.de
---
drivers/media/common/tuners/mt2063.c | 585
--
1 files changed, 0 insertions(+), 585 deletions(-)
diff --git a/drivers/media/common/tuners/mt2063.c
b/drivers/media/common/tuners/mt2063.c
index a79e4ef..ee59ebe 100644
--- a/drivers/media/common/tuners/mt2063.c
+++ b/drivers/media/common/tuners/mt2063.c
@@ -41,15 +41,6 @@ static LIST_HEAD(hybrid_tuner_instance_list);
* 2 additional calculating, result etc.
* 3 maximum debug information
-/* positive error codes used internally */
-
-/* Info: Unavoidable LO-related spur may be present in the output */
-#define MT2063_SPUR_PRESENT_ERR (0x0080)
-
-/* Info: Mask of bits used for # of LO-related spurs that were avoided
during tuning */
-#define MT2063_SPUR_CNT_MASK(0x001f)
-#define MT2063_SPUR_SHIFT (16)
-
/* Info: Upconverter frequency is out of range (may be reason for
MT_UPC_UNLOCK) */
#define MT2063_UPC_RANGE(0x0400)
@@ -69,61 +60,6 @@ if (debug = level)
\
printk(KERN_DEBUG mt2063 %s: fmt, __func__, ##arg); \
} while (0)
-/* DECT Frequency Avoidance */
-#define MT2063_DECT_AVOID_US_FREQS 0x0001
-
-#define MT2063_DECT_AVOID_EURO_FREQS0x0002
-
-#define MT2063_EXCLUDE_US_DECT_FREQUENCIES(s) (((s)
MT2063_DECT_AVOID_US_FREQS) != 0)
-
-#define MT2063_EXCLUDE_EURO_DECT_FREQUENCIES(s) (((s)
MT2063_DECT_AVOID_EURO_FREQS) != 0)
-
-enum MT2063_DECT_Avoid_Type {
- MT2063_NO_DECT_AVOIDANCE = 0, /* Do not
create DECT exclusion zones. */
- MT2063_AVOID_US_DECT = MT2063_DECT_AVOID_US_FREQS, /* Avoid US
DECT frequencies. */
- MT2063_AVOID_EURO_DECT = MT2063_DECT_AVOID_EURO_FREQS, /* Avoid
European DECT frequencies.*/
- MT2063_AVOID_BOTH /* Avoid both
regions. Not typically used. */
-};
-
-#define MT2063_MAX_ZONES 48
-
-struct MT2063_ExclZone_t {
- u32 min_;
- u32 max_;
- struct MT2063_ExclZone_t *next_;
-};
-
-/*
- * Structure of data needed for Spur Avoidance
- */
-struct MT2063_AvoidSpursData_t {
- u32 f_ref;
- u32 f_in;
- u32 f_LO1;
- u32 f_if1_Center;
- u32 f_if1_Request;
- u32 f_if1_bw;
- u32 f_LO2;
- u32 f_out;
- u32 f_out_bw;
- u32 f_LO1_Step;
- u32 f_LO2_Step;
- u32 f_LO1_FracN_Avoid;
- u32 f_LO2_FracN_Avoid;
- u32 f_zif_bw;
- u32 f_min_LO_Separation;
- u32 maxH1;
- u32 maxH2;
- enum MT2063_DECT_Avoid_Type avoidDECT;
- u32 bSpurPresent;
- u32 bSpurAvoided;
- u32 nSpursFound;
- u32 nZones;
- struct MT2063_ExclZone_t *freeZones;
- struct MT2063_ExclZone_t *usedZones;
- struct MT2063_ExclZone_t MT2063_ExclZones[MT2063_MAX_ZONES];
-};
-
/*
* Parameter for function MT2063_SetPowerMask that specifies the power down
* of various sections of the MT2063.
@@ -375,351 +311,20 @@ static int MT2063_Sleep(struct dvb_frontend *fe)
-/*
- * MT_ChooseFirstIF - Choose the best available 1st IF
- *If f_Desired is not excluded, choose that first.
- *Otherwise, return the value closest to f_Center that is
- *not excluded
- */
-static u32 MT2063_ChooseFirstIF(struct MT2063_AvoidSpursData_t *pAS_Info)
-{
- /*
- * Update f_Desired to be the nearest combinational-multiple of
- * f_LO1_Step.
- * The resulting number, F_LO1 must be a multiple of f_LO1_Step.
- * And F_LO1 is the arithmetic sum of f_in + f_Center.
- * Neither f_in, nor f_Center must be a multiple of f_LO1_Step.
- * However, the sum must be.
- */
- const u32 f_Desired =
- pAS_Info-f_LO1_Step *
- ((pAS_Info-f_if1_Request + pAS_Info-f_in +
- pAS_Info-f_LO1_Step / 2) / pAS_Info-f_LO1_Step) -
- pAS_Info-f_in;
- const u32 f_Step =
- (pAS_Info-f_LO1_Step
- pAS_Info-f_LO2_Step) ? pAS_Info-f_LO1_Step : pAS_Info-
- f_LO2_Step;
- u32 f_Center;
- s32 i;
- s32 j = 0;
- u32 bDesiredExcluded = 0;
- u32 bZeroExcluded = 0;
- s32 tmpMin, tmpMax;
- s32 bestDiff;
- struct MT2063_ExclZone_t *pNode = pAS_Info-usedZones;
- struct MT2063_FIFZone_t zones[MT2063_MAX_ZONES];
-
- dprintk(2,
Re: [PATCH] em28xx: support for 2304:0242 PCTV QuatroStick (510e)
Hardware is based of: Empia EM2884 Micronas DRX 3926K NXP TDA18271HDC2 AVF4910 (not used atm) This model is almost identical to the PCTV 520e. There is no LED on it and the drx-k may be spin A1, A2 or A3. Signed-off-by: Ivan Kalvachev ikalvac...@gmail.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] em28xx: support for 2304:0242 PCTV QuatroStick (510e)
Em 19-03-2012 20:09, Ivan Kalvachev escreveu:
This patch should be applied after the
PATCH 2/2] em28xx: support for 2013:0251 PCTV QuatroStick nano
(520e) patchset.
It is mostly copy/paste of the 520e code with setting GPIO7 removed
(no LED light).
I've worked on just released vanilla linux-3.3.0 kernel, so there may
be 1/2 lines offset to the internal working source, but most of the
code should apply cleanly.
I was able to get the DVB-C working (tuned and watched TV). Haven't
tested DVB-T (no signal atm).
Here is a log of the `dmsg` when detecting my device.
[ 1197.735520] em28xx: New device Pinnacle Systems PCTV 510e @ 480
Mbps (2304:0242, interface 0, class 0)
[ 1197.735525] em28xx: Audio Vendor Class interface 0 found
[ 1197.735527] em28xx: Video interface 0 found
[ 1197.735530] em28xx: DVB interface 0 found
[ 1197.735588] em28xx #0: chip ID is em2884
[ 1198.030970] em28xx #0: Identified as PCTV QuatroStick (510e) (card=85)
[ 1198.053727] Registered IR keymap rc-pinnacle-pctv-hd
[ 1198.053829] input: em28xx IR (em28xx #0) as
/devices/pci:00/:00:1a.7/usb1/1-4/rc/rc0/input10
[ 1198.053933] rc0: em28xx IR (em28xx #0) as
/devices/pci:00/:00:1a.7/usb1/1-4/rc/rc0
[ 1198.054591] em28xx #0: Config register raw data: 0xb7
[ 1198.054595] em28xx #0: I2S Audio (5 sample rates)
[ 1198.054598] em28xx #0: No AC97 audio processor
[ 1198.071627] em28xx #0: v4l2 driver version 0.1.3
[ 1198.093354] em28xx #0: V4L2 video device registered as video1
[ 1198.093382] usbcore: registered new interface driver em28xx
[ 1198.097021] em28xx-audio.c: probing for em28xx Audio Vendor Class
[ 1198.097026] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger
[ 1198.097028] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab
[ 1198.097721] Em28xx: Initialized (Em28xx Audio Extension) extension
[ 1198.116227] drxk: status = 0x039260d9
[ 1198.116233] drxk: detected a drx-3926k, spin A1, xtal 20.250 MHz
[ 1199.570712] DRXK driver version 0.9.4300
[ 1199.585694] drxk: frontend initialized.
[ 1199.588100] tda18271 2-0060: creating new instance
[ 1199.597682] TDA18271HD/C2 detected @ 2-0060
[ 1199.935489] DVB: registering new adapter (em28xx #0)
[ 1199.935495] DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)...
[ 1199.936048] em28xx #0: Successfully loaded em28xx-dvb
[ 1199.936054] Em28xx: Initialized (Em28xx dvb Extension) extension
Special thanks to everybody who worked on the code and to Antti
Palosaari and Devin Heitmueller who provided essential support on irc.
Best Regards
Ivan Kalvachev
iive
pctv510e.patch
Please send your Signed-off-by:. This is a requirement for us to merge it
upstream.
Thanks!
Mauro
diff -urdp em28xx.org/em28xx-cards.c em28xx/em28xx-cards.c
--- a/drivers/media/video/em28xx/em28xx-cards.c 2012-03-20
00:15:11.463410017 +0200
+++ b/drivers/media/video/em28xx/em28xx-cards.c 2012-03-20
00:21:48.974379246 +0200
@@ -364,6 +364,19 @@ static struct em28xx_reg_seq maxmedia_ub
{-1, -1,-1, -1},
};
+/* 2304:0242 PCTV QuatroStick (510e)
+ * GPIO_2: decoder reset, 0=active
+ * GPIO_4: decoder suspend, 0=active
+ * GPIO_6: demod reset, 0=active
+ * GPIO_7: LED, 1=active
+ */
+static struct em28xx_reg_seq pctv_510e[] = {
+ {EM2874_R80_GPIO, 0x10, 0xff, 100},
+ {EM2874_R80_GPIO, 0x14, 0xff, 100}, /* GPIO_2 = 1 */
+ {EM2874_R80_GPIO, 0x54, 0xff, 050}, /* GPIO_6 = 1 */
+ { -1, -1, -1, -1},
+};
+
/* 2013:0251 PCTV QuatroStick nano (520e)
* GPIO_2: decoder reset, 0=active
* GPIO_4: decoder suspend, 0=active
@@ -1944,6 +1957,18 @@ struct em28xx_board em28xx_boards[] = {
EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_FREQ_400_KHZ,
},
+ /* 2304:0242 PCTV QuatroStick (510e)
+ * Empia EM2884 + Micronas DRX 3926K + NXP TDA18271HDC2 */
+ [EM2884_BOARD_PCTV_510E] = {
+ .name = PCTV QuatroStick (510e),
+ .tuner_type= TUNER_ABSENT,
+ .tuner_gpio= pctv_510e,
+ .has_dvb = 1,
+ .ir_codes = RC_MAP_PINNACLE_PCTV_HD,
+ .i2c_speed = EM2874_I2C_SECONDARY_BUS_SELECT |
+ EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_FREQ_400_KHZ,
+ },
/* 2013:0251 PCTV QuatroStick nano (520e)
* Empia EM2884 + Micronas DRX 3926K + NXP TDA18271HDC2 */
[EM2884_BOARD_PCTV_520E] = {
@@ -2109,6 +2134,8 @@ struct usb_device_id em28xx_id_table[] =
.driver_info = EM2860_BOARD_EASYCAP },
{ USB_DEVICE(0x1b80, 0xe425),
.driver_info = EM2874_BOARD_MAXMEDIA_UB425_TC },
+ { USB_DEVICE(0x2304, 0x0242),
+ .driver_info = EM2884_BOARD_PCTV_510E },
{ USB_DEVICE(0x2013, 0x0251),
.driver_info =
Re: [PATCH 1/3] Support for tuner FC0012
Em 22-02-2012 20:21, Hans-Frieder Vogt escreveu:
Support for the tuner Fitipower FC0012
Signed-off-by: Hans-Frieder Vogt hfv...@gmx.net
diff -Nupr a/drivers/media/common/tuners/fc0012.c
b/drivers/media/common/tuners/fc0012.c
--- a/drivers/media/common/tuners/fc0012.c1970-01-01 01:00:00.0
+0100
+++ b/drivers/media/common/tuners/fc0012.c2012-02-19 17:37:27.364482154
+0100
@@ -0,0 +1,430 @@
+/*
+ * Fitipower FC0012 tuner driver
+ *
+ * Copyright (C) 2012 Hans-Frieder Vogt hfv...@gmx.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/version.h
Media drivers shouldn't include linux/version.h.
+#include fc0012.h
+#include fc0012-priv.h
+
+static int fc0012_debug;
+module_param_named(debug, fc0012_debug, int, 0644);
+MODULE_PARM_DESC(debug, Select debug level (default: debug off));
+
+/* the FC0012 seems to have only byte access to the registers */
+static int fc0012_writeregs(struct fc0012_priv *priv, u8 reg, u8 *val, int
len)
Your emailer is mangling the patch, breaking long lines.
+{
+ u8 buf[1+len];
This is generally not a good idea, as the Kernel stack is very small
(about 2K-4K, depending on the arch).
+ struct i2c_msg msg = { .addr = priv-addr,
+ .flags = 0, .buf = buf, .len = sizeof(buf) };
+
+ buf[0] = reg;
+ memcpy(buf[1], val, len);
+
+ msleep(1);
+ if (i2c_transfer(priv-i2c, msg, 1) != 1) {
+ err(I2C write regs failed, reg: %02x, val[0]: %02x,
+ reg, val[0]);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+static int fc0012_writereg(struct fc0012_priv *priv, u8 reg, u8 val)
+{
+ u8 buf[2] = {reg, val};
+ struct i2c_msg msg = { .addr = priv-addr,
+ .flags = 0, .buf = buf, .len = 2 };
+
+ msleep(1);
+ if (i2c_transfer(priv-i2c, msg, 1) != 1) {
+ err(I2C write reg failed, reg: %02x, val: %02x, reg, val);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+static int fc0012_readreg(struct fc0012_priv *priv, u8 reg, u8 *val)
+{
+ struct i2c_msg msg[2] = {
+ { .addr = priv-addr,
+ .flags = 0, .buf = reg, .len = 1 },
+ { .addr = priv-addr,
+ .flags = I2C_M_RD, .buf = val, .len = 1 },
+ };
+
+ if (i2c_transfer(priv-i2c, msg, 2) != 2) {
+ err(I2C read failed, reg: %02x, reg);
+ return -EREMOTEIO;
+ }
+ return 0;
+}
+
+static int fc0012_release(struct dvb_frontend *fe)
+{
+ kfree(fe-tuner_priv);
+ fe-tuner_priv = NULL;
+ return 0;
+}
+
+static int fc0012_init(struct dvb_frontend *fe)
+{
+ struct fc0012_priv *priv = fe-tuner_priv;
+ int ret = 0;
+ u8 i;
+ unsigned char reg[] = {
+ 0x00, /* dummy reg. 0 */
+ 0x05, /* reg. 0x01 */
+ 0x10, /* reg. 0x02 */
+ 0x00, /* reg. 0x03 */
+ 0x00, /* reg. 0x04 */
+ 0x0a, /* reg. 0x05 CHECK: correct? */
+ 0x00, /* reg. 0x06: divider 2, VCO slow */
+ 0x0f, /* reg. 0x07 */
+ 0xff, /* reg. 0x08: AGC Clock divide by 256, AGC gain 1/256,
Loop Bw
1/8 */
+ 0x6e, /* reg. 0x09: Disable LoopThrough */
+ 0xb8, /* reg. 0x0a: Disable LO Test Buffer */
+ 0x83, /* reg. 0x0b: Output Clock is same as clock frequency */
+ 0xfe, /* reg. 0x0c: depending on AGC Up-Down mode, may need
0xf8 */
+ 0x02, /* reg. 0x0d: AGC Not Forcing LNA Forcing, 0x02 for
DVB-T */
+ 0x00, /* reg. 0x0e */
+ 0x00, /* reg. 0x0f */
+ 0x0d, /* reg. 0x10 */
+ 0x00, /* reg. 0x11 */
+ 0x1f, /* reg. 0x12: Set to maximum gain */
+ 0x90, /* reg. 0x13: Enable IX2, Set to Middle Gain: 0x08, Low
Gain:
0x00, High Gain: 0x10 */
+ 0x00, /* reg. 0x14 */
+ 0x04, /* reg. 0x15: Enable LNA COMPS */
+ };
+
+ switch (priv-xtal_freq) {
+ case FC_XTAL_27_MHZ:
+ case FC_XTAL_28_8_MHZ:
+ reg[0x07] |= 0x20;
+ break;
+ case FC_XTAL_36_MHZ:
+ default:
+ break;
+ }
+ for (i =
Re: [PATCH 2/3] Basic AF9035/AF9033 driver
Em 22-02-2012 20:21, Hans-Frieder Vogt escreveu: Support for DVB-T USB 2.0 sticks based on AF9035/AF9033. Currently supported devices: - Terratec T5 Ver.2 (also known as T6) - Avermedia Volar HD Nano (A867) Signed-off-by: Hans-Frieder Vogt hfv...@gmx.net http://home.arcor.de/hfvogt/af903x/af903x.patch.gz Please, don't submit patches like that. The Linuxtv patchwork will never get it (http://linuxtv.org/patchwork). Thanks, Mauro Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Firmware for AF9035/AF9033 driver
Em 22-02-2012 20:22, Hans-Frieder Vogt escreveu: Firmware for the AF9035/AF9033 driver. irmware format for af903x driver: copied from it9135-driver by Jason Dong (C) 2011 ITE Technologies, INC. : 8 chars AF9035BXIdentifier of firmware 0008: 4 bytes LE length of firmware following this: 32 + 4 + 4 + 4 + 4 + 4 + Firmware_CODELENGTH + Firmware_SEGMENTLENGTH * Firmware_PARTITIONLENGTH * 5 + 5 + 2 + Firmware_scriptSets[0] * 5; 000C: 32 chars firmware release version 002C: 4 bytes BE link version 0030: 4 bytes BE ofdm version 0034: 4 bytes LE firmware code length (Firmware_CODELENGTH) 0038: 1 bytes number of firmware segments (Firmware_SEGMENTLENGTH) 0039: 3 bytes filler (0) 003C: 1 bytes number of firmware partitions (Firmware_PARTITIONLENGTH) 003D: 3 bytes filler (0) 0040: Firmware_CODELENGTH bytes abcd: description of firmware segments, for each segment in every partition: 1 byte segment type (0: download firmware, 1: copy firmware, else: direct write firmware) 4 bytes LE segment length bcde: 1 byte Firmware_SEGMENTLENGTH check bcdf: 1 byte Firmware_PARTITIONLENGTH check bce0: 3 bytes filler (0) bce3: 2 bytes LE number of firmware (demodulator) scripts bce5: list of firmware scripts, for each entry: 4 bytes LE address 1 byte value Signed-off-by: Hans-Frieder Vogt hfv...@gmx.net http://home.arcor.de/hfvogt/af903x/dvb-usb-af9035-03.fw = for Terratec T5 Ver. 2 / T6 http://home.arcor.de/hfvogt/af903x/dvb-usb-af9035-04.fw = for Avermedia A867 Firmware patches should be against the linux-firmware tree [1]. [1] http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=summary We need a licensing text signed by the board or chipset manufacturer, in order to be able to add it there. If you can't get it, then the alternative is to change the Documentation/dvb/get_dvb_firmware script to get it from somewhere (although this is a bad option, as the firmware won't be distributed together with the Linux distributions). Regards, Mauro Hans-Frieder Vogt e-mail: hfvogt at gmx .dot. net -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] video: mx3_camera: Allocate camera object via kzalloc
Em 20-02-2012 16:23, Fabio Estevam escreveu: On Mon, Feb 20, 2012 at 4:17 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 20 Feb 2012, Fabio Estevam wrote: Align mx3_camera driver with the other soc camera driver implementations by allocating the camera object via kzalloc. Sorry, any specific reason, why you think this aligning is so important? Not really. Just compared it with all other soc camera drivers I found and mx3_camera was the only one that uses vzalloc Any specific reason that requires mx3_camera to use vzalloc instead of kzalloc? kzalloc() is more restrictive than vzalloc(). With v*alloc, it will allocate a virtual memory area, with can be discontinuous, while kzalloc will get a continuous area. The DMA logic need to be prepared for virtual memory, if v*alloc() is used (e. g. using videobuf2-vmalloc). As it is currently including media/videobuf2-dma-contig.h, I this patch makes sense on my eyes. Tested with kzalloc and it worked fine on my mx31pdk. If the driver is working with vzalloc, then maybe it is due to some arch-specific implementation for v*alloc. It shouldn't be working like that. Regards, Mauro Regards, Fabio Estevam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-jpeg: Make the output format setting conditional
Hi Andrzej, On 19/03/2012, Andrzej Pietrasiewicz andrze...@samsung.com wrote: Hello, On March 19, 2012 12:35 PM Sachin Kamat wrote: Subject: [PATCH] [media] s5p-jpeg: Make the output format setting conditional S5P-JPEG IP on Exynos4210 SoC supports YCbCr422 and YCbCr420 as decoded output formats. But the driver used to fix the output format as YCbCr422. This is now made conditional depending upon the requested output format. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/video/s5p-jpeg/jpeg-core.c |5 - snip This has already been submitted and been pulled by Mauro: http://git.linuxtv.org/media_tree.git/commit/fb6f8c0269644a19ee5e9bd6db080b3 64ab28ea7 Thanks for the update. I did not notice this patch. Please ignore my patch. Andrzej -- With warm regards, Sachin -- 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
