[PATCH 2/2] solo6x10: Simplify solo_enum_ext_input

[Ismael Luceno]

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

[Ismael Luceno]

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(_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

[Hans Verkuil]

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)

[Akihiro TSUKADA]

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)

[Ivaylo Dimitrov]

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

[Shuah Khan]

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(>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(>devnode->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(>kobj, _devnode_ktype);
+
/* Part 2: Initialize and register the character device */
cdev_init(>cdev, 

Re: camera application for testing (was Re: v4l subdevs without big device)

[Pali Rohár]

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)

[Pavel Machek]

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*)

[Pavel Machek]

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 = <_pins>;
+   ti,camera-flashes = <   >;
 
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 = <>;
+
+   #io-channel-cells = <0>;
+   };
 };
 
  {
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
+ */
+

Re: [RFC PATCH 00/24] Make Nokia N900 cameras working

[Ivaylo Dimitrov]

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

[Sebastian Reichel]

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

[Shuah Khan]

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(_devnode_lock);
return -ENXIO;
}
 +
 +  kobject_get(>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(>dev);
mutex_unlock(_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 _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(>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(>dev) and device_del() deletes the dev->kobj

In other words, devnode->dev lifetime is going to be within
device_register(>dev) and 

[PATCH] [media] em28xx_dvb: add support for PLEX PX-BCUD (ISDB-S usb dongle)

[Satoshi Nagahama]

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, );
-   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},
+   

Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*

[Pavel Machek]

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 = <_pins>;
+   ti,camera-flashes = < >;
 
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 = >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, );
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] = >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)
+   return -EINVAL;
 
-

Re: [PATCH v2] media: vb2-dma-contig: configure DMA max segment size properly

[Sakari Ailus]

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

[Hans Verkuil]

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

[Hans Verkuil]

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
+++ 

[PATCHv16 09/13] cec: adv7604: add cec support.

[Hans Verkuil]

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 = 

[PATCHv16 07/13] cec.txt: add CEC framework documentation

[Hans Verkuil]

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 

[PATCHv16 12/13] cec: s5p-cec: Add s5p-cec driver

[Hans Verkuil]

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 = < CLK_HDMI_CEC>;
+   clock-names = "hdmicec";
+   samsung,syscon-phandle = <_system_controller>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_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 

[PATCHv16 11/13] cec: adv7511: add cec support.

[Hans Verkuil]

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 = 

[PATCHv16 05/13] cec/TODO: add TODO file so we know why this is still in staging

[Hans Verkuil]

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

[Hans Verkuil]

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 == 

[PATCHv16 08/13] DocBook/media: add CEC documentation

[Hans Verkuil]

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 

[PATCHv16 00/13] HDMI CEC framework

[Hans Verkuil]

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 

[PATCHv16 02/13] HID: add HDMI CEC specific keycodes

[Hans Verkuil]

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

[Hans Verkuil]

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 03/13] rc: Add HDMI CEC protocol handling

[Hans Verkuil]

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 

[PATCHv16 01/13] input.h: add BUS_CEC type

[Hans Verkuil]

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

Re: [RFC PATCH 12/24] dt: bindings: Add CSI1/CCP2 related properties to video-interfaces.txt

[Pavel Machek]

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

[Pavel Machek]

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

[Pavel Machek]

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

[Pavel Machek]

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

[Peter Ujfalusi]

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, , 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 = _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

[Nick Dyer]

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(>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

[Sakari Ailus]

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

[Rob Clark]

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

[Marek Szyprowski]

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 Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe 

Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*

[Sakari Ailus]

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

[Sakari Ailus]

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

[Hans Verkuil]

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)

Re: [GIT PULL] two patches: pipeline validation error code

[Mauro Carvalho Chehab]

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*

[Pali Rohár]

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*

[Sakari Ailus]

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:
> > 
> > 
> >
> 
> 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

[Hans Verkuil]

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*

[Pavel Machek]

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:
> 
> 
> 
> 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 = <>;
+			focus = <>;			
 		};
 	};
 
@@ -198,6 +199,11 @@
 		};
 	};
 
+	autofocus: dac-camera-autofocus {
+		compatible = "dac-camera-autofocus";
+		io-channels = <>;
+	};
+
 	video-bus-switch {
 		compatible = "video-bus-switch";
 
@@ -255,6 +261,11 @@
 crc = <0>;
 			};
 		};
+		port@99 {
+			adp1653_link: endpoint {
+  remote-endpoint = <_ep>;
+			};
+		};
 	};
 };
 
@@ -696,6 +707,11 @@
 		indicator {
 			led-max-microamp = <17500>;
 		};
+		port {
+			adp1653_ep: endpoint {
+   remote-endpoint = <_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>;
+	};
 };
 
  {
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 = _internal_ops;
 
-	ret = media_entity_init(>subdev.entity, 0, NULL, 0);
+	ret = media_entity_pads_init(>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(>subdev, client, _ops);
 	flash->subdev.internal_ops = _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(>dev, "adp1653 probe: should be ok\n");		
+	dev_info(>dev, "adp1653 probe: should be ok\n");
+
+	ret = v4l2_async_register_subdev(>subdev);
+	if (ret < 0)
+		goto free_and_quit;
+
+	dev_info(>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(>v4l2_dev, >notifier);
 	if (ret)
 		goto error_register_entities;
+===
+	if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
+		isp->notifier.bound = isp_subdev_notifier_bound;
+		

Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*

[Pavel Machek]

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:
> 
> 
>

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 2/3] omap4: add CEC support

[Hans Verkuil]

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 */
 _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 */
 _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_INIT 

[RFC PATCH 1/3] drm/omap: fix OMAP4 hdmi_core_powerdown_disable()

[Hans Verkuil]

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 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

[Hans Verkuil]

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

[Hans Verkuil]

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

[Stanimir Varbanov]

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

[Peter Rosin]

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

[Sakari Ailus]

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(, 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, , 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(_ent, 0, sizeof(u_ent));
-   if (copy_from_user(_ent.id, >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(_ent.raw, >info, sizeof(ent->info));
-   if (copy_to_user(uent, _ent, sizeof(u_ent)))
-   return -EFAULT;
+   memcpy(>raw, >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)
 {
struct 

[PATCH 0/3] Refactor media IOCTL handling

[Sakari Ailus]

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

[PATCH 3/3] media: Refactor IOCTL handler calling

[Sakari Ailus]

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 = _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(>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(>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

[Sakari Ailus]

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(>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

Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*

[Sakari Ailus]

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:



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

[Sakari Ailus]

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 

Re: v4l subdevs without big device was Re: drivers/media/i2c/adp1653.c: does not show as /dev/video* or v4l-subdev*

[Hans Verkuil]

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

[Wolfram Sang]

> 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*

[Pavel Machek]

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

Re: [PATCH v7 22/24] [media] rtl2832: change the i2c gate to be mux-locked

[Wolfram Sang]

> So, I think all is ok, or do you need more than Tested-by?

I think this will do. Thanks!



signature.asc
Description: PGP signature