[PATCH for v3.18] wl128x: fix fmdbg compiler warning
fmdrv_common.c: In function 'fm_download_firmware': fmdrv_common.c:1259:2: warning: format '%d' expects argument of type 'int', but argument 3 has type 'size_t' [-Wformat=] fmdbg(Firmware(%s) length : %d bytes\n, fw_name, fw_entry-size); ^ Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/radio/wl128x/fmdrv_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c index 6f28f6e..704397f 100644 --- a/drivers/media/radio/wl128x/fmdrv_common.c +++ b/drivers/media/radio/wl128x/fmdrv_common.c @@ -1256,7 +1256,7 @@ static int fm_download_firmware(struct fmdev *fmdev, const u8 *fw_name) fmerr(Unable to read firmware(%s) content\n, fw_name); return ret; } - fmdbg(Firmware(%s) length : %d bytes\n, fw_name, fw_entry-size); + fmdbg(Firmware(%s) length : %zu bytes\n, fw_name, fw_entry-size); fw_data = (void *)fw_entry-data; fw_len = fw_entry-size; -- 2.1.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: [media] CODA960: Fails to allocate memory
Hi Philipp, 2014-10-21 18:21 GMT+02:00 Philipp Zabel p.za...@pengutronix.de: Hi Jean-Michel, Am Dienstag, den 21.10.2014, 17:39 +0200 schrieb Jean-Michel Hautbois: [...] And the output is now : v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw [ 6208.240919] coda 204.vpu: Not output type [ 6208.245316] coda 204.vpu: streamon_out (N), streamon_cap (Y) [ 6208.251353] coda 204.vpu: fill bitstream [ 6208.255653] coda 204.vpu: fill bitstream payload : 0 VIDIOC_STREAMON: failed: Invalid argument Any idea ? JM $ trace-cmd record -e v4l2* v4l2-ctl -d13 --stream-out-mmap --stream-mmap --stream-to x.raw [...] $ trace-cmd report -R | grep bytesused [...] v4l2-ctl-308 [003] 1030.861067: v4l2_qbuf: minor=44 index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861292: v4l2_qbuf: minor=44 index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861471: v4l2_qbuf: minor=44 index=2 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.861638: v4l2_qbuf: minor=44 index=3 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862301: v4l2_qbuf: minor=44 index=0 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030852944000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862490: v4l2_qbuf: minor=44 index=1 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853139000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862672: v4l2_qbuf: minor=44 index=2 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853322000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-308 [003] 1030.862841: v4l2_qbuf: minor=44 index=3 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853491000 timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 I may have misunderstand something... I try to encode, and modified the CODA_MAX_FRAME_SIZE to 0x50 just to see. And here is the trace-cmd : $ trace-cmd record -e v4l2* v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw [...] $ trace-cmd report -R | grep bytesused v4l2-ctl-1162 [000] 324.061644: v4l2_qbuf: minor=1 index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timeco de_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-1162 [000] 324.062207: v4l2_qbuf: minor=1 index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timeco de_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-1162 [000] 324.062297: v4l2_qbuf: minor=1 index=2 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timeco de_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-1162 [000] 324.062397: v4l2_qbuf: minor=1 index=3 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timeco de_seconds=0 timecode_minutes=0 timecode_hours=0
Re: [media] CODA960: Fails to allocate memory
Hi Jean-Michel, Am Mittwoch, den 22.10.2014, 11:21 +0200 schrieb Jean-Michel Hautbois: I may have misunderstand something... I try to encode, and modified the CODA_MAX_FRAME_SIZE to 0x50 just to see. And here is the trace-cmd : $ trace-cmd record -e v4l2* v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw Are you sure /dev/video1 is the encoder device? $ cat /sys/class/video4linux/video12/name coda-encoder $ cat /sys/class/video4linux/video13/name coda-decoder [...] And the bytesused is 5MB which corresponds to the 0x50... How is the encoder supposed to work precisely ? I missed something... The encoder just takes raw frames and returns encoded frames. The bitstream ringbuffer is not involved there. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed 22 Oct 10:54:01 CEST 2014 git branch: test git hash: 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.17-0.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK 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.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-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK 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.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 linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The 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: [media] CODA960: Fails to allocate memory
2014-10-22 11:29 GMT+02:00 Philipp Zabel p.za...@pengutronix.de:
Hi Jean-Michel,
Am Mittwoch, den 22.10.2014, 11:21 +0200 schrieb Jean-Michel Hautbois:
I may have misunderstand something...
I try to encode, and modified the CODA_MAX_FRAME_SIZE to 0x50 just to
see.
And here is the trace-cmd :
$ trace-cmd record -e v4l2* v4l2-ctl -d1 --stream-out-mmap
--stream-mmap --stream-to x.raw
Are you sure /dev/video1 is the encoder device?
$ cat /sys/class/video4linux/video12/name
coda-encoder
$ cat /sys/class/video4linux/video13/name
coda-decoder
Ahem you are right... :/
So, here is the trace-cmd with device 0 which is the encoder... and
this is pretty bad :(
$ trace-cmd record -e v4l2* v4l2-ctl -d0 --stream-out-mmap
--stream-mmap --stream-to x.raw
[ 1429.222887] cma: cma_alloc(cma 814923f8, count 3, align 2)
[ 1429.223856] cma: cma_alloc(): returned b7eb8f80
[ 1429.224073] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.224579] cma: cma_alloc(): returned b7ebe000
[ 1429.256453] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.258174] cma: cma_alloc(): memory range at b7ec8000 is busy, retrying
[ 1429.259623] cma: cma_alloc(): memory range at b7eca000 is busy, retrying
[ 1429.261581] cma: cma_alloc(): returned b7ecc000
[ 1429.279247] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.279618] cma: cma_alloc(): returned b7ed6000
[ 1429.293288] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.295417] cma: cma_alloc(): returned b7ee
[ 1429.309931] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.312176] cma: cma_alloc(): returned b7eea000
[ 1429.326262] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.328392] cma: cma_alloc(): returned b7ef4000
[ 1429.339247] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.339453] cma: cma_alloc(): returned b7efa000
[ 1429.349290] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.350072] cma: cma_alloc(): returned b7f0
[ 1429.359980] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.361497] cma: cma_alloc(): returned b7f06000
[ 1429.373118] coda 204.vpu: Not output type
[ 1429.377539] coda 204.vpu: streamon_out (N), streamon_cap (Y)
[ 1429.383950] coda 204.vpu: Not H264 pix fmt
[ 1429.388526] cma: cma_alloc(cma 814923f8, count 20, align 5)
[ 1429.390033] cma: cma_alloc(): returned b7ebd400
[ 1429.391953] ==
[ 1429.398137] [ INFO: possible circular locking dependency detected ]
[ 1429.404410] 3.18.0-rc1+yocto+gc943ff8 #2 Not tainted
[ 1429.409378] ---
[ 1429.415648] v4l2-ctl/1179 is trying to acquire lock:
[ 1429.420617] (sb-s_type-i_mutex_key#3){+.+.+.}, at: [802d7d9c]
__create_file+0x70/0x21c
[ 1429.429157]
but task is already holding lock:
[ 1429.434996] (dev-dev_mutex){+.+.+.}, at: [8052be98]
v4l2_ioctl+0x60/0x17c
[ 1429.442294]
which lock already depends on the new lock.
[ 1429.450477]
the existing dependency chain (in reverse order) is:
[ 1429.457964]
- #2 (dev-dev_mutex){+.+.+.}:
[ 1429.462473][807879ec] mutex_lock_interruptible_nested+0x6c/0x454
[ 1429.469379][7f000e3c] v4l2_m2m_fop_mmap+0x34/0x90 [v4l2_mem2mem]
[ 1429.476291][8052b9a8] v4l2_mmap+0x64/0x9c
[ 1429.481191][80113de8] mmap_region+0x380/0x6a0
[ 1429.486440][80114428] do_mmap_pgoff+0x320/0x3b8
[ 1429.491859][800fe504] vm_mmap_pgoff+0x74/0xa4
[ 1429.497115][80112868] SyS_mmap_pgoff+0xa4/0xcc
[ 1429.502449][8000fa40] ret_fast_syscall+0x0/0x48
[ 1429.507875]
- #1 (mm-mmap_sem){++}:
[ 1429.512208][8010bb28] might_fault+0x70/0x98
[ 1429.517290][8013e6a0] filldir64+0x7c/0x194
[ 1429.522279][80153020] dcache_readdir+0x1a4/0x25c
[ 1429.527787][8013e41c] iterate_dir+0x90/0x110
[ 1429.532946][8013e934] SyS_getdents64+0x84/0xf8
[ 1429.538278][8000fa40] ret_fast_syscall+0x0/0x48
[ 1429.543700]
- #0 (sb-s_type-i_mutex_key#3){+.+.+.}:
[ 1429.549180][8006cc3c] lock_acquire+0xb0/0x118
[ 1429.554427][80786dd4] mutex_lock_nested+0x60/0x3d4
[ 1429.560110][802d7d9c] __create_file+0x70/0x21c
[ 1429.565445][802d7f7c] debugfs_create_file+0x34/0x40
[ 1429.571212][802d830c] debugfs_create_blob+0x24/0x30
[ 1429.576981][7f022ef4] coda_alloc_aux_buf+0xa4/0x100 [coda]
[ 1429.583372][7f025080] coda_alloc_context_buffers+0xa4/0x20c [coda]
[ 1429.590451][7f026068] coda_start_encoding+0x2c/0x88c [coda]
[ 1429.596921][7f021f44] coda_start_streaming+0xb8/0x268 [coda]
[ 1429.603474][80542d04] vb2_start_streaming+0x6c/0x168
[ 1429.609337][805451d8] vb2_internal_streamon+0xfc/0x158
[ 1429.615367][80545270] vb2_streamon+0x3c/0x60
[ 1429.620527][7f00086c] v4l2_m2m_streamon+0x30/0x48 [v4l2_mem2mem]
[ 1429.627429][7f0008a4] v4l2_m2m_ioctl_streamon+0x20/0x24
[v4l2_mem2mem]
[ 1429.634851][8052d684]
[GIT PULL FOR v3.19] cx88: convert to vb2
This pull request contains this patch series: https://www.mail-archive.com/linux-media@vger.kernel.org/msg79597.html It's unchanged except for rebasing to v3.18-rc1. Regards, Hans The following changes since commit 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c: Merge tag 'v3.18-rc1' into patchwork (2014-10-21 08:32:51 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git cx88 for you to fetch changes up to ad3314ca0ea90fd7b82d0a8a72727a7cc7bd99f1: cx88: fix VBI support (2014-10-22 11:30:36 +0200) Hans Verkuil (16): cx88: remove fmt from the buffer struct cx88: drop the bogus 'queue' list in dmaqueue. cx88: drop videobuf abuse in cx88-alsa cx88: convert to vb2 cx88: fix sparse warning cx88: return proper errors during fw load cx88: drop cx88_free_buffer cx88: remove dependency on btcx-risc cx88: increase API command timeout cx88: don't pollute the kernel log cx88: move width, height and field to core struct cx88: drop mpeg_active field. cx88: don't allow changes while vb2_is_busy cx88: consistently use UNSET for absent tuner cx88: pci_disable_device comes after free_irq. cx88: fix VBI support drivers/media/pci/cx88/Kconfig | 5 +- drivers/media/pci/cx88/Makefile | 1 - drivers/media/pci/cx88/cx88-alsa.c | 112 +++-- drivers/media/pci/cx88/cx88-blackbird.c | 565 - drivers/media/pci/cx88/cx88-cards.c | 71 +++--- drivers/media/pci/cx88/cx88-core.c | 113 +++-- drivers/media/pci/cx88/cx88-dvb.c | 158 + drivers/media/pci/cx88/cx88-mpeg.c | 159 - drivers/media/pci/cx88/cx88-vbi.c | 216 + drivers/media/pci/cx88/cx88-video.c | 871 + drivers/media/pci/cx88/cx88.h | 104 - 11 files changed, 985 insertions(+), 1390 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
[GIT PULL FOR v3.19] mem2mem_testdev: rename to vim2m
This is identical to https://patchwork.linuxtv.org/patch/26044/ except for being
rebased to v3.18-rc1.
Regards,
Hans
The following changes since commit 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c:
Merge tag 'v3.18-rc1' into patchwork (2014-10-21 08:32:51 -0200)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git vim2m
for you to fetch changes up to 456e598de9719ddf0dfe69f37909759a35ab20d2:
mem2mem_testdev: rename to vim2m. (2014-10-22 11:42:32 +0200)
Hans Verkuil (1):
mem2mem_testdev: rename to vim2m.
drivers/media/platform/Kconfig| 4 +-
drivers/media/platform/Makefile | 2 +-
drivers/media/platform/{mem2mem_testdev.c = vim2m.c} | 221
+++
3 files changed, 113 insertions(+), 114 deletions(-)
rename drivers/media/platform/{mem2mem_testdev.c = vim2m.c} (81%)
--
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-ctrls: fix sparse warning
It seems I forgot about this patch and I never posted it, but it is something
that
needs to be fixed. Validating compound types could cause user pointers to be
interpreted
as kernel pointers with potentially bad results. Pawel, this is likely to be
relevant
to the codec API you are doing.
The warning is simple:
drivers/media/v4l2-core/v4l2-ctrls.c:1685:15: warning: incorrect type in
assignment (different address spaces)
but the fix isn't.
The core problem was that the conversion from user to kernelspace was
done at too low a level and that needed to be moved up. That made it possible
to drop pointers to v4l2_ext_control from set_ctrl and validate_new and
clean up this sparse warning because those functions now always operate
on kernelspace pointers.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ctrls.c | 87 +---
1 file changed, 52 insertions(+), 35 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 8601214..45c5b47 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1658,10 +1658,8 @@ static int check_range(enum v4l2_ctrl_type type,
}
/* Validate a new control */
-static int validate_new(const struct v4l2_ctrl *ctrl,
- struct v4l2_ext_control *c)
+static int validate_new(const struct v4l2_ctrl *ctrl, union v4l2_ctrl_ptr
p_new)
{
- union v4l2_ctrl_ptr ptr;
unsigned idx;
int err = 0;
@@ -1674,19 +1672,14 @@ static int validate_new(const struct v4l2_ctrl *ctrl,
case V4L2_CTRL_TYPE_BOOLEAN:
case V4L2_CTRL_TYPE_BUTTON:
case V4L2_CTRL_TYPE_CTRL_CLASS:
- ptr.p_s32 = c-value;
- return ctrl-type_ops-validate(ctrl, 0, ptr);
-
case V4L2_CTRL_TYPE_INTEGER64:
- ptr.p_s64 = c-value64;
- return ctrl-type_ops-validate(ctrl, 0, ptr);
+ return ctrl-type_ops-validate(ctrl, 0, p_new);
default:
break;
}
}
- ptr.p = c-ptr;
- for (idx = 0; !err idx c-size / ctrl-elem_size; idx++)
- err = ctrl-type_ops-validate(ctrl, idx, ptr);
+ for (idx = 0; !err idx ctrl-elems; idx++)
+ err = ctrl-type_ops-validate(ctrl, idx, p_new);
return err;
}
@@ -3012,6 +3005,7 @@ static int validate_ctrls(struct v4l2_ext_controls *cs,
cs-error_idx = cs-count;
for (i = 0; i cs-count; i++) {
struct v4l2_ctrl *ctrl = helpers[i].ctrl;
+ union v4l2_ctrl_ptr p_new;
cs-error_idx = i;
@@ -3025,7 +3019,17 @@ static int validate_ctrls(struct v4l2_ext_controls *cs,
best-effort to avoid that. */
if (set (ctrl-flags V4L2_CTRL_FLAG_GRABBED))
return -EBUSY;
- ret = validate_new(ctrl, cs-controls[i]);
+ /*
+* Skip validation for now if the payload needs to be copied
+* from userspace into kernelspace. We'll validate those later.
+*/
+ if (ctrl-is_ptr)
+ continue;
+ if (ctrl-type == V4L2_CTRL_TYPE_INTEGER64)
+ p_new.p_s64 = cs-controls[i].value64;
+ else
+ p_new.p_s32 = cs-controls[i].value;
+ ret = validate_new(ctrl, p_new);
if (ret)
return ret;
}
@@ -3120,7 +3124,11 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct
v4l2_ctrl_handler *hdl,
/* Copy the new caller-supplied control values.
user_to_new() sets 'is_new' to 1. */
do {
- ret = user_to_new(cs-controls + idx,
helpers[idx].ctrl);
+ struct v4l2_ctrl *ctrl = helpers[idx].ctrl;
+
+ ret = user_to_new(cs-controls + idx, ctrl);
+ if (!ret ctrl-is_ptr)
+ ret = validate_new(ctrl, ctrl-p_new);
idx = helpers[idx].next;
} while (!ret idx);
@@ -3170,10 +3178,10 @@ int v4l2_subdev_s_ext_ctrls(struct v4l2_subdev *sd, struct v4l2_ext_controls *cs
EXPORT_SYMBOL(v4l2_subdev_s_ext_ctrls);
/* Helper function for VIDIOC_S_CTRL compatibility */
-static int set_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
- struct v4l2_ext_control *c, u32 ch_flags)
+static int set_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32 ch_flags)
{
struct v4l2_ctrl *master = ctrl-cluster[0];
+ int ret;
int i;
/* Reset the 'is_new' flags of the cluster */
@@ -3181,8 +3189,9 @@ static int set_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl
*ctrl,
if (master-cluster[i])
Re: [PATCH/RFC v2 2/4] Add media device related data structures and API.
Hi Jacek,
On Fri, Oct 17, 2014 at 04:54:40PM +0200, Jacek Anaszewski wrote:
...
+/*
+ * struct media_entity - media device entity data
+ * @id: media entity id within media controller
+ * @name:media entity name
+ * @node_name: media entity related device node name
+ * @pads:array of media_entity pads
+ * @num_pads:number of elements in the pads array
+ * @links: array of media_entity links
+ * @num_links: number of elements in the links array
+ * @subdev_fmt: related sub-device format
+ * @fd: related sub-device node file descriptor
+ * @src_pad_id: source pad id when entity is linked
+ * @sink_pad_id: sink pad id when entity is linked
+ * @next:pointer to the next data structure in the list
+ */
+struct media_entity {
+ int id;
+ char name[32];
+ char node_name[32];
+ struct media_pad_desc *pads;
+ int num_pads;
+ struct media_link_desc *links;
+ int num_links;
+ struct v4l2_subdev_format subdev_fmt;
+ int fd;
+ int src_pad_id;
+ int sink_pad_id;
+ struct media_entity *next;
+};
Could you use libmediactl and libv4l2subdev instead here as well? They do
actually implement much of what you do here. Feel free to comment on the
API. The libraries have a little bit different background than this one.
Obviously there's functionality in this library what's not in the two; some
of this might belong to either of the two libraries.
I think we'll need V4L2 sub-device related information stored next to the
media entities as well, so that's something to be added.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] [media] vivid: add support for contiguous DMA buffers
To simulate the behaviour of real hardware with such limitations or to
connect vivid to real hardware with such limitations, add an option to
let vivid use the dma-contig allocator instead of vmalloc.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/vivid/Kconfig | 1 +
drivers/media/platform/vivid/vivid-core.c| 30 +++-
drivers/media/platform/vivid/vivid-core.h| 1 +
drivers/media/platform/vivid/vivid-vid-cap.c | 4 +++-
drivers/media/platform/vivid/vivid-vid-out.c | 5 -
5 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/vivid/Kconfig
b/drivers/media/platform/vivid/Kconfig
index 3bfda25..f48c998 100644
--- a/drivers/media/platform/vivid/Kconfig
+++ b/drivers/media/platform/vivid/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_VIVID
select FONT_SUPPORT
select FONT_8x16
select VIDEOBUF2_VMALLOC
+ select VIDEOBUF2_DMA_CONTIG
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index c79d60d..4c4fc3d 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -29,6 +29,7 @@
#include linux/platform_device.h
#include linux/videodev2.h
#include linux/v4l2-dv-timings.h
+#include media/videobuf2-dma-contig.h
#include media/videobuf2-vmalloc.h
#include media/v4l2-dv-timings.h
#include media/v4l2-ioctl.h
@@ -107,6 +108,11 @@ MODULE_PARM_DESC(multiplanar, 0 (default) is alternating
single and multiplana
\t\t1 is single planar devices,\n
\t\t2 is multiplanar devices);
+static unsigned allocators[VIVID_MAX_DEVS];
+module_param_array(allocators, uint, NULL, 0444);
+MODULE_PARM_DESC(allocators, memory allocator selection, default is 0.\n
+\t\t0=vmalloc, 1=dma-contig);
+
/* Default: video + vbi-cap (raw and sliced) + radio rx + radio tx + sdr +
vbi-out + vid-out */
static unsigned node_types[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] =
0x1d3d };
module_param_array(node_types, uint, NULL, 0444);
@@ -640,6 +646,10 @@ static int __init vivid_create_instance(int inst)
{
static const struct v4l2_dv_timings def_dv_timings =
V4L2_DV_BT_CEA_1280X720P60;
+ static const struct vb2_mem_ops * const vivid_mem_ops[2] = {
+ vb2_vmalloc_memops,
+ vb2_dma_contig_memops,
+ };
unsigned in_type_counter[4] = { 0, 0, 0, 0 };
unsigned out_type_counter[4] = { 0, 0, 0, 0 };
int ccs_cap = ccs_cap_mode[inst];
@@ -650,6 +660,7 @@ static int __init vivid_create_instance(int inst)
struct video_device *vfd;
struct vb2_queue *q;
unsigned node_type = node_types[inst];
+ unsigned allocator = allocators[inst];
v4l2_std_id tvnorms_cap = 0, tvnorms_out = 0;
int ret;
int i;
@@ -1001,6 +1012,15 @@ static int __init vivid_create_instance(int inst)
dev-fb_cap.fmt.bytesperline = dev-src_rect.width *
tpg_g_twopixelsize(dev-tpg, 0) / 2;
dev-fb_cap.fmt.sizeimage = dev-src_rect.height *
dev-fb_cap.fmt.bytesperline;
+ /* initialize allocator context */
+ if (allocator == 1) {
+ dev-alloc_ctx = vb2_dma_contig_init_ctx(dev-v4l2_dev.dev);
+ if (IS_ERR(dev-alloc_ctx))
+ goto unreg_dev;
+ } else if (allocator = ARRAY_SIZE(vivid_mem_ops)) {
+ allocator = 0;
+ }
+
/* initialize locks */
spin_lock_init(dev-slock);
mutex_init(dev-mutex);
@@ -1022,7 +1042,7 @@ static int __init vivid_create_instance(int inst)
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct vivid_buffer);
q-ops = vivid_vid_cap_qops;
- q-mem_ops = vb2_vmalloc_memops;
+ q-mem_ops = vivid_mem_ops[allocator];
q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q-min_buffers_needed = 2;
@@ -1040,7 +1060,7 @@ static int __init vivid_create_instance(int inst)
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct vivid_buffer);
q-ops = vivid_vid_out_qops;
- q-mem_ops = vb2_vmalloc_memops;
+ q-mem_ops = vivid_mem_ops[allocator];
q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q-min_buffers_needed = 2;
@@ -1058,7 +1078,7 @@ static int __init vivid_create_instance(int inst)
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct vivid_buffer);
q-ops = vivid_vbi_cap_qops;
- q-mem_ops = vb2_vmalloc_memops;
+ q-mem_ops = vivid_mem_ops[allocator];
q-timestamp_flags =
[PATCH 2/5] [media] vivid: remove unused videobuf2-vmalloc headers
The videobuf2-vmalloc header is not used by the changed files, so remove it. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/media/platform/vivid/vivid-kthread-cap.c | 1 - drivers/media/platform/vivid/vivid-kthread-out.c | 1 - drivers/media/platform/vivid/vivid-osd.c | 1 - 3 files changed, 3 deletions(-) diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c b/drivers/media/platform/vivid/vivid-kthread-cap.c index 39a67cf..65e5f76 100644 --- a/drivers/media/platform/vivid/vivid-kthread-cap.c +++ b/drivers/media/platform/vivid/vivid-kthread-cap.c @@ -31,7 +31,6 @@ #include linux/random.h #include linux/v4l2-dv-timings.h #include asm/div64.h -#include media/videobuf2-vmalloc.h #include media/v4l2-dv-timings.h #include media/v4l2-ioctl.h #include media/v4l2-fh.h diff --git a/drivers/media/platform/vivid/vivid-kthread-out.c b/drivers/media/platform/vivid/vivid-kthread-out.c index d9f36cc..6da0e01 100644 --- a/drivers/media/platform/vivid/vivid-kthread-out.c +++ b/drivers/media/platform/vivid/vivid-kthread-out.c @@ -31,7 +31,6 @@ #include linux/random.h #include linux/v4l2-dv-timings.h #include asm/div64.h -#include media/videobuf2-vmalloc.h #include media/v4l2-dv-timings.h #include media/v4l2-ioctl.h #include media/v4l2-fh.h diff --git a/drivers/media/platform/vivid/vivid-osd.c b/drivers/media/platform/vivid/vivid-osd.c index 084d346..c90cf13 100644 --- a/drivers/media/platform/vivid/vivid-osd.c +++ b/drivers/media/platform/vivid/vivid-osd.c @@ -29,7 +29,6 @@ #include linux/kthread.h #include linux/freezer.h #include linux/fb.h -#include media/videobuf2-vmalloc.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-ctrls.h -- 2.1.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
[PATCH 3/5] [media] vivid: convert to platform device
For contiguous DMA buffer allocation, a struct is needed that
DMA buffers can be associated with.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/vivid/vivid-core.c | 37 +--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 2c61a62..c79d60d 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -26,6 +26,7 @@
#include linux/vmalloc.h
#include linux/font.h
#include linux/mutex.h
+#include linux/platform_device.h
#include linux/videodev2.h
#include linux/v4l2-dv-timings.h
#include media/videobuf2-vmalloc.h
@@ -152,6 +153,7 @@ module_param(no_error_inj, bool, 0444);
MODULE_PARM_DESC(no_error_inj, if set disable the error injecting controls);
static struct vivid_dev *vivid_devs[VIVID_MAX_DEVS];
+static struct platform_device *vivid_pdev;
const struct v4l2_rect vivid_min_rect = {
0, 0, MIN_WIDTH, MIN_HEIGHT
@@ -1288,7 +1290,7 @@ free_dev:
will succeed. This is limited to the maximum number of devices that
videodev supports, which is equal to VIDEO_NUM_DEVICES.
*/
-static int __init vivid_init(void)
+static int vivid_probe(struct platform_device *pdev)
{
const struct font_desc *font = find_font(VGA8x16);
int ret = 0, i;
@@ -1323,7 +1325,7 @@ static int __init vivid_init(void)
return ret;
}
-static void __exit vivid_exit(void)
+static int vivid_remove(struct platform_device *pdev)
{
struct vivid_dev *dev;
unsigned i;
@@ -1384,6 +1386,37 @@ static void __exit vivid_exit(void)
kfree(dev);
vivid_devs[i] = NULL;
}
+
+ return 0;
+}
+
+struct platform_driver vivid_driver = {
+ .probe = vivid_probe,
+ .remove = vivid_remove,
+ .driver = {
+ .name = vivid,
+ },
+};
+
+static int __init vivid_init(void)
+{
+ int ret;
+
+ vivid_pdev = platform_device_register_simple(vivid, -1, NULL, 0);
+ if (IS_ERR(vivid_pdev))
+ return PTR_ERR(vivid_pdev);
+
+ ret = platform_driver_register(vivid_driver);
+ if (ret != 0)
+ platform_device_unregister(vivid_pdev);
+
+ return ret;
+}
+
+static void __exit vivid_exit(void)
+{
+ platform_device_unregister(vivid_pdev);
+ platform_driver_unregister(vivid_driver);
}
module_init(vivid_init);
--
2.1.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
[PATCH 0/5] Contiguous DMA buffer support for the Virtual Video Test Driver
Hi, to use vivid as test source for a hardware pipeline with elements that can only handle contiguous DMA buffers, I'd like to add support for the videobuf2-dma-contig allocator and enable VIDIOC_EXPBUF in vivid. Since DMA memory should be associated with a struct device, I have added a platform device to vivid. There is a new 'allocators' module parameter array that selects the dma-contig allocator for an instance when the value is set to 1: modprobe vivid n_devs=2 allocators=1,1 regards Philipp Philipp Zabel (5): [media] vivid: select CONFIG_FB_CFB_FILLRECT/COPYAREA/IMAGEBLIT [media] vivid: remove unused videobuf2-vmalloc headers [media] vivid: convert to platform device [media] vivid: add support for contiguous DMA buffers [media] vivid: enable VIDIOC_EXPBUF drivers/media/platform/vivid/Kconfig | 4 ++ drivers/media/platform/vivid/vivid-core.c| 69 +--- drivers/media/platform/vivid/vivid-core.h| 1 + drivers/media/platform/vivid/vivid-kthread-cap.c | 1 - drivers/media/platform/vivid/vivid-kthread-out.c | 1 - drivers/media/platform/vivid/vivid-osd.c | 1 - drivers/media/platform/vivid/vivid-vid-cap.c | 4 +- drivers/media/platform/vivid/vivid-vid-out.c | 5 +- 8 files changed, 73 insertions(+), 13 deletions(-) -- 2.1.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
[PATCH 5/5] [media] vivid: enable VIDIOC_EXPBUF
Instances created with allocators == 1 use videobuf2-dma-contig, and are
able to export DMA buffers via VIDIOC_EXPBUF.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/vivid/vivid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 4c4fc3d..695286b 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -596,7 +596,7 @@ static const struct v4l2_ioctl_ops vivid_ioctl_ops = {
.vidioc_querybuf= vb2_ioctl_querybuf,
.vidioc_qbuf= vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
-/* Not yet .vidioc_expbuf = vb2_ioctl_expbuf,*/
+ .vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon= vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
--
2.1.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
[PATCH 1/5] [media] vivid: select CONFIG_FB_CFB_FILLRECT/COPYAREA/IMAGEBLIT
The OSD simulation uses the framebuffer core functions, so vivid needs to select the corresponding configuration options. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/media/platform/vivid/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/vivid/Kconfig b/drivers/media/platform/vivid/Kconfig index d71139a..3bfda25 100644 --- a/drivers/media/platform/vivid/Kconfig +++ b/drivers/media/platform/vivid/Kconfig @@ -4,6 +4,9 @@ config VIDEO_VIVID select FONT_SUPPORT select FONT_8x16 select VIDEOBUF2_VMALLOC + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT default n ---help--- Enables a virtual video driver. This driver emulates a webcam, -- 2.1.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 1/5] [media] vivid: select CONFIG_FB_CFB_FILLRECT/COPYAREA/IMAGEBLIT
Superseded. Already part of a pull request for 3.18. But thanks anyway :-) Hans On 10/22/2014 12:03 PM, Philipp Zabel wrote: The OSD simulation uses the framebuffer core functions, so vivid needs to select the corresponding configuration options. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/media/platform/vivid/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/vivid/Kconfig b/drivers/media/platform/vivid/Kconfig index d71139a..3bfda25 100644 --- a/drivers/media/platform/vivid/Kconfig +++ b/drivers/media/platform/vivid/Kconfig @@ -4,6 +4,9 @@ config VIDEO_VIVID select FONT_SUPPORT select FONT_8x16 select VIDEOBUF2_VMALLOC + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT default n ---help--- Enables a virtual video driver. This driver emulates a webcam, -- 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/5] [media] vivid: remove unused videobuf2-vmalloc headers
On 10/22/2014 12:03 PM, Philipp Zabel wrote: The videobuf2-vmalloc header is not used by the changed files, so remove it. Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/media/platform/vivid/vivid-kthread-cap.c | 1 - drivers/media/platform/vivid/vivid-kthread-out.c | 1 - drivers/media/platform/vivid/vivid-osd.c | 1 - 3 files changed, 3 deletions(-) diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c b/drivers/media/platform/vivid/vivid-kthread-cap.c index 39a67cf..65e5f76 100644 --- a/drivers/media/platform/vivid/vivid-kthread-cap.c +++ b/drivers/media/platform/vivid/vivid-kthread-cap.c @@ -31,7 +31,6 @@ #include linux/random.h #include linux/v4l2-dv-timings.h #include asm/div64.h -#include media/videobuf2-vmalloc.h #include media/v4l2-dv-timings.h #include media/v4l2-ioctl.h #include media/v4l2-fh.h diff --git a/drivers/media/platform/vivid/vivid-kthread-out.c b/drivers/media/platform/vivid/vivid-kthread-out.c index d9f36cc..6da0e01 100644 --- a/drivers/media/platform/vivid/vivid-kthread-out.c +++ b/drivers/media/platform/vivid/vivid-kthread-out.c @@ -31,7 +31,6 @@ #include linux/random.h #include linux/v4l2-dv-timings.h #include asm/div64.h -#include media/videobuf2-vmalloc.h #include media/v4l2-dv-timings.h #include media/v4l2-ioctl.h #include media/v4l2-fh.h diff --git a/drivers/media/platform/vivid/vivid-osd.c b/drivers/media/platform/vivid/vivid-osd.c index 084d346..c90cf13 100644 --- a/drivers/media/platform/vivid/vivid-osd.c +++ b/drivers/media/platform/vivid/vivid-osd.c @@ -29,7 +29,6 @@ #include linux/kthread.h #include linux/freezer.h #include linux/fb.h -#include media/videobuf2-vmalloc.h #include media/v4l2-device.h #include media/v4l2-ioctl.h #include media/v4l2-ctrls.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
Re: [PATCH 3/5] [media] vivid: convert to platform device
On 10/22/2014 12:03 PM, Philipp Zabel wrote:
For contiguous DMA buffer allocation, a struct is needed that
DMA buffers can be associated with.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Acked-by: Hans Verkuil hans.verk...@cisco.com
Nice! I was planning something like that myself.
Regards,
Hans
---
drivers/media/platform/vivid/vivid-core.c | 37 +--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 2c61a62..c79d60d 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -26,6 +26,7 @@
#include linux/vmalloc.h
#include linux/font.h
#include linux/mutex.h
+#include linux/platform_device.h
#include linux/videodev2.h
#include linux/v4l2-dv-timings.h
#include media/videobuf2-vmalloc.h
@@ -152,6 +153,7 @@ module_param(no_error_inj, bool, 0444);
MODULE_PARM_DESC(no_error_inj, if set disable the error injecting
controls);
static struct vivid_dev *vivid_devs[VIVID_MAX_DEVS];
+static struct platform_device *vivid_pdev;
const struct v4l2_rect vivid_min_rect = {
0, 0, MIN_WIDTH, MIN_HEIGHT
@@ -1288,7 +1290,7 @@ free_dev:
will succeed. This is limited to the maximum number of devices that
videodev supports, which is equal to VIDEO_NUM_DEVICES.
*/
-static int __init vivid_init(void)
+static int vivid_probe(struct platform_device *pdev)
{
const struct font_desc *font = find_font(VGA8x16);
int ret = 0, i;
@@ -1323,7 +1325,7 @@ static int __init vivid_init(void)
return ret;
}
-static void __exit vivid_exit(void)
+static int vivid_remove(struct platform_device *pdev)
{
struct vivid_dev *dev;
unsigned i;
@@ -1384,6 +1386,37 @@ static void __exit vivid_exit(void)
kfree(dev);
vivid_devs[i] = NULL;
}
+
+ return 0;
+}
+
+struct platform_driver vivid_driver = {
+ .probe = vivid_probe,
+ .remove = vivid_remove,
+ .driver = {
+ .name = vivid,
+ },
+};
+
+static int __init vivid_init(void)
+{
+ int ret;
+
+ vivid_pdev = platform_device_register_simple(vivid, -1, NULL, 0);
+ if (IS_ERR(vivid_pdev))
+ return PTR_ERR(vivid_pdev);
+
+ ret = platform_driver_register(vivid_driver);
+ if (ret != 0)
+ platform_device_unregister(vivid_pdev);
+
+ return ret;
+}
+
+static void __exit vivid_exit(void)
+{
+ platform_device_unregister(vivid_pdev);
+ platform_driver_unregister(vivid_driver);
}
module_init(vivid_init);
--
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 4/5] [media] vivid: add support for contiguous DMA buffers
On 10/22/2014 12:03 PM, Philipp Zabel wrote:
To simulate the behaviour of real hardware with such limitations or to
connect vivid to real hardware with such limitations, add an option to
let vivid use the dma-contig allocator instead of vmalloc.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/vivid/Kconfig | 1 +
drivers/media/platform/vivid/vivid-core.c| 30 +++-
drivers/media/platform/vivid/vivid-core.h| 1 +
drivers/media/platform/vivid/vivid-vid-cap.c | 4 +++-
drivers/media/platform/vivid/vivid-vid-out.c | 5 -
5 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/vivid/Kconfig
b/drivers/media/platform/vivid/Kconfig
index 3bfda25..f48c998 100644
--- a/drivers/media/platform/vivid/Kconfig
+++ b/drivers/media/platform/vivid/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_VIVID
select FONT_SUPPORT
select FONT_8x16
select VIDEOBUF2_VMALLOC
+ select VIDEOBUF2_DMA_CONTIG
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index c79d60d..4c4fc3d 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -29,6 +29,7 @@
#include linux/platform_device.h
#include linux/videodev2.h
#include linux/v4l2-dv-timings.h
+#include media/videobuf2-dma-contig.h
#include media/videobuf2-vmalloc.h
#include media/v4l2-dv-timings.h
#include media/v4l2-ioctl.h
@@ -107,6 +108,11 @@ MODULE_PARM_DESC(multiplanar, 0 (default) is alternating
single and multiplana
\t\t1 is single planar devices,\n
\t\t2 is multiplanar devices);
+static unsigned allocators[VIVID_MAX_DEVS];
+module_param_array(allocators, uint, NULL, 0444);
+MODULE_PARM_DESC(allocators, memory allocator selection, default is 0.\n
+\t\t0=vmalloc, 1=dma-contig);
+
/* Default: video + vbi-cap (raw and sliced) + radio rx + radio tx + sdr +
vbi-out + vid-out */
static unsigned node_types[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 1)] =
0x1d3d };
module_param_array(node_types, uint, NULL, 0444);
@@ -640,6 +646,10 @@ static int __init vivid_create_instance(int inst)
{
static const struct v4l2_dv_timings def_dv_timings =
V4L2_DV_BT_CEA_1280X720P60;
+ static const struct vb2_mem_ops * const vivid_mem_ops[2] = {
+ vb2_vmalloc_memops,
+ vb2_dma_contig_memops,
+ };
unsigned in_type_counter[4] = { 0, 0, 0, 0 };
unsigned out_type_counter[4] = { 0, 0, 0, 0 };
int ccs_cap = ccs_cap_mode[inst];
@@ -650,6 +660,7 @@ static int __init vivid_create_instance(int inst)
struct video_device *vfd;
struct vb2_queue *q;
unsigned node_type = node_types[inst];
+ unsigned allocator = allocators[inst];
v4l2_std_id tvnorms_cap = 0, tvnorms_out = 0;
int ret;
int i;
@@ -1001,6 +1012,15 @@ static int __init vivid_create_instance(int inst)
dev-fb_cap.fmt.bytesperline = dev-src_rect.width *
tpg_g_twopixelsize(dev-tpg, 0) / 2;
dev-fb_cap.fmt.sizeimage = dev-src_rect.height *
dev-fb_cap.fmt.bytesperline;
+ /* initialize allocator context */
+ if (allocator == 1) {
+ dev-alloc_ctx = vb2_dma_contig_init_ctx(dev-v4l2_dev.dev);
+ if (IS_ERR(dev-alloc_ctx))
+ goto unreg_dev;
+ } else if (allocator = ARRAY_SIZE(vivid_mem_ops)) {
+ allocator = 0;
+ }
+
/* initialize locks */
spin_lock_init(dev-slock);
mutex_init(dev-mutex);
@@ -1022,7 +1042,7 @@ static int __init vivid_create_instance(int inst)
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct vivid_buffer);
q-ops = vivid_vid_cap_qops;
- q-mem_ops = vb2_vmalloc_memops;
+ q-mem_ops = vivid_mem_ops[allocator];
q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q-min_buffers_needed = 2;
@@ -1040,7 +1060,7 @@ static int __init vivid_create_instance(int inst)
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct vivid_buffer);
q-ops = vivid_vid_out_qops;
- q-mem_ops = vb2_vmalloc_memops;
+ q-mem_ops = vivid_mem_ops[allocator];
q-timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
q-min_buffers_needed = 2;
@@ -1058,7 +1078,7 @@ static int __init vivid_create_instance(int inst)
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct vivid_buffer);
q-ops = vivid_vbi_cap_qops;
- q-mem_ops = vb2_vmalloc_memops;
+ q-mem_ops =
Re: [PATCH 5/5] [media] vivid: enable VIDIOC_EXPBUF
On 10/22/2014 12:03 PM, Philipp Zabel wrote:
Instances created with allocators == 1 use videobuf2-dma-contig, and are
able to export DMA buffers via VIDIOC_EXPBUF.
Can you test what happens if you use EXPBUF when vmalloc is used? I hope it
will just fail, but I am not sure.
Regards,
Hans
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/vivid/vivid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 4c4fc3d..695286b 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -596,7 +596,7 @@ static const struct v4l2_ioctl_ops vivid_ioctl_ops = {
.vidioc_querybuf= vb2_ioctl_querybuf,
.vidioc_qbuf= vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
-/* Not yet .vidioc_expbuf = vb2_ioctl_expbuf,*/
+ .vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon= vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
--
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
ERROR: cfb_fillrect undefined!
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: c3351dfabf5c78fb5ddc79d0f7b65ebd9e441337 commit: e75420dd25bc9d7b6f4e3b4c4f6c778b610c8cda [media] vivid: enable the vivid driver date: 7 weeks ago config: i386-randconfig-x1-10221122 (attached as .config) reproduce: git checkout e75420dd25bc9d7b6f4e3b4c4f6c778b610c8cda # save the attached .config to linux build tree make ARCH=i386 All error/warnings: ERROR: cfb_fillrect undefined! ERROR: cfb_imageblit undefined! ERROR: fb_alloc_cmap undefined! ERROR: register_framebuffer undefined! ERROR: fb_dealloc_cmap undefined! ERROR: cfb_copyarea undefined! ERROR: unregister_framebuffer undefined! --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.17.0-rc1 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_NOCB_CPU=y CONFIG_RCU_NOCB_CPU_NONE=y # CONFIG_RCU_NOCB_CPU_ZERO is not set # CONFIG_RCU_NOCB_CPU_ALL is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y # CONFIG_MEMCG is not set # CONFIG_CGROUP_HUGETLB is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y
[PATCH for v3.18] tw68: remove bogus I2C_ALGOBIT dependency
tw68 doesn't use i2c at all, so remove this bogus dependency to prevent this warning: warning: (CAN_PEAK_PCIEC SFC IGB VIDEO_TW68 DRM FB_DDC FB_VIA) selects I2C_ALGOBIT which has unmet direct dependencies (I2C) CC [M] drivers/i2c/algos/i2c-algo-bit.o ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_bus': ../drivers/i2c/algos/i2c-algo-bit.c:658:33: error: 'i2c_add_adapter' undeclared (first use in this function) ../drivers/i2c/algos/i2c-algo-bit.c:658:33: note: each undeclared identifier is reported only once for each function it appears in ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_numbered_bus': ../drivers/i2c/algos/i2c-algo-bit.c:664:33: error: 'i2c_add_numbered_adapter' undeclared (first use in this function) ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_bus': ../drivers/i2c/algos/i2c-algo-bit.c:659:1: warning: control reaches end of non-void function [-Wreturn-type] ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_numbered_bus': ../drivers/i2c/algos/i2c-algo-bit.c:665:1: warning: control reaches end of non-void function [-Wreturn-type] Reported-by: Randy Dunlap rdun...@infradead.org Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/pci/tw68/Kconfig b/drivers/media/pci/tw68/Kconfig index 5425ba1..95d5d52 100644 --- a/drivers/media/pci/tw68/Kconfig +++ b/drivers/media/pci/tw68/Kconfig @@ -1,7 +1,6 @@ config VIDEO_TW68 tristate Techwell tw68x Video For Linux depends on VIDEO_DEV PCI VIDEO_V4L2 - select I2C_ALGOBIT select VIDEOBUF2_DMA_SG ---help--- Support for Techwell tw68xx based frame grabber boards. -- 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 -next] media: tw68: fix build errors and warnings
Hi Randy, After analyzing this it became clear that the I2C_ALGOBIT select was bogus since this driver doesn't use i2c at all. I've posted a new patch fixing that. Thanks, Hans On 10/06/2014 07:05 PM, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix build errors and kconfig warning: since 'select' does not check Kconfig symbol dependencies, add that dependency explicitly. VIDEO_TW68 selects I2C_ALGOBIT, so it should depend on I2C to prevent build errors and warnings. warning: (CAN_PEAK_PCIEC SFC IGB VIDEO_TW68 DRM FB_DDC FB_VIA) selects I2C_ALGOBIT which has unmet direct dependencies (I2C) CC [M] drivers/i2c/algos/i2c-algo-bit.o ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_bus': ../drivers/i2c/algos/i2c-algo-bit.c:658:33: error: 'i2c_add_adapter' undeclared (first use in this function) ../drivers/i2c/algos/i2c-algo-bit.c:658:33: note: each undeclared identifier is reported only once for each function it appears in ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_numbered_bus': ../drivers/i2c/algos/i2c-algo-bit.c:664:33: error: 'i2c_add_numbered_adapter' undeclared (first use in this function) ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_bus': ../drivers/i2c/algos/i2c-algo-bit.c:659:1: warning: control reaches end of non-void function [-Wreturn-type] ../drivers/i2c/algos/i2c-algo-bit.c: In function 'i2c_bit_add_numbered_bus': ../drivers/i2c/algos/i2c-algo-bit.c:665:1: warning: control reaches end of non-void function [-Wreturn-type] Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Hans Verkuil hverk...@xs4all.nl --- drivers/media/pci/tw68/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20141001.orig/drivers/media/pci/tw68/Kconfig +++ linux-next-20141001/drivers/media/pci/tw68/Kconfig @@ -1,6 +1,6 @@ config VIDEO_TW68 tristate Techwell tw68x Video For Linux - depends on VIDEO_DEV PCI VIDEO_V4L2 + depends on VIDEO_DEV PCI VIDEO_V4L2 I2C select I2C_ALGOBIT select VIDEOBUF2_DMA_SG ---help--- -- 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
[GIT FIXES for v3.18] Various fixes
Various fixes for 3.18. Regards, Hans The following changes since commit 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c: Merge tag 'v3.18-rc1' into patchwork (2014-10-21 08:32:51 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.18f for you to fetch changes up to 30da44af2da231c02a8cb2d6d4d3905c6e8030c9: videobuf-dma-contig: set vm_pgoff to be zero to pass the sanity check in vm_iomap_memory(). (2014-10-22 13:04:09 +0200) Dan Carpenter (3): em28xx-input: NULL dereference on error xc5000: use after free in release() usbvision-video: two use after frees Fabian Frederick (1): tw68: remove deprecated IRQF_DISABLED Fancy Fang (1): videobuf-dma-contig: set vm_pgoff to be zero to pass the sanity check in vm_iomap_memory(). Hans Verkuil (2): wl128x: fix fmdbg compiler warning tw68: remove bogus I2C_ALGOBIT dependency drivers/media/pci/tw68/Kconfig| 1 - drivers/media/pci/tw68/tw68-core.c| 2 +- drivers/media/radio/wl128x/fmdrv_common.c | 2 +- drivers/media/tuners/xc5000.c | 2 +- drivers/media/usb/em28xx/em28xx-input.c | 4 +++- drivers/media/usb/usbvision/usbvision-video.c | 2 ++ drivers/media/v4l2-core/videobuf-dma-contig.c | 9 + 7 files changed, 17 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/15] media: davinci: vpbe: add support for VIDIOC_CREATE_BUFS
Hi Prabhakar,
This patch series looks good, except for this one.
If you add create_bufs support, then you should also update queue_setup.
If the fmt argument to queue_setup is non-NULL, then check that the
fmt.pix.sizeimage field is = the current format's sizeimage. If not,
return -EINVAL.
This prevents userspace from creating additional buffers that are smaller than
the minimum required size.
I'm just skipping this patch and queuing all the others for 3.19. Just post an
updated version for this one and I'll pick it up later.
Regards,
Hans
On 10/12/2014 10:40 PM, Lad, Prabhakar wrote:
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpbe_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index c33b77e..fd8d4f0 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -1260,6 +1260,7 @@ static const struct v4l2_ioctl_ops vpbe_ioctl_ops = {
.vidioc_dqbuf= vb2_ioctl_dqbuf,
.vidioc_streamon = vb2_ioctl_streamon,
.vidioc_streamoff= vb2_ioctl_streamoff,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
.vidioc_cropcap = vpbe_display_cropcap,
.vidioc_g_crop = vpbe_display_g_crop,
--
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.19] davinci vpbe cleanups and improvements
Note: I skipped patch https://patchwork.linuxtv.org/patch/26430/ from Prabhakar's patch series since that needs a bit more work, but all other patches from that series are part of this pull request. Over 300 lines deleted, always nice! Regards, Hans The following changes since commit 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c: Merge tag 'v3.18-rc1' into patchwork (2014-10-21 08:32:51 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.19a for you to fetch changes up to fc1079f3dd25adfe5eaf8c7b0d097994f91f8601: media: davinci: vpbe: return -ENODATA for *dv_timings/*_std calls (2014-10-22 13:22:13 +0200) Prabhakar Lad (14): media: davinci: vpbe: initialize vb2 queue and DMA context in probe media: davinci: vpbe: drop buf_init() callback media: davinci: vpbe: use vb2_ops_wait_prepare/finish helper functions media: davinci: vpbe: drop buf_cleanup() callback media: davinci: vpbe: improve vpbe_buffer_prepare() callback media: davinci: vpbe: use vb2_fop_mmap/poll media: davinci: vpbe: use fh handling provided by v4l media: davinci: vpbe: use vb2_ioctl_* helpers media: davinci: vpbe: add support for VB2_DMABUF media: davinci: vpbe: add support for VIDIOC_EXPBUF media: davinci: vpbe: use helpers provided by core if streaming is started media: davinci: vpbe: drop unused member memory from vpbe_layer media: davinci: vpbe: group v4l2_ioctl_ops media: davinci: vpbe: return -ENODATA for *dv_timings/*_std calls drivers/media/platform/davinci/vpbe.c | 18 +- drivers/media/platform/davinci/vpbe_display.c | 606 +++ include/media/davinci/vpbe_display.h | 19 -- 3 files changed, 158 insertions(+), 485 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] s5p-mfc: correct the formats info for encoder
Hi Ayaka,
Could you resend this patch with your sign-off?
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
-Original Message-
From: ayaka [mailto:ay...@soulik.info]
Sent: Wednesday, July 23, 2014 6:15 PM
To: linux-media@vger.kernel.org
Cc: kyungmin.p...@samsung.com; k.deb...@samsung.com;
jtp.p...@samsung.com; m.che...@samsung.com; ayaka
Subject: [PATCH] s5p-mfc: correct the formats info for encoder
The NV12M is supported by all the version of MFC, so it is better to
use it as default OUTPUT format.
MFC v5 doesn't support NV21, I have tested it, for the SEC doc it is
not supported either.
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index d26b248..4ea3796 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -32,7 +32,7 @@
#include s5p_mfc_intr.h
#include s5p_mfc_opr.h
-#define DEF_SRC_FMT_ENC V4L2_PIX_FMT_NV12MT
+#define DEF_SRC_FMT_ENC V4L2_PIX_FMT_NV12M
#define DEF_DST_FMT_ENC V4L2_PIX_FMT_H264
static struct s5p_mfc_fmt formats[] = { @@ -67,8 +67,7 @@ static
struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
},
{
.name = H264 Encoded Stream,
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] [media] vivid: add support for contiguous DMA buffers
Am Mittwoch, den 22.10.2014, 12:14 +0200 schrieb Hans Verkuil:
[...]
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 331c544..04b5fbf 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -151,8 +151,10 @@ static int vid_cap_queue_setup(struct vb2_queue *vq,
const struct v4l2_format *f
/*
* videobuf2-vmalloc allocator is context-less so no need to set
-* alloc_ctxs array.
+* alloc_ctxs array. videobuf2-dma-contig needs a context, though.
*/
+ for (p = 0; p planes; p++)
+ alloc_ctxs[p] = dev-alloc_ctx;
if (planes == 2)
dprintk(dev, 1, %s, count=%d, sizes=%u, %u\n, __func__,
diff --git a/drivers/media/platform/vivid/vivid-vid-out.c
b/drivers/media/platform/vivid/vivid-vid-out.c
index 69c2dbd..6b8dfd6 100644
--- a/drivers/media/platform/vivid/vivid-vid-out.c
+++ b/drivers/media/platform/vivid/vivid-vid-out.c
@@ -39,6 +39,7 @@ static int vid_out_queue_setup(struct vb2_queue *vq,
const struct v4l2_format *f
unsigned planes = dev-fmt_out-planes;
unsigned h = dev-fmt_out_rect.height;
unsigned size = dev-bytesperline_out[0] * h;
+ unsigned p;
if (dev-field_out == V4L2_FIELD_ALTERNATE) {
/*
@@ -98,8 +99,10 @@ static int vid_out_queue_setup(struct vb2_queue *vq,
const struct v4l2_format *f
/*
* videobuf2-vmalloc allocator is context-less so no need to set
-* alloc_ctxs array.
+* alloc_ctxs array. videobuf2-dma-contig needs a context, though.
*/
+ for (p = 0; p planes; p++)
+ alloc_ctxs[p] = dev-alloc_ctx;
if (planes == 2)
dprintk(dev, 1, %s, count=%d, sizes=%u, %u\n, __func__,
This is not sufficient. alloc_ctxs should be filled in for all device types
in the
queue_setup op, so also for vbi cap/out and sdr cap. Without that these
devices
would fail.
Thanks, I'll add the following changes to the next version:
diff --git a/drivers/media/platform/vivid/vivid-sdr-cap.c
b/drivers/media/platform/vivid/vivid-sdr-cap.c
index 8c5d661..ac6ee15 100644
--- a/drivers/media/platform/vivid/vivid-sdr-cap.c
+++ b/drivers/media/platform/vivid/vivid-sdr-cap.c
@@ -196,6 +196,7 @@ static int sdr_cap_queue_setup(struct vb2_queue *vq, const
struct v4l2_format *f
{
/* 2 = max 16-bit sample returned */
sizes[0] = SDR_CAP_SAMPLES_PER_BUF * 2;
+ alloc_ctxs[0] = dev-alloc_ctx;
*nplanes = 1;
return 0;
}
diff --git a/drivers/media/platform/vivid/vivid-vbi-cap.c
b/drivers/media/platform/vivid/vivid-vbi-cap.c
index 2166d0b..27a636f 100644
--- a/drivers/media/platform/vivid/vivid-vbi-cap.c
+++ b/drivers/media/platform/vivid/vivid-vbi-cap.c
@@ -149,6 +149,7 @@ static int vbi_cap_queue_setup(struct vb2_queue *vq, const
struct v4l2_format *f
return -EINVAL;
sizes[0] = size;
+ alloc_ctxs[0] = dev-alloc_ctx;
if (vq-num_buffers + *nbuffers 2)
*nbuffers = 2 - vq-num_buffers;
diff --git a/drivers/media/platform/vivid/vivid-vbi-out.c
b/drivers/media/platform/vivid/vivid-vbi-out.c
index 9d00a07..5912ed8 100644
--- a/drivers/media/platform/vivid/vivid-vbi-out.c
+++ b/drivers/media/platform/vivid/vivid-vbi-out.c
@@ -41,6 +41,7 @@ static int vbi_out_queue_setup(struct vb2_queue *vq, const
struct v4l2_format *f
return -EINVAL;
sizes[0] = size;
+ alloc_ctxs[0] = dev-alloc_ctx;
if (vq-num_buffers + *nbuffers 2)
*nbuffers = 2 - vq-num_buffers;
--
2.1.1
regards
Philipp
--
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: Re: [PATCH 3/3] DVBSky V3 PCIe card: add some changes to M88DS3103for supporting the demod of M88RS6000
On 2014-10-22 05:24:02, Antti Palosaari wrote:
On 10/13/2014 09:44 AM, Nibble Max wrote:
M88RS6000 is the integrated chip, which includes tuner and demod.
Its internal demod is similar with M88DS3103 except some registers
definition.
The main different part of this internal demod from others is its clock/pll
generation IP block sitting inside the tuner die.
So clock/pll functions should be configed through its tuner i2c bus, NOT its
demod i2c bus.
The demod of M88RS6000 need the firmware: dvb-demod-m88rs6000.fw
firmware download link:
http://www.dvbsky.net/download/linux/dvbsky-firmware.tar.gz
@@ -250,6 +251,7 @@ static int m88ds3103_set_frontend(struct dvb_frontend
*fe)
u16 u16tmp, divide_ratio;
u32 tuner_frequency, target_mclk;
s32 s32tmp;
+struct m88rs6000_mclk_config mclk_cfg;
dev_dbg(priv-i2c-dev,
%s: delivery_system=%d modulation=%d frequency=%d
symbol_rate=%d inversion=%d pilot=%d rolloff=%d\n,
@@ -291,6 +293,26 @@ static int m88ds3103_set_frontend(struct dvb_frontend
*fe)
if (ret)
goto err;
+if (priv-chip_id == M88RS6000_CHIP_ID) {
+ret = m88ds3103_wr_reg(priv, 0x06, 0xe0);
+if (ret)
+goto err;
+if (fe-ops.tuner_ops.set_config) {
+/* select main mclk */
+mclk_cfg.config_op = 0;
+mclk_cfg.TunerfreqMHz = c-frequency / 1000;
+mclk_cfg.SymRateKSs = c-symbol_rate / 1000;
+ret = fe-ops.tuner_ops.set_config(fe, mclk_cfg);
+if (ret)
+goto err;
+priv-mclk_khz = mclk_cfg.MclkKHz;
+}
+ret = m88ds3103_wr_reg(priv, 0x06, 0x00);
+if (ret)
+goto err;
+usleep_range(1, 2);
+}
That looks odd and also ugly. You pass some values from demod to tuner
using set_config callback. Tuner driver can get symbol_rate and
frequency just similarly from property cache than demod. Why you do it
like that?
Clock is provided by tuner as you mention. I see you use that to pass
used clock frequency from tuner to demod. This does not look nice and I
would like to see clock framework instead. Or calculate clock on both
drivers. Does the demod clock even needs to be changed? I think it is
only TS stream size which defines used clock frequency - smaller the TS
bitstream, the smaller the clock frequency needed = optimizes power
consumption a little. But TS clock is calculated on tuner driver in any
case?
Yes, M88RS6000 looks odd. This integrated chip has two part die, tuner die and
demod die.
Its demod's clock(PLL) block is sitting insided the tuner die. The demod has no
PLL ip block that makes demod die smaller.
The demod's clock can be adjusted according to the transponder's frequency and
symbol rate.
So that the demod's clock and its harmonic frequency will not overlap with the
transponder's frequency range.
It will improve its tuner's sensitivity.
However the tuner driver can get the values from property cache.
Tuner driver does not know when need adjust this demod pll
and return the current demod pll value to the demod driver.
in struct dvb_tuner_ops, there is no call back to do this directly.
So I select the general set_config call back.
TS main clock of demdod also need to be controlled in the tuner die.
These demod's PLL registers have no relationship with tuner at all.
Logically, These demod's PLL registers should go with demod die as usual.
But in this case they goes with the tuner die physically and controlled through
tuner i2c bus.
The current dvb-frontend driver requires the tuner and demod to split into the
seperate drivers.
The demod driver will not access tuner i2c bus directly.
But this integrate chip has more tighter relationship of its tuner and demod
die.
That is reason why these odd call backs happen.
BR,
Max
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] Fix smatch warning: unknown field name in initializer
I sadly missed this patch and it is merged now. But: Nacked-by: Hans Verkuil hans.verk...@cisco.com This sparse warnings are due to a sparse bug that has been fixed in the sparse git repo. It's not included in sparse-0.5.0, the fix came in later. The #define that you kept it the version that does not comply with the C11 spec, so this is likely to fail with non-gcc compilers (gcc apparently kept support for the old pre-4.6 syntax). Regards, Hans On 09/24/2014 02:51 PM, Mauro Carvalho Chehab wrote: This is detected with: gcc-4.8.3-7.fc20.x86_64 Smatch, up to this patch: commit de462ba2c79d9347368c887ed93113e7818a7b07 Author: Dan Carpenter dan.carpen...@oracle.com Date: Wed Sep 17 13:31:16 2014 +0300 drivers/media/v4l2-core/v4l2-dv-timings.c:34:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:35:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:36:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:37:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:38:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:39:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:40:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:41:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:42:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:43:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:44:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:45:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:46:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:47:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:48:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:49:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:50:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:51:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:52:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:53:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:54:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:55:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:56:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:57:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:58:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:59:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:60:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:61:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:62:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:63:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:64:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:65:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:66:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:67:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:68:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:69:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:70:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:71:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:72:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:73:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:74:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:75:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:76:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:77:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:78:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:79:9: error: unknown field name in initializer drivers/media/v4l2-core/v4l2-dv-timings.c:80:9: error: unknown field name in initializer
RE: [PATCH] s5p-mfc: correct the formats info for encoder
I am very sorry to forget the Sign-off again and thank you for reviewing. ayaka (1): s5p-mfc: correct the formats info for encoder drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s5p-mfc: correct the formats info for encoder
The NV12M is supported by all the version of MFC, so it is better
to use it as default OUTPUT format.
MFC v5 doesn't support NV21, I have tested it, for the SEC doc
it is not supported either.
Signed-off-by: ayaka ay...@soulik.info
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index d26b248..4ea3796 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -32,7 +32,7 @@
#include s5p_mfc_intr.h
#include s5p_mfc_opr.h
-#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12MT
+#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M
#define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264
static struct s5p_mfc_fmt formats[] = {
@@ -67,8 +67,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
},
{
.name = H264 Encoded Stream,
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW] Submitting Media Patches
During the mini-summit it was decided that we should put up a document on how to post/handle patches etc. for the media drivers in the wiki. I had such a doc already which I'm posting now for review. Once it's all OK Pawel offered to put it up in the wiki. - For general information on how to submit patches see: http://linuxtv.org/wiki/index.php/Developer_Section In particular the section 'Submitting Your Work'. This document goes into more detail regarding media specific requirements when submitting patches and what the patch flow looks like in this subsystem. Note 1: there are always exceptions to the rule, so if you believe certain requirements do not apply to your code, then let us know and we can discuss it. Note 2: this list is not exhaustive and will be updated over time, so make sure you always use the latest version of this document. The latest version will always be available here: TBD. Note 3: when submitting a patch use ./scripts/get_maintainer.pl to figure out who is maintaining the sources you touched. Submitting New Media Drivers When submitting new media drivers for inclusion in drivers/staging/media all that is required is that the driver compiles with the latest kernel, that an entry is added to the MAINTAINERS file, and that a TODO file is added with a list of action items that need to be taken before the driver can be moved to drivers/media. It should be noticed, however, that it is expected that the driver will be fixed to fulfill the requirements for upstream addition. If a driver at staging lacks relevant patches fixing it for more than a few kernel cycles, it can be dropped from staging. We will contact you before doing that provided that the email address of the maintainer is still valid. For inclusion as a non-staging driver the requirements are more strict: General requirements: - It must pass checkpatch.pl, but see the note regarding interpreting the output from checkpatch below. - An entry for the driver is added to the MAINTAINERS file. - The kernel internal APIs are used properly. - Don't reinvent the wheel by adding new defines, math logic, etc. for which there are already solutions in the kernel. - Follow the CodingStyle guidelines, paying specific attention to the follow frequently made mistakes: - Errors should be reported as negative numbers using the kernel error codes. See also the CodingStyle document, chapter 16. - Don't use typedefs. See also the CodingStyle document, chapter 5. - When adding/enhancing the API the documentation must be updated as well, otherwise the patch will not be accepted. V4L2 specific requirements: - Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for sub-device drivers. - Each i2c/spi device should be implemented as a separate sub-device driver. - Use the control framework for control handling. - Use struct v4l2_fh if the driver supports events (implied by the use of controls) or priority handling. - Use videobuf2 for buffer handling. - Must pass the v4l2-compliance tests. - Hybrid tuners should be shared with DVB. - When introducing new APIs: - update v4l2-ctl - updates to v4l2-compliance (if applicable) are highly appreciated - update valgrind: support for v4l2 and media ioctls was added for valgrind 3.10 synced to the 3.18 kernel. This should be kept up to date. Patches should be posted as a bug report. See: http://valgrind.org/support/bug_reports.html DVB specific requirements: - Use the DVB core for both internal and external APIs. - Each I2C-based chip should have its own driver. - Tuners and frontends should be mapped as different drivers. - dvb_frontend_ops should specify the delivery system instead of specifying the frontend type via the dvb_frontend_ops info.type field. - DVB frontends should not implement dummy function handlers; if the function is not implemented, the DVB core should handle it properly. - Hybrid tuners should be shared with V4L. How to deal with checkpatch.pl? === First of all, the requirement to comply to the kernel coding style is there for a reason. Sometimes people feel that it is a pointless exercise: after all, code is code, right? Why would just changing some spacing improve it? But the coding style is not there to help you (at least, not directly), it is there to help those who have to review and/or maintain your code as it takes a lot of time to review code or try to figure out how someone else's code works. By at least ensuring that the coding style is consistent with other code we can concentrate on what humans to best: pattern matching. Ever read a book or article that did not use the correct spelling, grammar and/or punctuation rules? Did you notice how your brain 'stumbles' whenever it encounters such mistakes? It makes the text harder
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
Hi Shuah, Some notes below... On 10/21/2014 07:32 PM, Shuah Khan wrote: On 10/21/2014 10:05 AM, Takashi Iwai wrote: At Tue, 21 Oct 2014 17:42:51 +0200, Hans Verkuil wrote: Quite often media apps open the alsa device at the start and then switch between TV, radio or DVB mode. If the alsa device would claim the tuner just by being opened (as opposed to actually using the tuner, which happens when you start streaming), What about parameter changes? The sound devices have to be configured before using. Don't they influence on others at all, i.e. you can change the PCM sample rate etc during TV, radio or DVB is running? Yes. kaffeine uses snd_usb_capture_ops ioctl - snd_pcm_lib_ioctl Other v4l and vlc (dvb) uses open/close as well as trigger start and stop. trigger start/stop is done by a special audio thread in some cases. open/close happens from the main thread. then that would make it impossible for the application to switch tuner mode. In general you want to avoid that open() will start configuring hardware since that can quite often be slow. Tuner configuration in particular can be slow since several common tuners need to load firmware over i2c. You only want to do that when it is really needed, and not when some application (udev!) opens the device just to examine what sort of device it is. But most apps close the device soon after that, no? Which programs keep the PCM device (not the control) opened without actually using? So claiming the tuner in the trigger seems to be the right place. If returning EBUSY is a poor error code for alsa, then we can use something else for that. EACCES perhaps? Sorry, I'm not convinced by that. If the device has to be controlled exclusively, the right position is the open/close. Otherwise, the program cannot know when it becomes inaccessible out of sudden during its operation. Let me share my test matrix for this patch series. Hans pointed out one test case I didn't know about as a result missed testing. Please see if any of the tests miss use-cases or break them: you can scroll down to the proposal at the end, if this is too much detail :) Digital active and analog starting testing: kaffeine running - v4l2-ctl --all - works I would recommend using v4l2-ctl --all --list-inputs, this enumerates inputs as well (which includes reading the tuner status). This would have failed with all these tests with this patch series. - Changing channels works with the same token hold, even when frequency changes. Tested changing channels that force freq change. - vlc resource is busy with no disruption to kaffeine - xawtv - tuner busy when it tries to do ioctls that change tuner settings - snd_usb_pcm_open detects device is busy ( pcm open called from the same thread, trigger gets called from another thread ) - tvtime - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine ( pcm open called from the same thread, trigger gets called from another thread ) - vlc - audio capture on WinTV HVR-950 - device is busy start vlc with no channels for this test - arecord to capture on WinTV HVR-950 - device busy vlc running vlc -v channels.xspf - v4l2-ctl --all - works - Changing channels works with the same token hold, even when frequency changes. Tested changing channels that force freq change. - kaffeine resource is busy with no disruption to vlc - xawtv - tuner busy when it tries to do ioctls that change tuner settings - snd_usb_pcm_open detects device is busy ( pcm open called from the same thread, trigger gets called from another thread ) - tvtime - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine ( pcm open called from the same thread, trigger gets called from another thread ) - vlc - audio capture on WinTV HVR-950 - device is busy - arecord to capture on WinTV HVR-950 - device busy Analog active and start digital testing: xawtv -noalsa -c /dev/video1 - v4l2-ctl --all - works - start kaffeine - fails with device busy and no disruption - start vlc - fails with device busy and no disruption - tvtime - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine - vlc - audio capture on WinTV HVR-950 - device is busy - arecord to capture on WinTV HVR-950 - device busy tvtime - v4l2-ctl --all - works - start kaffeine - fails with device busy and no disruption - start vlc - fails with device busy and no disruption - xawtv - tuner busy when it tries to do ioctls that change tuner settings with no disruption to kaffeine - vlc - audio capture on WinTV HVR-950 - device is busy - arecord to capture on WinTV HVR-950 - device busy The following audio/video start/stop combination tests: ( used arecord as well to test these cases, arecord ) - tvtime start/vlc start/vlc stop/tvtime stop no disruption to
[PATCH 2/2] adv7604: Add support for i2c_new_secondary_device
The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts
as a standard slave device on the I²C bus.
If nothing is defined, it uses default addresses.
The main purpose is using two adv76xx on the same i2c bus.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
.../devicetree/bindings/media/i2c/adv7604.txt | 16 +-
drivers/media/i2c/adv7604.c| 59 ++
2 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 5c8b3e6..8486b5c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -12,7 +12,10 @@ Required Properties:
- adi,adv7611 for the ADV7611
- adi,adv7604 for the ADV7604
- - reg: I2C slave address
+ - reg: I2C slave addresses
+The ADV7604 has thirteen 256-byte maps that can be accessed via the main
+I²C ports. Each map has it own I²C address and acts
+as a standard slave device on the I²C bus.
- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -33,6 +36,12 @@ The digital output port node must contain at least one
endpoint.
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
+ - reg-names : Names of maps with programmable addresses.
+ It can contain any map needing another address than default one.
+ Possible maps names are :
+ADV7604 : main, avlink, cec, infoframe, esdp, dpp, afe, rep,
+ edid, hdmi, test, cp, vdp
+ADV7611 : main, cec, infoframe, afe, rep, edid, hdmi, cp
Optional Endpoint Properties:
@@ -51,7 +60,10 @@ Example:
hdmi_receiver@4c {
compatible = adi,adv7611;
- reg = 0x4c;
+ /* edid page will be accessible @ 0x66 on i2c bus */
+ /* other maps keep their default addresses */
+ reg = 0x4c 0x66;
+ reg-names = main, edid;
reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 421035f..e4e30a2 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,27 @@ static const struct adv7604_video_standards
adv7604_prim_mode_hdmi_gr[] = {
{ },
};
+struct adv7604_register {
+ const char *name;
+ u8 default_addr;
+};
+
+static const struct adv7604_register adv7604_secondary_names[] = {
+ [ADV7604_PAGE_IO] = { main, 0x4c },
+ [ADV7604_PAGE_AVLINK] = { avlink, 0x42 },
+ [ADV7604_PAGE_CEC] = { cec, 0x40 },
+ [ADV7604_PAGE_INFOFRAME] = { infoframe, 0x3e },
+ [ADV7604_PAGE_ESDP] = { esdp, 0x38 },
+ [ADV7604_PAGE_DPP] = { dpp, 0x3c },
+ [ADV7604_PAGE_AFE] = { afe, 0x26 },
+ [ADV7604_PAGE_REP] = { rep, 0x32 },
+ [ADV7604_PAGE_EDID] = { edid, 0x36 },
+ [ADV7604_PAGE_HDMI] = { hdmi, 0x34 },
+ [ADV7604_PAGE_TEST] = { test, 0x30 },
+ [ADV7604_PAGE_CP] = { cp, 0x22 },
+ [ADV7604_PAGE_VDP] = { vdp, 0x24 },
+};
+
/* --- */
static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2549,26 @@ static void adv7604_unregister_clients(struct
adv7604_state *state)
}
static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
- u8 addr, u8 io_reg)
+ unsigned int i)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct adv7604_platform_data *pdata = client-dev.platform_data;
+ unsigned int io_reg = 0xf2 + i;
+ unsigned int default_addr = io_read(sd, io_reg) 1;
+ struct i2c_client *new_client;
+
+ if (pdata pdata-i2c_addresses[i])
+ new_client = i2c_new_dummy(client-adapter,
+ pdata-i2c_addresses[i]);
+ else
+ new_client = i2c_new_secondary_device(client,
+ adv7604_secondary_names[i].name,
+ adv7604_secondary_names[i].default_addr);
+
+ if (new_client)
+ io_write(sd, io_reg, new_client-addr 1);
- if (addr)
- io_write(sd, io_reg, addr 1);
- return i2c_new_dummy(client-adapter, io_read(sd, io_reg) 1);
+ return new_client;
}
static const struct adv7604_reg_seq adv7604_recommended_settings_afe[] = {
@@ -2718,20 +2752,6 @@ static int adv7604_parse_dt(struct adv7604_state *state)
/* Disable the interrupt for now as no DT-based board uses it. */
state-pdata.int1_config
[PATCH 1/2] i2c: Add generic support passing secondary devices addresses
Some I2C devices have multiple addresses assigned, for example each address
corresponding to a different internal register map page of the device.
So far drivers which need support for this have handled this with a driver
specific and non-generic implementation, e.g. passing the additional address
via platform data.
This patch provides a new helper function called i2c_new_secondary_device()
which is intended to provide a generic way to get the secondary address
as well as instantiate a struct i2c_client for the secondary address.
The function expects a pointer to the primary i2c_client, a name
for the secondary address and an optional default address. The name is used
as a handle to specify which secondary address to get.
The default address is used as a fallback in case no secondary address
was explicitly specified. In case no secondary address and no default
address were specified the function returns NULL.
For now the function only supports look-up of the secondary address
from devicetree, but it can be extended in the future
to for example support board files and/or ACPI.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
drivers/i2c/i2c-core.c | 40
include/linux/i2c.h| 8
2 files changed, 48 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 2f90ac6..fd3b07c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1166,6 +1166,46 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter
*adapter, u16 address)
}
EXPORT_SYMBOL_GPL(i2c_new_dummy);
+/**
+ * i2c_new_secondary_device - Helper to get the instantiated secondary address
+ * @client: Handle to the primary client
+ * @name: Handle to specify which secondary address to get
+ * @default_addr: Used as a fallback if no secondary address was specified
+ * Context: can sleep
+ *
+ * This returns an I2C client bound to the dummy driver based on DT parsing.
+ *
+ * This returns the new i2c client, which should be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u16 default_addr)
+{
+ int i;
+ u32 addr;
+ struct device_node *np;
+
+ np = client-dev.of_node;
+
+ if (np) {
+ i = of_property_match_string(np, reg-names, name);
+ if (i = 0)
+ of_property_read_u32_index(np, reg, i, addr);
+ else if (default_addr != 0)
+ addr = default_addr;
+ else
+ addr = NULL;
+ } else {
+ addr = default_addr;
+ }
+
+ dev_dbg(client-adapter-dev, Address for %s : 0x%x\n, name, addr);
+ return i2c_new_dummy(client-adapter, addr);
+}
+EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
+
+
/* - */
/* I2C bus adapters -- one roots each I2C or SMBUS segment */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b556e0a..8629287 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -322,6 +322,14 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *,
unsigned short addr);
extern struct i2c_client *
i2c_new_dummy(struct i2c_adapter *adap, u16 address);
+/* Helper function providing a generic way to get the secondary address
+ * as well as a client handle to this extra address.
+ */
+extern struct i2c_client *
+i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u16 default_addr);
+
extern void i2c_unregister_device(struct i2c_client *);
#endif /* I2C */
--
2.1.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
[PATCH] adv7604: Add DT parsing support
This patch adds support for DT parsing of ADV7604 as well as ADV7611.
It needs to be improved in order to get ports parsing too.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
Documentation/devicetree/bindings/media/i2c/adv7604.txt | 1 +
drivers/media/i2c/adv7604.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..5c8b3e6 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,6 +10,7 @@ Required Properties:
- compatible: Must contain one of the following
- adi,adv7611 for the ADV7611
+- adi,adv7604 for the ADV7604
- reg: I2C slave address
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 47795ff..421035f 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2677,6 +2677,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+ { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
{ }
};
MODULE_DEVICE_TABLE(of, adv7604_of_id);
--
2.1.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] DocBook: Reduce noise from make cleandocs
On Tue, 21 Oct 2014 18:18:12 +0200 Takashi Iwai ti...@suse.de wrote: I've got a harmless warning when running make cleandocs on an already cleaned tree: Applied, thanks. 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: linux-next: Tree for Oct 22 (media/usb/dvb-usb/az6027)
On 10/21/14 20:42, Stephen Rothwell wrote: Hi all, Changes since 20141021: on x86_64: when MEDIA_SUBDRV_AUTOSELECT is not enabled: when DVB_USB_AZ6027=y and DVB_STB0899=m and DVB_STB6100=m: drivers/built-in.o: In function `az6027_frontend_attach': az6027.c:(.text+0x18c50d): undefined reference to `stb0899_attach' az6027.c:(.text+0x18c536): undefined reference to `stb6100_attach' -- ~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] s5p-mfc: correct the formats info for encoder
I am very sorry to forget the Sign-off again and thank you for reviewing. ayaka (1): s5p-mfc: correct the formats info for encoder drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] s5p-mfc: correct the formats info for encoder
The NV12M is supported by all the version of MFC, so it is better
to use it as default OUTPUT format.
MFC v5 doesn't support NV21, I have tested it, for the SEC doc
it is not supported either.
Signed-off-by: ayaka ay...@soulik.info
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index d26b248..4ea3796 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -32,7 +32,7 @@
#include s5p_mfc_intr.h
#include s5p_mfc_opr.h
-#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12MT
+#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M
#define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264
static struct s5p_mfc_fmt formats[] = {
@@ -67,8 +67,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
},
{
.name = H264 Encoded Stream,
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
On 10/21/14, 11:08 AM, Devin Heitmueller wrote: Sorry, I'm not convinced by that. If the device has to be controlled exclusively, the right position is the open/close. Otherwise, the program cannot know when it becomes inaccessible out of sudden during its operation. I can say that I've definitely seen cases where if you configure a device as the default capture device in PulseAudio, then pulse will continue to capture from it even if you're not actively capturing the audio from pulse. I only spotted this because I had a USB analyzer on the device and was dumbfounded when the ISOC packets kept arriving even after I had closed VLC. this seems like a feature, not a bug. PulseAudio starts streaming before clients push any data and likewise keeps sources active even after for some time after clients stop recording. Closing VLC in your example doesn't immediately close the ALSA device. look for module-suspend-on-idle in your default.pa config file. I also agree that the open/close of the alsa device is the only way to control exclusion. -Pierre -- 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: [alsa-devel] [PATCH v2 5/6] sound/usb: pcm changes to use media token api
this seems like a feature, not a bug. PulseAudio starts streaming before clients push any data and likewise keeps sources active even after for some time after clients stop recording. Closing VLC in your example doesn't immediately close the ALSA device. look for module-suspend-on-idle in your default.pa config file. The ALSA userland emulation in PulseAudio is supposed to faithfully emulate the behavior of the ALSA kernel ABI... except when it doesn't, then it's not a bug but rather a feature. :-) I also agree that the open/close of the alsa device is the only way to control exclusion. I was also a proponent that we should have fairly coarse locking done at open/close for the various device nodes (ALSA/V4L/DVB). The challenge here is that we have a large installed based of existing applications that rely on kernel behavior that isn't formally specified in any specification. Hence we're forced to try to come up with a solution that minimizes the risk of ABI breakage. If we were doing this from scratch then we could lay down some hard/fast rules about things apps aren't supposed to do and how apps are supposed to respond to those exception cases. Unfortunately we don't have that luxury here. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: [REVIEW] Submitting Media Patches
Hi Hans, Thanks for doing that! I added a few comments below. Regards, Mauro Em Wed, 22 Oct 2014 16:12:27 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: During the mini-summit it was decided that we should put up a document on how to post/handle patches etc. for the media drivers in the wiki. I had such a doc already which I'm posting now for review. Once it's all OK Pawel offered to put it up in the wiki. - For general information on how to submit patches see: http://linuxtv.org/wiki/index.php/Developer_Section In particular the section 'Submitting Your Work'. This document goes into more detail regarding media specific requirements when submitting patches and what the patch flow looks like in this subsystem. Note 1: there are always exceptions to the rule, so if you believe certain requirements do not apply to your code, then let us know and we can discuss it. Note 2: this list is not exhaustive and will be updated over time, so make sure you always use the latest version of this document. The latest version will always be available here: TBD. Just a remind: don't forget to replace TBD by something at the final version ;) Note 3: when submitting a patch use ./scripts/get_maintainer.pl to figure out who is maintaining the sources you touched. Submitting New Media Drivers When submitting new media drivers for inclusion in drivers/staging/media all that is required is that the driver compiles with the latest kernel, that an entry is added to the MAINTAINERS file, and that a TODO file is added with a list of action items that need to be taken before the driver can be moved to drivers/media. I would replace all that is required by the requirements are, or the basic requirements are. There are of course other reasons why the (sub)maintainers will not allow a driver to be merged at staging, but I'm pretty sure we won't be able to list all of them. For example, very likely a staging a driver for a device already supported at mainstream won't be merged. Also, a driver at staging to be used by some other driver in the mainstream is something that should be avoided. So, better to avoid the usage of all, as I'm sure that will always be some valid exceptions on both directions. Also, IMHO, the best is to present it as a list of requirements. Another requirement that should be added there: - The email of the driver maintainer should always be kept updated. It should be noticed, however, that it is expected that the driver will be fixed to fulfill the requirements for upstream addition. If a driver at staging lacks relevant patches fixing it for more than a few kernel cycles, it can be dropped from staging. We will contact you before doing that provided that the email address of the maintainer is still valid. For inclusion as a non-staging driver the requirements are more strict: General requirements: - It must pass checkpatch.pl, but see the note regarding interpreting the output from checkpatch below. - An entry for the driver is added to the MAINTAINERS file. - The kernel internal APIs are used properly. - Don't reinvent the wheel by adding new defines, math logic, etc. for which there are already solutions in the kernel. - Follow the CodingStyle guidelines, paying specific attention to the follow frequently made mistakes: - Errors should be reported as negative numbers using the kernel error codes. See also the CodingStyle document, chapter 16. - Don't use typedefs. See also the CodingStyle document, chapter 5. - When adding/enhancing the API the documentation must be updated as well, otherwise the patch will not be accepted. V4L2 specific requirements: - Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for sub-device drivers. - Each i2c/spi device should be implemented as a separate sub-device driver. - Use the control framework for control handling. - Use struct v4l2_fh if the driver supports events (implied by the use of controls) or priority handling. - Use videobuf2 for buffer handling. - Must pass the v4l2-compliance tests. - Hybrid tuners should be shared with DVB. According with the discussions at the media mini-summit, they should now use the I2C binding model for both DVB and V4L2. (I suspect you missed this part of the meeting - it was together with the DVB discussions that happened on Friday afternoon). - When introducing new APIs: - update v4l2-ctl - updates to v4l2-compliance (if applicable) are highly appreciated - update valgrind: support for v4l2 and media ioctls was added for valgrind 3.10 synced to the 3.18 kernel. This should be kept up to date. Patches should be posted as a bug report. See: http://valgrind.org/support/bug_reports.html DVB specific requirements: - Use the DVB core
Re: [PATCH/RFC v2 2/4] Add media device related data structures and API.
Hi Sakari,
On Wednesday 22 October 2014 13:03:02 Sakari Ailus wrote:
On Fri, Oct 17, 2014 at 04:54:40PM +0200, Jacek Anaszewski wrote:
...
+/*
+ * struct media_entity - media device entity data
+ * @id:media entity id within media controller
+ * @name: media entity name
+ * @node_name: media entity related device node name
+ * @pads: array of media_entity pads
+ * @num_pads: number of elements in the pads array
+ * @links: array of media_entity links
+ * @num_links: number of elements in the links array
+ * @subdev_fmt:related sub-device format
+ * @fd:related sub-device node file descriptor
+ * @src_pad_id:source pad id when entity is linked
+ * @sink_pad_id: sink pad id when entity is linked
+ * @next: pointer to the next data structure in the list
+ */
+struct media_entity {
+ int id;
+ char name[32];
+ char node_name[32];
+ struct media_pad_desc *pads;
+ int num_pads;
+ struct media_link_desc *links;
+ int num_links;
+ struct v4l2_subdev_format subdev_fmt;
+ int fd;
+ int src_pad_id;
+ int sink_pad_id;
+ struct media_entity *next;
+};
Could you use libmediactl and libv4l2subdev instead here as well? They do
actually implement much of what you do here. Feel free to comment on the
API. The libraries have a little bit different background than this one.
Obviously there's functionality in this library what's not in the two; some
of this might belong to either of the two libraries.
I think we'll need V4L2 sub-device related information stored next to the
media entities as well, so that's something to be added.
I generic mechanism to attach subsystem-specific data to entities sounds good
to me. The fd field could then be moved out of struct media_entity.
--
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
[PATCH v2] media: davinci: vpbe: add support for VIDIOC_CREATE_BUFS
this patch adds support for vidioc_create_bufs. Along side
remove unneeded member numbuffers.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Changes for v2:
a: return -EINVAL in queue_setup() callback if sizeimage is
less then current format size.
b: removed unneeded member numbuffers.
drivers/media/platform/davinci/vpbe_display.c | 10 +++---
include/media/davinci/vpbe_display.h | 2 --
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 3b60749..78b9ffe 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -244,12 +244,15 @@ vpbe_buffer_queue_setup(struct vb2_queue *vq, const
struct v4l2_format *fmt,
v4l2_dbg(1, debug, vpbe_dev-v4l2_dev, vpbe_buffer_setup\n);
+ if (fmt fmt-fmt.pix.sizeimage layer-pix_fmt.sizeimage)
+ return -EINVAL;
+
/* Store number of buffers allocated in numbuffer member */
- if (*nbuffers VPBE_DEFAULT_NUM_BUFS)
- *nbuffers = layer-numbuffers = VPBE_DEFAULT_NUM_BUFS;
+ if (vq-num_buffers + *nbuffers VPBE_DEFAULT_NUM_BUFS)
+ *nbuffers = VPBE_DEFAULT_NUM_BUFS - vq-num_buffers;
*nplanes = 1;
- sizes[0] = layer-pix_fmt.sizeimage;
+ sizes[0] = fmt ? fmt-fmt.pix.sizeimage : layer-pix_fmt.sizeimage;
alloc_ctxs[0] = layer-alloc_ctx;
return 0;
@@ -1241,6 +1244,7 @@ static const struct v4l2_ioctl_ops vpbe_ioctl_ops = {
.vidioc_try_fmt_vid_out = vpbe_display_try_fmt,
.vidioc_reqbufs = vb2_ioctl_reqbufs,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
.vidioc_querybuf = vb2_ioctl_querybuf,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf= vb2_ioctl_dqbuf,
diff --git a/include/media/davinci/vpbe_display.h
b/include/media/davinci/vpbe_display.h
index 163a02b..fa0247a 100644
--- a/include/media/davinci/vpbe_display.h
+++ b/include/media/davinci/vpbe_display.h
@@ -70,8 +70,6 @@ struct vpbe_disp_buffer {
/* vpbe display object structure */
struct vpbe_layer {
- /* number of buffers in fbuffers */
- unsigned int numbuffers;
/* Pointer to the vpbe_display */
struct vpbe_display *disp_dev;
/* Pointer pointing to current v4l2_buffer */
--
1.9.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 10/15] media: davinci: vpbe: add support for VIDIOC_CREATE_BUFS
Hi Hans, On Wed, Oct 22, 2014 at 12:26 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Prabhakar, This patch series looks good, except for this one. If you add create_bufs support, then you should also update queue_setup. If the fmt argument to queue_setup is non-NULL, then check that the fmt.pix.sizeimage field is = the current format's sizeimage. If not, return -EINVAL. This prevents userspace from creating additional buffers that are smaller than the minimum required size. I'm just skipping this patch and queuing all the others for 3.19. Just post an updated version for this one and I'll pick it up later. I fixed it and posted the patch. To avoid conflicts I have rebased the patch on for-v3.19a branch of your tree. Thanks, --Prabhakar Lad -- 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 1/2] i2c: Add generic support passing secondary devices addresses
Hi Jean-Michel,
Thank you for the patch.
On Wednesday 22 October 2014 17:30:47 Jean-Michel Hautbois wrote:
Some I2C devices have multiple addresses assigned, for example each address
corresponding to a different internal register map page of the device.
So far drivers which need support for this have handled this with a driver
specific and non-generic implementation, e.g. passing the additional address
via platform data.
This patch provides a new helper function called i2c_new_secondary_device()
which is intended to provide a generic way to get the secondary address
as well as instantiate a struct i2c_client for the secondary address.
The function expects a pointer to the primary i2c_client, a name
for the secondary address and an optional default address. The name is used
as a handle to specify which secondary address to get.
The default address is used as a fallback in case no secondary address
was explicitly specified. In case no secondary address and no default
address were specified the function returns NULL.
For now the function only supports look-up of the secondary address
from devicetree, but it can be extended in the future
to for example support board files and/or ACPI.
As this is core code I believe the DT bindings should be documented somewhere
in Documentation/devicetree/bindings/i2c/.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
drivers/i2c/i2c-core.c | 40
include/linux/i2c.h| 8
2 files changed, 48 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 2f90ac6..fd3b07c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1166,6 +1166,46 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter
*adapter, u16 address) }
EXPORT_SYMBOL_GPL(i2c_new_dummy);
+/**
+ * i2c_new_secondary_device - Helper to get the instantiated secondary
address
It does more than that, it also creates the device.
+ * @client: Handle to the primary client
+ * @name: Handle to specify which secondary address to get
+ * @default_addr: Used as a fallback if no secondary address was specified
+ * Context: can sleep
+ *
+ * This returns an I2C client bound to the dummy driver based on DT
parsing.
Could you elaborate on that ? I would explain that the address is retrieved
from the firmware based on the name, and that default_addr is used in case the
firmware doesn't provide any information.
+ *
+ * This returns the new i2c client, which should be saved for later use
with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u16 default_addr)
+{
+ int i;
+ u32 addr;
+ struct device_node *np;
+
+ np = client-dev.of_node;
+
+ if (np) {
+ i = of_property_match_string(np, reg-names, name);
+ if (i = 0)
+ of_property_read_u32_index(np, reg, i, addr);
This call could fail in which case addr will be uninitialized.
+ else if (default_addr != 0)
+ addr = default_addr;
+ else
+ addr = NULL;
addr isn't a pointer. I'm surprised the compiler hasn't warned you.
+ } else {
+ addr = default_addr;
+ }
The whole logic can be simplified to
struct device_node *np = client-dev.of_node;
u32 addr = default_addr;
int i;
if (np) {
i = of_property_match_string(np, reg-names, name);
if (i = 0)
of_property_read_u32_index(np, reg, i, addr);
}
+
+ dev_dbg(client-adapter-dev, Address for %s : 0x%x\n, name, addr);
+ return i2c_new_dummy(client-adapter, addr);
+}
+EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
+
+
/*
-
*/
/* I2C bus adapters -- one roots each I2C or SMBUS segment */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b556e0a..8629287 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -322,6 +322,14 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter
*, unsigned short addr); extern struct i2c_client *
i2c_new_dummy(struct i2c_adapter *adap, u16 address);
+/* Helper function providing a generic way to get the secondary address
+ * as well as a client handle to this extra address.
+ */
The function is already documented in i2c-core.c, I would ditch this comment.
+extern struct i2c_client *
+i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u16 default_addr);
+
extern void i2c_unregister_device(struct i2c_client *);
#endif /* I2C */
--
Regards,
Laurent Pinchart
--
To
Re: [PATCH 2/2] adv7604: Add support for i2c_new_secondary_device
Hi Jean-Michel,
Thank you for the patch.
On Wednesday 22 October 2014 17:30:48 Jean-Michel Hautbois wrote:
The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts
as a standard slave device on the I²C bus.
If nothing is defined, it uses default addresses.
The main purpose is using two adv76xx on the same i2c bus.
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
.../devicetree/bindings/media/i2c/adv7604.txt | 16 +-
drivers/media/i2c/adv7604.c| 59 ---
2 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
5c8b3e6..8486b5c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -12,7 +12,10 @@ Required Properties:
- adi,adv7611 for the ADV7611
- adi,adv7604 for the ADV7604
Given that I'll have comment on the independent patch that adds support for
the adv7604, you should rebase this series to remote that dependency if you
want to get it merged now, otherwise it will get delayed.
- - reg: I2C slave address
+ - reg: I2C slave addresses
+The ADV7604 has thirteen 256-byte maps that can be accessed via the
main
+I²C ports. Each map has it own I²C address and acts
+as a standard slave device on the I²C bus.
- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -33,6 +36,12 @@ The digital output port node must contain at least one
endpoint. Optional Properties:
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
+ - reg-names : Names of maps with programmable addresses.
+ It can contain any map needing another address than default one.
+ Possible maps names are :
+ADV7604 : main, avlink, cec, infoframe, esdp, dpp, afe,
rep,
+ edid, hdmi, test, cp, vdp
If you rebase the series in order to avoid depending on the adv7604 DT support
patch this line should be moved to adv7604: Add DT parsing support.
+ADV7611 : main, cec, infoframe, afe, rep, edid, hdmi, cp
Optional Endpoint Properties:
@@ -51,7 +60,10 @@ Example:
hdmi_receiver@4c {
compatible = adi,adv7611;
- reg = 0x4c;
+ /* edid page will be accessible @ 0x66 on i2c bus */
+ /* other maps keep their default addresses */
+ reg = 0x4c 0x66;
+ reg-names = main, edid;
reset-gpios = ioexp 0 GPIO_ACTIVE_LOW;
hpd-gpios = ioexp 2 GPIO_ACTIVE_HIGH;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 421035f..e4e30a2 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,27 @@ static const struct adv7604_video_standards
adv7604_prim_mode_hdmi_gr[] = { { },
};
+struct adv7604_register {
+ const char *name;
+ u8 default_addr;
+};
+
+static const struct adv7604_register adv7604_secondary_names[] = {
+ [ADV7604_PAGE_IO] = { main, 0x4c },
+ [ADV7604_PAGE_AVLINK] = { avlink, 0x42 },
+ [ADV7604_PAGE_CEC] = { cec, 0x40 },
+ [ADV7604_PAGE_INFOFRAME] = { infoframe, 0x3e },
+ [ADV7604_PAGE_ESDP] = { esdp, 0x38 },
+ [ADV7604_PAGE_DPP] = { dpp, 0x3c },
+ [ADV7604_PAGE_AFE] = { afe, 0x26 },
+ [ADV7604_PAGE_REP] = { rep, 0x32 },
+ [ADV7604_PAGE_EDID] = { edid, 0x36 },
+ [ADV7604_PAGE_HDMI] = { hdmi, 0x34 },
+ [ADV7604_PAGE_TEST] = { test, 0x30 },
+ [ADV7604_PAGE_CP] = { cp, 0x22 },
+ [ADV7604_PAGE_VDP] = { vdp, 0x24 },
+};
+
/* ---
*/
static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2549,26 @@ static void adv7604_unregister_clients(struct
adv7604_state *state) }
static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
- u8 addr, u8 io_reg)
+ unsigned int i)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct adv7604_platform_data *pdata = client-dev.platform_data;
+ unsigned int io_reg = 0xf2 + i;
+ unsigned int default_addr = io_read(sd, io_reg) 1;
The variable isn't used.
+ struct i2c_client *new_client;
+
+ if (pdata pdata-i2c_addresses[i])
+ new_client = i2c_new_dummy(client-adapter,
+ pdata-i2c_addresses[i]);
+ else
+ new_client = i2c_new_secondary_device(client,
+ adv7604_secondary_names[i].name,
+ adv7604_secondary_names[i].default_addr);
+
+ if
Re: [PATCH] adv7604: Add DT parsing support
Hi Jean-Michel,
Thank you for the patch.
On Wednesday 22 October 2014 17:34:21 Jean-Michel Hautbois wrote:
This patch adds support for DT parsing of ADV7604 as well as ADV7611.
It needs to be improved in order to get ports parsing too.
Let's improve it then :-) The DT bindings as proposed by this patch are
incomplete, that's just asking for trouble.
How would you model the adv7604 ports ?
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
Documentation/devicetree/bindings/media/i2c/adv7604.txt | 1 +
drivers/media/i2c/adv7604.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
c27cede..5c8b3e6 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,6 +10,7 @@ Required Properties:
- compatible: Must contain one of the following
- adi,adv7611 for the ADV7611
+- adi,adv7604 for the ADV7604
Please switch the two lines to keep them alphabetically sorted.
- reg: I2C slave address
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 47795ff..421035f 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2677,6 +2677,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+ { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
Same comment here.
{ }
};
MODULE_DEVICE_TABLE(of, adv7604_of_id);
--
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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Oct 23 04:00:16 CEST 2014 git branch: test git hash: 1ef24960ab78554fe7e8e77d8fc86524fbd60d3c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-34-g71e642a host hardware: x86_64 host os:3.17-0.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK 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.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-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-i686: OK 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.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 linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS 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: [PATCH] adv7604: Add DT parsing support
Hi Laurent,
Thank you for reviewing,
2014-10-23 1:53 GMT+02:00 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Jean-Michel,
Thank you for the patch.
On Wednesday 22 October 2014 17:34:21 Jean-Michel Hautbois wrote:
This patch adds support for DT parsing of ADV7604 as well as ADV7611.
It needs to be improved in order to get ports parsing too.
Let's improve it then :-) The DT bindings as proposed by this patch are
incomplete, that's just asking for trouble.
How would you model the adv7604 ports ?
I am opened to suggestions :).
But it has to remain as simple as possible, ideally allowing for
giving names to the ports.
As done today, it works, ports are parsed but are all the same...
Signed-off-by: Jean-Michel Hautbois jean-michel.hautb...@vodalys.com
---
Documentation/devicetree/bindings/media/i2c/adv7604.txt | 1 +
drivers/media/i2c/adv7604.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
c27cede..5c8b3e6 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,6 +10,7 @@ Required Properties:
- compatible: Must contain one of the following
- adi,adv7611 for the ADV7611
+- adi,adv7604 for the ADV7604
Please switch the two lines to keep them alphabetically sorted.
- reg: I2C slave address
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 47795ff..421035f 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2677,6 +2677,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = adi,adv7611, .data = adv7604_chip_info[ADV7611] },
+ { .compatible = adi,adv7604, .data = adv7604_chip_info[ADV7604] },
Same comment here.
Done on my side, but will wait for your suggestions, in order to add
ports parsing ;-).
Thanks,
JM
--
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
