[PATCH 2/2] solo6x10: Simplify solo_enum_ext_input
Additionally, now it specifies which channels it's showing. Signed-off-by: Ismael Luceno --- drivers/media/pci/solo6x10/solo6x10-v4l2.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2.c b/drivers/media/pci/solo6x10/solo6x10-v4l2.c index 721ff53..935c1b6 100644 --- a/drivers/media/pci/solo6x10/solo6x10-v4l2.c +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2.c @@ -386,26 +386,17 @@ static int solo_querycap(struct file *file, void *priv, static int solo_enum_ext_input(struct solo_dev *solo_dev, struct v4l2_input *input) { - static const char * const dispnames_1[] = { "4UP" }; - static const char * const dispnames_2[] = { "4UP-1", "4UP-2" }; - static const char * const dispnames_5[] = { - "4UP-1", "4UP-2", "4UP-3", "4UP-4", "16UP" - }; - const char * const *dispnames; - - if (input->index >= (solo_dev->nr_chans + solo_dev->nr_ext)) - return -EINVAL; - - if (solo_dev->nr_ext == 5) - dispnames = dispnames_5; - else if (solo_dev->nr_ext == 2) - dispnames = dispnames_2; - else - dispnames = dispnames_1; + int ext = input->index - solo_dev->nr_chans; + unsigned int nup, first; - snprintf(input->name, sizeof(input->name), "Multi %s", -dispnames[input->index - solo_dev->nr_chans]); + if (ext >= solo_dev->nr_ext) + return -EINVAL; + nup = (ext == 4) ? 16 : 4; + first = (ext & 3) << 2; + snprintf(input->name, sizeof(input->name), +"Multi %d-up (cameras %d-%d)", +nup, first + 1, first + nup); return 0; } -- 2.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB
Such frame size is met in practice. Also report oversized frames. Based on patches by Andrey Utkin . Signed-off-by: Ismael Luceno --- drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c index 67a14c4..f98017b 100644 --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c @@ -33,7 +33,7 @@ #include "solo6x10-jpeg.h" #define MIN_VID_BUFFERS2 -#define FRAME_BUF_SIZE (196 * 1024) +#define FRAME_BUF_SIZE (200 * 1024) #define MP4_QS 16 #define DMA_ALIGN 4096 @@ -323,8 +323,11 @@ static int solo_send_desc(struct solo_enc_dev *solo_enc, int skip, int i; int ret; - if (WARN_ON_ONCE(size > FRAME_BUF_SIZE)) + if (WARN_ON_ONCE(size > FRAME_BUF_SIZE)) { + dev_warn(&solo_dev->pdev->dev, +"oversized frame (%d bytes)\n", size); return -EINVAL; + } solo_enc->desc_count = 1; -- 2.8.0 -- 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: OK
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: Sat Apr 30 04:00:17 CEST 2016 git branch: test git hash: 45c175c4ae9695d6d2f30a45ab7f3866cfac184b gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3413-g618cd5c host hardware: x86_64 host os:4.5.0-164 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-bf561: 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.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK 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.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-i686: OK linux-4.5-i686: OK linux-4.6-rc1-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK 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.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-x86_64: OK linux-4.5-x86_64: OK linux-4.6-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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] [media] em28xx_dvb: add support for PLEX PX-BCUD (ISDB-S usb dongle)
Hi, Satoshi, just some small comments about tuners/qm1d1c0042... > --- a/drivers/media/tuners/qm1d1c0042.c > +++ b/drivers/media/tuners/qm1d1c0042.c > @@ -32,14 +32,23 @@ > #include "qm1d1c0042.h" > > #define QM1D1C0042_NUM_REGS 0x20 > - > -static const u8 reg_initval[QM1D1C0042_NUM_REGS] = { > -0x48, 0x1c, 0xa0, 0x10, 0xbc, 0xc5, 0x20, 0x33, > -0x06, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, > -0x00, 0xff, 0xf3, 0x00, 0x2a, 0x64, 0xa6, 0x86, > -0x8c, 0xcf, 0xb8, 0xf1, 0xa8, 0xf2, 0x89, 0x00 > +#define QM1D1C0042_NUM_REG_ROWS 2 > + > +static const u8 > reg_initval[QM1D1C0042_NUM_REG_ROWS][QM1D1C0042_NUM_REGS] = { { > +0x48, 0x1c, 0xa0, 0x10, 0xbc, 0xc5, 0x20, 0x33, > +0x06, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, > +0x00, 0xff, 0xf3, 0x00, 0x2a, 0x64, 0xa6, 0x86, > +0x8c, 0xcf, 0xb8, 0xf1, 0xa8, 0xf2, 0x89, 0x00 > +}, { > +0x68, 0x1c, 0xc0, 0x10, 0xbc, 0xc1, 0x11, 0x33, > +0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, > +0x00, 0xff, 0xf3, 0x00, 0x3f, 0x25, 0x5c, 0xd6, > +0x55, 0xcf, 0x95, 0xf6, 0x36, 0xf2, 0x09, 0x00 > +} > }; > > +static int reg_index; > + * The names of _REG_ROWS / reg_index might be a bit vague to others. I would prefer _CHIP_IDS / chip_id or something like that. * reg_index should not be static as it is per device property. Instead, it shouldj be defined in qm1d1c0042_init() locally, or in struct qm1d1c0042_state, if "reg_index" can be used elsewhere. Thre rest looks OK to me. regards, akihiro -- 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: camera application for testing (was Re: v4l subdevs without big device)
Hi, On 30.04.2016 01:20, Pali Rohár wrote: On Saturday 30 April 2016 00:13:59 Pavel Machek wrote: Any other application I should look at? Thanks, Maybe camera-ui, which is part of CSSU? https://github.com/community-ssu/camera-ui This is based on gdigicam, are you sure it is compatible with recent kernel/userspace? Also, iirc gdigicam needs omap3camd working, but we still don't have the needed compat layer. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: fix use-after-free in cdev_put() when app exits after driver unbind
When driver unbinds while media_ioctl is in progress, cdev_put() fails with when app exits after driver unbinds. Add a kobject to the media_devnode structure and set this kobject as the cdev parent kobject. This allows cdev_add() to hold a reference to it and release the reference in cdev_del() ensuring that the media_devnode is not deallocated as long as the application has the cdev open. This problem is found on uvcvideo, em28xx, and au0828 drivers and fix has been tested on all three. cdev_put() error as follows: kernel: [ 193.599736] BUG: KASAN: use-after-free in cdev_put+0x4e/0x50 at addr 8801d31af2b8 kernel: [ 193.599745] Read of size 8 by task media_device_te/1851 kernel: [ 193.599792] INFO: Allocated in __media_device_register+0x54/0x2e0 [media] age=38615 cpu=0 pid=313 kernel: [ 193.599951] INFO: Freed in media_devnode_release+0xa4/0xc0 [media] age=0 cpu=0 pid=1851 kernel: [ 193.601083] Call Trace: kernel: [ 193.601093] [] dump_stack+0x67/0x94 kernel: [ 193.601102] [] print_trailer+0x112/0x1a0 kernel: [ 193.60] [] object_err+0x34/0x40 kernel: [ 193.601119] [] kasan_report_error+0x224/0x530 kernel: [ 193.601128] [] ? kzfree+0x2d/0x40 kernel: [ 193.601137] [] ? kfree+0x1d2/0x1f0 kernel: [ 193.601145] [] __asan_report_load8_noabort+0x43/0x50 kernel: [ 193.601154] [] ? cdev_put+0x4e/0x50 kernel: [ 193.601162] [] cdev_put+0x4e/0x50 kernel: [ 193.601170] [] __fput+0x52b/0x6c0 kernel: [ 193.601179] [] ? switch_task_namespaces+0x2a/0x90 kernel: [ 193.601188] [] fput+0xe/0x10 kernel: [ 193.601196] [] task_work_run+0x133/0x1f0 kernel: [ 193.601204] [] ? switch_task_namespaces+0x5e/0x90 anduin kernel: [ 193.601213] [] do_exit+0x72c/0x2c20 anduin kernel: [ 193.601224] [] ? release_task+0x1250/0x1250 - - - kernel: [ 193.601360] [] ? exit_to_usermode_loop+0xe7/0x170 kernel: [ 193.601368] [] exit_to_usermode_loop+0x120/0x170 kernel: [ 193.601376] [] syscall_return_slowpath+0x16a/0x1a0 kernel: [ 193.601386] [] entry_SYSCALL_64_fastpath+0xa6/0xa8 Signed-off-by: Shuah Khan --- drivers/media/media-device.c | 6 -- drivers/media/media-devnode.c | 21 +++-- include/media/media-devnode.h | 2 ++ 3 files changed, 25 insertions(+), 4 deletions(-) diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 84e6a0b..b388a0e 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -742,16 +742,16 @@ int __must_check __media_device_register(struct media_device *mdev, ret = media_devnode_register(mdev, devnode, owner); if (ret < 0) { + /* kfree devnode is done via kobject_put() handler */ mdev->devnode = NULL; - kfree(devnode); return ret; } ret = device_create_file(&devnode->dev, &dev_attr_model); if (ret < 0) { + /* kfree devnode is done via kobject_put() handler */ mdev->devnode = NULL; media_devnode_unregister(devnode); - kfree(devnode); return ret; } @@ -829,6 +829,8 @@ void media_device_unregister(struct media_device *mdev) if (media_devnode_is_registered(mdev->devnode)) { device_remove_file(&mdev->devnode->dev, &dev_attr_model); media_devnode_unregister(mdev->devnode); + /* kfree devnode is done via kobject_put() handler */ + mdev->devnode = NULL; } dev_dbg(mdev->dev, "Media device unregistered\n"); diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index ca7c4b9..21f81f3 100644 --- a/drivers/media/media-devnode.c +++ b/drivers/media/media-devnode.c @@ -75,8 +75,6 @@ static void media_devnode_release(struct device *cd) /* Release media_devnode and perform other cleanups as needed. */ if (devnode->release) devnode->release(devnode); - - kfree(devnode); } static struct bus_type media_bus_type = { @@ -221,6 +219,19 @@ static const struct file_operations media_devnode_fops = { .llseek = no_llseek, }; +static void media_devnode_free(struct kobject *kobj) +{ + struct media_devnode *devnode = + container_of(kobj, struct media_devnode, kobj); + + kfree(devnode); + pr_info("%s: Media Devnode Deallocated\n", __func__); +} + +static struct kobj_type media_devnode_ktype = { + .release = media_devnode_free, +}; + int __must_check media_devnode_register(struct media_device *mdev, struct media_devnode *devnode, struct module *owner) @@ -243,9 +254,12 @@ int __must_check media_devnode_register(struct media_device *mdev, devnode->minor = minor; devnode->media_dev = mdev; + kobject_init(&devnode->kobj, &media_devnode_ktype); + /* Part 2: Initialize and register the character device */ cdev_i
Re: camera application for testing (was Re: v4l subdevs without big device)
On Saturday 30 April 2016 00:13:59 Pavel Machek wrote: > Any other application I should look at? Thanks, Maybe camera-ui, which is part of CSSU? https://github.com/community-ssu/camera-ui -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
camera application for testing (was Re: v4l subdevs without big device)
Hi! What is reasonable camera application for testing? N900 looks like a low-end digital camera. I have now have the hardware working (can set focus to X cm using command line), but that's not going to be useful for taking photos. In particular, who is going to do computation neccessary for autofocus, whitebalance and exposure/gain? There's http://fcam.garage.maemo.org/gettingStarted.html that should work on maemo, but a) it is not in Debian, b) it has non-trivial dependencies and c) will be a lot of fun to get working... (and d), will not be too useful, anyway, due to 1sec shutter lag: Fast resolution switching (less shutter lag) FCam is built on top of V4L2, which doesn't handle rapidly varying resolutions. When a Shot with a different resolution to the previous one comes down the pipeline, FCam currently flushes the entire V4L2 pipeline, shuts down and restarts the whole camera subsystem, then starts streaming at the new resolution. This takes a long time (nearly a second), and is the cause of the horrible shutter lag on the N900. A brave kernel hacker may be able to reduce this time by fiddling with the FCam ISP kernel modules and the guts of the FCam library source (primarily Daemon.cpp). Anyone who solves this one will have our undying gratitude. An ideal solution would be able to insert a 5MP capture into a stream of 640x480 frames running at 30fps, without skipping more than the frame time of the 5MP capture. That is, the viewfinder would effectively stay live while taking a photograph. ) Any other application I should look at? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[pre-rfc] focus and flash for Nokia N900 (was Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*)
Hi! > "5. DT Bindings for flash & lens controllers > > There are drivers that create their MC topology using the device tree > information, > which works great for entities that transport data, but how to detect entities > that don’t transport data such as flash devices, focusers, etc.? How can > those be > deduced using the device tree? > > Sensor DT node add phandle to focus controller: add generic v4l binding > properties > to reference such devices." > > This wasn't a problem with the original N900 since that didn't use DT AFAIK > and > these devices were loaded explicitly through board code. > > But now you run into the same problem that I have. > > The solution is that sensor devices have to provide phandles to those > controller > devices. And to do that you need to define bindings which is always the hard > part. > > Look in Documentation/devicetree/bindings/media/video-interfaces.txt, section > "Optional endpoint properties". > > Something like: > > controllers: an array of phandles to controller devices associated with this > endpoint such as flash and lens controllers. Ok, so after a big fight, I got both auto focus and flash to work on n900. Relative to N900 camera trees recently posted. Subdevs behave rather funny, and --sleep-forever is needed for useful operation. YA=/my/tui/yavta/yavta # torch sudo $YA --sleep-forever --set-control '0x009c0901 2' /dev/v4l-subdev11 # focus -- near sudo $YA --sleep-forever --set-control '0x009a090a 1023' /dev/l-subdev12 Signed-off-by: Pavel Machek diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 9c9c1e8..acf1457 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -239,6 +239,7 @@ pinctrl-names = "default"; pinctrl-0 = <&camera_pins>; + ti,camera-flashes = <&adp1653 &cam1 &ad5820 &cam1>; ports { port@1 { @@ -251,7 +252,7 @@ data-lanes = <1>; lane-polarity = <0 0>; clock-inv = <0>; - strobe = <0>; + strobe = <1>; crc = <0>; }; }; @@ -879,6 +880,16 @@ }; }; }; + + /* D/A converter for auto-focus */ + ad5820: dac@0c { + compatible = "adi,ad5820"; + reg = <0x0c>; + + VANA-supply = <&vaux4>; + + #io-channel-cells = <0>; + }; }; &mmc1 { diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 254c106..77313a1 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -279,6 +279,13 @@ config VIDEO_ML86V7667 To compile this driver as a module, choose M here: the module will be called ml86v7667. +config VIDEO_AD5820 + tristate "AD5820 lens voice coil support" + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER + ---help--- + This is a driver for the AD5820 camera lens voice coil. + It is used for example in Nokia N900 (RX-51). + config VIDEO_SAA7110 tristate "Philips SAA7110 video decoder" depends on VIDEO_V4L2 && I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 05e79aa..34434ae 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -20,6 +20,7 @@ obj-$(CONFIG_VIDEO_SAA717X) += saa717x.o obj-$(CONFIG_VIDEO_SAA7127) += saa7127.o obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o +obj-$(CONFIG_VIDEO_AD5820) += ad5820.o obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c new file mode 100644 index 000..5aee185 --- /dev/null +++ b/drivers/media/i2c/ad5820.c @@ -0,0 +1,526 @@ +/* + * drivers/media/i2c/ad5820.c + * + * AD5820 DAC driver for camera voice coil focus. + * + * Copyright (C) 2008 Nokia Corporation + * Copyright (C) 2007 Texas Instruments + * + * Contact: Tuukka Toivonen + * Sakari Ailus + * + * Based on af_d88.c by Texas Instruments. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + */ + +#include +#include +#include
Re: [RFC PATCH 00/24] Make Nokia N900 cameras working
Hi, On 29.04.2016 20:45, Sebastian Reichel wrote: Hi, On Fri, Apr 29, 2016 at 02:05:52AM +0200, Sebastian Reichel wrote: On Wed, Apr 27, 2016 at 08:12:50PM +0300, Ивайло Димитров wrote: The zImage + initrd works with the steps you described below. Great! I also got it working with the previously referenced branch with the following built as modules: CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_MEMOPS=m CONFIG_VIDEOBUF2_DMA_CONTIG=m CONFIG_VIDEO_OMAP3=m CONFIG_VIDEO_BUS_SWITCH=m CONFIG_VIDEO_SMIAPP_PLL=m CONFIG_VIDEO_SMIAPP=m CONFIG_VIDEO_SMIAREGS=m CONFIG_VIDEO_ET8EK8=m Ok, I found the problem. CONFIG_VIDEO_OMAP3=y does not work, due to missing -EPROBE_DEFER handling for vdds_csib. I added it and just got a test image with builtin CONFIG_VIDEO_OMAP3. The below patch fixes the problem. Cool :) vdd-csiphy1/2 will need the same handling, but lets have what is done so far rolling, those can be fixed later on. commit 9d8333b29207de3a9b6ac99db2dfd91e2f8c0216 Author: Sebastian Reichel Date: Fri Apr 29 19:23:02 2016 +0200 omap3isp: handle -EPROBE_DEFER for vdds_csib omap3isp may be initialized before the regulator's driver has been loaded resulting in vdds_csib=NULL. Fix this by handling -EPROBE_DEFER for vdds_csib. Signed-Off-By: Sebastian Reichel diff --git a/drivers/media/platform/omap3isp/ispccp2.c b/drivers/media/platform/omap3isp/ispccp2.c index 833eed411886..2d1463a72d6a 100644 --- a/drivers/media/platform/omap3isp/ispccp2.c +++ b/drivers/media/platform/omap3isp/ispccp2.c @@ -1167,6 +1167,8 @@ int omap3isp_ccp2_init(struct isp_device *isp) if (isp->revision == ISP_REVISION_2_0) { ccp2->vdds_csib = devm_regulator_get(isp->dev, "vdds_csib"); if (IS_ERR(ccp2->vdds_csib)) { + if (PTR_ERR(ccp2->vdds_csib) == -EPROBE_DEFER) + return -EPROBE_DEFER; dev_dbg(isp->dev, "Could not get regulator vdds_csib\n"); ccp2->vdds_csib = NULL; Sakari, how we're going to proceed, it seems there are a couple of patches in the series which can be directly upstreamed, how's that gonna happen? IOW - I don't know how this RFC stuff works, are there any docs I can use to educate myself? Thanks, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/24] Make Nokia N900 cameras working
Hi, On Fri, Apr 29, 2016 at 02:05:52AM +0200, Sebastian Reichel wrote: > On Wed, Apr 27, 2016 at 08:12:50PM +0300, Ивайло Димитров wrote: > > > The zImage + initrd works with the steps you described below. > > > > Great! > > I also got it working with the previously referenced branch with the > following built as modules: > > CONFIG_VIDEOBUF2_CORE=m > CONFIG_VIDEOBUF2_MEMOPS=m > CONFIG_VIDEOBUF2_DMA_CONTIG=m > CONFIG_VIDEO_OMAP3=m > CONFIG_VIDEO_BUS_SWITCH=m > CONFIG_VIDEO_SMIAPP_PLL=m > CONFIG_VIDEO_SMIAPP=m > CONFIG_VIDEO_SMIAREGS=m > CONFIG_VIDEO_ET8EK8=m Ok, I found the problem. CONFIG_VIDEO_OMAP3=y does not work, due to missing -EPROBE_DEFER handling for vdds_csib. I added it and just got a test image with builtin CONFIG_VIDEO_OMAP3. The below patch fixes the problem. commit 9d8333b29207de3a9b6ac99db2dfd91e2f8c0216 Author: Sebastian Reichel Date: Fri Apr 29 19:23:02 2016 +0200 omap3isp: handle -EPROBE_DEFER for vdds_csib omap3isp may be initialized before the regulator's driver has been loaded resulting in vdds_csib=NULL. Fix this by handling -EPROBE_DEFER for vdds_csib. Signed-Off-By: Sebastian Reichel diff --git a/drivers/media/platform/omap3isp/ispccp2.c b/drivers/media/platform/omap3isp/ispccp2.c index 833eed411886..2d1463a72d6a 100644 --- a/drivers/media/platform/omap3isp/ispccp2.c +++ b/drivers/media/platform/omap3isp/ispccp2.c @@ -1167,6 +1167,8 @@ int omap3isp_ccp2_init(struct isp_device *isp) if (isp->revision == ISP_REVISION_2_0) { ccp2->vdds_csib = devm_regulator_get(isp->dev, "vdds_csib"); if (IS_ERR(ccp2->vdds_csib)) { + if (PTR_ERR(ccp2->vdds_csib) == -EPROBE_DEFER) + return -EPROBE_DEFER; dev_dbg(isp->dev, "Could not get regulator vdds_csib\n"); ccp2->vdds_csib = NULL; -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] media: fix media_ioctl use-after-free when driver unbinds
On 04/28/2016 01:19 AM, Lars-Peter Clausen wrote: > On 04/27/2016 11:56 PM, Shuah Khan wrote: dev_dbg(mdev->dev, "Media device unregistered\n"); } diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c index 29409f4..9af9ba1 100644 --- a/drivers/media/media-devnode.c +++ b/drivers/media/media-devnode.c @@ -171,6 +171,9 @@ static int media_open(struct inode *inode, struct file *filp) mutex_unlock(&media_devnode_lock); return -ENXIO; } + + kobject_get(&mdev->kobj); >>> >>> This is not necessary, and if it was it would be prone to race condition as >>> the last reference could be dropped before this line. But assigning the cdev >>> parent makes sure that we always have a reference to the object while the >>> open() callback is running. >> >> I don't see cdev parent kobj get in cdev_get() which does kobject_get() >> on cdev->kobj. Is that enough to get the reference? >> >> cdev_add() gets the cdev parent kobj and cdev_del() puts it back. That is >> the reason why I added a get here and put in media_release(). >> > > The cdev takes the parent reference when created and only drops it once it > is released. So as long as the cdev exists there is a reference to the > parent. While cdev_del() puts one reference to the cdev there is also one > reference for each open file. So as long as there is a open file there is a > reference to the parent as well. > >> I can remove the get and put and test. Looks like I am not checking >> kobject_get() return value which isn't good? > > kobject_get() can't fail. Yes looks that way, yet there are so many places in lib/kobject.c that check for kobject_get() returning NULL. :) > >> >>> + /* and increase the device refcount */ get_device(&mdev->dev); mutex_unlock(&media_devnode_lock); /* >>> [...] diff --git a/include/media/media-devnode.h b/include/media/media-devnode.h index fe42f08..ba4bdaa 100644 --- a/include/media/media-devnode.h +++ b/include/media/media-devnode.h @@ -70,7 +70,9 @@ struct media_file_operations { * @fops: pointer to struct &media_file_operations with media device ops * @dev: struct device pointer for the media controller device * @cdev: struct cdev pointer character device + * @kobj: struct kobject * @parent: parent device + * @media_dev:media device * @minor:device node minor number * @flags:flags, combination of the MEDIA_FLAG_* constants * @release: release callback called at the end of media_devnode_release() @@ -87,7 +89,9 @@ struct media_devnode { /* sysfs */ struct device dev; /* media device */ struct cdev cdev; /* character device */ + struct kobject kobj;/* set as cdev parent kobj */ >>> >>> You don't need a extra kobj. Just use the struct dev kobj. >> >> Yeah I can use that as long as I can override the default release >> function with media_devnode_free(). media_devnode should stick around >> until the last app closes /dev/mediaX even if the media_device is no >> longer registered. i.e media_ioctl should be able to check if devnode >> is registered or not. I think I am missing something and don't understand >> how struct dev kobj can be used. > > The struct dev that is embedded into th media_devnode as the same live time > as the media_devnode itself. In addition to that struct device is a > reference counted object. This means a structure that embeds struct device > must not be freed until the last reference is dropped. > > What you do here is introduce a independent reference counting mechanism for > the same structure. Which means if there is a reference to struct device, > but not to the new kobj you end up with a use-after-free again. > > The solution is to only use one reference counting mechanism (the struct > device) and intialize the cdev kobj parent to the device kobj and whenever > you did kobj_{get,put}() replace that with {get,put}_device(). And in the > device release callback free the struct media_devnode. > Okay. It is all well and good that I can use the kobj in devnode->dev, however, devnode->dev doesn't get initialized in device_register(&devnode->dev) and cdev_add() is the one that does kobject_get() on the cdev parent kobj. I am seeing: [ 45.724866] au0828: Registered device AU0828 [Hauppauge HVR950Q] [ 45.724961] [ cut here ] [ 45.724975] WARNING: CPU: 1 PID: 312 at lib/kobject.c:597 kobject_get+0x8f/0xf0 [ 45.724982] kobject: '(null)' (8801f6166530): is not initialized, yet kobject_get() is being called. warnings as soon as drivers do cdev_add(). This will be a problem at cdev_del() time, since cdev_del() is done after device_unregister(&devnode->dev) and device_del() deletes the dev->kobj In other words, devnode->dev lifetime is go
[PATCH] [media] em28xx_dvb: add support for PLEX PX-BCUD (ISDB-S usb dongle)
Hi Mauro, Akihiro, I resend the same patch except that no credit info of mine is added because of not rewriting a significant amount of the driver. I got some reports that this patch works well on PX-BCUD and PT3, those are the all devices can be affected by this patch. -- I added em28xx_dvb to support for PLEX PX-BCUD (ISDB-S usb dongle). Please move forward with this patch if there is no problem. Or something wrong, please advise me what I should do. PX-BCUD has the following components: USB interface: Empia EM28178 Demodulator: Toshiba TC90532 (works by code for TC90522) Tuner: Next version of Sharp QM1D1C0042 em28xx_dvb_init(), add init code for PLEX PX-BCUD with calling px_bcud_init() that does things like pin configuration. qm1d1c0042_init(), support the next version of QM1D1C0042, change to choose an appropriate array of initial registers by reading chip id. Signed-off-by: Satoshi Nagahama --- drivers/media/tuners/qm1d1c0042.c | 34 +++--- drivers/media/usb/em28xx/Kconfig| 2 + drivers/media/usb/em28xx/em28xx-cards.c | 27 drivers/media/usb/em28xx/em28xx-dvb.c | 115 drivers/media/usb/em28xx/em28xx.h | 1 + 5 files changed, 168 insertions(+), 11 deletions(-) diff --git a/drivers/media/tuners/qm1d1c0042.c b/drivers/media/tuners/qm1d1c0042.c index 18bc745..bc2fb74 100644 --- a/drivers/media/tuners/qm1d1c0042.c +++ b/drivers/media/tuners/qm1d1c0042.c @@ -32,14 +32,23 @@ #include "qm1d1c0042.h" #define QM1D1C0042_NUM_REGS 0x20 - -static const u8 reg_initval[QM1D1C0042_NUM_REGS] = { - 0x48, 0x1c, 0xa0, 0x10, 0xbc, 0xc5, 0x20, 0x33, - 0x06, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, - 0x00, 0xff, 0xf3, 0x00, 0x2a, 0x64, 0xa6, 0x86, - 0x8c, 0xcf, 0xb8, 0xf1, 0xa8, 0xf2, 0x89, 0x00 +#define QM1D1C0042_NUM_REG_ROWS 2 + +static const u8 reg_initval[QM1D1C0042_NUM_REG_ROWS][QM1D1C0042_NUM_REGS] = { { + 0x48, 0x1c, 0xa0, 0x10, 0xbc, 0xc5, 0x20, 0x33, + 0x06, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x00, 0xff, 0xf3, 0x00, 0x2a, 0x64, 0xa6, 0x86, + 0x8c, 0xcf, 0xb8, 0xf1, 0xa8, 0xf2, 0x89, 0x00 + }, { + 0x68, 0x1c, 0xc0, 0x10, 0xbc, 0xc1, 0x11, 0x33, + 0x03, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, + 0x00, 0xff, 0xf3, 0x00, 0x3f, 0x25, 0x5c, 0xd6, + 0x55, 0xcf, 0x95, 0xf6, 0x36, 0xf2, 0x09, 0x00 + } }; +static int reg_index; + static const struct qm1d1c0042_config default_cfg = { .xtal_freq = 16000, .lpf = 1, @@ -320,7 +329,6 @@ static int qm1d1c0042_init(struct dvb_frontend *fe) int i, ret; state = fe->tuner_priv; - memcpy(state->regs, reg_initval, sizeof(reg_initval)); reg_write(state, 0x01, 0x0c); reg_write(state, 0x01, 0x0c); @@ -330,15 +338,19 @@ static int qm1d1c0042_init(struct dvb_frontend *fe) goto failed; usleep_range(2000, 3000); - val = state->regs[0x01] | 0x10; - ret = reg_write(state, 0x01, val); /* soft reset off */ + ret = reg_write(state, 0x01, 0x1c); /* soft reset off */ if (ret < 0) goto failed; - /* check ID */ + /* check ID and choose initial registers corresponding ID */ ret = reg_read(state, 0x00, &val); - if (ret < 0 || val != 0x48) + if (ret < 0) + goto failed; + for (reg_index = 0; reg_index < QM1D1C0042_NUM_REG_ROWS; reg_index++) + if (val == reg_initval[reg_index][0x00]) break; + if (reg_index >= QM1D1C0042_NUM_REG_ROWS) goto failed; + memcpy(state->regs, reg_initval[reg_index], QM1D1C0042_NUM_REGS); usleep_range(2000, 3000); state->regs[0x0c] |= 0x40; diff --git a/drivers/media/usb/em28xx/Kconfig b/drivers/media/usb/em28xx/Kconfig index e382210..d917b0a 100644 --- a/drivers/media/usb/em28xx/Kconfig +++ b/drivers/media/usb/em28xx/Kconfig @@ -59,6 +59,8 @@ config VIDEO_EM28XX_DVB select DVB_DRX39XYJ if MEDIA_SUBDRV_AUTOSELECT select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT + select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT + select MEDIA_TUNER_QM1D1C0042 if MEDIA_SUBDRV_AUTOSELECT ---help--- This adds support for DVB cards based on the Empiatech em28xx chips. diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c index 930e3e3..772a8f8 100644 --- a/drivers/media/usb/em28xx/em28xx-cards.c +++ b/drivers/media/usb/em28xx/em28xx-cards.c @@ -492,6 +492,20 @@ static struct em28xx_reg_seq terratec_t2_stick_hd[] = { {-1, -1, -1, -1}, }; +static struct em28xx_reg_seq plex_px_bcud[] = { + {EM2874_R80_GPIO_P0_CTRL, 0xff, 0xff, 0}, + {0x0d, 0xff, 0xff, 0}, + {EM2874_R50_IR_CO
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi! > > > This seems to be mostly in line with what has been discussed in the > > > meeting, > > > except that the patches add a device specific property. Please ignore the > > > led patches in that tree for now (i.e. four patches on the top are the > > > relevant ones here). > > > > > > > I'm currently trying to apply them to v4.6, but am getting rather ugly > > rejects :-(. > > :-\ > > There have been patches applied to the omap3isp driver since that I suppose. > These aren't overly complex, feel free to take the patches if they're still > useful. Ok, I got it to work. I can split it back, if needed. I've got patches on camera-fm3 branch. And yes, that gets flash to work. (I don't know how to turn flash into torch, which is what I really wanted, but I guess I'll figure it out.) Pavel diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 640d409..a6b9fac 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -239,6 +239,7 @@ pinctrl-names = "default"; pinctrl-0 = <&camera_pins>; + ti,camera-flashes = <&adp1653 &cam1>; ports { port@1 { diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 6361fde..23d484c 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2095,13 +2095,20 @@ static void isp_of_parse_node_csi2(struct device *dev, buscfg->bus.csi2.crc = 1; } -static int isp_of_parse_node(struct device *dev, struct device_node *node, -struct isp_async_subdev *isd) +static int isp_of_parse_node_endpoint(struct device *dev, + struct device_node *node, + struct isp_async_subdev *isd) { - struct isp_bus_cfg *buscfg = &isd->bus; + struct isp_bus_cfg *buscfg; struct v4l2_of_endpoint vep; int ret; + isd->bus = devm_kzalloc(dev, sizeof(*isd->bus), GFP_KERNEL); + if (!isd->bus) + return -ENOMEM; + + buscfg = isd->bus; + ret = v4l2_of_parse_endpoint(node, &vep); if (ret) return ret; @@ -2144,10 +2151,51 @@ static int isp_of_parse_node(struct device *dev, struct device_node *node, return 0; } +static int isp_of_parse_node(struct device *dev, struct device_node *node, +struct v4l2_async_notifier *notifier, +u32 group_id, bool link) +{ + struct isp_async_subdev *isd; + + isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL); + if (!isd) { + of_node_put(node); + return -ENOMEM; + } + + notifier->subdevs[notifier->num_subdevs] = &isd->asd; + + if (link) { + if (isp_of_parse_node_endpoint(dev, node, isd)) { + of_node_put(node); + return -EINVAL; + } + + isd->asd.match.of.node = of_graph_get_remote_port_parent(node); + of_node_put(node); + } else { + isd->asd.match.of.node = node; + } + + if (!isd->asd.match.of.node) { + dev_warn(dev, "bad remote port parent\n"); + return -EINVAL; + } + + isd->asd.match_type = V4L2_ASYNC_MATCH_OF; + isd->group_id = group_id; + notifier->num_subdevs++; + + return 0; +} + static int isp_of_parse_nodes(struct device *dev, struct v4l2_async_notifier *notifier) { struct device_node *node = NULL; + int ret; + unsigned int flash = 0; + u32 group_id = 0; notifier->subdevs = devm_kcalloc( dev, ISP_MAX_SUBDEVS, sizeof(*notifier->subdevs), GFP_KERNEL); @@ -2156,30 +2204,57 @@ static int isp_of_parse_nodes(struct device *dev, while (notifier->num_subdevs < ISP_MAX_SUBDEVS && (node = of_graph_get_next_endpoint(dev->of_node, node))) { - struct isp_async_subdev *isd; + ret = isp_of_parse_node(dev, node, notifier, group_id++, true); + if (ret) + return ret; + } - isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL); - if (!isd) { - of_node_put(node); - return -ENOMEM; - } + while (notifier->num_subdevs < ISP_MAX_SUBDEVS && + (node = of_parse_phandle(dev->of_node, "ti,camera-flashes", + flash++))) { + struct device_node *sensor_node = + of_parse_phandle(dev->of_node, "ti,camera-flashes", +flash++); + unsigned int i; + u32 flash_group_id; + + if (!sensor_node) +
Re: [PATCH v2] media: vb2-dma-contig: configure DMA max segment size properly
Hi Marek, On Fri, Apr 29, 2016 at 01:39:43PM +0200, Marek Szyprowski wrote: > Hi Sakari, > > > On 2016-04-29 13:21, Sakari Ailus wrote: > >Hi Marek, > > > >Thanks for the patch! > > > >On Thu, Apr 28, 2016 at 03:20:03PM +0200, Marek Szyprowski wrote: > >>This patch lets vb2-dma-contig memory allocator to configure DMA max > >>segment size properly for the client device. Setting it is needed to let > >>DMA-mapping subsystem to create a single, contiguous mapping in DMA > >>address space. This is essential for all devices, which use dma-contig > >>videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes > >>of operations). > >> > >>Signed-off-by: Marek Szyprowski > >>--- > >>Hello, > >> > >>This patch is a follow-up of my previous attempts to let Exynos > >>multimedia devices to work properly with shared buffers when IOMMU is > >>enabled: > >>1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html > >>2. > >>http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316 > >>3. https://patchwork.linuxtv.org/patch/30870/ > >> > >>As sugested by Hans, configuring DMA max segment size should be done by > >>videobuf2-dma-contig module instead of requiring all device drivers to > >>do it on their own. > >> > >>Here is some backgroud why this is done in videobuf2-dc not in the > >>respective generic bus code: > >>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html > >> > >>Best regards, > >>Marek Szyprowski > >> > >>changelog: > >>v2: > >>- fixes typos and other language issues in the comments > >> > >>v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690 > >>--- > >> drivers/media/v4l2-core/videobuf2-dma-contig.c | 39 > >> ++ > >> 1 file changed, 39 insertions(+) > >> > >>diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c > >>b/drivers/media/v4l2-core/videobuf2-dma-contig.c > >>index 461ae55eaa98..d0382d62954d 100644 > >>--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c > >>+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c > >>@@ -443,6 +443,36 @@ static void vb2_dc_put_userptr(void *buf_priv) > >> } > >> /* > >>+ * To allow mapping the scatter-list into a single chunk in the DMA > >>+ * address space, the device is required to have the DMA max segment > >>+ * size parameter set to a value larger than the buffer size. Otherwise, > >>+ * the DMA-mapping subsystem will split the mapping into max segment > >>+ * size chunks. This function increases the DMA max segment size > >>+ * parameter to let DMA-mapping map a buffer as a single chunk in DMA > >>+ * address space. > >>+ * This code assumes that the DMA-mapping subsystem will merge all > >>+ * scatter-list segments if this is really possible (for example when > >>+ * an IOMMU is available and enabled). > >>+ * Ideally, this parameter should be set by the generic bus code, but it > >>+ * is left with the default 64KiB value due to historical litmiations in > >>+ * other subsystems (like limited USB host drivers) and there no good > >>+ * place to set it to the proper value. It is done here to avoid fixing > >>+ * all the vb2-dc client drivers. > >>+ */ > >>+static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size) > >>+{ > >>+ if (!dev->dma_parms) { > >>+ dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL); > >Doesn't this create a memory leak? Do consider that devices may be also > >removed from the system at runtime. > > > >Looks very nice otherwise. > > Yes it does, but there is completely no way to determine when to do that > (dma_params might have been already allocated by the bus code). The whole > dma_params idea and its handling is a bit messy. IMHO we can leave this > for now until dma_params gets cleaned up (I remember someone said that he > has this on his todo list, but I don't remember now who it was...). You could fix this in a V4L2-specific way by storing the information whether you've allocated the dma-params e.g. in struct video_device. That's probably not worth the trouble, especially if someone's about to have a better solution. I'd add a "FIXME: ..." comment so we won't forget about it. Acked-by: Sakari Ailus -- 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
[GIT PULL FOR v4.7] Add HDMI CEC framework
Hi Mauro, Here is the pull request for the HDMI CEC framework. The code of this pull request is identical to the v16 patch series: http://www.mail-archive.com/linux-media@vger.kernel.org/msg97057.html The pull request is for 4.7, but I am aware that it is likely that it will slide to 4.8 since we're late in the 4.7 cycle. The cec DocBook documentation is here: https://hverkuil.home.xs4all.nl/cec.html#cec The cec utilities are here: http://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=cec To test with real hardware the easiest is to use a pandaboard. I posted patches for that earlier today. Regards, Hans The following changes since commit 45c175c4ae9695d6d2f30a45ab7f3866cfac184b: [media] tw686x: avoid going past array (2016-04-26 06:38:53 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git cec for you to fetch changes up to 61f2a9e6228b00248f657e8af3946145fba4e1f4: vivid: add CEC emulation (2016-04-29 15:41:43 +0200) Hans Verkuil (10): input.h: add BUS_CEC type cec: add HDMI CEC framework cec/TODO: add TODO file so we know why this is still in staging cec: add compat32 ioctl support cec.txt: add CEC framework documentation DocBook/media: add CEC documentation cec: adv7604: add cec support. cec: adv7842: add cec support cec: adv7511: add cec support. vivid: add CEC emulation Kamil Debski (3): HID: add HDMI CEC specific keycodes rc: Add HDMI CEC protocol handling cec: s5p-cec: Add s5p-cec driver Documentation/DocBook/device-drivers.tmpl|4 + Documentation/DocBook/media/Makefile |2 + Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml | 72 ++ Documentation/DocBook/media/v4l/cec-func-close.xml | 59 + Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 ++ Documentation/DocBook/media/v4l/cec-func-open.xml| 94 ++ Documentation/DocBook/media/v4l/cec-func-poll.xml| 89 ++ Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml | 140 +++ Documentation/DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml | 324 + Documentation/DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml | 82 ++ Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml | 190 +++ Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 245 Documentation/DocBook/media/v4l/cec-ioc-receive.xml | 260 Documentation/DocBook/media_api.tmpl |6 +- Documentation/cec.txt| 267 Documentation/devicetree/bindings/media/s5p-cec.txt | 31 + Documentation/video4linux/vivid.txt | 36 +- MAINTAINERS | 23 + drivers/media/Kconfig|3 + drivers/media/Makefile |2 + drivers/media/cec-edid.c | 139 +++ drivers/media/i2c/Kconfig| 27 + drivers/media/i2c/adv7511.c | 401 +- drivers/media/i2c/adv7604.c | 332 - drivers/media/i2c/adv7842.c | 368 +- drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile |1 + drivers/media/platform/s5p-cec/Makefile |2 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 38 + drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 209 drivers/media/platform/s5p-cec/regs-cec.h| 96 ++ drivers/media/platform/s5p-cec/s5p_cec.c | 295 + drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++ drivers/media/platform/vivid/Kconfig |9 + drivers/media/platform/vivid/Makefile|4 + drivers/media/platform/vivid/vivid-cec.c | 254 drivers/media/platform/vivid/vivid-cec.h | 33 + drivers/media/platform/vivid/vivid-core.c| 119 +- drivers/media/platform/vivid/vivid-core.h| 27 + drivers/media/platform/vivid/vivid-kthread-cap.c | 11 + drivers/media/platform/vivid/vivid-vid-cap.c | 23 +- drivers/media/platform/vivid/vivid-vid-common.c |7 + drivers/media/rc/keymaps/Makefile|1 + drivers/media/rc/keymaps/rc-cec.c| 174 +++ drivers/media/rc/rc-main.c |1 + drivers/staging/media/Kconfig
[PATCHv16 13/13] vivid: add CEC emulation
From: Hans Verkuil The vivid driver has been extended to provide CEC adapters for the HDMI input and HDMI outputs in order to test CEC applications. This CEC emulation is faithful to the CEC timings (i.e., it all at a snail's pace). Signed-off-by: Hans Verkuil --- Documentation/video4linux/vivid.txt | 36 +++- drivers/media/platform/vivid/Kconfig | 9 + drivers/media/platform/vivid/Makefile| 4 + drivers/media/platform/vivid/vivid-cec.c | 254 +++ drivers/media/platform/vivid/vivid-cec.h | 33 +++ drivers/media/platform/vivid/vivid-core.c| 119 ++- drivers/media/platform/vivid/vivid-core.h| 27 +++ drivers/media/platform/vivid/vivid-kthread-cap.c | 11 + drivers/media/platform/vivid/vivid-vid-cap.c | 23 +- drivers/media/platform/vivid/vivid-vid-common.c | 7 + 10 files changed, 508 insertions(+), 15 deletions(-) create mode 100644 drivers/media/platform/vivid/vivid-cec.c create mode 100644 drivers/media/platform/vivid/vivid-cec.h diff --git a/Documentation/video4linux/vivid.txt b/Documentation/video4linux/vivid.txt index 8da5d2a..1b26519 100644 --- a/Documentation/video4linux/vivid.txt +++ b/Documentation/video4linux/vivid.txt @@ -74,7 +74,8 @@ Section 11: Cropping, Composing, Scaling Section 12: Formats Section 13: Capture Overlay Section 14: Output Overlay -Section 15: Some Future Improvements +Section 15: CEC (Consumer Electronics Control) +Section 16: Some Future Improvements Section 1: Configuring the driver @@ -364,7 +365,11 @@ For HDMI inputs it is possible to set the EDID. By default a simple EDID is provided. You can only set the EDID for HDMI inputs. Internally, however, the EDID is shared between all HDMI inputs. -No interpretation is done of the EDID data. +No interpretation is done of the EDID data with the exception of the +physical address. See the CEC section for more details. + +There is a maximum of 15 HDMI inputs (if there are more, then they will be +reduced to 15) since that's the limitation of the EDID physical address. Section 3: Video Output @@ -409,6 +414,9 @@ standard, and for all others a 1:1 pixel aspect ratio is returned. An HDMI output has a valid EDID which can be obtained through VIDIOC_G_EDID. +There is a maximum of 15 HDMI outputs (if there are more, then they will be +reduced to 15) since that's the limitation of the EDID physical address. See +also the CEC section for more details. Section 4: VBI Capture -- @@ -1108,7 +1116,26 @@ capabilities will slow down the video loop considerably as a lot of checks have to be done per pixel. -Section 15: Some Future Improvements +Section 15: CEC (Consumer Electronics Control) +-- + +If there are HDMI inputs then a CEC adapter will be created that has +the same number of input ports. This is the equivalent of e.g. a TV that +has that number of inputs. Each HDMI output will also create a +CEC adapter that is hooked up to the corresponding input port, or (if there +are more outputs than inputs) is not hooked up at all. In other words, +this is the equivalent of hooking up each output device to an input port of +the TV. Any remaining output devices remain unconnected. + +The EDID that each output reads reports a unique CEC physical address that is +based on the physical address of the EDID of the input. So if the EDID of the +receiver has physical address A.B.0.0, then each output will see an EDID +containing physical address A.B.C.0 where C is 1 to the number of inputs. If +there are more outputs than inputs then the remaining outputs have a CEC adapter +that is disabled and reports an invalid physical address. + + +Section 16: Some Future Improvements Just as a reminder and in no particular order: @@ -1121,8 +1148,6 @@ Just as a reminder and in no particular order: - Fix sequence/field numbering when looping of video with alternate fields - Add support for V4L2_CID_BG_COLOR for video outputs - Add ARGB888 overlay support: better testing of the alpha channel -- Add custom DV timings support -- Add support for V4L2_DV_FL_REDUCED_FPS - Improve pixel aspect support in the tpg code by passing a real v4l2_fract - Use per-queue locks and/or per-device locks to improve throughput - Add support to loop from a specific output to a specific input across @@ -1133,3 +1158,4 @@ Just as a reminder and in no particular order: - Make a thread for the RDS generation, that would help in particular for the "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated in real-time. +- Changing the EDID should cause hotplug detect emulation to happen. diff --git a/drivers/media/platform/vivid/Kconfig b/drivers/media/platform/vivid/Kconfig index f535f57..20c5eea 100644 --- a/drivers/media/platform/vivid/Kconfig +++ b/drivers/media/platform/vivid/Kconfig @@ -6,6 +6,7 @@ con
[PATCHv16 09/13] cec: adv7604: add cec support.
From: Hans Verkuil Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: add missing methods cec/io_write_and_or] [k.deb...@samsung.com: change adv7604 to adv76xx in added functions] [hansv...@cisco.com: use _clr_set instead of _and_or] --- drivers/media/i2c/Kconfig | 9 ++ drivers/media/i2c/adv7604.c | 332 +++- 2 files changed, 305 insertions(+), 36 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 993dc50..cba1fc7 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -209,6 +209,7 @@ config VIDEO_ADV7604 depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API depends on GPIOLIB || COMPILE_TEST select HDMI + select MEDIA_CEC_EDID ---help--- Support for the Analog Devices ADV7604 video decoder. @@ -218,6 +219,14 @@ config VIDEO_ADV7604 To compile this driver as a module, choose M here: the module will be called adv7604. +config VIDEO_ADV7604_CEC + bool "Enable Analog Devices ADV7604 CEC support" + depends on VIDEO_ADV7604 && MEDIA_CEC + default y + ---help--- + When selected the adv7604 will support the optional + HDMI CEC feature. + config VIDEO_ADV7842 tristate "Analog Devices ADV7842 decoder" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index beb2841..f462585 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -40,6 +40,7 @@ #include #include +#include #include #include #include @@ -80,6 +81,8 @@ MODULE_LICENSE("GPL"); #define ADV76XX_OP_SWAP_CB_CR (1 << 0) +#define ADV76XX_MAX_ADDRS (3) + enum adv76xx_type { ADV7604, ADV7611, @@ -184,6 +187,12 @@ struct adv76xx_state { u16 spa_port_a[2]; struct v4l2_fract aspect_ratio; u32 rgb_quantization_range; + + struct cec_adapter *cec_adap; + u8 cec_addr[ADV76XX_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + struct workqueue_struct *work_queues; struct delayed_work delayed_work_enable_hotplug; bool restart_stdi_once; @@ -381,7 +390,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg, u8 val) return regmap_write(state->regmap[ADV76XX_PAGE_IO], reg, val); } -static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) { return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val); } @@ -414,6 +424,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) return regmap_write(state->regmap[ADV76XX_PAGE_CEC], reg, val); } +static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val); +} + static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg) { struct adv76xx_state *state = to_state(sd); @@ -872,9 +888,9 @@ static int adv76xx_s_detect_tx_5v_ctrl(struct v4l2_subdev *sd) { struct adv76xx_state *state = to_state(sd); const struct adv76xx_chip_info *info = state->info; + u16 cable_det = info->read_cable_det(sd); - return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, - info->read_cable_det(sd)); + return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det); } static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd, @@ -1900,6 +1916,210 @@ static int adv76xx_set_format(struct v4l2_subdev *sd, return 0; } +#if IS_ENABLED(CONFIG_VIDEO_ADV7604_CEC) +static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status) +{ + struct adv76xx_state *state = to_state(sd); + + if ((cec_read(sd, 0x11) & 0x01) == 0) { + v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__); + return; + } + + if (tx_raw_status & 0x02) { + v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n", +__func__); + cec_transmit_done(state->cec_adap, CEC_TX_STATUS_ARB_LOST, + 1, 0, 0, 0); + } + if (tx_raw_status & 0x04) { + u8 status; + u8 nack_cnt; + u8 low_drive_cnt; + + v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__); + /* +* We set this status bit since this hardware performs +* retransmissions. +*/ + status = CEC_TX_STATUS_MAX_RETRIES; + nack_cnt = c
[PATCHv16 07/13] cec.txt: add CEC framework documentation
From: Hans Verkuil Document the new HDMI CEC framework. Signed-off-by: Hans Verkuil [k.deb...@samsung.com: add DocBook documentation by Hans Verkuil, with Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/cec.txt | 267 ++ 1 file changed, 267 insertions(+) create mode 100644 Documentation/cec.txt diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..75155fe --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,267 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple types of hardware (receivers, +transmitters, USB dongles). The framework also gives the option to decide +what to do in the kernel driver and what should be handled by userspace +applications. In addition it integrates the remote control passthrough +feature into the kernel's remote control framework. + + +The CEC Protocol + + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physical address is determined by the physical +connection between devices. + +The CEC framework described here is up to date with the CEC 2.0 specification. +It is documented in the HDMI 1.4 specification with the new 2.0 bits documented +in the HDMI 2.0 specification. But for most of the features the freely available +HDMI 1.3a specification is sufficient: + +http://www.microprocessor.org/HDMISpecification13a.pdf + + +The Kernel Interface + + +CEC Adapter +--- + +The struct cec_adapter represents the CEC adapter hardware. It is created by +calling cec_allocate_adapter() and deleted by calling cec_delete_adapter(): + +struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, + void *priv, const char *name, u32 caps, u8 available_las, + struct device *parent); +void cec_delete_adapter(struct cec_adapter *adap); + +To create an adapter you need to pass the following information: + +ops: adapter operations which are called by the CEC framework and that you +have to implement. + +priv: will be stored in adap->priv and can be used by the adapter ops. + +name: the name of the CEC adapter. Note: this name will be copied. + +caps: capabilities of the CEC adapter. These capabilities determine the + capabilities of the hardware and which parts are to be handled + by userspace and which parts are handled by kernelspace. The + capabilities are returned by CEC_ADAP_G_CAPS. + +available_las: the number of simultaneous logical addresses that this + adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS. + +parent: the parent device. + + +To register the /dev/cecX device node and the remote control device (if +CEC_CAP_RC is set) you call: + +int cec_register_adapter(struct cec_adapter *adap); + +To unregister the devices call: + +void cec_unregister_adapter(struct cec_adapter *adap); + +Note: if cec_register_adapter() fails, then call cec_delete_adapter() to +clean up. But if cec_register_adapter() succeeded, then only call +cec_unregister_adapter() to clean up, never cec_delete_adapter(). The +unregister function will delete the adapter automatically once the last user +of that /dev/cecX device has closed its file handle. + + +Implementing the Low-Level CEC Adapter +-- + +The following low-level adapter operations have to be implemented in +your driver: + +struct cec_adap_ops { + /* Low-level callbacks */ + int (*adap_enable)(struct cec_adapter *adap, bool enable); + int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); + int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, +u32 signal_free_time, struct cec_msg *msg); + void (*adap_log_status)(struct cec_adapter *adap); + + /* High-level callbacks */ + ... +}; + +The three low-level ops deal with various aspects of controlling the CEC adapter +hardware: + + +To enable/disable the hardware: + + int (*adap_enable)(struct cec_adapter *adap, bool enable); + +This callback enables or disables the CEC hardware. Enabling the CEC hardware +means powering it up in a state where no logical addresses are claimed. This +op assumes that the physical address (adap->phys_addr) is valid when enable is +true and will not change while the CEC adapter remains enabled. The initial +state of the CEC adapter after calling cec_allocate_adapter() is disabled. + +Note that adap_enable must return 0 if enable is false. +
[PATCHv16 12/13] cec: s5p-cec: Add s5p-cec driver
From: Kamil Debski Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- .../devicetree/bindings/media/s5p-cec.txt | 31 +++ MAINTAINERS| 7 + drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile| 1 + drivers/media/platform/s5p-cec/Makefile| 2 + drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 38 +++ .../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 209 +++ drivers/media/platform/s5p-cec/regs-cec.h | 96 +++ drivers/media/platform/s5p-cec/s5p_cec.c | 295 + drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++ 10 files changed, 766 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt create mode 100644 drivers/media/platform/s5p-cec/Makefile create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt b/Documentation/devicetree/bindings/media/s5p-cec.txt new file mode 100644 index 000..925ab4d --- /dev/null +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt @@ -0,0 +1,31 @@ +* Samsung HDMI CEC driver + +The HDMI CEC module is present is Samsung SoCs and its purpose is to +handle communication between HDMI connected devices over the CEC bus. + +Required properties: + - compatible : value should be following + "samsung,s5p-cec" + + - reg : Physical base address of the IP registers and length of memory + mapped region. + + - interrupts : HDMI CEC interrupt number to the CPU. + - clocks : from common clock binding: handle to HDMI CEC clock. + - clock-names : from common clock binding: must contain "hdmicec", + corresponding to entry in the clocks property. + - samsung,syscon-phandle - phandle to the PMU system controller + +Example: + +hdmicec: cec@100B { + compatible = "samsung,s5p-cec"; + reg = <0x100B 0x200>; + interrupts = <0 114 0>; + clocks = <&clock CLK_HDMI_CEC>; + clock-names = "hdmicec"; + samsung,syscon-phandle = <&pmu_system_controller>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_cec>; + status = "okay"; +}; diff --git a/MAINTAINERS b/MAINTAINERS index 83bd865..0e43b30 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1581,6 +1581,13 @@ L: linux-media@vger.kernel.org S: Maintained F: drivers/media/platform/s5p-tv/ +ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT +M: Kyungmin Park +L: linux-arm-ker...@lists.infradead.org +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/platform/s5p-cec/ + ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT M: Andrzej Pietrasiewicz M: Jacek Anaszewski diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 84e041c..c3945c3 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -108,6 +108,17 @@ config VIDEO_S3C_CAMIF source "drivers/media/platform/soc_camera/Kconfig" source "drivers/media/platform/exynos4-is/Kconfig" source "drivers/media/platform/s5p-tv/Kconfig" + +config VIDEO_SAMSUNG_S5P_CEC + tristate "Samsung S5P CEC driver" + depends on VIDEO_DEV && MEDIA_CEC && (PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST) + default n + ---help--- + This is a driver for Samsung S5P HDMI CEC interface. It uses the + generic CEC framework interface. + CEC bus is present in the HDMI connector and enables communication + between compatible devices. + source "drivers/media/platform/am437x/Kconfig" source "drivers/media/platform/xilinx/Kconfig" diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index bbb7bd1..f598c80 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/ +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ diff --git a/drivers/media/platform/s5p-cec/Makefile b/drivers/media/platform/s5p-cec/Makefile new file mode 100644 index 000..0e2cf45 --- /dev/null +++ b/drivers/media/platform/s5p-cec/Makefile @@ -0,0 +1,2 @@ +obj-$(CONFIG_VID
[PATCHv16 11/13] cec: adv7511: add cec support.
From: Hans Verkuil Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil [k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- drivers/media/i2c/Kconfig | 9 + drivers/media/i2c/adv7511.c | 401 +++- include/media/i2c/adv7511.h | 6 +- 3 files changed, 403 insertions(+), 13 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 5168454..6c2acb6 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -465,6 +465,7 @@ config VIDEO_ADV7511 tristate "Analog Devices ADV7511 encoder" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API select HDMI + select MEDIA_CEC_EDID ---help--- Support for the Analog Devices ADV7511 video encoder. @@ -473,6 +474,14 @@ config VIDEO_ADV7511 To compile this driver as a module, choose M here: the module will be called adv7511. +config VIDEO_ADV7511_CEC + bool "Enable Analog Devices ADV7511 CEC support" + depends on VIDEO_ADV7511 && MEDIA_CEC + default y + ---help--- + When selected the adv7511 will support the optional + HDMI CEC feature. + config VIDEO_AD9389B tristate "Analog Devices AD9389B encoder" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 39271c3..002117b 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -33,6 +33,7 @@ #include #include #include +#include static int debug; module_param(debug, int, 0644); @@ -59,6 +60,8 @@ MODULE_LICENSE("GPL v2"); #define ADV7511_MIN_PIXELCLOCK 2000 #define ADV7511_MAX_PIXELCLOCK 22500 +#define ADV7511_MAX_ADDRS (3) + /* ** * @@ -90,12 +93,20 @@ struct adv7511_state { struct v4l2_ctrl_handler hdl; int chip_revision; u8 i2c_edid_addr; - u8 i2c_cec_addr; u8 i2c_pktmem_addr; + u8 i2c_cec_addr; + + struct i2c_client *i2c_cec; + struct cec_adapter *cec_adap; + u8 cec_addr[ADV7511_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; + /* Is the adv7511 powered on? */ bool power_on; /* Did we receive hotplug and rx-sense signals? */ bool have_monitor; + bool enabled_irq; /* timings from s_dv_timings */ struct v4l2_dv_timings dv_timings; u32 fmt_code; @@ -227,7 +238,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client *client, return ret; } -static inline void adv7511_edid_rd(struct v4l2_subdev *sd, u16 len, u8 *buf) +static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf) { struct adv7511_state *state = get_adv7511_state(sd); int i; @@ -242,6 +253,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd, u16 len, u8 *buf) v4l2_err(sd, "%s: i2c read error\n", __func__); } +static inline int adv7511_cec_read(struct v4l2_subdev *sd, u8 reg) +{ + struct adv7511_state *state = get_adv7511_state(sd); + + return i2c_smbus_read_byte_data(state->i2c_cec, reg); +} + +static int adv7511_cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) +{ + struct adv7511_state *state = get_adv7511_state(sd); + int ret; + int i; + + for (i = 0; i < 3; i++) { + ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val); + if (ret == 0) + return 0; + } + v4l2_err(sd, "%s: I2C Write Problem\n", __func__); + return ret; +} + +static inline int adv7511_cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, + u8 val) +{ + return adv7511_cec_write(sd, reg, (adv7511_cec_read(sd, reg) & mask) | val); +} + static int adv7511_pktmem_rd(struct v4l2_subdev *sd, u8 reg) { struct adv7511_state *state = get_adv7511_state(sd); @@ -425,16 +464,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = { #ifdef CONFIG_VIDEO_ADV_DEBUG static void adv7511_inv_register(struct v4l2_subdev *sd) { + struct adv7511_state *state = get_adv7511_state(sd); + v4l2_info(sd, "0x000-0x0ff: Main Map\n"); + if (state->i2c_cec) + v4l2_info(sd, "0x100-0x1ff: CEC Map\n"); } static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register *reg) { + struct adv7511_state *state = get_adv7511_state(sd); + reg->size = 1; switch (reg->reg >> 8) { case 0: reg->val = adv7511_rd(sd, reg->reg & 0xff); break; + case 1: + if (state->i2c_cec) { + reg->val = adv7511_cec_read(sd, reg->reg & 0xff); + break; + } +
[PATCHv16 05/13] cec/TODO: add TODO file so we know why this is still in staging
From: Hans Verkuil Explain why cec.c is still in staging. Signed-off-by: Hans Verkuil --- drivers/staging/media/cec/TODO | 13 + 1 file changed, 13 insertions(+) create mode 100644 drivers/staging/media/cec/TODO diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/cec/TODO new file mode 100644 index 000..c0751ef --- /dev/null +++ b/drivers/staging/media/cec/TODO @@ -0,0 +1,13 @@ +The reason why cec.c is still in staging is that I would like +to have a bit more confidence in the uABI. The kABI is fine, +no problem there, but I would like to let the public API mature +a bit. + +Once I'm confident that I didn't miss anything then the cec.c source +can move to drivers/media and the linux/cec.h and linux/cec-funcs.h +headers can move to uapi/linux and added to uapi/linux/Kbuild to make +them public. + +Hopefully this will happen later in 2016. + +Hans Verkuil -- 2.8.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
[PATCHv16 10/13] cec: adv7842: add cec support
From: Hans Verkuil Add CEC support to the adv7842 driver. Signed-off-by: Hans Verkuil --- drivers/media/i2c/Kconfig | 9 ++ drivers/media/i2c/adv7842.c | 368 2 files changed, 314 insertions(+), 63 deletions(-) diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index cba1fc7..5168454 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -231,6 +231,7 @@ config VIDEO_ADV7842 tristate "Analog Devices ADV7842 decoder" depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API select HDMI + select MEDIA_CEC_EDID ---help--- Support for the Analog Devices ADV7842 video decoder. @@ -240,6 +241,14 @@ config VIDEO_ADV7842 To compile this driver as a module, choose M here: the module will be called adv7842. +config VIDEO_ADV7842_CEC + bool "Enable Analog Devices ADV7842 CEC support" + depends on VIDEO_ADV7842 && MEDIA_CEC + default y + ---help--- + When selected the adv7842 will support the optional + HDMI CEC feature. + config VIDEO_BT819 tristate "BT819A VideoStream decoder" depends on VIDEO_V4L2 && I2C diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c index ecaacb0..297ba7a 100644 --- a/drivers/media/i2c/adv7842.c +++ b/drivers/media/i2c/adv7842.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include @@ -79,6 +80,8 @@ MODULE_LICENSE("GPL"); #define ADV7842_OP_SWAP_CB_CR (1 << 0) +#define ADV7842_MAX_ADDRS (3) + /* ** * @@ -142,6 +145,11 @@ struct adv7842_state { struct v4l2_ctrl *free_run_color_ctrl_manual; struct v4l2_ctrl *free_run_color_ctrl; struct v4l2_ctrl *rgb_quantization_range_ctrl; + + struct cec_adapter *cec_adap; + u8 cec_addr[ADV7842_MAX_ADDRS]; + u8 cec_valid_addrs; + bool cec_enabled_adap; }; /* Unsupported timings. This device cannot support 720p30. */ @@ -418,9 +426,9 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg, u8 val) return adv_smbus_write_byte_data(state->i2c_cec, reg, val); } -static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) +static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8 val) { - return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val); + return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val); } static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg) @@ -696,6 +704,18 @@ adv7842_get_dv_timings_cap(struct v4l2_subdev *sd) /* --- */ +static u16 adv7842_read_cable_det(struct v4l2_subdev *sd) +{ + u8 reg = io_read(sd, 0x6f); + u16 val = 0; + + if (reg & 0x02) + val |= 1; /* port A */ + if (reg & 0x01) + val |= 2; /* port B */ + return val; +} + static void adv7842_delayed_work_enable_hotplug(struct work_struct *work) { struct delayed_work *dwork = to_delayed_work(work); @@ -762,50 +782,18 @@ static int edid_write_vga_segment(struct v4l2_subdev *sd) return 0; } -static int edid_spa_location(const u8 *edid) -{ - u8 d; - - /* -* TODO, improve and update for other CEA extensions -* currently only for 1 segment (256 bytes), -* i.e. 1 extension block and CEA revision 3. -*/ - if ((edid[0x7e] != 1) || - (edid[0x80] != 0x02) || - (edid[0x81] != 0x03)) { - return -EINVAL; - } - /* -* search Vendor Specific Data Block (tag 3) -*/ - d = edid[0x82] & 0x7f; - if (d > 4) { - int i = 0x84; - int end = 0x80 + d; - do { - u8 tag = edid[i]>>5; - u8 len = edid[i] & 0x1f; - - if ((tag == 3) && (len >= 5)) - return i + 4; - i += len + 1; - } while (i < end); - } - return -EINVAL; -} - static int edid_write_hdmi_segment(struct v4l2_subdev *sd, u8 port) { struct i2c_client *client = v4l2_get_subdevdata(sd); struct adv7842_state *state = to_state(sd); - const u8 *val = state->hdmi_edid.edid; - int spa_loc = edid_spa_location(val); + const u8 *edid = state->hdmi_edid.edid; + int spa_loc; + u16 pa; int err = 0; int i; - v4l2_dbg(2, debug, sd, "%s: write EDID on port %c (spa at 0x%x)\n", - __func__, (port == ADV7842_EDID_PORT_A) ? 'A' : 'B', spa_loc); + v4l2_dbg(2, debug, sd, "%s: write EDID on port %c\n", + __func__, (port == ADV7842_EDID_PORT_A) ? 'A' : 'B'); /* HPA disable on
[PATCHv16 08/13] DocBook/media: add CEC documentation
From: Hans Verkuil Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil [k.deb...@samsung.com: add documentation for passthrough mode] [k.deb...@samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/DocBook/device-drivers.tmpl | 4 + Documentation/DocBook/media/Makefile | 2 + Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 72 + Documentation/DocBook/media/v4l/cec-func-close.xml | 59 Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 + Documentation/DocBook/media/v4l/cec-func-open.xml | 94 ++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 ++ .../DocBook/media/v4l/cec-ioc-adap-g-caps.xml | 140 + .../DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml | 324 + .../DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml | 82 ++ .../DocBook/media/v4l/cec-ioc-dqevent.xml | 190 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 245 .../DocBook/media/v4l/cec-ioc-receive.xml | 260 + Documentation/DocBook/media_api.tmpl | 6 +- 15 files changed, 1649 insertions(+), 1 deletion(-) create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 893b2ca..31258bf 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -270,6 +270,10 @@ X!Isound/sound_firmware.c !Iinclude/media/media-devnode.h !Iinclude/media/media-entity.h + Consumer Electronics Control devices +!Iinclude/media/cec.h +!Iinclude/media/cec-edid.h + diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 2840ff4..fdc1386 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -64,6 +64,7 @@ IOCTLS = \ $(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/cec.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ DEFINES = \ @@ -100,6 +101,7 @@ STRUCTS = \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/cec.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index 9beb30f..87f1d24 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -342,6 +342,16 @@ in the frequency range from 87,5 to 108,0 MHz Specification Version 1.4a + + HDMI2 + + HDMI Licensing LLC +(http://www.hdmi.org";>http://www.hdmi.org) + + High-Definition Multimedia Interface + Specification Version 2.0 + + DP diff --git a/Documentation/DocBook/media/v4l/cec-api.xml b/Documentation/DocBook/media/v4l/cec-api.xml new file mode 100644 index 000..caa04c0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/cec-api.xml @@ -0,0 +1,72 @@ + + + + Hans + Verkuil + hans.verk...@cisco.com + Initia
[PATCHv16 00/13] HDMI CEC framework
From: Hans Verkuil Hi all, The sixteenth version of this patchset does some final cleanup and I'll post a pull request on the linux-media list for this patch series. At first I didn't want to post a v16 at all, but there were just a bit too many changes, even though each change itself was trivial. While the pull request will be for 4.7 I think it is more likely that it will end up in 4.8 given how late we are in the 4.7 cycle. I dropped the RFC patches for the pulse8 and ARC/CDC support since those aren't ready for mainlining. Same for the omap4 support patches I posted today. See the changelog below for more details. The cec-ctl and cec-compliance utilities used to test the CEC framework can be found here: http://git.linuxtv.org/cgit.cgi/hverkuil/v4l-utils.git/log/?h=cec Best regards, Hans Changes since v15 = - Properly document cec-edid.h - Fix various sparse/smatch warnings - Fixed several DocBook issues - Fixed incorrect return values in the adv drivers that caused an otherwise harmless WARN_ON. Changes since v14 = - Dropped the Samsung dts patches, these will go in via the samsung tree. - CEC_LOG_STATUS is replaced by a debugfs status file. - Dropped the reserved fields in the API, use versioning instead. Two flags field were added instead. - Extended cec_caps with a version field. - Dropped CEC_CAP_IS_SOURCE as it is not needed in practice. - The adv drivers now create the CEC adapter themselves instead of leaving that to the bridge. It greatly simplifies the code and it was really a left-over from the early days of the framework. - The CEC implementation of the adv drivers is now configured through a separate config option. CEC is an optional HDMI feature and you may not want to compile this in if your hardware hasn't hooked up the CEC pin. - The EDID CEC helper functions have been split off into their own cec-edid module. You likely need them even if MEDIA_CEC is not set. - Added missing copyright statements. - Added RFC code for the pulse-eight USB CEC adapter. Changes since v13 = - Removed CEC_CAP_STATE and _VENDOR_ID - Removed CEC_ADAP_G/S_STATE and CEC_ADAP_G/S_VENDOR_ID - Add vendor_id to struct cec_log_addrs - CEC_EVENT_STATE_CHANGE now reports the physical address, the logical address mask and the logical address type mask. - Add the logical address mask and the logical address type mask to struct cec_log_addrs. - Dropped cec_enable, instead enable/disable the adapter based on the physical address. - Once a valid physical address is available and userspace or driver specified the requested logical address configuration the framework will automatically claim the needed logical addresses. It will retry the last used addresses first, as per the recommendation in the CEC specification. - Dropped CEC power status handling: it's not clear if the kernel should handle that, and if it has to, whether this is the correct way. - Dropped CEC_EVENT_PHYS_ADDR_CHANGE, this is now handled by CEC_EVENT_STATE_CHANGE. - Add helper functions for manipulating physical addresses. - Updated documentation. - Dropped ninputs field in struct cec_caps. - Dropped CEC_EVENT_INPUTS_CHANGE, was never used and it is unclear if it is needed. Changes since v12 = - Added driver and name fields to the cec_caps struct. Without this it was very difficult to tell CEC adapters apart in a human readable manner. - Renamed CEC_CAP_IO to CEC_CAP_TRANSMIT, which better describes this capability. - Added the CEC_ADAP_LOG_STATUS to log the current status of the CEC adapter. Very useful when debugging. - Added comments to the cec.c source. - Added a timeout when waiting for a transmit to finish. Without the timeout the state machine could lock up when dealing with broken CEC adapter drivers or just unlucky situations. - Commenting the code also found a number of bugs which have been fixed. - Trying to poll yourself is now handled by the framework since different hardware would give different results. The framework will just NACK it. - Disabling the CEC adapter doesn't clear the physical address anymore. This turned out to be quite painful for applications. - Merged the CLAIM/RELEASE, G/S_MONITOR and G_PASSTHROUGH ioctls into two G/S_MODE ioctls. This allows you to tell the driver which initiator and follower modes you want, and greatly simplifies how these modes are handled. Changes since v11 = - Add a new CEC_EVENT_PHYS_ADDR_CHANGED to report when the physical address of the CEC adapter changes. Since the physical address is obtained from the EDID the application has to be informed when the kernel (or userspace for that matter) sets that. - Add a new internal cec_set_phys_addr() function to change the physical address and post the event. - Modified the retry-transmit mechanism: the framework will do the retry if the low-level driver returns a TX_STATUS error, but does
[PATCHv16 02/13] HID: add HDMI CEC specific keycodes
From: Kamil Debski Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Dmitry Torokhov --- include/uapi/linux/input-event-codes.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 87cf351..02b7b3a 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -611,6 +611,36 @@ #define KEY_KBDINPUTASSIST_ACCEPT 0x264 #define KEY_KBDINPUTASSIST_CANCEL 0x265 +/* Diagonal movement keys */ +#define KEY_RIGHT_UP 0x266 +#define KEY_RIGHT_DOWN 0x267 +#define KEY_LEFT_UP0x268 +#define KEY_LEFT_DOWN 0x269 + +#define KEY_ROOT_MENU 0x26a /* Show Device's Root Menu */ +#define KEY_MEDIA_TOP_MENU 0x26b /* Show Top Menu of the Media (e.g. DVD) */ +#define KEY_NUMERIC_11 0x26c +#define KEY_NUMERIC_12 0x26d +/* + * Toggle Audio Description: refers to an audio service that helps blind and + * visually impaired consumers understand the action in a program. Note: in + * some countries this is referred to as "Video Description". + */ +#define KEY_AUDIO_DESC 0x26e +#define KEY_3D_MODE0x26f +#define KEY_NEXT_FAVORITE 0x270 +#define KEY_STOP_RECORD0x271 +#define KEY_PAUSE_RECORD 0x272 +#define KEY_VOD0x273 /* Video on Demand */ +#define KEY_UNMUTE 0x274 +#define KEY_FASTREVERSE0x275 +#define KEY_SLOWREVERSE0x276 +/* + * Control a data application associated with the currently viewed channel, + * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.) + */ +#define KEY_DATA 0x275 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 2.8.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
[PATCHv16 06/13] cec: add compat32 ioctl support
From: Hans Verkuil The CEC ioctls didn't have compat32 support, so they returned -ENOTTY when used in a 32 bit application on a 64 bit kernel. Since all the CEC ioctls are 32-bit compatible adding support for this API is trivial. Signed-off-by: Hans Verkuil --- fs/compat_ioctl.c | 12 1 file changed, 12 insertions(+) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index bd01b92..c1e9f29 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -57,6 +57,7 @@ #include #include #include +#include #include "internal.h" @@ -1377,6 +1378,17 @@ COMPATIBLE_IOCTL(VIDEO_GET_NAVI) COMPATIBLE_IOCTL(VIDEO_SET_ATTRIBUTES) COMPATIBLE_IOCTL(VIDEO_GET_SIZE) COMPATIBLE_IOCTL(VIDEO_GET_FRAME_RATE) +/* cec */ +COMPATIBLE_IOCTL(CEC_ADAP_G_CAPS) +COMPATIBLE_IOCTL(CEC_ADAP_G_LOG_ADDRS) +COMPATIBLE_IOCTL(CEC_ADAP_S_LOG_ADDRS) +COMPATIBLE_IOCTL(CEC_ADAP_G_PHYS_ADDR) +COMPATIBLE_IOCTL(CEC_ADAP_S_PHYS_ADDR) +COMPATIBLE_IOCTL(CEC_G_MODE) +COMPATIBLE_IOCTL(CEC_S_MODE) +COMPATIBLE_IOCTL(CEC_TRANSMIT) +COMPATIBLE_IOCTL(CEC_RECEIVE) +COMPATIBLE_IOCTL(CEC_DQEVENT) /* joystick */ COMPATIBLE_IOCTL(JSIOCGVERSION) -- 2.8.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
[PATCHv16 01/13] input.h: add BUS_CEC type
From: Hans Verkuil Inputs can come in over the HDMI CEC bus, so add a new type for this. Signed-off-by: Hans Verkuil Acked-by: Dmitry Torokhov --- include/uapi/linux/input.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h index 0111384..c514941 100644 --- a/include/uapi/linux/input.h +++ b/include/uapi/linux/input.h @@ -247,6 +247,7 @@ struct input_mask { #define BUS_ATARI 0x1B #define BUS_SPI0x1C #define BUS_RMI0x1D +#define BUS_CEC0x1E /* * MT_TOOL types -- 2.8.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
[PATCHv16 03/13] rc: Add HDMI CEC protocol handling
From: Kamil Debski Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- drivers/media/rc/keymaps/Makefile | 1 + drivers/media/rc/keymaps/rc-cec.c | 174 ++ drivers/media/rc/rc-main.c| 1 + include/media/rc-map.h| 5 +- 4 files changed, 180 insertions(+), 1 deletion(-) create mode 100644 drivers/media/rc/keymaps/rc-cec.c diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile index fbbd3bb..9cffcc6 100644 --- a/drivers/media/rc/keymaps/Makefile +++ b/drivers/media/rc/keymaps/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-behold.o \ rc-behold-columbus.o \ rc-budget-ci-old.o \ + rc-cec.o \ rc-cinergy-1400.o \ rc-cinergy.o \ rc-delock-61959.o \ diff --git a/drivers/media/rc/keymaps/rc-cec.c b/drivers/media/rc/keymaps/rc-cec.c new file mode 100644 index 000..193cdca --- /dev/null +++ b/drivers/media/rc/keymaps/rc-cec.c @@ -0,0 +1,174 @@ +/* Keytable for the CEC remote control + * + * Copyright (c) 2015 by Kamil Debski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include + +/* CEC Spec "High-Definition Multimedia Interface Specification" can be obtained + * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf + * The list of control codes is listed in Table 27: User Control Codes p. 95 */ + +static struct rc_map_table cec[] = { + { 0x00, KEY_OK }, + { 0x01, KEY_UP }, + { 0x02, KEY_DOWN }, + { 0x03, KEY_LEFT }, + { 0x04, KEY_RIGHT }, + { 0x05, KEY_RIGHT_UP }, + { 0x06, KEY_RIGHT_DOWN }, + { 0x07, KEY_LEFT_UP }, + { 0x08, KEY_LEFT_DOWN }, + { 0x09, KEY_ROOT_MENU }, /* CEC Spec: Device Root Menu - see Note 2 */ + /* Note 2: This is the initial display that a device shows. It is +* device-dependent and can be, for example, a contents menu, setup +* menu, favorite menu or other menu. The actual menu displayed +* may also depend on the device's current state. */ + { 0x0a, KEY_SETUP }, + { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */ + { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */ + { 0x0d, KEY_EXIT }, + /* 0x0e-0x0f: Reserved */ + { 0x10, KEY_MEDIA_TOP_MENU }, + { 0x11, KEY_CONTEXT_MENU }, + /* 0x12-0x1c: Reserved */ + { 0x1d, KEY_DIGITS }, /* CEC Spec: select/toggle a Number Entry Mode */ + { 0x1e, KEY_NUMERIC_11 }, + { 0x1f, KEY_NUMERIC_12 }, + /* 0x20-0x29: Keys 0 to 9 */ + { 0x20, KEY_NUMERIC_0 }, + { 0x21, KEY_NUMERIC_1 }, + { 0x22, KEY_NUMERIC_2 }, + { 0x23, KEY_NUMERIC_3 }, + { 0x24, KEY_NUMERIC_4 }, + { 0x25, KEY_NUMERIC_5 }, + { 0x26, KEY_NUMERIC_6 }, + { 0x27, KEY_NUMERIC_7 }, + { 0x28, KEY_NUMERIC_8 }, + { 0x29, KEY_NUMERIC_9 }, + { 0x2a, KEY_DOT }, + { 0x2b, KEY_ENTER }, + { 0x2c, KEY_CLEAR }, + /* 0x2d-0x2e: Reserved */ + { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */ + { 0x30, KEY_CHANNELUP }, + { 0x31, KEY_CHANNELDOWN }, + { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */ + { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */ + { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */ + { 0x35, KEY_INFO }, /* CEC Spec: Display Information */ + { 0x36, KEY_HELP }, + { 0x37, KEY_PAGEUP }, + { 0x38, KEY_PAGEDOWN }, + /* 0x39-0x3f: Reserved */ + { 0x40, KEY_POWER }, + { 0x41, KEY_VOLUMEUP }, + { 0x42, KEY_VOLUMEDOWN }, + { 0x43, KEY_MUTE }, + { 0x44, KEY_PLAYCD }, + { 0x45, KEY_STOPCD }, + { 0x46, KEY_PAUSECD }, + { 0x47, KEY_RECORD }, + { 0x48, KEY_REWIND }, + { 0x49, KEY_FASTFORWARD }, + { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */ + { 0x4b, KEY_FORWARD }, + { 0x4c, KEY_BACK }, + { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */ + { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */ + /* 0x4f: Reserved */ + { 0x50, KEY_ANGLE }, + { 0x51, KEY_TV2 }, + { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */ + { 0x53, KEY_EPG }, + { 0x54, KEY_TIME }, /* CEC Spec: Timer */ + { 0x55, KEY_CONFIG }, + /* The following codes are hard to implement at this moment, as they +
Re: [RFC PATCH 12/24] dt: bindings: Add CSI1/CCP2 related properties to video-interfaces.txt
On Mon 2016-04-25 00:08:12, Ivaylo Dimitrov wrote: > From: Sakari Ailus > > Document the CSI1/CCP2 properties strobe_clk_inv and strobe_clock > properties. The former tells whether the strobe/clock signal is inverted, > while the latter signifies the clock or strobe mode. > > Signed-off-by: Sakari Ailus > --- > Documentation/devicetree/bindings/media/video-interfaces.txt | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt > b/Documentation/devicetree/bindings/media/video-interfaces.txt > index f5b61bd..f0523f7 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -114,9 +114,10 @@ Optional endpoint properties >lane and followed by the data lanes in the same order as in data-lanes. >Valid values are 0 (normal) and 1 (inverted). The length of the array >should be the combined length of data-lanes and clock-lanes properties. > - If the lane-polarities property is omitted, the value must be interpreted > - as 0 (normal). This property is valid for serial busses only. > - > +- clock-inv: Clock or strobe signal inversion. > + Possible values: 0 -- not inverted; 1 -- inverted I'd do "clock-inverted". And probably dt people need to be cc-ed on this one. > +- strobe: Whether the clock signal is used as clock or strobe. Used > + with CCP2, for instance. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC PATCH 11/24] dt: bindings: v4l: Add bus-type video interface property
On Mon 2016-04-25 00:08:11, Ivaylo Dimitrov wrote: > From: Sakari Ailus > > In the vast majority of cases the bus type is known to the driver(s) since > a receiver or transmitter can only support a single one. There are cases > however where different options are possible. > > Signed-off-by: Sakari Ailus Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC PATCH 09/24] v4l: Add CSI1 and CCP2 bus type to enum v4l2_mbus_type
On Mon 2016-04-25 00:08:09, Ivaylo Dimitrov wrote: > From: Sakari Ailus > > CCP2, or CSI-1, is an older single data lane serial bus. > > Signed-off-by: Sakari Ailus Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC PATCH 07/24] v4l: of: Call CSI2 bus csi2, not csi
On Mon 2016-04-25 00:08:07, Ivaylo Dimitrov wrote: > From: Sakari Ailus > > The function to parse CSI2 bus parameters was called > v4l2_of_parse_csi_bus(), rename it as v4l2_of_parse_csi2_bus() in > anticipation of CSI1/CCP2 support. > > Signed-off-by: Sakari Ailus Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[PATCH] media: omap3isp: Use dma_request_chan() to requesting DMA channel
With the new dma_request_chan() the client driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the driver can now support deferred probing against DMA. Signed-off-by: Peter Ujfalusi CC: Laurent Pinchart CC: Mauro Carvalho Chehab --- drivers/media/platform/omap3isp/isphist.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/media/platform/omap3isp/isphist.c b/drivers/media/platform/omap3isp/isphist.c index 7138b043a4aa..e163e3d92517 100644 --- a/drivers/media/platform/omap3isp/isphist.c +++ b/drivers/media/platform/omap3isp/isphist.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include @@ -486,27 +485,19 @@ int omap3isp_hist_init(struct isp_device *isp) hist->isp = isp; if (HIST_CONFIG_DMA) { - struct platform_device *pdev = to_platform_device(isp->dev); - struct resource *res; - unsigned int sig = 0; - dma_cap_mask_t mask; - - dma_cap_zero(mask); - dma_cap_set(DMA_SLAVE, mask); - - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, - "hist"); - if (res) - sig = res->start; - - hist->dma_ch = dma_request_slave_channel_compat(mask, - omap_dma_filter_fn, &sig, isp->dev, "hist"); - if (!hist->dma_ch) + hist->dma_ch = dma_request_chan(isp->dev, "hist"); + if (IS_ERR(hist->dma_ch)) { + ret = PTR_ERR(hist->dma_ch); + if (ret == -EPROBE_DEFER) + return ret; + + hist->dma_ch = NULL; dev_warn(isp->dev, "hist: DMA channel request failed, using PIO\n"); - else + } else { dev_dbg(isp->dev, "hist: using DMA channel %s\n", dma_chan_name(hist->dma_ch)); + } } hist->ops = &hist_ops; -- 2.8.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 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L
On 22/04/2016 16:44, Mauro Carvalho Chehab wrote: >> On the other hand, it would be a good place to tell the user that it >> is from a touch sensor. >> >> Using the upcoming metadata feature wouldn't work since there is no width >> and height in the metadata format. >> >> I wonder what others think about adding a new type value. > > IMO, two things should be done here: > > 1) Add some caps flag to help userspace to identify what's there >on those devices; In the patches I have written so far, I have used inputs to select between different types of data, so I believe there's no real need for this yet. Did you have anything else in mind? > 2) Make sure that udev/systemd won't be naming the devnodes as >"/dev/video"; > > > The latter one could be solved with either the new dev meta or > with another VFL_TYPE for input systems (like VFL_TYPE_TOUCH_SENSOR) > and use this code snippet: > > diff --git a/drivers/media/v4l2-core/v4l2-dev.c > b/drivers/media/v4l2-core/v4l2-dev.c > index d8e5994cccf1..4d3e574eba49 100644 > --- a/drivers/media/v4l2-core/v4l2-dev.c > +++ b/drivers/media/v4l2-core/v4l2-dev.c > @@ -887,6 +887,9 @@ int __video_register_device(struct video_device *vdev, > int type, int nr, > /* Use device name 'swradio' because 'sdr' was already taken. > */ > name_base = "swradio"; > break; > + case VFL_TYPE_TOUCH_SENSOR: > + name_base = "v4l-touch"; > + break; > default: > printk(KERN_ERR "%s called with unknown type: %d\n", >__func__, type); > > > Such change would cause __video_register_device() to pass a different > name_base to: > dev_set_name(&vdev->dev, "%s%d", name_base, vdev->num); > > This way, udev/systemd will use a different name (by default, > /dev/v4l-touch0), and existing apps won't identify this as a > webcam. Thanks - this sounds like a good approach to me. I will update. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Drop obsolete 'experimental' annotations
Hi, Hans! On Fri, Apr 22, 2016 at 11:06:57AM +0200, Hans Verkuil wrote: > From: Hans Verkuil > > Both in videodev2.h and in the documentation there are a lot of features > marked 'experimental' that have been around for years. Remove these > annotations since it was pure laziness that we didn't do that before. Acked-by: Sakari Ailus -- 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
Re: gstreamer: v4l2videodec plugin
On Thu, Apr 28, 2016 at 7:33 AM, Stanimir Varbanov wrote: > On 04/15/2016 07:09 PM, Nicolas Dufresne wrote: >> Le vendredi 15 avril 2016 à 11:58 -0400, Rob Clark a écrit : >>> The issue is probably the YUV format, which we cannot really deal >>> with >>> properly in gallium.. it's a similar issue to multi-planer even if >>> it >>> is in a single buffer. >>> >>> The best way to handle this would be to import the same dmabuf fd >>> twice, with appropriate offsets, to create one GL_RED eglimage for Y >>> and one GL_RG eglimage for UV, and then combine them in shader in a >>> similar way to how you'd handle separate Y and UV planes.. >> >> That's the strategy we use in GStreamer, as very few GL stack support >> implicit color conversions. For that to work you need to implement the >> "offset" field in winsys_handle, that was added recently, and make sure >> you have R8 and RG88 support (usually this is just mapping). > > Thanks, > > OK, I have made the relevant changes in Mesa and now I have image but > the U and V components are swapped (the format is NV12, the UV plane is > at the same buffer but at offset). Digging further and tracing gstreamer > with apitrace I'm observing something weird. > > The gst import dmabuf with following call: > > eglCreateImageKHR(dpy = 0x7fa8013030, ctx = NULL, target = > EGL_LINUX_DMA_BUF_EXT, buffer = NULL, attrib_list = {EGL_WIDTH, 640, > EGL_HEIGHT, 360, EGL_LINUX_DRM_FOURCC_EXT, 943215175, > EGL_DMA_BUF_PLANE0_FD_EXT, 29, EGL_DMA_BUF_PLANE0_OFFSET_EXT, 942080, > EGL_DMA_BUF_PLANE0_PITCH_EXT, 1280, EGL_NONE}) = 0x7f980027d0 > > the fourcc format is DRM_FORMAT_GR88 (943215175 decimal). > > after that: > > glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RG8, > width = 640, height = 360, border = 0, format = GL_RG, type = > GL_UNSIGNED_BYTE, pixels = NULL) > > and finally on the fragment shader we have: > > yuv.x=texture2D(Ytex, texcoord * tex_scale0).r; > yuv.yz=texture2D(UVtex, texcoord * tex_scale1).rg; > > I was expecting to see DRM_FORMAT_RG88 / GL_RG and shader sampling > y <- r > z <- g > > or DRM_FORMAT_GR88 / GL_RG and shader sampling > y <- g > z <- r IIRC you are using gles? Could you recompile glimagesink to use desktop GL? I'm wondering a bit, but just speculation since I don't have a way to step through it, but the 'if (_mesa_is_gles())' case in st_ChooseTextureFormat.. normally for gles the driver is more free to choose the corresponding internal-format, which is maybe not the right thing to do for textures which are imported eglimages. (if recompiling mesa is easier, you could just change that to 'if (0)' and see if it "fixes" things.. that ofc is not the proper fix, but it would confirm whether this is what is going on..) BR, -R > Also, browsing the code in Mesa for Intel i965 dri driver I found where > the __DRI_IMAGE_FORMAT_GR88 becomes MESA_FORMAT_R8G8_UNORM [1]. > > So I'm wondering is that intensional? > > Depending on the answer I should make the same in the Gallium dri2 in > dri2_from_dma_bufs(). > > -- > regards, > Stan > > [1] > https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/common/dri_util.c#n878 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media: vb2-dma-contig: configure DMA max segment size properly
Hi Sakari, On 2016-04-29 13:21, Sakari Ailus wrote: Hi Marek, Thanks for the patch! On Thu, Apr 28, 2016 at 03:20:03PM +0200, Marek Szyprowski wrote: This patch lets vb2-dma-contig memory allocator to configure DMA max segment size properly for the client device. Setting it is needed to let DMA-mapping subsystem to create a single, contiguous mapping in DMA address space. This is essential for all devices, which use dma-contig videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes of operations). Signed-off-by: Marek Szyprowski --- Hello, This patch is a follow-up of my previous attempts to let Exynos multimedia devices to work properly with shared buffers when IOMMU is enabled: 1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html 2. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316 3. https://patchwork.linuxtv.org/patch/30870/ As sugested by Hans, configuring DMA max segment size should be done by videobuf2-dma-contig module instead of requiring all device drivers to do it on their own. Here is some backgroud why this is done in videobuf2-dc not in the respective generic bus code: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html Best regards, Marek Szyprowski changelog: v2: - fixes typos and other language issues in the comments v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690 --- drivers/media/v4l2-core/videobuf2-dma-contig.c | 39 ++ 1 file changed, 39 insertions(+) diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index 461ae55eaa98..d0382d62954d 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -443,6 +443,36 @@ static void vb2_dc_put_userptr(void *buf_priv) } /* + * To allow mapping the scatter-list into a single chunk in the DMA + * address space, the device is required to have the DMA max segment + * size parameter set to a value larger than the buffer size. Otherwise, + * the DMA-mapping subsystem will split the mapping into max segment + * size chunks. This function increases the DMA max segment size + * parameter to let DMA-mapping map a buffer as a single chunk in DMA + * address space. + * This code assumes that the DMA-mapping subsystem will merge all + * scatter-list segments if this is really possible (for example when + * an IOMMU is available and enabled). + * Ideally, this parameter should be set by the generic bus code, but it + * is left with the default 64KiB value due to historical litmiations in + * other subsystems (like limited USB host drivers) and there no good + * place to set it to the proper value. It is done here to avoid fixing + * all the vb2-dc client drivers. + */ +static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size) +{ + if (!dev->dma_parms) { + dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL); Doesn't this create a memory leak? Do consider that devices may be also removed from the system at runtime. Looks very nice otherwise. Yes it does, but there is completely no way to determine when to do that (dma_params might have been already allocated by the bus code). The whole dma_params idea and its handling is a bit messy. IMHO we can leave this for now until dma_params gets cleaned up (I remember someone said that he has this on his todo list, but I don't remember now who it was...). + if (!dev->dma_parms) + return -ENOMEM; + } + if (dma_get_max_seg_size(dev) < size) + return dma_set_max_seg_size(dev, size); + + return 0; +} + +/* * For some kind of reserved memory there might be no struct page available, * so all that can be done to support such 'pages' is to try to convert * pfn to dma address or at the last resort just assume that @@ -499,6 +529,10 @@ static void *vb2_dc_get_userptr(struct device *dev, unsigned long vaddr, return ERR_PTR(-EINVAL); } + ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size + PAGE_SIZE)); + if (!ret) + return ERR_PTR(ret); + buf = kzalloc(sizeof *buf, GFP_KERNEL); if (!buf) return ERR_PTR(-ENOMEM); @@ -675,10 +709,15 @@ static void *vb2_dc_attach_dmabuf(struct device *dev, struct dma_buf *dbuf, { struct vb2_dc_buf *buf; struct dma_buf_attachment *dba; + int ret; if (dbuf->size < size) return ERR_PTR(-EFAULT); + ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size)); + if (!ret) + return ERR_PTR(ret); + buf = kzalloc(sizeof(*buf), GFP_KERNEL); if (!buf) return ERR_PTR(-ENOMEM); Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a messag
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
On Fri, Apr 29, 2016 at 01:05:46PM +0200, Pali Rohár wrote: > On Friday 29 April 2016 13:59:44 Sakari Ailus wrote: > > > pavel@amd:/data/l/linux-n900$ git fetch > > > git://git.retiisi.org.uk/~sailus/linux.git leds-as3645a:leds-as3645a > > > fatal: unable to connect to git.retiisi.org.uk: > > > git.retiisi.org.uk: Name or service not known > > > > > > pavel@amd:/data/l/linux-n900$ git fetch > > > git://salottisipuli.retiisi.org.uk/~sailus/linux.git > > > leds-as3645a:leds-as3645a > > > remote: Counting objects: 132, done. > > > remote: Compressing objects: 100% (46/46), done. > > > remote: Total 132 (delta 111), reused 107 (delta 86) > > > Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. > > > Resolving deltas: 100% (111/111), completed with 34 local objects. > > > From git://salottisipuli.retiisi.org.uk/~sailus/linux > > > * [new branch] leds-as3645a -> leds-as3645a > > > > Yeah, that works, too. git alias has been added some three weeks ago so > > there seem to be something strange going on with DNS. > > Maybe update SOA record? The host has been added before that. It looks like the slaves are performing the zone transfer nicely but for some reason they don't seem to correctly respond when the newly added name is queried. -- 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
Re: [PATCH v2] media: vb2-dma-contig: configure DMA max segment size properly
Hi Marek, Thanks for the patch! On Thu, Apr 28, 2016 at 03:20:03PM +0200, Marek Szyprowski wrote: > This patch lets vb2-dma-contig memory allocator to configure DMA max > segment size properly for the client device. Setting it is needed to let > DMA-mapping subsystem to create a single, contiguous mapping in DMA > address space. This is essential for all devices, which use dma-contig > videobuf2 memory allocator and shared buffers (in USERPTR or DMAbuf modes > of operations). > > Signed-off-by: Marek Szyprowski > --- > Hello, > > This patch is a follow-up of my previous attempts to let Exynos > multimedia devices to work properly with shared buffers when IOMMU is > enabled: > 1. https://www.mail-archive.com/linux-media@vger.kernel.org/msg96946.html > 2. > http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97316 > 3. https://patchwork.linuxtv.org/patch/30870/ > > As sugested by Hans, configuring DMA max segment size should be done by > videobuf2-dma-contig module instead of requiring all device drivers to > do it on their own. > > Here is some backgroud why this is done in videobuf2-dc not in the > respective generic bus code: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305913.html > > Best regards, > Marek Szyprowski > > changelog: > v2: > - fixes typos and other language issues in the comments > > v1: http://article.gmane.org/gmane.linux.kernel.samsung-soc/53690 > --- > drivers/media/v4l2-core/videobuf2-dma-contig.c | 39 > ++ > 1 file changed, 39 insertions(+) > > diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c > b/drivers/media/v4l2-core/videobuf2-dma-contig.c > index 461ae55eaa98..d0382d62954d 100644 > --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c > +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c > @@ -443,6 +443,36 @@ static void vb2_dc_put_userptr(void *buf_priv) > } > > /* > + * To allow mapping the scatter-list into a single chunk in the DMA > + * address space, the device is required to have the DMA max segment > + * size parameter set to a value larger than the buffer size. Otherwise, > + * the DMA-mapping subsystem will split the mapping into max segment > + * size chunks. This function increases the DMA max segment size > + * parameter to let DMA-mapping map a buffer as a single chunk in DMA > + * address space. > + * This code assumes that the DMA-mapping subsystem will merge all > + * scatter-list segments if this is really possible (for example when > + * an IOMMU is available and enabled). > + * Ideally, this parameter should be set by the generic bus code, but it > + * is left with the default 64KiB value due to historical litmiations in > + * other subsystems (like limited USB host drivers) and there no good > + * place to set it to the proper value. It is done here to avoid fixing > + * all the vb2-dc client drivers. > + */ > +static int vb2_dc_set_max_seg_size(struct device *dev, unsigned int size) > +{ > + if (!dev->dma_parms) { > + dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL); Doesn't this create a memory leak? Do consider that devices may be also removed from the system at runtime. Looks very nice otherwise. > + if (!dev->dma_parms) > + return -ENOMEM; > + } > + if (dma_get_max_seg_size(dev) < size) > + return dma_set_max_seg_size(dev, size); > + > + return 0; > +} > + > +/* > * For some kind of reserved memory there might be no struct page available, > * so all that can be done to support such 'pages' is to try to convert > * pfn to dma address or at the last resort just assume that > @@ -499,6 +529,10 @@ static void *vb2_dc_get_userptr(struct device *dev, > unsigned long vaddr, > return ERR_PTR(-EINVAL); > } > > + ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size + PAGE_SIZE)); > + if (!ret) > + return ERR_PTR(ret); > + > buf = kzalloc(sizeof *buf, GFP_KERNEL); > if (!buf) > return ERR_PTR(-ENOMEM); > @@ -675,10 +709,15 @@ static void *vb2_dc_attach_dmabuf(struct device *dev, > struct dma_buf *dbuf, > { > struct vb2_dc_buf *buf; > struct dma_buf_attachment *dba; > + int ret; > > if (dbuf->size < size) > return ERR_PTR(-EFAULT); > > + ret = vb2_dc_set_max_seg_size(dev, PAGE_ALIGN(size)); > + if (!ret) > + return ERR_PTR(ret); > + > buf = kzalloc(sizeof(*buf), GFP_KERNEL); > if (!buf) > return ERR_PTR(-ENOMEM); -- 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
Re: [PATCH v9 0/8] Add MT8173 Video Encoder Driver and VPU Driver
Hi Tiffany, On 04/26/2016 10:58 AM, Tiffany Lin wrote: > == > Introduction > == > > The purpose of this series is to add the driver for video codec hw embedded > in the Mediatek's MT8173 SoCs. > Mediatek Video Codec is able to handle video encoding of in a range of > formats. > > This patch series also include VPU driver. Mediatek Video Codec driver rely > on VPU driver to load, > communicate with VPU. > > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both > have been merged in v4.6-rc1. > > == > Device interface > == > > In principle the driver bases on v4l2 memory-to-memory framework: > it provides a single video node and each opened file handle gets its own > private context with separate > buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source > buffers, i.e. raw video > frames) and CAPTURE (for destination buffers, i.e. encoded video frames). > > == > VPU (Video Processor Unit) > == > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. > It is able to handle video decoding/encoding in a range of formats. > The driver provides with VPU firmware download, memory management and the > communication interface between CPU and VPU. > For VPU initialization, it will create virtual memory for CPU access and > physical address for VPU hw device access. > When a decode/encode instance opens a device node, vpu driver will download > vpu firmware to the device. > A decode/encode instant will decode/encode a frame using VPU interface to > interrupt vpu to handle decoding/encoding jobs. > > Please have a look at the code and comments will be very much appreciated. I build this using my daily build setup and got a bunch of errors and warnings from both the compiler (when this driver is compile-tested on a 32 bit arch) and from sparse/smatch. Can you fix these? linux-git-i686: WARNINGS /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c: In function 'load_requested_vpu': /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c:498:117: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat=] /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c:498:117: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Wformat=] /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c:501:410: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'size_t {aka unsigned int}' [-Wformat=] /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/venc_vpu_if.c: In function 'vpu_enc_ipi_handler': /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/venc_vpu_if.c:40:30: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] struct venc_vpu_inst *vpu = (struct venc_vpu_inst *)msg->venc_inst; ^ /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c: In function 'mtk_venc_worker': /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c:1046:43: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type 'size_t {aka unsigned int}' [-Wformat=] /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c:1046:43: warning: format '%lx' expects argument of type 'long unsigned int', but argument 10 has type 'size_t {aka unsigned int}' [-Wformat=] /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c:1046:43: warning: format '%lx' expects argument of type 'long unsigned int', but argument 13 has type 'size_t {aka unsigned int}' [-Wformat=] Tip: use %zu or %zx for size_t. sparse: ERRORS /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:261:24: warning: incorrect type in assignment (different base types) /home/hans/work/build/media-git/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:476:23: warning: symbol 'get_vp8_enc_comm_if' was not declared. Should it be static? /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c:237:6: warning: symbol 'vpu_clock_disable' was not declared. Should it be static? /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c:250:5: warning: symbol 'vpu_clock_enable' was not declared. Should it be static? /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c:436:54: warning: incorrect type in return expression (different address spaces) /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/mtk_vpu.c:504:14: warning: incorrect type in assignment (different address spaces) /home/hans/work/build/media-git/drivers/media/platform/mtk-vpu/m
Re: [GIT PULL] two patches: pipeline validation error code
Em Wed, 27 Apr 2016 15:01:31 -0300 Helen Koike escreveu: > Hi Mauro, > > Please pull the following patches correcting the returned error codes > and respective docs in the pipeline validation. > > Regards, > Helen > > The following changes since commit 45c175c4ae9695d6d2f30a45ab7f3866cfac184b: > >[media] tw686x: avoid going past array (2016-04-26 06:38:53 -0300) > > are available in the git repository at: > >https://github.com/helen-fornazier/opw-staging.git media/devel > > for you to fetch changes up to 957f69645eae5faae6daa205e85471ef82752abc: > >[media] DocBook: update error code in videoc-streamon (2016-04-27 > 14:14:11 -0300) Hi Helen, Not sure how you generated this pull request, but my script didn't recognize it as a valid pull request. My scripts use exactly the same format as the one produced by "git request-pull" command without the "-p" flag. PS.: I tried to remove the diff from the pull request and fix a whitespace wrapper that your emailer seemed to do, but, even so, it was not recognized. This time, I manually apply the two patches from your tree, but next time, please be sure to fix those issues if you intend to send as a pull request (or otherwise, send as e-mails). Regards, Mauro > > > Helen Mae Koike Fornazier (2): >[media] media: change pipeline validation return error >[media] DocBook: update error code in videoc-streamon > > Documentation/DocBook/media/v4l/vidioc-streamon.xml | 8 > drivers/media/media-entity.c| 2 +- > drivers/media/v4l2-core/v4l2-subdev.c | 4 ++-- > 3 files changed, 11 insertions(+), 3 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml > b/Documentation/DocBook/media/v4l/vidioc-streamon.xml > index df2c63d..89fd7ce 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-streamon.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml > @@ -123,6 +123,14 @@ synchronize with other events. > > > > + > + ENOLINK > + > + The driver implements Media Controller interface and > + the pipeline link configuration is invalid. > + > + > + > > > > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c > index c53c1d5..d8a2299 100644 > --- a/drivers/media/media-entity.c > +++ b/drivers/media/media-entity.c > @@ -445,7 +445,7 @@ __must_check int > __media_entity_pipeline_start(struct media_entity *entity, > bitmap_or(active, active, has_no_links, entity->num_pads); > > if (!bitmap_full(active, entity->num_pads)) { > -ret = -EPIPE; > +ret = -ENOLINK; > dev_dbg(entity->graph_obj.mdev->dev, > "\"%s\":%u must be connected by an enabled link\n", > entity->name, > diff --git a/drivers/media/v4l2-core/v4l2-subdev.c > b/drivers/media/v4l2-core/v4l2-subdev.c > index 224ea60..953eab0 100644 > --- a/drivers/media/v4l2-core/v4l2-subdev.c > +++ b/drivers/media/v4l2-core/v4l2-subdev.c > @@ -510,7 +510,7 @@ int v4l2_subdev_link_validate_default(struct > v4l2_subdev *sd, > if (source_fmt->format.width != sink_fmt->format.width > || source_fmt->format.height != sink_fmt->format.height > || source_fmt->format.code != sink_fmt->format.code) > -return -EINVAL; > +return -EPIPE; > > /* The field order must match, or the sink field order must be NONE >* to support interlaced hardware connected to bridges that support > @@ -518,7 +518,7 @@ int v4l2_subdev_link_validate_default(struct > v4l2_subdev *sd, >*/ > if (source_fmt->format.field != sink_fmt->format.field && > sink_fmt->format.field != V4L2_FIELD_NONE) > -return -EINVAL; > +return -EPIPE; > > return 0; > } > > -- > 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 -- Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
On Friday 29 April 2016 13:59:44 Sakari Ailus wrote: > > pavel@amd:/data/l/linux-n900$ git fetch > > git://git.retiisi.org.uk/~sailus/linux.git leds-as3645a:leds-as3645a > > fatal: unable to connect to git.retiisi.org.uk: > > git.retiisi.org.uk: Name or service not known > > > > pavel@amd:/data/l/linux-n900$ git fetch > > git://salottisipuli.retiisi.org.uk/~sailus/linux.git > > leds-as3645a:leds-as3645a > > remote: Counting objects: 132, done. > > remote: Compressing objects: 100% (46/46), done. > > remote: Total 132 (delta 111), reused 107 (delta 86) > > Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. > > Resolving deltas: 100% (111/111), completed with 34 local objects. > > From git://salottisipuli.retiisi.org.uk/~sailus/linux > > * [new branch] leds-as3645a -> leds-as3645a > > Yeah, that works, too. git alias has been added some three weeks ago so > there seem to be something strange going on with DNS. Maybe update SOA record? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi Pavel, On Fri, Apr 29, 2016 at 11:50:02AM +0200, Pavel Machek wrote: > Hi! > > > > > adp1653 registers itself as a subdev, but there's no device that > > > > register it as its part. > > > > > > > > (ad5820 driver seems to have the same problem). > > > > > > > > Is there example "dummy" device I could use, for sole purpose of > > > > having these devices appear in /dev? They are on i2c, so both can work > > > > on their own. > > > > > > Ah, interesting. This was discussed a little bit during the Media Summit > > > a few weeks back: > > > > > > http://linuxtv.org/news.php?entry=2016-04-20.mchehab > > > > > > See section 5: > > > > > > "5. DT Bindings for flash & lens controllers > > > > > > There are drivers that create their MC topology using the device tree > > > information, > > > which works great for entities that transport data, but how to detect > > > entities > > > that don’t transport data such as flash devices, focusers, etc.? How can > > > those be > > > deduced using the device tree? > > > > > > Sensor DT node add phandle to focus controller: add generic v4l binding > > > properties > > > to reference such devices." > > > > > > This wasn't a problem with the original N900 since that didn't use DT > > > AFAIK and > > > these devices were loaded explicitly through board code. > > > > But now you run into the same problem that I have. > > Actually... being able to do board-code solution for testing for now > would be nice... > > > > > > > The solution is that sensor devices have to provide phandles to those > > > controller > > > devices. And to do that you need to define bindings which is always the > > > hard part. > > > > > > Look in Documentation/devicetree/bindings/media/video-interfaces.txt, > > > section > > > "Optional endpoint properties". > > > > > > Something like: > > > > > > controllers: an array of phandles to controller devices associated with > > > this > > > endpoint such as flash and lens controllers. > > > > > > Warning: I'm no DT expert, so this is just a first attempt. > > > > > > Platform drivers (omap3isp) will have to add these controller devices to > > > the list > > > of subdevs to load asynchronously. > > > > I seem to have patches I haven't had time to push back then: > > > > http://salottisipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/leds-as3645a> > > > > That gitweb is a bit confused about its own address, but I figured it > out. Let me check... > > pavel@amd:/data/l/linux-n900$ git fetch > git://git.retiisi.org.uk/~sailus/linux.git leds-as3645a:leds-as3645a > fatal: unable to connect to git.retiisi.org.uk: > git.retiisi.org.uk: Name or service not known > > pavel@amd:/data/l/linux-n900$ git fetch > git://salottisipuli.retiisi.org.uk/~sailus/linux.git > leds-as3645a:leds-as3645a > remote: Counting objects: 132, done. > remote: Compressing objects: 100% (46/46), done. > remote: Total 132 (delta 111), reused 107 (delta 86) > Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. > Resolving deltas: 100% (111/111), completed with 34 local objects. > From git://salottisipuli.retiisi.org.uk/~sailus/linux > * [new branch] leds-as3645a -> leds-as3645a Yeah, that works, too. git alias has been added some three weeks ago so there seem to be something strange going on with DNS. > > > > This seems to be mostly in line with what has been discussed in the meeting, > > except that the patches add a device specific property. Please ignore the > > led patches in that tree for now (i.e. four patches on the top are the > > relevant ones here). > > > > I'm currently trying to apply them to v4.6, but am getting rather ugly > rejects :-(. :-\ There have been patches applied to the omap3isp driver since that I suppose. These aren't overly complex, feel free to take the patches if they're still useful. -- 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
[GIT PULL FOR v4.7] Add new rcar-vin driver
Hi Mauro, This adds the new non-soc-camera rcar-vin driver, deprecating the older driver. Tested with my Koelsch board. This patch just marks the old driver as DEPRECATED. I am unsure what is better: 1) just mark as DEPRECATED and remove it in the next kernel 2) move it to drivers/staging/media and remove it in the next kernel 3) just remove it now I have no strong preference myself. Regards, Hans The following changes since commit 45c175c4ae9695d6d2f30a45ab7f3866cfac184b: [media] tw686x: avoid going past array (2016-04-26 06:38:53 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git rcar for you to fetch changes up to dd34ebe6deb4162993efb5de12b0418354ee5173: rcar-vin: add Renesas R-Car VIN driver (2016-04-29 12:13:16 +0200) Niklas Söderlund (1): rcar-vin: add Renesas R-Car VIN driver drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile |2 + drivers/media/platform/rcar-vin/Kconfig | 11 + drivers/media/platform/rcar-vin/Makefile|3 + drivers/media/platform/rcar-vin/rcar-core.c | 337 drivers/media/platform/rcar-vin/rcar-dma.c | 1196 +++ drivers/media/platform/rcar-vin/rcar-v4l2.c | 768 +++ drivers/media/platform/rcar-vin/rcar-vin.h | 163 drivers/media/platform/soc_camera/Kconfig |4 +- drivers/media/platform/soc_camera/Makefile |2 +- 10 files changed, 2484 insertions(+), 3 deletions(-) create mode 100644 drivers/media/platform/rcar-vin/Kconfig create mode 100644 drivers/media/platform/rcar-vin/Makefile create mode 100644 drivers/media/platform/rcar-vin/rcar-core.c create mode 100644 drivers/media/platform/rcar-vin/rcar-dma.c create mode 100644 drivers/media/platform/rcar-vin/rcar-v4l2.c create mode 100644 drivers/media/platform/rcar-vin/rcar-vin.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: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi! > > Warning: I'm no DT expert, so this is just a first attempt. > > > > Platform drivers (omap3isp) will have to add these controller devices to > > the list > > of subdevs to load asynchronously. > > I seem to have patches I haven't had time to push back then: > > http://salottisipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/leds-as3645a> > > This seems to be mostly in line with what has been discussed in the meeting, > except that the patches add a device specific property. Please ignore the > led patches in that tree for now (i.e. four patches on the top are the > relevant ones here). Ok, I attempted to forward-port the patches to v4.6. Not sure if I was successful. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >From fad952ee3d1e888401b047c9657f04afeaf40fc5 Mon Sep 17 00:00:00 2001 From: Sakari Ailus Date: Sat, 16 May 2015 23:34:34 +0300 Subject: [PATCH 1/5] omap3isp: Fix async notifier registration order The async notifier was registered before the v4l2_device was registered and before the notifier callbacks were set. This could lead to missing the bound() and complete() callbacks and to attempting to spin_lock() and uninitialised spin lock. Also fix unregistering the async notifier in the case of an error --- the function may not fail anymore after the notifier is registered. Signed-off-by: Sakari Ailus Conflicts: drivers/media/platform/omap3isp/isp.c --- arch/arm/boot/dts/omap3-n900.dts | 24 drivers/media/i2c/ad5820.c| 2 +- drivers/media/i2c/adp1653.c | 9 - drivers/media/platform/omap3isp/isp.c | 12 4 files changed, 45 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 640d409..0729c69 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -186,6 +186,7 @@ module { model = "TCM8341MD"; sensor = <&cam1>; + focus = <&autofocus>; }; }; @@ -198,6 +199,11 @@ }; }; + autofocus: dac-camera-autofocus { + compatible = "dac-camera-autofocus"; + io-channels = <&ad5820>; + }; + video-bus-switch { compatible = "video-bus-switch"; @@ -255,6 +261,11 @@ crc = <0>; }; }; + port@99 { + adp1653_link: endpoint { + remote-endpoint = <&adp1653_ep>; + }; + }; }; }; @@ -696,6 +707,11 @@ indicator { led-max-microamp = <17500>; }; + port { + adp1653_ep: endpoint { + remote-endpoint = <&adp1653_link>; + }; + }; }; lp5523: lp5523@32 { @@ -879,6 +895,14 @@ }; }; }; + + /* D/A converter for auto-focus */ + ad5820: dac@0c { + compatible = "adi,ad5820"; + reg = <0x0c>; + + #io-channel-cells = <0>; + }; }; &mmc1 { diff --git a/drivers/media/i2c/ad5820.c b/drivers/media/i2c/ad5820.c index 58a44f1..400200c 100644 --- a/drivers/media/i2c/ad5820.c +++ b/drivers/media/i2c/ad5820.c @@ -421,7 +421,7 @@ static int ad5820_probe(struct i2c_client *client, coil->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; coil->subdev.internal_ops = &ad5820_internal_ops; - ret = media_entity_init(&coil->subdev.entity, 0, NULL, 0); + ret = media_entity_pads_init(&coil->subdev.entity, 0, NULL); if (ret < 0) kfree(coil); diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c index b90e15b..6dd5d6a 100644 --- a/drivers/media/i2c/adp1653.c +++ b/drivers/media/i2c/adp1653.c @@ -515,6 +515,7 @@ static int adp1653_probe(struct i2c_client *client, v4l2_i2c_subdev_init(&flash->subdev, client, &adp1653_ops); flash->subdev.internal_ops = &adp1653_internal_ops; flash->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE; + strcpy(flash->subdev.name, "adp1653 flash"); ret = adp1653_init_controls(flash); if (ret) @@ -524,7 +525,13 @@ static int adp1653_probe(struct i2c_client *client, if (ret < 0) goto free_and_quit; - dev_info(&client->dev, "adp1653 probe: should be ok\n"); + dev_info(&client->dev, "adp1653 probe: should be ok\n"); + + ret = v4l2_async_register_subdev(&flash->subdev); + if (ret < 0) + goto free_and_quit; + + dev_info(&client->dev, "adp1653 probe: async register subdev ok\n"); flash->subdev.entity.function = MEDIA_ENT_F_FLASH; diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 6361fde..9f51127 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2392,6 +2392,7 @@ static int isp_probe(struct platform_device *pdev) if (ret < 0) goto error_modules; +<<< HEAD ret = isp_create_links(isp); if (ret < 0) goto error_register_entities; @@ -2402,6 +2403,17 @@ static int isp_probe(struct platform_device *pdev) ret = v4l2_async_notifier_register(&isp->v4l2_dev, &isp->notifier); if (ret) goto error_register_entities; +=== + if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi! > > > adp1653 registers itself as a subdev, but there's no device that > > > register it as its part. > > > > > > (ad5820 driver seems to have the same problem). > > > > > > Is there example "dummy" device I could use, for sole purpose of > > > having these devices appear in /dev? They are on i2c, so both can work > > > on their own. > > > > Ah, interesting. This was discussed a little bit during the Media Summit > > a few weeks back: > > > > http://linuxtv.org/news.php?entry=2016-04-20.mchehab > > > > See section 5: > > > > "5. DT Bindings for flash & lens controllers > > > > There are drivers that create their MC topology using the device tree > > information, > > which works great for entities that transport data, but how to detect > > entities > > that don’t transport data such as flash devices, focusers, etc.? How can > > those be > > deduced using the device tree? > > > > Sensor DT node add phandle to focus controller: add generic v4l binding > > properties > > to reference such devices." > > > > This wasn't a problem with the original N900 since that didn't use DT AFAIK > > and > > these devices were loaded explicitly through board code. > > But now you run into the same problem that I have. Actually... being able to do board-code solution for testing for now would be nice... > > > > The solution is that sensor devices have to provide phandles to those > > controller > > devices. And to do that you need to define bindings which is always the > > hard part. > > > > Look in Documentation/devicetree/bindings/media/video-interfaces.txt, > > section > > "Optional endpoint properties". > > > > Something like: > > > > controllers: an array of phandles to controller devices associated with this > > endpoint such as flash and lens controllers. > > > > Warning: I'm no DT expert, so this is just a first attempt. > > > > Platform drivers (omap3isp) will have to add these controller devices to > > the list > > of subdevs to load asynchronously. > > I seem to have patches I haven't had time to push back then: > > http://salottisipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/leds-as3645a> > That gitweb is a bit confused about its own address, but I figured it out. Let me check... pavel@amd:/data/l/linux-n900$ git fetch git://git.retiisi.org.uk/~sailus/linux.git leds-as3645a:leds-as3645a fatal: unable to connect to git.retiisi.org.uk: git.retiisi.org.uk: Name or service not known pavel@amd:/data/l/linux-n900$ git fetch git://salottisipuli.retiisi.org.uk/~sailus/linux.git leds-as3645a:leds-as3645a remote: Counting objects: 132, done. remote: Compressing objects: 100% (46/46), done. remote: Total 132 (delta 111), reused 107 (delta 86) Receiving objects: 100% (132/132), 22.80 KiB | 0 bytes/s, done. Resolving deltas: 100% (111/111), completed with 34 local objects. >From git://salottisipuli.retiisi.org.uk/~sailus/linux * [new branch] leds-as3645a -> leds-as3645a > This seems to be mostly in line with what has been discussed in the meeting, > except that the patches add a device specific property. Please ignore the > led patches in that tree for now (i.e. four patches on the top are the > relevant ones here). > I'm currently trying to apply them to v4.6, but am getting rather ugly rejects :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[RFC PATCH 1/3] drm/omap: fix OMAP4 hdmi_core_powerdown_disable()
From: Tomi Valkeinen hdmi_core_powerdown_disable() is supposed to disable HDMI core's power-down mode. However, the function sets the power-down bit to 0, which means "enable power-down". This hasn't caused any issues as the PD seems to affect only interrupts from HDMI core, and none of those interrupts are used at the moment. CEC functionality requires core interrupts, and the PD mode needs to be fixed. This patch fixes hdmi_core_powerdown_disable() to actually disable the PD mode. Signed-off-by: Tomi Valkeinen Reported-by: Hans Verkuil --- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c index fa72e73..ef3afe9 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c @@ -211,7 +211,7 @@ static void hdmi_core_init(struct hdmi_core_video_config *video_cfg) static void hdmi_core_powerdown_disable(struct hdmi_core_data *core) { DSSDBG("Enter hdmi_core_powerdown_disable\n"); - REG_FLD_MOD(core->base, HDMI_CORE_SYS_SYS_CTRL1, 0x0, 0, 0); + REG_FLD_MOD(core->base, HDMI_CORE_SYS_SYS_CTRL1, 0x1, 0, 0); } static void hdmi_core_swreset_release(struct hdmi_core_data *core) -- 2.8.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
[RFC PATCH 2/3] omap4: add CEC support
From: Hans Verkuil Signed-off-by: Hans Verkuil --- arch/arm/boot/dts/omap4-panda-a4.dts | 2 +- arch/arm/boot/dts/omap4-panda-es.dts | 2 +- arch/arm/boot/dts/omap4.dtsi | 5 +- drivers/gpu/drm/omapdrm/dss/Kconfig| 8 + drivers/gpu/drm/omapdrm/dss/Makefile | 3 + drivers/gpu/drm/omapdrm/dss/hdmi.h | 62 ++- drivers/gpu/drm/omapdrm/dss/hdmi4.c| 39 +++- drivers/gpu/drm/omapdrm/dss/hdmi_cec.c | 329 + 8 files changed, 441 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi_cec.c diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts b/arch/arm/boot/dts/omap4-panda-a4.dts index 78d3631..f0c1020 100644 --- a/arch/arm/boot/dts/omap4-panda-a4.dts +++ b/arch/arm/boot/dts/omap4-panda-a4.dts @@ -13,7 +13,7 @@ /* Pandaboard Rev A4+ have external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = < - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* hdmi_cec.hdmi_cec */ + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ >; diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 119f8e6..940fe4f 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -34,7 +34,7 @@ /* PandaboardES has external pullups on SCL & SDA */ &dss_hdmi_pins { pinctrl-single,pins = < - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* hdmi_cec.hdmi_cec */ + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* hdmi_cec.hdmi_cec */ OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* hdmi_scl.hdmi_scl */ OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /* hdmi_sda.hdmi_sda */ >; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 2bd9c83..1bb490f 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -1006,8 +1006,9 @@ reg = <0x58006000 0x200>, <0x58006200 0x100>, <0x58006300 0x100>, - <0x58006400 0x1000>; - reg-names = "wp", "pll", "phy", "core"; + <0x58006400 0x900>, + <0x58006D00 0x100>; + reg-names = "wp", "pll", "phy", "core", "cec"; interrupts = ; status = "disabled"; ti,hwmods = "dss_hdmi"; diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig b/drivers/gpu/drm/omapdrm/dss/Kconfig index d1fa730..69638e9 100644 --- a/drivers/gpu/drm/omapdrm/dss/Kconfig +++ b/drivers/gpu/drm/omapdrm/dss/Kconfig @@ -71,9 +71,17 @@ config OMAP4_DSS_HDMI bool "HDMI support for OMAP4" default y select OMAP2_DSS_HDMI_COMMON + select MEDIA_CEC_EDID help HDMI support for OMAP4 based SoCs. +config OMAP2_DSS_HDMI_CEC + bool "Enable HDMI CEC support for OMAP4" + depends on OMAP4_DSS_HDMI && MEDIA_CEC + default y + ---help--- + When selected the HDMI transmitter will support the CEC feature. + config OMAP5_DSS_HDMI bool "HDMI support for OMAP5" default n diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile b/drivers/gpu/drm/omapdrm/dss/Makefile index b651ec9..37eb597 100644 --- a/drivers/gpu/drm/omapdrm/dss/Makefile +++ b/drivers/gpu/drm/omapdrm/dss/Makefile @@ -10,6 +10,9 @@ omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \ hdmi_phy.o +ifeq ($(CONFIG_OMAP2_DSS_HDMI_CEC),y) + omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_cec.o +endif omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h b/drivers/gpu/drm/omapdrm/dss/hdmi.h index 53616b0..7cf8a91 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi.h +++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h @@ -24,6 +24,7 @@ #include #include #include +#include #include "dss.h" @@ -83,6 +84,31 @@ #define HDMI_TXPHY_PAD_CFG_CTRL0xC #define HDMI_TXPHY_BIST_CONTROL0x1C +/* HDMI CEC */ +#define HDMI_CEC_DEV_ID 0x0 +#define HDMI_CEC_SPEC 0x4 +#define HDMI_CEC_DBG_3 0x1C +#define HDMI_CEC_TX_INIT0x20 +#define HDMI_CE
[RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid
From: Hans Verkuil As long as there is a valid physical address in the EDID and the omap CEC support is enabled, then we keep ls_oe_gpio on to ensure the CEC signal is passed through the tpd12s015. Signed-off-by: Hans Verkuil Suggested-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c index 916a899..efbba23 100644 --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c @@ -16,6 +16,7 @@ #include #include +#include #include #include @@ -65,6 +66,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev, return; gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0); + gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0); dst->src = NULL; dssdev->dst = NULL; @@ -142,6 +144,7 @@ static int tpd_read_edid(struct omap_dss_device *dssdev, { struct panel_drv_data *ddata = to_panel_data(dssdev); struct omap_dss_device *in = ddata->in; + bool valid_phys_addr = 0; int r; if (!gpiod_get_value_cansleep(ddata->hpd_gpio)) @@ -151,7 +154,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev, r = in->ops.hdmi->read_edid(in, edid, len); - gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0); +#ifdef CONFIG_OMAP2_DSS_HDMI_CEC + /* +* In order to support CEC this pin should remain high +* as long as the EDID has a valid physical address. +*/ + valid_phys_addr = + cec_get_edid_phys_addr(edid, r, NULL) != CEC_PHYS_ADDR_INVALID; +#endif + gpiod_set_value_cansleep(ddata->ls_oe_gpio, valid_phys_addr); return r; } -- 2.8.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
[RFC PATCH 0/3] OMAP4 HDMI CEC support
From: Hans Verkuil This patch series sits on top of my earlier HDMI CEC framework: http://www.spinics.net/lists/linux-media/msg99847.html It is an RFC patch for now as I want to clean up hdmi_cec a bit more and do a bit more testing. Many thanks to Tomi for finding obscure problems in the omap4 drivers that prevented CEC from working on my pandaboard. Feedback is welcome! Regards, Hans Hans Verkuil (2): omap4: add CEC support encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid Tomi Valkeinen (1): drm/omap: fix OMAP4 hdmi_core_powerdown_disable() arch/arm/boot/dts/omap4-panda-a4.dts | 2 +- arch/arm/boot/dts/omap4-panda-es.dts | 2 +- arch/arm/boot/dts/omap4.dtsi | 5 +- .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 +- drivers/gpu/drm/omapdrm/dss/Kconfig| 8 + drivers/gpu/drm/omapdrm/dss/Makefile | 3 + drivers/gpu/drm/omapdrm/dss/hdmi.h | 62 +++- drivers/gpu/drm/omapdrm/dss/hdmi4.c| 39 ++- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 2 +- drivers/gpu/drm/omapdrm/dss/hdmi_cec.c | 329 + 10 files changed, 454 insertions(+), 11 deletions(-) create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi_cec.c -- 2.8.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: gstreamer: v4l2videodec plugin
cc: mesa-dev ML On 04/28/2016 02:33 PM, Stanimir Varbanov wrote: > On 04/15/2016 07:09 PM, Nicolas Dufresne wrote: >> Le vendredi 15 avril 2016 à 11:58 -0400, Rob Clark a écrit : >>> The issue is probably the YUV format, which we cannot really deal >>> with >>> properly in gallium.. it's a similar issue to multi-planer even if >>> it >>> is in a single buffer. >>> >>> The best way to handle this would be to import the same dmabuf fd >>> twice, with appropriate offsets, to create one GL_RED eglimage for Y >>> and one GL_RG eglimage for UV, and then combine them in shader in a >>> similar way to how you'd handle separate Y and UV planes.. >> >> That's the strategy we use in GStreamer, as very few GL stack support >> implicit color conversions. For that to work you need to implement the >> "offset" field in winsys_handle, that was added recently, and make sure >> you have R8 and RG88 support (usually this is just mapping). > > Thanks, > > OK, I have made the relevant changes in Mesa and now I have image but > the U and V components are swapped (the format is NV12, the UV plane is > at the same buffer but at offset). Digging further and tracing gstreamer > with apitrace I'm observing something weird. > > The gst import dmabuf with following call: > > eglCreateImageKHR(dpy = 0x7fa8013030, ctx = NULL, target = > EGL_LINUX_DMA_BUF_EXT, buffer = NULL, attrib_list = {EGL_WIDTH, 640, > EGL_HEIGHT, 360, EGL_LINUX_DRM_FOURCC_EXT, 943215175, > EGL_DMA_BUF_PLANE0_FD_EXT, 29, EGL_DMA_BUF_PLANE0_OFFSET_EXT, 942080, > EGL_DMA_BUF_PLANE0_PITCH_EXT, 1280, EGL_NONE}) = 0x7f980027d0 > > the fourcc format is DRM_FORMAT_GR88 (943215175 decimal). > > after that: > > glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RG8, > width = 640, height = 360, border = 0, format = GL_RG, type = > GL_UNSIGNED_BYTE, pixels = NULL) > > and finally on the fragment shader we have: > > yuv.x=texture2D(Ytex, texcoord * tex_scale0).r; > yuv.yz=texture2D(UVtex, texcoord * tex_scale1).rg; > > I was expecting to see DRM_FORMAT_RG88 / GL_RG and shader sampling > y <- r > z <- g > > or DRM_FORMAT_GR88 / GL_RG and shader sampling > y <- g > z <- r > > Also, browsing the code in Mesa for Intel i965 dri driver I found where > the __DRI_IMAGE_FORMAT_GR88 becomes MESA_FORMAT_R8G8_UNORM [1]. > > So I'm wondering is that intensional? > > Depending on the answer I should make the same in the Gallium dri2 in > dri2_from_dma_bufs(). > -- 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 v7 16/24] i2c: allow adapter drivers to override the adapter locking
On 2016-04-29 09:16, Wolfram Sang wrote: >> Yes, obviously... I'll make that change locally and wait for the rest. > Another nit: You could use '--strict' with checkpatch and see if you > want to fix the issues reported. I am not keen on those (except for > 'space around operators'), it's a matter of taste I guess, but maybe you > like some of the suggestions. > Yes, they look like reasonable complaints. So, I fixed all of them locally except the complaint about lack of comment on the new struct mutex member in struct si2168_dev (patch 21/24), because that patch is Anttis and he's the maintainer of that driver... Antti, if you want that fixed as part of this series, send a suitable comment for the mutex this way and I'll incorporate it. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] media: Refactor copying IOCTL arguments from and to user space
Refactor copying the IOCTL argument structs from the user space and back, in order to reduce code copied around and make the implementation more robust. As a result, the copying is done while not holding the graph mutex. Signed-off-by: Sakari Ailus --- drivers/media/media-device.c | 167 +-- 1 file changed, 66 insertions(+), 101 deletions(-) diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 6d3ee5c..4a66a2d5 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -59,27 +59,24 @@ static int media_device_close(struct file *filp) } static int media_device_get_info(struct media_device *dev, -struct media_device_info __user *__info) +struct media_device_info *info) { - struct media_device_info info; - - memset(&info, 0, sizeof(info)); + memset(info, 0, sizeof(*info)); if (dev->driver_name[0]) - strlcpy(info.driver, dev->driver_name, sizeof(info.driver)); + strlcpy(info->driver, dev->driver_name, sizeof(info->driver)); else - strlcpy(info.driver, dev->dev->driver->name, sizeof(info.driver)); + strlcpy(info->driver, dev->dev->driver->name, + sizeof(info->driver)); - strlcpy(info.model, dev->model, sizeof(info.model)); - strlcpy(info.serial, dev->serial, sizeof(info.serial)); - strlcpy(info.bus_info, dev->bus_info, sizeof(info.bus_info)); + strlcpy(info->model, dev->model, sizeof(info->model)); + strlcpy(info->serial, dev->serial, sizeof(info->serial)); + strlcpy(info->bus_info, dev->bus_info, sizeof(info->bus_info)); - info.media_version = MEDIA_API_VERSION; - info.hw_revision = dev->hw_revision; - info.driver_version = dev->driver_version; + info->media_version = MEDIA_API_VERSION; + info->hw_revision = dev->hw_revision; + info->driver_version = dev->driver_version; - if (copy_to_user(__info, &info, sizeof(*__info))) - return -EFAULT; return 0; } @@ -101,29 +98,25 @@ static struct media_entity *find_entity(struct media_device *mdev, u32 id) } static long media_device_enum_entities(struct media_device *mdev, - struct media_entity_desc __user *uent) + struct media_entity_desc *entd) { struct media_entity *ent; - struct media_entity_desc u_ent; - - memset(&u_ent, 0, sizeof(u_ent)); - if (copy_from_user(&u_ent.id, &uent->id, sizeof(u_ent.id))) - return -EFAULT; - - ent = find_entity(mdev, u_ent.id); + ent = find_entity(mdev, entd->id); if (ent == NULL) return -EINVAL; - u_ent.id = media_entity_id(ent); + memset(entd, 0, sizeof(*entd)); + + entd->id = media_entity_id(ent); if (ent->name) - strlcpy(u_ent.name, ent->name, sizeof(u_ent.name)); - u_ent.type = ent->function; - u_ent.revision = 0; /* Unused */ - u_ent.flags = ent->flags; - u_ent.group_id = 0; /* Unused */ - u_ent.pads = ent->num_pads; - u_ent.links = ent->num_links - ent->num_backlinks; + strlcpy(entd->name, ent->name, sizeof(entd->name)); + entd->type = ent->function; + entd->revision = 0; /* Unused */ + entd->flags = ent->flags; + entd->group_id = 0; /* Unused */ + entd->pads = ent->num_pads; + entd->links = ent->num_links - ent->num_backlinks; /* * Workaround for a bug at media-ctl <= v1.10 that makes it to @@ -139,14 +132,13 @@ static long media_device_enum_entities(struct media_device *mdev, if (ent->function < MEDIA_ENT_F_OLD_BASE || ent->function > MEDIA_ENT_T_DEVNODE_UNKNOWN) { if (is_media_entity_v4l2_subdev(ent)) - u_ent.type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN; + entd->type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN; else if (ent->function != MEDIA_ENT_F_IO_V4L) - u_ent.type = MEDIA_ENT_T_DEVNODE_UNKNOWN; + entd->type = MEDIA_ENT_T_DEVNODE_UNKNOWN; } - memcpy(&u_ent.raw, &ent->info, sizeof(ent->info)); - if (copy_to_user(uent, &u_ent, sizeof(u_ent))) - return -EFAULT; + memcpy(&entd->raw, &ent->info, sizeof(ent->info)); + return 0; } @@ -158,8 +150,8 @@ static void media_device_kpad_to_upad(const struct media_pad *kpad, upad->flags = kpad->flags; } -static long __media_device_enum_links(struct media_device *mdev, - struct media_links_enum *links) +static long media_device_enum_links(struct media_device *mdev, + struct media_links_enum *links) { s
[PATCH 3/3] media: Refactor IOCTL handler calling
Replace the switch by a nice array of supported IOCTLs, just like in V4L2. Signed-off-by: Sakari Ailus --- drivers/media/media-device.c | 58 +++- 1 file changed, 19 insertions(+), 39 deletions(-) diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 4a66a2d5..8a4daf9 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -363,18 +363,22 @@ static long media_device_get_topology(struct media_device *mdev, return ret; } -#define MEDIA_IOC(__cmd) \ - [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd } +#define MEDIA_IOC(__cmd, func) \ + [_IOC_NR(MEDIA_IOC_##__cmd)] = {\ + .cmd = MEDIA_IOC_##__cmd, \ + .fn = (long (*)(struct media_device *, void *))func,\ + } /* the table is indexed by _IOC_NR(cmd) */ -static const struct { +static const struct media_ioctl_info { unsigned int cmd; + long (*fn)(struct media_device *dev, void *arg); } media_ioctl_info[] = { - MEDIA_IOC(DEVICE_INFO), - MEDIA_IOC(ENUM_ENTITIES), - MEDIA_IOC(ENUM_LINKS), - MEDIA_IOC(SETUP_LINK), - MEDIA_IOC(G_TOPOLOGY), + MEDIA_IOC(DEVICE_INFO, media_device_get_info), + MEDIA_IOC(ENUM_ENTITIES, media_device_enum_entities), + MEDIA_IOC(ENUM_LINKS, media_device_enum_links), + MEDIA_IOC(SETUP_LINK, media_device_setup_link), + MEDIA_IOC(G_TOPOLOGY, media_device_get_topology), }; static unsigned int media_ioctl_max_arg_size(void) { @@ -395,11 +399,15 @@ static long media_device_ioctl(struct file *filp, unsigned int cmd, { struct media_devnode *devnode = media_devnode_data(filp); struct media_device *dev = to_media_device(devnode); + const struct media_ioctl_info *info; char karg[media_ioctl_max_arg_size()]; long ret; - if (_IOC_NR(cmd) >= ARRAY_SIZE(media_ioctl_info) - || media_ioctl_info[_IOC_NR(cmd)].cmd != cmd) + if (_IOC_NR(cmd) >= ARRAY_SIZE(media_ioctl_info)) + return -ENOIOCTLCMD; + + info = &media_ioctl_info[_IOC_NR(cmd)]; + if (info->cmd != cmd) return -ENOIOCTLCMD; /* All media IOCTLs are _IOWR() */ @@ -407,35 +415,7 @@ static long media_device_ioctl(struct file *filp, unsigned int cmd, return -EFAULT; mutex_lock(&dev->graph_mutex); - switch (cmd) { - case MEDIA_IOC_DEVICE_INFO: - ret = media_device_get_info(dev, - (struct media_device_info *)karg); - break; - - case MEDIA_IOC_ENUM_ENTITIES: - ret = media_device_enum_entities(dev, - (struct media_entity_desc *)karg); - break; - - case MEDIA_IOC_ENUM_LINKS: - ret = media_device_enum_links(dev, - (struct media_links_enum *)karg); - break; - - case MEDIA_IOC_SETUP_LINK: - ret = media_device_setup_link(dev, - (struct media_link_desc *)karg); - break; - - case MEDIA_IOC_G_TOPOLOGY: - ret = media_device_get_topology(dev, - (struct media_v2_topology *)karg); - break; - - default: - ret = -ENOIOCTLCMD; - } + ret = info->fn(dev, karg); mutex_unlock(&dev->graph_mutex); if (!ret && copy_to_user((void *)arg, karg, _IOC_SIZE(cmd))) -- 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
[PATCH 1/3] media: Determine early whether an IOCTL is supported
Preparation for refactoring media IOCTL handling to unify common parts. Signed-off-by: Sakari Ailus --- drivers/media/media-device.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c index 898a3cf..6d3ee5c 100644 --- a/drivers/media/media-device.c +++ b/drivers/media/media-device.c @@ -419,6 +419,20 @@ static long media_device_get_topology(struct media_device *mdev, return 0; } +#define MEDIA_IOC(__cmd) \ + [_IOC_NR(MEDIA_IOC_##__cmd)] = { .cmd = MEDIA_IOC_##__cmd } + +/* the table is indexed by _IOC_NR(cmd) */ +static struct { + unsigned int cmd; +} media_ioctl_info[] = { + MEDIA_IOC(DEVICE_INFO), + MEDIA_IOC(ENUM_ENTITIES), + MEDIA_IOC(ENUM_LINKS), + MEDIA_IOC(SETUP_LINK), + MEDIA_IOC(G_TOPOLOGY), +}; + static long media_device_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { @@ -426,6 +440,10 @@ static long media_device_ioctl(struct file *filp, unsigned int cmd, struct media_device *dev = to_media_device(devnode); long ret; + if (_IOC_NR(cmd) >= ARRAY_SIZE(media_ioctl_info) + || media_ioctl_info[_IOC_NR(cmd)].cmd != cmd) + return -ENOIOCTLCMD; + mutex_lock(&dev->graph_mutex); switch (cmd) { case MEDIA_IOC_DEVICE_INFO: -- 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
[PATCH 0/3] Refactor media IOCTL handling
A number of years ago when someone (read: Laurent) added a new IOCTL to the MC interface, I wanted IOCTL handling to be refactored. That wasn't done however, so here are patches to do just that: there are too many IOCTLs that copy the argument struct from the user and back. The changes will also make the request API patches a little bit cleaner as the argument copying is removed there. I'll post an RFC set on those in the near future. -- Kind regards, Sakari -- 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: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi Hans and Pavel, On Fri, Apr 29, 2016 at 09:31:51AM +0200, Hans Verkuil wrote: > On 04/29/2016 09:15 AM, Pavel Machek wrote: > > Hi! > > > >> On n900, probe finishes ok (verified by adding printks), and the > >> device shows up in /sys, but I don't get /dev/video* or > >> /dev/v4l-subdev*. > >> > >> Other drivers (back and front camera) load ok, and actually work. Any > >> idea what could be wrong? > > > > Ok, so I guess I realized what is the problem: > > > > adp1653 registers itself as a subdev, but there's no device that > > register it as its part. > > > > (ad5820 driver seems to have the same problem). > > > > Is there example "dummy" device I could use, for sole purpose of > > having these devices appear in /dev? They are on i2c, so both can work > > on their own. > > Ah, interesting. This was discussed a little bit during the Media Summit > a few weeks back: > > http://linuxtv.org/news.php?entry=2016-04-20.mchehab > > See section 5: > > "5. DT Bindings for flash & lens controllers > > There are drivers that create their MC topology using the device tree > information, > which works great for entities that transport data, but how to detect entities > that don’t transport data such as flash devices, focusers, etc.? How can > those be > deduced using the device tree? > > Sensor DT node add phandle to focus controller: add generic v4l binding > properties > to reference such devices." > > This wasn't a problem with the original N900 since that didn't use DT AFAIK > and > these devices were loaded explicitly through board code. > > But now you run into the same problem that I have. > > The solution is that sensor devices have to provide phandles to those > controller > devices. And to do that you need to define bindings which is always the hard > part. > > Look in Documentation/devicetree/bindings/media/video-interfaces.txt, section > "Optional endpoint properties". > > Something like: > > controllers: an array of phandles to controller devices associated with this > endpoint such as flash and lens controllers. > > Warning: I'm no DT expert, so this is just a first attempt. > > Platform drivers (omap3isp) will have to add these controller devices to the > list > of subdevs to load asynchronously. I seem to have patches I haven't had time to push back then: http://salottisipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/leds-as3645a> This seems to be mostly in line with what has been discussed in the meeting, except that the patches add a device specific property. Please ignore the led patches in that tree for now (i.e. four patches on the top are the relevant ones here). -- 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
Re: [RFC PATCH 01/24] V4L fixes
Hi Ivaylo, On Mon, Apr 25, 2016 at 07:32:50PM +0300, Ivaylo Dimitrov wrote: > Hi, > > On 25.04.2016 16:25, Sakari Ailus wrote: > >Hi Ivaylo, > > > >Thanks for the set! > > > >On Mon, Apr 25, 2016 at 12:08:01AM +0300, Ivaylo Dimitrov wrote: > >>From: "Tuukka.O Toivonen" > >> > >>Squashed from the following upstream commits: > >> > >>V4L: Create control class for sensor mode > >>V4L: add ad5820 focus specific custom controls > >>V4L: add V4L2_CID_TEST_PATTERN > >>V4L: Add V4L2_CID_MODE_OPSYSCLOCK for reading output system clock > >> > >>Signed-off-by: Tuukka Toivonen > >>Signed-off-by: Pali Rohár > >>--- > >> include/uapi/linux/v4l2-controls.h | 17 + > >> 1 file changed, 17 insertions(+) > >> > >>diff --git a/include/uapi/linux/v4l2-controls.h > >>b/include/uapi/linux/v4l2-controls.h > >>index b6a357a..23011cc 100644 > >>--- a/include/uapi/linux/v4l2-controls.h > >>+++ b/include/uapi/linux/v4l2-controls.h > >>@@ -62,6 +62,7 @@ > >> #define V4L2_CTRL_CLASS_FM_RX 0x00a1 /* FM Receiver > >> controls */ > >> #define V4L2_CTRL_CLASS_RF_TUNER 0x00a2 /* RF tuner controls */ > >> #define V4L2_CTRL_CLASS_DETECT0x00a3 /* Detection > >> controls */ > >>+#define V4L2_CTRL_CLASS_MODE 0x00a4 /* Sensor mode > >>information */ > >> > >> /* User-class control IDs */ > >> > >>@@ -974,4 +975,20 @@ enum v4l2_detect_md_mode { > >> #define V4L2_CID_DETECT_MD_THRESHOLD_GRID (V4L2_CID_DETECT_CLASS_BASE + 3) > >> #define V4L2_CID_DETECT_MD_REGION_GRID > >> (V4L2_CID_DETECT_CLASS_BASE + 4) > >> > >>+/* SMIA-type sensor information */ > >>+#define V4L2_CID_MODE_CLASS_BASE (V4L2_CTRL_CLASS_MODE | 0x900) > >>+#define V4L2_CID_MODE_CLASS(V4L2_CTRL_CLASS_MODE | > >>1) > >>+#define V4L2_CID_MODE_FRAME_WIDTH (V4L2_CID_MODE_CLASS_BASE+1) > >>+#define V4L2_CID_MODE_FRAME_HEIGHT (V4L2_CID_MODE_CLASS_BASE+2) > >>+#define V4L2_CID_MODE_VISIBLE_WIDTH > >>(V4L2_CID_MODE_CLASS_BASE+3) > >>+#define V4L2_CID_MODE_VISIBLE_HEIGHT > >>(V4L2_CID_MODE_CLASS_BASE+4) > > > >The interface here pre-dates the selection API. The frame width and height > >is today conveyed to the bridge driver by the smiapp driver in the scaler > >(or binner in case of the lack of the scaler) sub-device's source pad > >format. > > > >(While that's the current interface, I'm not entirely happy with it; it > >requires more sub-devices to be created for the same I2C device). I think in > >this case you'd need one more to properly control the sensor. > > > > By looking at the code, it seems those are read-only, so I don't think it > make sense to add a binner sub-device with read-only controls. Well, I can't disagree with that. However, I think a number of other drivers would benefit from doing this properly --- the V4L2 selection API which defines a strict order for the processing steps does not suit to this use case very well. You could use the crop selection rectangle for now, albeit that doesn't fully express what the sensor does, or use private controls. We could then later replace this with something better. > > >>+#define V4L2_CID_MODE_PIXELCLOCK (V4L2_CID_MODE_CLASS_BASE+5) > >>+#define V4L2_CID_MODE_SENSITIVITY (V4L2_CID_MODE_CLASS_BASE+6) > >>+#define V4L2_CID_MODE_OPSYSCLOCK (V4L2_CID_MODE_CLASS_BASE+7) > > > >While I don't remember quite what the sensitivity value was about (it could > >be e.g. binning summing / averaging), the other two values are passed to > >(and also controlled by) the user space using controls. There are > >V4L2_CID_PIXEL_RATE and V4L2_CID_LINK_FREQ or such. > > > > I've already made a change so V4L2_CID_PIXEL_RATE is used in et8ek8 driver > (https://github.com/freemangordon/linux-n900/commit/54433e50451b4ed6cc6e3b25d149c5cacd97e438), > but V4L2_CID_MODE_PIXELCLOCK is used in smiapp driver, which seems to expose > its own controls. Not sure those are needed though. And if, what for. I hope > you know better than me. It's needed to tell the sensor timings to the user space. The camera control algorithms need that information. > > I guess V4L2_CID_MODE_OPSYSCLOCK can be easily transformed to > V4L2_CID_LINK_FREQ in the same way as V4L2_CID_MODE_PIXELCLOCK. Yes. > > >>+ > >>+/* Control IDs specific to the AD5820 driver as defined by V4L2 */ > >>+#define V4L2_CID_FOCUS_AD5820_BASE (V4L2_CTRL_CLASS_CAMERA > >>| 0x10af) > >>+#define V4L2_CID_FOCUS_AD5820_RAMP_TIME > >>(V4L2_CID_FOCUS_AD5820_BASE+0) > >>+#define V4L2_CID_FOCUS_AD5820_RAMP_MODE > >>(V4L2_CID_FOCUS_AD5820_BASE+1) > > > >The ad5820 driver isn't in upstream at the moment. It should be investigated > >whether there is a possibility to have standard V4L2 controls for lens > >devices, or whether device specific controls should be implemented instead. > >Device specific controls are a safe choice in this case, but the
Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
On 04/29/2016 09:15 AM, Pavel Machek wrote: > Hi! > >> On n900, probe finishes ok (verified by adding printks), and the >> device shows up in /sys, but I don't get /dev/video* or >> /dev/v4l-subdev*. >> >> Other drivers (back and front camera) load ok, and actually work. Any >> idea what could be wrong? > > Ok, so I guess I realized what is the problem: > > adp1653 registers itself as a subdev, but there's no device that > register it as its part. > > (ad5820 driver seems to have the same problem). > > Is there example "dummy" device I could use, for sole purpose of > having these devices appear in /dev? They are on i2c, so both can work > on their own. Ah, interesting. This was discussed a little bit during the Media Summit a few weeks back: http://linuxtv.org/news.php?entry=2016-04-20.mchehab See section 5: "5. DT Bindings for flash & lens controllers There are drivers that create their MC topology using the device tree information, which works great for entities that transport data, but how to detect entities that don’t transport data such as flash devices, focusers, etc.? How can those be deduced using the device tree? Sensor DT node add phandle to focus controller: add generic v4l binding properties to reference such devices." This wasn't a problem with the original N900 since that didn't use DT AFAIK and these devices were loaded explicitly through board code. But now you run into the same problem that I have. The solution is that sensor devices have to provide phandles to those controller devices. And to do that you need to define bindings which is always the hard part. Look in Documentation/devicetree/bindings/media/video-interfaces.txt, section "Optional endpoint properties". Something like: controllers: an array of phandles to controller devices associated with this endpoint such as flash and lens controllers. Warning: I'm no DT expert, so this is just a first attempt. Platform drivers (omap3isp) will have to add these controller devices to the list of subdevs to load asynchronously. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking
> Yes, obviously... I'll make that change locally and wait for the rest. Another nit: You could use '--strict' with checkpatch and see if you want to fix the issues reported. I am not keen on those (except for 'space around operators'), it's a matter of taste I guess, but maybe you like some of the suggestions. Thanks, Wolfram signature.asc Description: PGP signature
v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*
Hi! > On n900, probe finishes ok (verified by adding printks), and the > device shows up in /sys, but I don't get /dev/video* or > /dev/v4l-subdev*. > > Other drivers (back and front camera) load ok, and actually work. Any > idea what could be wrong? Ok, so I guess I realized what is the problem: adp1653 registers itself as a subdev, but there's no device that register it as its part. (ad5820 driver seems to have the same problem). Is there example "dummy" device I could use, for sole purpose of having these devices appear in /dev? They are on i2c, so both can work on their own. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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