Re: [PATCH] mxl111sf: don't redefine pr_err/info/debug
On Thu May 23 2013 08:50:43 Hans Verkuil wrote:
Remove the silly redefines of pr_err/info/debug.
This improves readability and it also gets rid of a bunch of warnings when
compiling this driver for older kernels using the compatibility media_build
system.
Mike,
Can you Ack this?
Thanks,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c |8 +--
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 90
-
2 files changed, 45 insertions(+), 53 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
index ef4c65f..879c529 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
@@ -31,8 +31,6 @@ MODULE_PARM_DESC(debug, set debugging level (1=info
(or-able)).);
if (mxl111sf_tuner_debug) \
mxl_printk(KERN_DEBUG, fmt, ##arg)
-#define err pr_err
-
/*
*/
struct mxl111sf_tuner_state {
@@ -113,7 +111,7 @@ static struct mxl111sf_reg_ctrl_info
*mxl111sf_calc_phy_tune_regs(u32 freq,
filt_bw = 63;
break;
default:
- err(%s: invalid bandwidth setting!, __func__);
+ pr_err(%s: invalid bandwidth setting!, __func__);
return NULL;
}
@@ -304,12 +302,12 @@ static int mxl111sf_tuner_set_params(struct
dvb_frontend *fe)
bw = 8;
break;
default:
- err(%s: bandwidth not set!, __func__);
+ pr_err(%s: bandwidth not set!, __func__);
return -EINVAL;
}
break;
default:
- err(%s: modulation type not supported!, __func__);
+ pr_err(%s: modulation type not supported!, __func__);
return -EINVAL;
}
ret = mxl1x1sf_tune_rf(fe, c-frequency, bw);
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..e97964e 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -52,12 +52,6 @@ MODULE_PARM_DESC(rfswitch, force rf switch position
(0=auto, 1=ext, 2=int).);
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
-#define deb_info pr_debug
-#define deb_reg pr_debug
-#define deb_adv pr_debug
-#define err pr_err
-#define info pr_info
-
int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
@@ -65,7 +59,7 @@ int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
int ret;
u8 sndbuf[1+wlen];
- deb_adv(%s(wlen = %d, rlen = %d)\n, __func__, wlen, rlen);
+ pr_debug(%s(wlen = %d, rlen = %d)\n, __func__, wlen, rlen);
memset(sndbuf, 0, 1+wlen);
@@ -98,12 +92,12 @@ int mxl111sf_read_reg(struct mxl111sf_state *state, u8
addr, u8 *data)
if (buf[0] == addr)
*data = buf[1];
else {
- err(invalid response reading reg: 0x%02x != 0x%02x, 0x%02x,
+ pr_err(invalid response reading reg: 0x%02x != 0x%02x, 0x%02x,
addr, buf[0], buf[1]);
ret = -EINVAL;
}
- deb_reg(R: (0x%02x, 0x%02x)\n, addr, *data);
+ pr_debug(R: (0x%02x, 0x%02x)\n, addr, *data);
fail:
return ret;
}
@@ -113,11 +107,11 @@ int mxl111sf_write_reg(struct mxl111sf_state *state, u8
addr, u8 data)
u8 buf[] = { addr, data };
int ret;
- deb_reg(W: (0x%02x, 0x%02x)\n, addr, data);
+ pr_debug(W: (0x%02x, 0x%02x)\n, addr, data);
ret = mxl111sf_ctrl_msg(state-d, MXL_CMD_REG_WRITE, buf, 2, NULL, 0);
if (mxl_fail(ret))
- err(error writing reg: 0x%02x, val: 0x%02x, addr, data);
+ pr_err(error writing reg: 0x%02x, val: 0x%02x, addr, data);
return ret;
}
@@ -134,7 +128,7 @@ int mxl111sf_write_reg_mask(struct mxl111sf_state *state,
#if 1
/* dont know why this usually errors out on the first try */
if (mxl_fail(ret))
- err(error writing addr: 0x%02x, mask: 0x%02x,
+ pr_err(error writing addr: 0x%02x, mask: 0x%02x,
data: 0x%02x, retrying..., addr, mask, data);
ret = mxl111sf_read_reg(state, addr, val);
@@ -167,7 +161,7 @@ int mxl111sf_ctrl_program_regs(struct mxl111sf_state
*state,
ctrl_reg_info[i].mask,
ctrl_reg_info[i].data);
if (mxl_fail(ret)) {
- err(failed on reg #%d (0x%02x), i,
+ pr_err(failed on reg #%d (0x%02x), i,
ctrl_reg_info[i].addr);
break;
[GIT PULL FOR v3.11] Updates Part 1
Mauro prefers to have the original large pull request split up in smaller pieces. So this is the first patch set. Note that the pull requests need to be done in order since there are dependencies between them. Regards, Hans The following changes since commit 62d54876c511628daed2246753e2fe348da022f1: [media] s5p-tv: Don't ignore return value of regulator_bulk_enable() in hdmi_drv.c (2013-06-12 22:17:59 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.11a for you to fetch changes up to 59834c3c791a01d9b7e460bf90d7ec4b47aaeab8: media: i2c: ths7303: make the pdata as a constant pointer (2013-06-13 08:14:07 +0200) Antti Palosaari (1): radio-keene: add delay in order to settle hardware Hans Verkuil (5): hdpvr: fix querystd 'unknown format' return. hdpvr: code cleanup hdpvr: improve error handling ml86v7667: fix the querystd implementation radio-keene: set initial frequency. Lad, Prabhakar (4): ARM: davinci: dm365 evm: remove init_enable from ths7303 pdata media: i2c: ths7303: remove init_enable option from pdata media: i2c: ths7303: remove unnecessary function ths7303_setup() media: i2c: ths7303: make the pdata as a constant pointer Vladimir Barinov (2): adv7180: add more subdev video ops ML86V7667: new video decoder driver arch/arm/mach-davinci/board-dm365-evm.c |1 - drivers/media/i2c/Kconfig |9 +++ drivers/media/i2c/Makefile |1 + drivers/media/i2c/adv7180.c | 46 +++ drivers/media/i2c/ml86v7667.c | 431 drivers/media/i2c/ths7303.c | 48 +++- drivers/media/radio/radio-keene.c |7 +- drivers/media/usb/hdpvr/hdpvr-control.c | 21 +++-- drivers/media/usb/hdpvr/hdpvr-video.c | 72 + drivers/media/usb/hdpvr/hdpvr.h |1 + include/media/ths7303.h |2 - 11 files changed, 552 insertions(+), 87 deletions(-) create mode 100644 drivers/media/i2c/ml86v7667.c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.11] Updates Part 2
Mauro prefers to have the original large pull request split up in smaller pieces. So this is the second patch set. Note that the pull requests need to be done in order since there are dependencies between them. Regards, Hans The following changes since commit 59834c3c791a01d9b7e460bf90d7ec4b47aaeab8: media: i2c: ths7303: make the pdata as a constant pointer (2013-06-13 08:14:07 +0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.11b for you to fetch changes up to 4cb7bf1ce4051911ae658f55e0d480246de9b727: v4l2-framework: replace g_chip_ident by g_std in the examples. (2013-06-13 08:15:20 +0200) Hans Verkuil (30): v4l2-ioctl: dbg_g/s_register: only match BRIDGE and SUBDEV types. v4l2: remove g_chip_ident from bridge drivers where it is easy to do so. cx18: remove g_chip_ident support. saa7115: add back the dropped 'found' message. ivtv: remove g_chip_ident cx23885: remove g_chip_ident. saa6752hs: drop obsolete g_chip_ident. gspca: remove g_chip_ident cx231xx: remove g_chip_ident. marvell-ccic: remove g_chip_ident. tveeprom: remove v4l2-chip-ident.h include. au8522_decoder: remove g_chip_ident op. radio: remove g_chip_ident op. indycam: remove g_chip_ident op. soc_camera sensors: remove g_chip_ident op. media/i2c: remove g_chip_ident op. cx25840: remove the v4l2-chip-ident.h include saa7134: check register address in g_register. mxb: check register address when reading/writing a register. vpbe_display: drop g/s_register ioctls. marvell-ccic: check register address. au0828: set reg-size. cx231xx: the reg-size field wasn't filled in. sn9c20x: the reg-size field wasn't filled in. pvrusb2: drop g/s_register ioctls. media/i2c: fill in missing reg-size fields. cx18: fix register range check ivtv: fix register range check DocBook/media/v4l: update VIDIOC_DBG_ documentation v4l2-framework: replace g_chip_ident by g_std in the examples. Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml |3 +- Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml | 15 ++- Documentation/video4linux/v4l2-framework.txt | 13 ++- Documentation/zh_CN/video4linux/v4l2-framework.txt | 13 ++- drivers/media/common/saa7146/saa7146_video.c | 23 - drivers/media/common/tveeprom.c| 142 +-- drivers/media/dvb-frontends/au8522_decoder.c | 17 drivers/media/i2c/ad9389b.c| 21 +--- drivers/media/i2c/adv7170.c| 13 --- drivers/media/i2c/adv7175.c|9 -- drivers/media/i2c/adv7180.c| 10 -- drivers/media/i2c/adv7183.c| 22 - drivers/media/i2c/adv7343.c| 10 -- drivers/media/i2c/adv7393.c| 10 -- drivers/media/i2c/adv7604.c| 18 drivers/media/i2c/ak881x.c | 35 +-- drivers/media/i2c/bt819.c | 14 --- drivers/media/i2c/bt856.c |9 -- drivers/media/i2c/bt866.c | 13 --- drivers/media/i2c/cs5345.c | 17 drivers/media/i2c/cs53l32a.c | 10 -- drivers/media/i2c/cx25840/cx25840-core.c | 64 + drivers/media/i2c/cx25840/cx25840-core.h | 34 --- drivers/media/i2c/ks0127.c | 16 drivers/media/i2c/m52790.c | 15 --- drivers/media/i2c/msp3400-driver.c | 10 -- drivers/media/i2c/mt9m032.c|9 +- drivers/media/i2c/mt9p031.c|1 - drivers/media/i2c/mt9v011.c| 24 - drivers/media/i2c/noon010pc30.c|1 - drivers/media/i2c/ov7640.c |1 - drivers/media/i2c/ov7670.c | 17 drivers/media/i2c/saa6588.c|9 -- drivers/media/i2c/saa7110.c|9 -- drivers/media/i2c/saa7115.c| 107 ++--- drivers/media/i2c/saa7127.c| 47 - drivers/media/i2c/saa717x.c|7 -- drivers/media/i2c/saa7185.c|9 -- drivers/media/i2c/saa7191.c|
[GIT PULL FOR v3.11] Updates Part 3
Mauro prefers to have the original large pull request split up in smaller pieces. So this is the third patch set. This patch set merges these patch series: Control framework conversions: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62772.html Removal of current_norm: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62914.html Note: patch 5 was dropped. It was 1) broken, and 2) not related to current_norm anyway. A fixed version will be posted separately. Note that the pull requests need to be done in order since there are dependencies between them. Regards, Hans The following changes since commit 4cb7bf1ce4051911ae658f55e0d480246de9b727: v4l2-framework: replace g_chip_ident by g_std in the examples. (2013-06-13 08:15:20 +0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.11c for you to fetch changes up to 992df036e18da2333d10be0d8451592502f4d3cd: v4l2: remove deprecated current_norm support completely. (2013-06-13 08:16:51 +0200) Hans Verkuil (33): saa7706h: convert to the control framework. sr030pc30: convert to the control framework. saa6752hs: convert to the control framework. radio-tea5764: add support for struct v4l2_device. radio-tea5764: embed struct video_device. radio-tea5764: convert to the control framework. radio-tea5764: audio and input ioctls do not apply to radio devices. radio-tea5764: add device_caps support. radio-tea5764: add prio and control event support. radio-tea5764: some cleanups and clamp frequency when out-of-range radio-timb: add device_caps support, remove input/audio ioctls. radio-timb: convert to the control framework. radio-timb: actually load the requested subdevs radio-timb: add control events and prio support. tef6862: clamp frequency. timblogiw: fix querycap. radio-sf16fmi: remove audio/input ioctls. radio-sf16fmi: add device_caps support to querycap. radio-sf16fmi: clamp frequency. radio-sf16fmi: convert to the control framework. radio-sf16fmi: add control event and prio support. mcam-core: replace current_norm by g_std. via-camera: replace current_norm by g_std. sh_vou: remove current_norm soc_camera: remove use of current_norm. fsl-viu: remove current_norm. tm6000: remove deprecated current_norm saa7164: replace current_norm by g_std cx23885: remove use of deprecated current_norm usbvision: replace current_norm by g_std. saa7134: drop deprecated current_norm. dt3155v4l: remove deprecated current_norm v4l2: remove deprecated current_norm support completely. drivers/media/i2c/sr030pc30.c | 276 ++- drivers/media/pci/cx23885/cx23885-417.c |5 +- drivers/media/pci/cx23885/cx23885-video.c |7 +- drivers/media/pci/saa7134/saa6752hs.c | 457 +--- drivers/media/pci/saa7134/saa7134-empress.c |1 - drivers/media/pci/saa7134/saa7134-video.c |1 - drivers/media/pci/saa7164/saa7164-encoder.c | 13 ++- drivers/media/pci/saa7164/saa7164-vbi.c | 13 ++- drivers/media/pci/saa7164/saa7164.h |1 + drivers/media/platform/fsl-viu.c|2 +- drivers/media/platform/marvell-ccic/mcam-core.c |8 +- drivers/media/platform/sh_vou.c |3 +- drivers/media/platform/soc_camera/soc_camera.c |3 - drivers/media/platform/timblogiw.c |7 +- drivers/media/platform/via-camera.c |8 +- drivers/media/radio/radio-sf16fmi.c | 106 -- drivers/media/radio/radio-tea5764.c | 190 +++--- drivers/media/radio/radio-timb.c| 81 - drivers/media/radio/saa7706h.c | 56 ++-- drivers/media/radio/tef6862.c | 10 +- drivers/media/usb/tm6000/tm6000-cards.c |2 +- drivers/media/usb/tm6000/tm6000-video.c | 13 ++- drivers/media/usb/usbvision/usbvision-video.c | 13 ++- drivers/media/v4l2-core/v4l2-dev.c |5 +- drivers/media/v4l2-core/v4l2-ioctl.c| 34 +-- drivers/staging/media/dt3155v4l/dt3155v4l.c |1 - include/media/v4l2-dev.h|1 - 27 files changed, 449 insertions(+), 868 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.11] Updates Part 2
On Thu June 13 2013 08:28:47 Hans Verkuil wrote: Mauro prefers to have the original large pull request split up in smaller pieces. So this is the second patch set. Oops, I forgot to mention that this pulls in this patch series: DBG_G_CHIP_IDENT removal: http://www.spinics.net/lists/linux-media/msg64081.html Note: patches 7, 13, 20-23, 25 and 36 are kept back. There is a pending cx88 fix for 3.10 (http://git.linuxtv.org/media_tree.git/commit/609c4c12af79b1ba5fd2d31727a95dd3a319c0ae) that conflicts with this patch series, so once that fix is merged back from 3.10 I can finalize this patch series. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.11] Updates Part 4
Mauro prefers to have the original large pull request split up in smaller
pieces.
So this is the fourth patch set.
This pulls in these two patch series:
QUERYSTD fixes (particularly in the case of 'no signal'):
http://www.spinics.net/lists/linux-media/msg64131.html
saa7134 cleanup:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg62863.html
Note that the pull requests need to be done in order since there are
dependencies
between them.
Regards,
Hans
The following changes since commit 992df036e18da2333d10be0d8451592502f4d3cd:
v4l2: remove deprecated current_norm support completely. (2013-06-13 08:16:51
+0200)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v3.11d
for you to fetch changes up to e8f0e37498734d20a1ac500e13db0aedf023650d:
ths8200: fix two compiler warnings (2013-06-13 08:17:36 +0200)
Hans Verkuil (32):
adv7183: fix querystd
bt819: fix querystd
ks0127: fix querystd
saa7110: fix querystd
saa7115: fix querystd
saa7191: fix querystd
tvp514x: fix querystd
vpx3220: fix querystd
bttv: fix querystd
zoran: remove bogus autodetect mode in set_norm
v4l2-ioctl: clarify querystd comment.
DocBook/media/v4l: clarify the QUERYSTD documentation.
tvp5150: fix s_std support
media: i2c: ths8200: driver for TI video encoder.
saa7134: remove radio/type field from saa7134_fh
saa7134: move the overlay fields from saa7134_fh to saa7134_dev.
saa7134: move fmt/width/height from saa7134_fh to saa7134_dev
saa7134: move qos_request from saa7134_fh to saa7134_dev.
saa7134: move the queue data from saa7134_fh to saa7134_dev.
saa7134: fix format-related compliance issues.
saa7134: convert to the control framework.
saa7134: cleanup radio/video/empress ioctl handling
saa7134: fix empress format compliance bugs.
saa7134: remove dev from saa7134_fh, use saa7134_fh for empress node
saa7134: share resource management between normal and empress nodes.
saa7134: add support for control events.
saa7134: use V4L2_IN_ST_NO_SIGNAL instead of NO_SYNC
saa6752hs: drop compat control code.
saa6752hs: move to media/i2c
saa6752hs.h: drop empty header.
saa7134: drop log_status for radio.
ths8200: fix two compiler warnings
Ismael Luceno (1):
solo6x10: reimplement SAA712x setup routine
Documentation/DocBook/media/v4l/vidioc-querystd.xml |3 +-
drivers/media/i2c/Kconfig | 23 +-
drivers/media/i2c/Makefile |2 +
drivers/media/i2c/adv7183.c | 16 +-
drivers/media/i2c/bt819.c |8 +-
drivers/media/i2c/ks0127.c | 17 +-
drivers/media/{pci/saa7134 = i2c}/saa6752hs.c | 77 +++
drivers/media/i2c/saa7110.c |4 +-
drivers/media/i2c/saa7115.c |5 +-
drivers/media/i2c/saa7191.c | 14 +-
drivers/media/i2c/ths8200.c | 556
drivers/media/i2c/ths8200_regs.h| 161 ++
drivers/media/i2c/tvp514x.c | 12 +-
drivers/media/i2c/tvp5150.c |8 +-
drivers/media/i2c/vpx3220.c | 10 +-
drivers/media/pci/bt8xx/bttv-driver.c |4 +-
drivers/media/pci/saa7134/Kconfig |1 +
drivers/media/pci/saa7134/Makefile |2 +-
drivers/media/pci/saa7134/saa7134-core.c| 10 +-
drivers/media/pci/saa7134/saa7134-empress.c | 374
+
drivers/media/pci/saa7134/saa7134-vbi.c | 11 +-
drivers/media/pci/saa7134/saa7134-video.c | 1015
+++-
drivers/media/pci/saa7134/saa7134.h | 83 +---
drivers/media/pci/zoran/zoran_driver.c | 23 --
drivers/media/v4l2-core/v4l2-ioctl.c|8 +-
drivers/staging/media/solo6x10/solo6x10-tw28.c | 112 ++
include/media/saa6752hs.h | 26 ---
include/uapi/linux/v4l2-controls.h |4 +
28 files changed, 1498 insertions(+), 1091 deletions(-)
rename drivers/media/{pci/saa7134 = i2c}/saa6752hs.c (97%)
create mode 100644 drivers/media/i2c/ths8200.c
create mode 100644 drivers/media/i2c/ths8200_regs.h
delete mode 100644 include/media/saa6752hs.h
--
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
[RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-syncid=4030bdee9bab5841ad32faade528d04cc0c5fc94 https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-syncid=6ca548e9ea9e865592719ef6b1cde58366af9f5c The framework
RE: [PATCH v4] [media] mem2mem: add support for hardware buffered queue
Hi,
Pawel and Marek, I would really like to hear your opinions on this patch.
I remember that the assumption of the mem2mem framework (not to be confused
with
mem2mem type of devices) was that it was for simple devices where one output
buffer
was equivalent to one capture buffer. More complicated devices were supposed
to use
videobuf2 directly.
Please state your opinions.
Best wishes,
--
Kamil Debski
Linux Kernel Developer
Samsung RD Institute Poland
-Original Message-
From: Philipp Zabel [mailto:p.za...@pengutronix.de]
Sent: Monday, June 03, 2013 10:24 AM
To: linux-media@vger.kernel.org
Cc: Sylwester Nawrocki; Mauro Carvalho Chehab; Pawel Osciak; John Sheu;
Hans Verkuil; Kamil Debski; Andrzej Hajda; Philipp Zabel
Subject: [PATCH v4] [media] mem2mem: add support for hardware buffered
queue
On mem2mem decoders with a hardware bitstream ringbuffer, to drain the
buffer at the end of the stream, remaining frames might need to be
decoded from the bitstream buffer without additional input buffers
being provided.
To achieve this, allow a queue to be marked as buffered by the driver,
and allow scheduling of device_runs when buffered ready queues are
empty.
This also allows a driver to copy input buffers into their bitstream
ringbuffer and immediately mark them as done to be dequeued.
The motivation for this patch is hardware assisted h.264 reordering
support in the coda driver. For high profile streams, the coda can hold
back out-of-order frames, causing a few mem2mem device runs in the
beginning, that don't produce any decompressed buffer at the v4l2
capture side. At the same time, the last few frames can be decoded from
the bitstream with mem2mem device runs that don't need a new input
buffer at the v4l2 output side. The decoder command ioctl can be used
to put the decoder into the ringbuffer draining end-of-stream mode.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v3:
- Split queue_set_buffered into set_src_buffered and set_dst_buffered,
which
take a v4l2_m2m_ctx pointer instead of a vb2_queue (which isn't
guaranteed
to be embedded in a v4l2_m2m_queue_ctx).
- Make them static inline.
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 --
include/media/v4l2-mem2mem.h | 13 +
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 66f599f..1007e60 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -196,6 +196,10 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev
*m2m_dev)
* 2) at least one destination buffer has to be queued,
* 3) streaming has to be on.
*
+ * If a queue is buffered (for example a decoder hardware ringbuffer
+ that has
+ * to be drained before doing streamoff), allow scheduling without
v4l2
+ buffers
+ * on that queue.
+ *
* There may also be additional, custom requirements. In such case the
driver
* should supply a custom callback (job_ready in v4l2_m2m_ops) that
should
* return 1 if the instance is ready.
@@ -224,14 +228,16 @@ static void v4l2_m2m_try_schedule(struct
v4l2_m2m_ctx *m2m_ctx)
}
spin_lock_irqsave(m2m_ctx-out_q_ctx.rdy_spinlock, flags);
- if (list_empty(m2m_ctx-out_q_ctx.rdy_queue)) {
+ if (list_empty(m2m_ctx-out_q_ctx.rdy_queue)
+ !m2m_ctx-out_q_ctx.buffered) {
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
dprintk(No input buffers available\n);
return;
}
spin_lock_irqsave(m2m_ctx-cap_q_ctx.rdy_spinlock, flags);
- if (list_empty(m2m_ctx-cap_q_ctx.rdy_queue)) {
+ if (list_empty(m2m_ctx-cap_q_ctx.rdy_queue)
+ !m2m_ctx-cap_q_ctx.buffered) {
spin_unlock_irqrestore(m2m_ctx-cap_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-
mem2mem.h index d3eef01..a8e1bb3 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -60,6 +60,7 @@ struct v4l2_m2m_queue_ctx {
struct list_headrdy_queue;
spinlock_t rdy_spinlock;
u8 num_rdy;
+ boolbuffered;
};
struct v4l2_m2m_ctx {
@@ -132,6 +133,18 @@ struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct
v4l2_m2m_dev *m2m_dev,
void *drv_priv,
int (*queue_init)(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *dst_vq));
+static inline void v4l2_m2m_set_src_buffered(struct v4l2_m2m_ctx
*m2m_ctx,
+ bool buffered)
+{
+ m2m_ctx-out_q_ctx.buffered = buffered; }
Re: [PATCH] Revert V4L/DVB: uvc: Enable USB autosuspend by default on uvcvideo
On Thu, Apr 25, 2013 at 02:33:06PM +0800, Adam Lee wrote: On Wed, Apr 24, 2013 at 11:17:52AM +0200, Laurent Pinchart wrote: Hi Adam, Thanks for the patch. On Wednesday 24 April 2013 15:57:19 adam@canonical.com wrote: From: Adam Lee adam@canonical.com This reverts commit 3dae8b41dc5651f8eb22cf310e8b116480ba25b7. 1, I do have a Chicony webcam, implements autosuspend in a broken way, make `poweroff` performs rebooting when its autosuspend enabled. 2, There are other webcams which don't support autosuspend too, like https://patchwork.kernel.org/patch/2356141/ 3, kernel removed USB_QUIRK_NO_AUTOSUSPEND in a691efa9888e71232dfb4088fb8a8304ffc7b0f9, because autosuspend is disabled by default. So, we need to disable autosuspend in uvcvideo, maintaining a quirk list only for uvcvideo is not a good idea. I've received very few bug reports about broken auto-suspend support in UVC devices. Most of them could be solved by setting the RESET_RESUME quirk in USB core, only the Creative Live! Cam Optia AF required a quirk in the uvcvideo driver. I would thus rather use the available quirks (USB_QUIRK_RESET_RESUME if possible, UVC_QUIRK_DISABLE_AUTOSUSPEND otherwise) than killing power management for the vast majority of webcams that behave correctly. Here comes another one, integrated Chicony webcam 04f2:b39f, its autosuspend makes `poweroff` performs rebooting at the laptop I'm working on. I tried USB_QUIRK_RESET_RESUME, not helping. The quirks list will go longer and longer absolutely, do uvcvideo wanna maintain that? And why only uvcvideo do this in kernel space which against general USB module? I still suggest we disable it by default, people can enable it in udev just like almost all distroes do for udisks. Please consider about it. Hi, Laurent Any comment of this? I still think it's a risk to enable autosuspend in uvcvideo by default, there must be users meeting weird issues but didn't report to you becaue they didn't figured out the cause. -- Regards, Adam Lee Hardware Enablement -- 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 v4] [media] mem2mem: add support for hardware buffered queue
On 06/13/2013 11:45 AM, Kamil Debski wrote:
Pawel and Marek, I would really like to hear your opinions on this patch.
I remember that the assumption of the mem2mem framework (not to be confused
with
mem2mem type of devices) was that it was for simple devices where one output
buffer
was equivalent to one capture buffer. More complicated devices were supposed
to use videobuf2 directly.
Please state your opinions.
Best wishes,
--
Kamil Debski
Linux Kernel Developer
Samsung RD Institute Poland
-Original Message-
From: Philipp Zabel [mailto:p.za...@pengutronix.de]
Sent: Monday, June 03, 2013 10:24 AM
To: linux-media@vger.kernel.org
Cc: Sylwester Nawrocki; Mauro Carvalho Chehab; Pawel Osciak; John Sheu;
Hans Verkuil; Kamil Debski; Andrzej Hajda; Philipp Zabel
Subject: [PATCH v4] [media] mem2mem: add support for hardware buffered
queue
On mem2mem decoders with a hardware bitstream ringbuffer, to drain the
buffer at the end of the stream, remaining frames might need to be
decoded from the bitstream buffer without additional input buffers
being provided.
To achieve this, allow a queue to be marked as buffered by the driver,
and allow scheduling of device_runs when buffered ready queues are
empty.
This also allows a driver to copy input buffers into their bitstream
ringbuffer and immediately mark them as done to be dequeued.
The motivation for this patch is hardware assisted h.264 reordering
support in the coda driver. For high profile streams, the coda can hold
back out-of-order frames, causing a few mem2mem device runs in the
beginning, that don't produce any decompressed buffer at the v4l2
capture side. At the same time, the last few frames can be decoded from
the bitstream with mem2mem device runs that don't need a new input
buffer at the v4l2 output side. The decoder command ioctl can be used
to put the decoder into the ringbuffer draining end-of-stream mode.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
As far as I'm concerned this change looks like something useful upstream,
it's really a simple modification and it makes the in-kernel m2m framework
more universal and useful for more drivers. But that's just my personal
opinion.
:-)
Thanks,
Sylwester
---
Changes since v3:
- Split queue_set_buffered into set_src_buffered and set_dst_buffered,
which
take a v4l2_m2m_ctx pointer instead of a vb2_queue (which isn't
guaranteed
to be embedded in a v4l2_m2m_queue_ctx).
- Make them static inline.
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 10 --
include/media/v4l2-mem2mem.h | 13 +
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 66f599f..1007e60 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -196,6 +196,10 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev
*m2m_dev)
* 2) at least one destination buffer has to be queued,
* 3) streaming has to be on.
*
+ * If a queue is buffered (for example a decoder hardware ringbuffer
+ that has
+ * to be drained before doing streamoff), allow scheduling without
v4l2
+ buffers
+ * on that queue.
+ *
* There may also be additional, custom requirements. In such case the
driver
* should supply a custom callback (job_ready in v4l2_m2m_ops) that
should
* return 1 if the instance is ready.
@@ -224,14 +228,16 @@ static void v4l2_m2m_try_schedule(struct
v4l2_m2m_ctx *m2m_ctx)
}
spin_lock_irqsave(m2m_ctx-out_q_ctx.rdy_spinlock, flags);
- if (list_empty(m2m_ctx-out_q_ctx.rdy_queue)) {
+ if (list_empty(m2m_ctx-out_q_ctx.rdy_queue)
+ !m2m_ctx-out_q_ctx.buffered) {
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
dprintk(No input buffers available\n);
return;
}
spin_lock_irqsave(m2m_ctx-cap_q_ctx.rdy_spinlock, flags);
- if (list_empty(m2m_ctx-cap_q_ctx.rdy_queue)) {
+ if (list_empty(m2m_ctx-cap_q_ctx.rdy_queue)
+ !m2m_ctx-cap_q_ctx.buffered) {
spin_unlock_irqrestore(m2m_ctx-cap_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_ctx-out_q_ctx.rdy_spinlock,
flags);
spin_unlock_irqrestore(m2m_dev-job_spinlock, flags_job);
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-
mem2mem.h index d3eef01..a8e1bb3 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -60,6 +60,7 @@ struct v4l2_m2m_queue_ctx {
struct list_headrdy_queue;
spinlock_t rdy_spinlock;
u8 num_rdy;
+ boolbuffered;
};
struct v4l2_m2m_ctx {
@@ -132,6 +133,18 @@ struct v4l2_m2m_ctx
Re: [PATCH v10 15/21] V4L2: add a device pointer to struct v4l2_subdev
On Tue 11 June 2013 10:23:42 Guennadi Liakhovetski wrote:
It is often useful to have simple means to get from a subdevice to the
underlying physical device. This patch adds such a pointer to struct
v4l2_subdev and sets it accordingly in the I2C and SPI cases.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/v4l2-core/v4l2-common.c |2 ++
include/media/v4l2-subdev.h |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index 3fed63f..accfec6 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -291,6 +291,7 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd, struct
i2c_client *client,
sd-flags |= V4L2_SUBDEV_FL_IS_I2C;
/* the owner is the same as the i2c_client's driver owner */
sd-owner = client-driver-driver.owner;
+ sd-dev = client-dev;
/* i2c_client and v4l2_subdev point to one another */
v4l2_set_subdevdata(sd, client);
i2c_set_clientdata(client, sd);
@@ -426,6 +427,7 @@ void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct
spi_device *spi,
sd-flags |= V4L2_SUBDEV_FL_IS_SPI;
/* the owner is the same as the spi_device's driver owner */
sd-owner = spi-dev.driver-owner;
+ sd-dev = spi-dev;
/* spi_device and v4l2_subdev point to one another */
v4l2_set_subdevdata(sd, spi);
spi_set_drvdata(spi, sd);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5298d67..d8756fa 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -585,6 +585,8 @@ struct v4l2_subdev {
void *host_priv;
/* subdev device node */
struct video_device *devnode;
+ /* pointer to the physical device */
Can you change this comment to:
/* pointer to the physical device, if any */
It's a small change, but this makes it clear that it's OK to leave it to
NULL for subdevs that don't have an underlying device struct.
Thanks!
Hans
+ struct device *dev;
};
#define media_entity_to_v4l2_subdev(ent) \
--
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: 3.9.2 kernel - IR / em28xx_rc broken?
Hi, Sorry for not getting into it earlier... too much work those days. Em Mon, 20 May 2013 17:36:46 +0200 Frank Schäfer fschaefer@googlemail.com escreveu: Am 20.05.2013 16:51, schrieb Chris Rankin: - Original Message - If I had to guess, I would say you should check your rc_maps.cfg / keytable. ;) This is unchanged between 3.8.x and 3.9.x, and so is correct by definition. No, just because it didn't change it isn't automatically correct. ;) Which protocol type does you keytable specify/select ? It should be RC5. If it's none or unknown, it's just dump luck that things are working (because the driver fortunately configures the device for RC5 in case of RC_BIT_UNKNOWN). The RC_BIT_UNKNOWN has 3 usages: 1) when the protocol is unknown; 2) on legacy tables, when the full scancode is unknown; 3) on broken devices where just the command part of the scancode (7 or 8 bits) is known. In the case of em28xx, only (2) applies. So, the behavior on em28xx is to support legacy IR tables written using the legacy input layer, that use to support only 8 bits for keycodes. So, we don't know the address bits of the keycodes. The expected behavior on em28xx when RC_BIT_UNKNOWN is used, is that the keycode tables would be 8-bits masked, and the same mask should also be applied to the received keycodes. This is done by the RC core. That is used only by a very few set of em28xx cards: $ for i in $(git grep RC_MAP_ $(git grep -l _UNKNOWN drivers/media/rc/keymaps/)|perl -ne 'print $1\n if (m/(RC_MAP_[\w\d\_]+)/)');do git grep $i drivers/media/usb/em28xx/; done drivers/media/usb/em28xx/em28xx-cards.c: .ir_codes = RC_MAP_ATI_TV_WONDER_HD_600, drivers/media/usb/em28xx/em28xx-input.c: rc-map_name = RC_MAP_EM_TERRATEC; drivers/media/usb/em28xx/em28xx-cards.c: .ir_codes = RC_MAP_EVGA_INDTUBE, drivers/media/usb/em28xx/em28xx-cards.c: .ir_codes = RC_MAP_GADMEI_RM008Z, drivers/media/usb/em28xx/em28xx-cards.c: .ir_codes = RC_MAP_KAIOMY, drivers/media/usb/em28xx/em28xx-input.c: rc-map_name = RC_MAP_PINNACLE_GREY; drivers/media/usb/em28xx/em28xx-cards.c: .ir_codes = RC_MAP_TERRATEC_CINERGY_XS, drivers/media/usb/em28xx/em28xx-cards.c: .ir_codes = RC_MAP_TERRATEC_CINERGY_XS, drivers/media/usb/em28xx/em28xx-input.c: rc-map_name = RC_MAP_WINFAST_USBII_DELUXE; drivers/media/usb/em28xx/em28xx-input.c: rc-map_name = RC_MAP_WINFAST_USBII_DELUXE; Patches are welcome to replace the above scancode tables by one with the full code, as we want to use RC_BIT_UNKNOWN only on broken hardware where the scancode is only partially filled. Btw, the bits that handles the masks are at rc-main.c, at ir_establish_scancode(): if (dev-scanmask) scancode = dev-scanmask; A quick look at em28xx shows that it is not using it anymore, so some patch likely broke support for RC_BIT_UNKNOWN there. So, a fix is needed there to fill dev-scanmask if a RC_BIT_UNKNOWN table is used. It should be noticed that tables with RC_BIT_UNKNOWN are generally not portable among devices, as some of those tables have the command bits inverted. Kernel Upgrades Do Not Break Userspace. Right. That's why I would say the third (scancode) change is problematic. Let's see what Mauro thinks about this. For legacy tables, only 16 bits are needed (as all those tables are for either RC5 or NEC), in the form of addrcmd and dev-scanmask should be 0xff. The rationale to not mask the scancode to contain just the cmd part is that the produced debug messages could be used by someone to identify the address for those broken IR keytables and write a patch for us fixing it. 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: 3.9.2 kernel - IR / em28xx_rc broken?
Em Mon, 20 May 2013 06:01:09 -0700 (PDT) Chris Rankin ranki...@yahoo.com escreveu: - Original Message - And this is me calling ir-keytable: [ 2183.812407] em28xx #0: Changing protocol: rc_type=1 So with 3.8 the same happens as with 3.9. Yes, that does appear to be part of the RC core ABI. Well, if ir-keycode / the RC core requests RC_BIT_UNKNOWN, they get RC_BIT_UNKNOWN. ;) If you expect the device to be configured for another protocol (RC5 ?), you need to find out what's going wrong in the RC core and/or ir-keycode. Are other RCs affected by this? I have difficulty blaming RC core when its behaviour hasn't changed. The point is that 3.8 ignores rc_type=1, whereas 3.9 uses it to update a new ir-rc_type field - which in turn controls how em2874_polling_getkey() encodes its scancode. There's something broken at either the tool or at the table, as the it shouldn't be passing rc_type=1. Ah, I know what's happening... thare are actually two hauppauge tables: $ grep haupp rc_maps.cfg # cx8800* ./keycodes/rc5_hauppauge_new # * * ./keycodes/rc5_hauppauge_new * rc-hauppauge hauppauge # * *haupp# found in nova-t-usb2.c The proper one is the hauppauge one. The haupp table is an alternative (broken) one for a driver that was not properly converted to the RC core yet. On that driver, the table is coded directly inside the driver. It shouldn't be hard to fix it there, but that requires someone with that hardware, in order to test it, and convert it to use dvb-usb-v2. If you're using that table, it will try to set the protocol to unknown, with is wrong, and have an unpredictable result, as, on some boards, the em28xx will be working with NEC protocol, while, on others, with RC5. You should, instead, use this table: $ more keytable/rc_keymaps/hauppauge # table hauppauge, type: RC5 0x1e3b KEY_SELECT 0x1e3d KEY_POWER2 0x1e1c KEY_TV 0x1e18 KEY_VIDEO 0x1e19 KEY_AUDIO 0x1e1a KEY_CAMERA 0x1e1b KEY_EPG 0x1e0c KEY_RADIO 0x1e14 KEY_UP 0x1e15 KEY_DOWN 0x1e16 KEY_LEFT 0x1e17 KEY_RIGHT 0x1e25 KEY_OK ... There, the protocol there seems to be properly identified as RC5, and the ir-keytable will use RC5 type when setting it. 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: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
+static void dmabuf_sync_timeout_worker(struct work_struct *work)
+{
+ struct dmabuf_sync *sync = container_of(work, struct dmabuf_sync,
work);
+ struct dmabuf_sync_object *sobj;
+
+ mutex_lock(sync-lock);
+
+ list_for_each_entry(sobj, sync-syncs, head) {
+ if (WARN_ON(!sobj-robj))
+ continue;
+
+ printk(KERN_WARNING %s: timeout = 0x%x [type = %d, \
+ refcnt = %d, locked = %d]\n,
+ sync-name, (u32)sobj-dmabuf,
+ sobj-access_type,
+
atomic_read(sobj-robj-shared_cnt),
+ sobj-robj-locked);
+
+ /* unlock only valid sync object. */
+ if (!sobj-robj-locked)
+ continue;
+
+ if (sobj-robj-shared
+ atomic_read(sobj-robj-shared_cnt) 1) {
+ atomic_dec(sobj-robj-shared_cnt);
+ continue;
+ }
+
+ ww_mutex_unlock(sobj-robj-lock);
+
+ if (sobj-access_type DMA_BUF_ACCESS_READ)
+ printk(KERN_WARNING %s: r-unlocked = 0x%x\n,
+ sync-name, (u32)sobj-dmabuf);
+ else
+ printk(KERN_WARNING %s: w-unlocked = 0x%x\n,
+ sync-name, (u32)sobj-dmabuf);
+
+#if defined(CONFIG_DEBUG_FS)
+ sync_debugfs_timeout_cnt++;
+#endif
Oops, unnecessary codes. will remove them.
--
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: [RFC] Add query/get/set matrix ioctls
On 06/12/2013 04:47 PM, Hans Verkuil wrote:
On Wed June 12 2013 16:07:48 Andrzej Hajda wrote:
Hi Hans and Sylwester,
I would like to add my two cents.
On 06/12/2013 10:35 AM, Hans Verkuil wrote:
On Tue 11 June 2013 23:33:42 Sylwester Nawrocki wrote:
Hi Hans,
On 06/03/2013 02:14 PM, Hans Verkuil wrote:
Hi all,
When working on the Motion Detection API, I realized that my proposal for
two new G/S_MD_BLOCKS ioctls was too specific for the motion detection use
case.
The Motion Detection RFC can be found here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html
What I was really attempting to do was to create an API to pass a matrix
to the hardware.
This is also related to a long-standing request to add support for
arrays to the control API. Adding such support to the control API is in my
opinion a very bad idea since the control API is meant to provide all
meta data necessary in order to create e.g. control panels. Adding array
support to the control API would make that very difficult, particularly
with respect to GUI design.
So instead this proposal creates a new API to query, get and set matrices:
This looks very interesting, one use case that comes immediately to mind is
configuring the quantization/Huffman tables in a hardware JPEG codec.
The only
thing left would have probably been setting up the comment segments,
consisting
of arbitrary byte strings.
Actually, I realized that that can be handled as well since those segments
are 1-dimensional matrices of unsigned chars.
Treating array of chars as matrix seems for me to be an abuse. Why not
treat any blob of data as a matrix of chars with one row?
Additionally passing string from/to driver via VIDIOC_G/S_MATRIX seems
awkward.
It's not a string. If it was a string, then we could use a control. It is
literally a blob of data that can be inserted into a comment segment.
The alternative is to create a new ioctl to do just this, but that's a lot
of work and it can be just as well by this ioctl. Since we assign this a
specific type ('JPEG_COMMENT' or something) we can prevent it from being
abused.
But claiming that blob of data/jpeg comment is a matrix seems
to be an abuse itself.
I try to show here that instead of encapsulating different entities into
a matrix maybe better is to create little more general ioctls.
This is even more nice than your previous proposal ;) Quite generic - but
I was wondering, what if we went one step further and defined QUERY/GET/
SET_PROPERTY ioctls, where the type (matrix or anything else) would be
also configurable ? :-) Just brainstorming, if memory serves me well few
people suggested something like this in the past.
The problem with that is that you basically create a meta-ioctl. Why not
just create an ioctl for whatever you want to do? After all, an ioctl is
basically a type (the command number) and a pointer. And with a property
ioctl you really just wrap that into another ioctl.
Those ioctls would share similar scheme (QUERY/SET/GET) and similar
purpose - passing some properties between user space and kernel, I think
this could be a good reason to use three ioctls instead of 3xN.
On the outside it looks like you have just three ioctls, but in the kernel
you promptly have a switch on the type that effectively acts as an ioctl
command. So you gain nothing, it's just an obfuscation layer.
Say you have two ioctls:
S_FOO(struct v4l2_foo *p)
S_BAR(struct v4l2_bar *p)
With properties you would implement it like this:
struct v4l2_prop {
__u32 type;
union {
struct v4l2_foo foo;
struct v4l2_bar bar;
};
};
S_PROP(struct v4l2_prop)
What does that gain you? It looks shorter, but in the kernel you have to
do a switch (type) everywhere you deal with properties. That's no different
than using switch (cmd) when dealing with an ioctl.
The same is with v4l2_query_matrix - you should also use switch(type)
or similar constructs on the kernel side.
I see there would be more common code in matrices of different types
but I guess properly designed properties could also allow to optimize
code for similar types.
So for the starters we could have matrix type and carefully be adding in
the future anything what's needed ?
/* Define to which motion detection region each element belongs.
* Each element is a __u8. */
#define V4L2_MATRIX_TYPE_MD_REGION (1)
/* Define the motion detection threshold for each element.
* Each element is a __u16. */
#define V4L2_MATRIX_TYPE_MD_THRESHOLD (2)
/**
* struct v4l2_query_matrix - VIDIOC_QUERY_MATRIX argument
* @type: matrix type
* @index: matrix index of the given type
* @columns:number of columns in the matrix
* @rows: number of rows in the matrix
* @elem_min: minimum matrix element value
* @elem_max: maximum matrix element value
* @elem_size: size in bytes each matrix element
* @reserved:
Re: [PATCH v6] V4L2: soc_camera: Renesas R-Car VIN driver
Hi Sergei
Patches, that this commit is based upon are hopefully moving towards the
mainline, but it's still possible, that some more changes will be
required. In any case, I wanted to comment to this version to let you
prepare for a new version in advance.
In general - looks better!
On Fri, 24 May 2013, Sergei Shtylyov wrote:
From: Vladimir Barinov vladimir.bari...@cogentembedded.com
Add Renesas R-Car VIN (Video In) V4L2 driver.
Based on the patch by Phil Edworthy phil.edwor...@renesas.com.
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
[Sergei: removed deprecated IRQF_DISABLED flag, reordered/renamed 'enum
chip_id'
values, reordered rcar_vin_id_table[] entries, removed senseless parens from
to_buf_list() macro, used ALIGN() macro in rcar_vin_setup(), added {} to the
*if* statement and used 'bool' values instead of 0/1 where necessary,
removed
unused macros, done some reformatting and clarified some comments.]
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
[snip]
Index: media_tree/drivers/media/platform/soc_camera/rcar_vin.c
===
--- /dev/null
+++ media_tree/drivers/media/platform/soc_camera/rcar_vin.c
@@ -0,0 +1,1476 @@
+/*
+ * SoC-camera host driver for Renesas R-Car VIN unit
+ *
+ * Copyright (C) 2011-2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Cogent Embedded, Inc., sou...@cogentembedded.com
+ *
+ * Based on V4L2 Driver for SuperH Mobile CEU interface
sh_mobile_ceu_camera.c
+ *
+ * Copyright (C) 2008 Magnus Damm
+ *
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/platform_data/camera-rcar.h
l before m please :)
[snip]
+static void rcar_vin_setup(struct rcar_vin_priv *priv)
+{
+ struct soc_camera_device *icd = priv-icd;
+ struct rcar_vin_cam *cam = icd-host_priv;
+ u32 vnmc, dmr, interrupts;
+ bool progressive = false, output_is_yuv = false;
+
+ switch (priv-field) {
+ case V4L2_FIELD_TOP:
+ vnmc = VNMC_IM_ODD;
+ break;
+ case V4L2_FIELD_BOTTOM:
+ vnmc = VNMC_IM_EVEN;
+ break;
+ case V4L2_FIELD_INTERLACED:
+ case V4L2_FIELD_INTERLACED_TB:
+ vnmc = VNMC_IM_FULL;
+ break;
+ case V4L2_FIELD_INTERLACED_BT:
+ vnmc = VNMC_IM_FULL | VNMC_FOC;
+ break;
+ case V4L2_FIELD_NONE:
+ if (is_continuous_transfer(priv)) {
+ vnmc = VNMC_IM_ODD_EVEN;
+ progressive = true;
+ } else {
+ vnmc = VNMC_IM_ODD;
+ }
+ break;
+ default:
+ vnmc = VNMC_IM_ODD;
+ break;
+ }
+
+ /* input interface */
+ switch (icd-current_fmt-code) {
+ case V4L2_MBUS_FMT_YUYV8_1X16:
+ /* BT.601/BT.1358 16bit YCbCr422 */
+ vnmc |= VNMC_INF_YUV16;
+ break;
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ /* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
+ vnmc |= priv-pdata-flags RCAR_VIN_BT656 ?
+ VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
+ default:
+ break;
+ }
+
+ /* output format */
+ switch (icd-current_fmt-host_fmt-fourcc) {
+ case V4L2_PIX_FMT_NV16:
+ iowrite32(ALIGN(cam-width * cam-height, 0x80),
+ priv-base + VNUVAOF_REG);
+ dmr = VNDMR_DTMD_YCSEP;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_YUYV:
+ dmr = VNDMR_BPSM;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_UYVY:
+ dmr = 0;
+ output_is_yuv = true;
+ break;
+ case V4L2_PIX_FMT_RGB555X:
+ dmr = VNDMR_DTMD_ARGB1555;
+ break;
+ case V4L2_PIX_FMT_RGB565:
+ dmr = 0;
+ break;
+ case V4L2_PIX_FMT_RGB32:
+ if (priv-chip == RCAR_H1 || priv-chip == RCAR_E1) {
+ dmr = VNDMR_EXRGB;
+ break;
+ }
+ default:
+ dev_warn(icd-parent, Invalid fourcc format (0x%x)\n,
+ icd-current_fmt-host_fmt-fourcc);
I'll put a marker here for now: I don't understand the logic - either you
don't support this case, then you should either fail somehow or switch to
a supported case, or you do support it, then you don't need a warning
[snip]
+static void
is there a user mailing list?
the developer list is very busy... I'm successfully using mmap but now wish to improve my understanding... in particular how to get the values of a frame in the buffer? write(STDOUT_FILENO, buffers[buf.index].start, Buffersize); sends one frame from the buffer to stdout what would be the syntax to iterate through that frame of the buffer? ie to get each of the 0-255 values for a frame regards -- Jonathan Chetwynd http://www.gnote.org Eyetracking in HTML5 -- 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: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
On Thu, Jun 13, 2013 at 05:28:08PM +0900, Inki Dae wrote: This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-syncid=4030bdee9bab5841ad32faade528d04cc0c5fc94
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Jun 13 19:00:23 CEST 2013 git branch: test git hash: dd8c393b3c39f7ebd9ad69ce50cc836773d512b6 gcc version:i686-linux-gcc (GCC) 4.8.0 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.10-rc1-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.10-rc1-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl28xxu IR remote
I think the most easiest way could be compile install whole Kernel from my tree. It is 3.10-rc4 + some fixes. Ok, but I first tried the easier alternative you advised below. media_build.git has also option to fetch developer git tree from linuxtv.org. Something like ./build --git git://linuxtv.org/anttip/media_tree.git rtl28xxu . That approach seem to be not documented on wiki: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Thanks for the suggestion. It is documented only in ./build --help, it seems. I tried this latter way, it built succesfully, but the modules won't work: modprobe --force dvb_usb_rtl28xxu gives err kernel: dvb_core: exports duplicate symbol dvb_ca_en50221_camchange_irq (owned by kernel) -- 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 v10 16/21] V4L2: support asynchronous subdevice registration
Hi Guennadi,
Overall it looks quite neat at this v10. :)
On 06/11/2013 10:23 AM, Guennadi Liakhovetski wrote:
Currently bridge device drivers register devices for all subdevices
synchronously, tupically, during their probing. E.g. if an I2C CMOS sensor
s/tupically/typically
is attached to a video bridge device, the bridge driver will create an I2C
+/**
+ * v4l2_async_subdev_list - provided by subdevices
+ * @list: links struct v4l2_async_subdev_list objects to a global list
+ * before probing, and onto notifier-done after probing
+ * @asd: pointer to respective struct v4l2_async_subdev
+ * @notifier: pointer to managing notifier
+ */
+struct v4l2_async_subdev_list {
+ struct list_head list;
+ struct v4l2_async_subdev *asd;
+ struct v4l2_async_notifier *notifier;
+};
I have a patch for this patch, which embeds members of this struct directly
into struct v4l2_subdev. My felling is that the code is simpler and easier
to follow this way, I might be missing some important details though.
+/**
+ * v4l2_async_notifier - v4l2_device notifier data
+ * @subdev_num:number of subdevices
+ * @subdev:array of pointers to subdevices
How about changing this to:
@subdevs: array of pointers to the subdevice descriptors
I think it would be more immediately clear this is the actual subdevs array
pointer, and perhaps we could have subdev_num renamed to num_subdevs ?
+ * @v4l2_dev: pointer to struct v4l2_device
+ * @waiting: list of struct v4l2_async_subdev, waiting for their drivers
+ * @done: list of struct v4l2_async_subdev_list, already probed
+ * @list: member in a global list of notifiers
+ * @bound: a subdevice driver has successfully probed one of subdevices
+ * @complete: all subdevices have been probed successfully
+ * @unbind:a subdevice is leaving
+ */
+struct v4l2_async_notifier {
+ unsigned int subdev_num;
+ struct v4l2_async_subdev **subdev;
+ struct v4l2_device *v4l2_dev;
+ struct list_head waiting;
+ struct list_head done;
+ struct list_head list;
+ int (*bound)(struct v4l2_async_notifier *notifier,
+struct v4l2_subdev *subdev,
+struct v4l2_async_subdev *asd);
+ int (*complete)(struct v4l2_async_notifier *notifier);
+ void (*unbind)(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *subdev,
+ struct v4l2_async_subdev *asd);
+};
+
+int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
+struct v4l2_async_notifier *notifier);
+void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier);
+int v4l2_async_register_subdev(struct v4l2_subdev *sd);
+void v4l2_async_unregister_subdev(struct v4l2_subdev *sd);
I still think async_ in this public API is unnecessary, since we register/
unregister a subdev with the core and notifiers are intrinsically
asynchronous.
But your preference seems be otherwise, what could I do... :) At most it
just
means one less happy user of this interface.
So except this bikeshedding I don't really have other comments, I'm
going to
test this series with the s3c-camif/ov9650 drivers and will report back
soon.
It would have been a shame to not have this series in 3.11. I guess three
kernel cycles, since the initial implementation, time frame is sufficient
for having finally working camera devices on a device tree enabled system
in mainline.
Thanks for the idea and patience during reviews! :)
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L2: Merge struct v4l2_async_subdev_list with struct v4l2_subdev
From: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Please consider squashing such change or similar into patch
[PATCH v10 16/21] V4L2: support asynchronous subdevice registration
This patch has not been tested yet.
---
drivers/media/v4l2-core/v4l2-async.c | 67 +++---
include/media/v4l2-async.h | 15 +---
include/media/v4l2-subdev.h | 13 +++
3 files changed, 36 insertions(+), 59 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 3590ccc..53f741d 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -42,12 +42,10 @@ static LIST_HEAD(notifier_list);
static DEFINE_MUTEX(list_lock);
static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier
*notifier,
- struct
v4l2_async_subdev_list *asdl)
+ struct v4l2_subdev *sd)
{
- struct v4l2_subdev *sd = v4l2_async_to_subdev(asdl);
struct v4l2_async_subdev *asd;
- bool (*match)(struct device *,
- struct v4l2_async_subdev *);
+ bool (*match)(struct device *, struct v4l2_async_subdev *);
list_for_each_entry(asd, notifier-waiting, list) {
/* bus_type has been verified valid before */
@@ -79,16 +77,15 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
}
static int v4l2_async_test_notify(struct v4l2_async_notifier *notifier,
- struct v4l2_async_subdev_list *asdl,
+ struct v4l2_subdev *sd,
struct v4l2_async_subdev *asd)
{
- struct v4l2_subdev *sd = v4l2_async_to_subdev(asdl);
int ret;
/* Remove from the waiting list */
list_del(asd-list);
- asdl-asd = asd;
- asdl-notifier = notifier;
+ sd-asd = asd;
+ sd-notifier = notifier;
if (notifier-bound) {
ret = notifier-bound(notifier, sd, asd);
@@ -96,7 +93,7 @@ static int v4l2_async_test_notify(struct v4l2_async_notifier
*notifier,
return ret;
}
/* Move from the global subdevice list to notifier's done */
- list_move(asdl-list, notifier-done);
+ list_move(sd-async_list, notifier-done);
ret = v4l2_device_register_subdev(notifier-v4l2_dev, sd);
if (ret 0) {
@@ -111,21 +108,19 @@ static int v4l2_async_test_notify(struct
v4l2_async_notifier *notifier,
return 0;
}
-static void v4l2_async_cleanup(struct v4l2_async_subdev_list *asdl)
+static void v4l2_async_cleanup(struct v4l2_subdev *sd)
{
- struct v4l2_subdev *sd = v4l2_async_to_subdev(asdl);
-
v4l2_device_unregister_subdev(sd);
- /* Subdevice driver will reprobe and put asdl back onto the list */
- list_del_init(asdl-list);
- asdl-asd = NULL;
+ /* Subdevice driver will reprobe and put the subdev back onto the list
*/
+ list_del_init(sd-async_list);
+ sd-asd = NULL;
sd-dev = NULL;
}
int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
struct v4l2_async_notifier *notifier)
{
- struct v4l2_async_subdev_list *asdl, *tmp;
+ struct v4l2_subdev *sd, *tmp;
struct v4l2_async_subdev *asd;
int i;
@@ -158,14 +153,14 @@ int v4l2_async_notifier_register(struct v4l2_device
*v4l2_dev,
/* Keep also completed notifiers on the list */
list_add(notifier-list, notifier_list);
- list_for_each_entry_safe(asdl, tmp, subdev_list, list) {
+ list_for_each_entry_safe(sd, tmp, subdev_list, list) {
int ret;
- asd = v4l2_async_belongs(notifier, asdl);
+ asd = v4l2_async_belongs(notifier, sd);
if (!asd)
continue;
- ret = v4l2_async_test_notify(notifier, asdl, asd);
+ ret = v4l2_async_test_notify(notifier, sd, asd);
if (ret 0) {
mutex_unlock(list_lock);
return ret;
@@ -180,7 +175,7 @@ EXPORT_SYMBOL(v4l2_async_notifier_register);
void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier)
{
- struct v4l2_async_subdev_list *asdl, *tmp;
+ struct v4l2_subdev *sd, *tmp;
unsigned int notif_n_subdev = notifier-subdev_num;
unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS);
struct device *dev[n_subdev];
@@ -190,18 +185,16 @@ void v4l2_async_notifier_unregister(struct
v4l2_async_notifier *notifier)
list_del(notifier-list);
- list_for_each_entry_safe(asdl, tmp, notifier-done, list) {
- struct v4l2_subdev *sd = v4l2_async_to_subdev(asdl);
-
+ list_for_each_entry_safe(sd,
[RFC PATCH 1/2] tea575x: Move header from sound to media
Move include/sound/tea575x-tuner.h to include/media/tea575x.h and update files
that include it.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/media/radio/radio-maxiradio.c |2 +-
drivers/media/radio/radio-sf16fmr2.c |2 +-
drivers/media/radio/radio-shark.c |2 +-
include/media/tea575x.h | 78 +
include/sound/tea575x-tuner.h | 78 -
sound/i2c/other/tea575x-tuner.c |2 +-
sound/pci/es1968.c|2 +-
sound/pci/fm801.c |2 +-
8 files changed, 84 insertions(+), 84 deletions(-)
create mode 100644 include/media/tea575x.h
delete mode 100644 include/sound/tea575x-tuner.h
diff --git a/drivers/media/radio/radio-maxiradio.c
b/drivers/media/radio/radio-maxiradio.c
index bd4d3a7..a76712a 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -42,7 +42,7 @@
#include linux/videodev2.h
#include linux/io.h
#include linux/slab.h
-#include sound/tea575x-tuner.h
+#include media/tea575x.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include media/v4l2-fh.h
diff --git a/drivers/media/radio/radio-sf16fmr2.c
b/drivers/media/radio/radio-sf16fmr2.c
index 9c09904..f1e3714 100644
--- a/drivers/media/radio/radio-sf16fmr2.c
+++ b/drivers/media/radio/radio-sf16fmr2.c
@@ -14,7 +14,7 @@
#include linux/io.h /* outb, outb_p */
#include linux/isa.h
#include linux/pnp.h
-#include sound/tea575x-tuner.h
+#include media/tea575x.h
MODULE_AUTHOR(Ondrej Zary);
MODULE_DESCRIPTION(MediaForte SF16-FMR2 and SF16-FMD2 FM radio card driver);
diff --git a/drivers/media/radio/radio-shark.c
b/drivers/media/radio/radio-shark.c
index 8fa18ab..b914772 100644
--- a/drivers/media/radio/radio-shark.c
+++ b/drivers/media/radio/radio-shark.c
@@ -33,7 +33,7 @@
#include linux/usb.h
#include linux/workqueue.h
#include media/v4l2-device.h
-#include sound/tea575x-tuner.h
+#include media/tea575x.h
#if defined(CONFIG_LEDS_CLASS) || \
(defined(CONFIG_LEDS_CLASS_MODULE) defined(CONFIG_RADIO_SHARK_MODULE))
diff --git a/include/media/tea575x.h b/include/media/tea575x.h
new file mode 100644
index 000..098c4de
--- /dev/null
+++ b/include/media/tea575x.h
@@ -0,0 +1,78 @@
+#ifndef __SOUND_TEA575X_TUNER_H
+#define __SOUND_TEA575X_TUNER_H
+
+/*
+ * ALSA driver for TEA5757/5759 Philips AM/FM tuner chips
+ *
+ * Copyright (c) 2004 Jaroslav Kysela pe...@perex.cz
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/videodev2.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-dev.h
+#include media/v4l2-device.h
+
+#define TEA575X_FMIF 10700
+#define TEA575X_AMIF 450
+
+#define TEA575X_DATA (1 0)
+#define TEA575X_CLK(1 1)
+#define TEA575X_WREN (1 2)
+#define TEA575X_MOST (1 3)
+
+struct snd_tea575x;
+
+struct snd_tea575x_ops {
+ /* Drivers using snd_tea575x must either define read_ and write_val */
+ void (*write_val)(struct snd_tea575x *tea, u32 val);
+ u32 (*read_val)(struct snd_tea575x *tea);
+ /* Or define the 3 pin functions */
+ void (*set_pins)(struct snd_tea575x *tea, u8 pins);
+ u8 (*get_pins)(struct snd_tea575x *tea);
+ void (*set_direction)(struct snd_tea575x *tea, bool output);
+};
+
+struct snd_tea575x {
+ struct v4l2_device *v4l2_dev;
+ struct v4l2_file_operations fops;
+ struct video_device vd; /* video device */
+ int radio_nr; /* radio_nr */
+ bool tea5759; /* 5759 chip is present */
+ bool has_am;/* Device can tune to AM freqs */
+ bool cannot_read_data; /* Device cannot read the data pin */
+ bool cannot_mute; /* Device cannot mute */
+ bool mute; /* Device is muted? */
+ bool stereo;/* receiving stereo */
+ bool tuned; /* tuned to a station */
+ unsigned int val; /* hw value */
+ u32 band; /* 0: FM, 1: FM-Japan, 2: AM */
+ u32 freq; /* frequency */
+ struct mutex mutex;
+ struct snd_tea575x_ops
[RFC PATCH 2/2] tea575x: Move from sound to media
Move tea575x from sound/i2c/other to drivers/media/radio
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/media/radio/Kconfig |5 +
drivers/media/radio/Makefile|1 +
drivers/media/radio/tea575x.c | 577 +++
sound/i2c/other/Makefile|2 -
sound/i2c/other/tea575x-tuner.c | 577 ---
sound/pci/Kconfig |5 -
6 files changed, 583 insertions(+), 584 deletions(-)
create mode 100644 drivers/media/radio/tea575x.c
delete mode 100644 sound/i2c/other/tea575x-tuner.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index c0beee2..0f6341d 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -12,6 +12,11 @@ menuconfig RADIO_ADAPTERS
if RADIO_ADAPTERS VIDEO_V4L2
+config RADIO_TEA575X
+ tristate
+ depends on SND_FM801_TEA575X_BOOL || SND_ES1968_RADIO || RADIO_SF16FMR2
|| RADIO_MAXIRADIO || RADIO_SHARK
+ default SND_FM801 || SND_ES1968 || RADIO_SF16FMR2 || RADIO_MAXIRADIO ||
RADIO_SHARK
+
config RADIO_SI470X
bool Silicon Labs Si470x FM Radio Receiver support
depends on VIDEO_V4L2
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index 0dcdb32..3b64560 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
obj-$(CONFIG_RADIO_WL128X) += wl128x/
+obj-$(CONFIG_RADIO_TEA575X) += tea575x.o
shark2-objs := radio-shark2.o radio-tea5777.o
diff --git a/drivers/media/radio/tea575x.c b/drivers/media/radio/tea575x.c
new file mode 100644
index 000..a1cb208
--- /dev/null
+++ b/drivers/media/radio/tea575x.c
@@ -0,0 +1,577 @@
+/*
+ * ALSA driver for TEA5757/5759 Philips AM/FM radio tuner chips
+ *
+ * Copyright (c) 2004 Jaroslav Kysela pe...@perex.cz
+ *
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include asm/io.h
+#include linux/delay.h
+#include linux/module.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/sched.h
+#include media/v4l2-device.h
+#include media/v4l2-dev.h
+#include media/v4l2-fh.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-event.h
+#include media/tea575x.h
+
+MODULE_AUTHOR(Jaroslav Kysela pe...@perex.cz);
+MODULE_DESCRIPTION(Routines for control of TEA5757/5759 Philips AM/FM radio
tuner chips);
+MODULE_LICENSE(GPL);
+
+/*
+ * definitions
+ */
+
+#define TEA575X_BIT_SEARCH (124) /* 1 = search action, 0 = tuned
*/
+#define TEA575X_BIT_UPDOWN (123) /* 0 = search down, 1 = search
up */
+#define TEA575X_BIT_MONO (122) /* 0 = stereo, 1 = mono */
+#define TEA575X_BIT_BAND_MASK (320)
+#define TEA575X_BIT_BAND_FM(020)
+#define TEA575X_BIT_BAND_MW(120)
+#define TEA575X_BIT_BAND_LW(220)
+#define TEA575X_BIT_BAND_SW(320)
+#define TEA575X_BIT_PORT_0 (119) /* user bit */
+#define TEA575X_BIT_PORT_1 (118) /* user bit */
+#define TEA575X_BIT_SEARCH_MASK(316) /* search level */
+#define TEA575X_BIT_SEARCH_5_28 (016)/* FM 5uV, AM 28uV */
+#define TEA575X_BIT_SEARCH_10_40 (116) /* FM 10uV, AM 40uV */
+#define TEA575X_BIT_SEARCH_30_63 (216) /* FM 30uV, AM 63uV */
+#define TEA575X_BIT_SEARCH_150_1000 (316) /* FM 150uV, AM 1000uV */
+#define TEA575X_BIT_DUMMY (115) /* buffer */
+#define TEA575X_BIT_FREQ_MASK 0x7fff
+
+enum { BAND_FM, BAND_FM_JAPAN, BAND_AM };
+
+static const struct v4l2_frequency_band bands[] = {
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 0,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 87500 * 16,
+ .rangehigh = 108000 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 0,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 76000 * 16,
+
[RFC PATCH 0/2] tea575x: Move from sound to media
Hello, TEA575x is neither a sound device nor an i2c device. Let's finally move it from sound/i2c/other to drivers/media/radio. Tested with snd-es1968, snd-fm801 and radio-sf16fmr2. I guess the Kconfig dependencies are not correct. -- Ondrej Zary -- 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: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
Hi Russell, -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Friday, June 14, 2013 2:26 AM To: Inki Dae Cc: maarten.lankho...@canonical.com; dan...@ffwll.ch; robdcl...@gmail.com; linux-fb...@vger.kernel.org; dri-de...@lists.freedesktop.org; kyungmin.p...@samsung.com; myungjoo@samsung.com; yj44@samsung.com; linux-arm-ker...@lists.infradead.org; linux-media@vger.kernel.org Subject: Re: [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework On Thu, Jun 13, 2013 at 05:28:08PM +0900, Inki Dae wrote: This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or
