[GIT PULL FOR v4.12] cec kernel config fixes

From the cover letter of the patch series: While working on drm CEC drivers I realized that the correct config setup is a pain. The problem is that the CEC subsystem is really independent of the media subsystem: both media and drm drivers can use it. So this patch series moves the core CEC

cron job: media_tree daily build: ERRORS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon May 29 05:00:31 CEST 2017 media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030 media_build

Re: [PATCH v3 1/1] [media] i2c: add support for OV13858 sensor

Hi Hyungwoo, On Mon, May 29, 2017 at 8:26 AM, Yang, Hyungwoo wrote: > > Hi Sakari, > > Here's my comments. > > -Hyungwoo > > > -Original Message- >> From: Sakari Ailus [mailto:sakari.ai...@iki.fi] >> Sent: Saturday, May 27, 2017 1:31 PM >> To: Yang, Hyungwoo

Re: [PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

Hi Wolfram Thankyou for the fixup On 28/05/17 18:30, Wolfram Sang wrote: > It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. > > Signed-off-by: Wolfram Sang Acked-by: Kieran Bingham

RE: [PATCH v3 1/1] [media] i2c: add support for OV13858 sensor

Hi Sakari, Here's my comments. -Hyungwoo -Original Message- > From: Sakari Ailus [mailto:sakari.ai...@iki.fi] > Sent: Saturday, May 27, 2017 1:31 PM > To: Yang, Hyungwoo > Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian Xu >

Re: [PATCH 00/19] cxd2841er/ddbridge: support Sony CXD28xx hardware

Am Sun, 9 Apr 2017 21:38:09 +0200 schrieb Daniel Scheller : > Important note: This series depends on the stv0367/ddbridge series > posted earlier (patches 12 [1] and 13 [2], depending on the I2C > functions and the TDA18212 attach function). > > This series improves

Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware

Am Sun, 7 May 2017 17:42:12 +0200 schrieb Daniel Scheller : > Am Wed, 12 Apr 2017 21:23:27 +0200 > schrieb Daniel Scheller : > > > Am Wed, 29 Mar 2017 18:43:00 +0200 > > schrieb Daniel Scheller : > > > > > From:

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

Am Sun, 28 May 2017 21:06:33 +0200 schrieb Karl Wallin : All, > In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from: > "ret = cdev_device_add(>cdev, >dev);" to: > "ret = device_add(>dev);" > and row 186 from: > "cdev_device_del(>cdev, >dev);" to: >

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

On 28.05.2017 21:33, Karl Wallin wrote: Thanks for such a quick reply :) Of course *facepalm* should have thought of that "./build" downloads everything again and of course replaces my modified "cec-core.c". I ran "make" and ran into new problems: Ok so using logic I should do the same

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on > a global v2p8_gpio value rather then storing info in the gmin_subdev struct, > as such passing the subdev->dev pointer would be simply wrong. AFAICT the > v1p8 / v2p8 gpio code is the only caller passing in a NULL

Re: [PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

On Mon, 29 May 2017 02:06:41 +0800 Chen Guanqiao wrote: > Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings. > > Signed-off-by: Chen Guanqiao > --- Reviewed-by: Alan Cox

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

On 28.05.2017 21:06, Karl Wallin wrote: Hi Thomas, Thanks for the help (and to Vincent as well) :) In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from: "ret = cdev_device_add(>cdev, >dev);" to: "ret = device_add(>dev);" and row 186 from: "cdev_device_del(>cdev, >dev);" to:

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

Thanks for such a quick reply :) Of course *facepalm* should have thought of that "./build" downloads everything again and of course replaces my modified "cec-core.c". I ran "make" and ran into new problems: "Make" log: ubuntu@nuc-d54250wyk:~/media_build$ make make -C

Re: Build fails Ubuntu 17.04 / "error: implicit declaration of function"

Hi Thomas, Thanks for the help (and to Vincent as well) :) In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from: "ret = cdev_device_add(>cdev, >dev);" to: "ret = device_add(>dev);" and row 186 from: "cdev_device_del(>cdev, >dev);" to: "device_del(>dev);" Even if I do that when I

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

Hi, On 28-05-17 19:08, Alan Cox wrote: On Sun, 28 May 2017 14:30:35 +0200 Hans de Goede wrote: Do not call dev_warn with a NULL device, this silence the following 2 warnings: [ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO [ 14.392257] (NULL

[PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings. Signed-off-by: Chen Guanqiao --- drivers/staging/media/atomisp/i2c/lm3554.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[2/7/] staging: atomisp: Do not call dev_warn with a NULL device

>On Sun, May 28, 2017 at 3:31 PM, Hans de Goede wrote: >> Do not call dev_warn with a NULL device, this silence the following 2 >> warnings: >> >> [ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO >> [ 14.392257] (NULL device *): Failed to find gmin

[GIT PULL FOR v4.13] RC fixes

Hi Mauro, Just minor cleanups and fixes this time round. Thanks, Sean The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030: [media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update() (2017-05-19 07:12:05 -0300) are available in the git repository at:

[PATCH] [media] rc-core: simplify ir_raw_event_store_edge()

There is no need to called ir_raw_event_reset() either after a long space or on startup. Many rc drivers never do this. Signed-off-by: Sean Young --- drivers/media/pci/saa7134/saa7134-input.c | 2 +- drivers/media/rc/gpio-ir-recv.c | 6 +++---

Re: [PATCH 13/16] lirc_dev: use an ida instead of a hand-rolled array to keep track of minors

On Sun, May 28, 2017 at 10:26:59AM +0200, David Härdeman wrote: > On Mon, May 22, 2017 at 09:09:42PM +0100, Sean Young wrote: > >On Mon, May 01, 2017 at 06:04:42PM +0200, David Härdeman wrote: > >> Using the kernel ida facilities, we can avoid a lot of unnecessary code > >> and at the same > >>

Re: [PATCH 03/16] lirc_dev: correct error handling

On Sun, May 28, 2017 at 10:23:37AM +0200, David Härdeman wrote: > On Sun, May 21, 2017 at 09:57:13AM +0100, Sean Young wrote: > >On Mon, May 01, 2017 at 06:03:51PM +0200, David Härdeman wrote: > >> If an error is generated, nonseekable_open() shouldn't be called. > > > >There is no harm in calling

Re: [PATCH RESEND2] [media] usbtv: add a new usbid

在 2017-04-16 14:51，Icenowy Zheng 写道： A new usbid of UTV007 is found in a newly bought device. The usbid is 1f71:3301. The ID on the chip is: UTV007 A89029.1 1520L18K1 Both video and audio is tested with the modified usbtv driver. Signed-off-by: Icenowy Zheng Acked-by:

Re: [PATCH 2/7] staging: atomisp: Do not call dev_warn with a NULL device

On Sun, May 28, 2017 at 3:31 PM, Hans de Goede wrote: > Do not call dev_warn with a NULL device, this silence the following 2 > warnings: > > [ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO > [ 14.392257] (NULL device *): Failed to find gmin

[PATCH 7/7] staging: atomisp: Make ov2680 driver less chatty

There is no reason for all this printk spamming and certainly not at an error log level. Signed-off-by: Hans de Goede --- drivers/staging/media/atomisp/i2c/ov2680.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

[PATCH 6/7] staging: atomisp: Ignore errors from second gpio in ov2680 driver

As the existing comment in the driver indicates the sensor has only 1 pin, but some boards may have 2 gpios defined and we toggle both as we we don't know which one is the right one. However if the ACPI resources table defines only 1 gpio (as expected) the gpio1_ctrl call will always fail, causing

[PATCH 1/7] staging: atomisp: Fix calling efivar_entry_get() with unaligned arguments

efivar_entry_get has certain alignment requirements and the atomisp platform code was not honoring these, causing an oops by triggering the WARN_ON in arch/x86/platform/efi/efi_64.c: virt_to_phys_or_null_size(). This commit fixes this by using the members of the efivar struct embedded in the

[PATCH 2/7] staging: atomisp: Do not call dev_warn with a NULL device

Do not call dev_warn with a NULL device, this silence the following 2 warnings: [ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO [ 14.392257] (NULL device *): Failed to find gmin variable gmin_V1P8GPIO We could switch to using pr_warn for dev == NULL instead, but as

[PATCH 3/7] staging: atomisp: Set step to 0 for mt9m114 menu control

menu controls are not allowed to have a step size, set step to 0 to fix an oops from the WARN_ON in v4l2_ctrl_new_custom() triggering because of this. Signed-off-by: Hans de Goede --- drivers/staging/media/atomisp/i2c/mt9m114.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 5/7] staging: atomisp: Add OVTI2680 ACPI id to ov2680 driver

Signed-off-by: Hans de Goede --- drivers/staging/media/atomisp/i2c/ov2680.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c b/drivers/staging/media/atomisp/i2c/ov2680.c index 566091035c64..449aa2aa276f 100644 ---

[PATCH 4/7] staging: atomisp: Add INT0310 ACPI id to gc0310 driver

Signed-off-by: Hans de Goede --- drivers/staging/media/atomisp/i2c/gc0310.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/atomisp/i2c/gc0310.c b/drivers/staging/media/atomisp/i2c/gc0310.c index 1ec616a15086..350fd7fd5b86 100644 ---

Firmware for staging atomisp driver

Hi All, I've been trying to get the atomisp driver from staging to work on a couple of devices I have. I started with an Asus T100TA after fixing 2 oopses in the sensor driver there I found out that the BIOS does not allow to put the ISP in PCI mode and that there is no code to drive it in ACPI

[PATCH for v4.12 1/3] cec: select CEC_CORE instead of depend on it

From: Hans Verkuil The CEC framework is used by both drm and media. That makes it tricky to get the dependencies right. This patch moves the CEC_CORE and MEDIA_CEC_NOTIFIER config options out of the media menu and instead drivers that want to use CEC should select

[PATCH for v4.12 0/3] cec: more kernel config cleanups

From: Hans Verkuil While working on drm CEC drivers I realized that the correct config setup is a pain. The problem is that the CEC subsystem is really independent of the media subsystem: both media and drm drivers can use it. So this patch series moves the core CEC

[PATCH for v4.12 3/3] cec: drop MEDIA_CEC_DEBUG

From: Hans Verkuil Just depend on DEBUG_FS, no need to invent a new kernel config. Especially since CEC can be enabled by drm without enabling MEDIA_SUPPORT. Signed-off-by: Hans Verkuil --- drivers/media/cec/Kconfig| 6 --

[PATCH for v4.12 2/3] cec: rename MEDIA_CEC_NOTIFIER to CEC_NOTIFIER

From: Hans Verkuil This config option is strictly speaking independent of the media subsystem since it can be used by drm as well. Besides, it looks odd when drivers select CEC_CORE and MEDIA_CEC_NOTIFIER, that's inconsistent naming. Signed-off-by: Hans Verkuil

[PATCH 0/7] tree-wide: use proper 'R-Car' product name

Small series to get the R-Car product name proper. Based on renesas-drivers/master, but can be applied to current linus/master as well. Except for the MMC patch, which depends on mmc/next. Please apply. Wolfram Sang (7): dmaengine: use proper name for the R-Car SoC i2c: use proper name for

[PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. Signed-off-by: Wolfram Sang --- I suggest this trivial patch should be picked individually per susbsystem. drivers/media/platform/rcar_fdp1.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH 6/7] [media] soc_camera: rcar_vin: use proper name for the R-Car SoC

It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. Signed-off-by: Wolfram Sang --- I suggest this trivial patch should be picked individually per susbsystem. Documentation/devicetree/bindings/media/rcar_vin.txt | 4 ++-- 1 file

Re: [PATCH 5/7] rc-core: ir-raw - leave the internals of rc_dev alone

On Tue, May 23, 2017 at 10:20:27AM +0100, Sean Young wrote: >On Mon, May 01, 2017 at 06:10:17PM +0200, David Härdeman wrote: >> Replace the REP_DELAY value with a static value, which makes more sense. >> Automatic repeat handling in the input layer has no relevance for the drivers >> idea of "a

Re: [PATCH 3/7] rc-core: img-nec-decoder - leave the internals of rc_dev alone

On Mon, May 22, 2017 at 09:40:30PM +0100, Sean Young wrote: >On Mon, May 01, 2017 at 06:10:06PM +0200, David Härdeman wrote: >> Obvious fix, leave repeat handling to rc-core >> >> Signed-off-by: David Härdeman >> --- >> drivers/media/rc/ir-nec-decoder.c | 10 +++--- >>

Re: [PATCH 13/16] lirc_dev: use an ida instead of a hand-rolled array to keep track of minors

On Mon, May 22, 2017 at 09:09:42PM +0100, Sean Young wrote: >On Mon, May 01, 2017 at 06:04:42PM +0200, David Härdeman wrote: >> Using the kernel ida facilities, we can avoid a lot of unnecessary code and >> at the same >> time get rid of lirc_dev_lock in favour of per-device locks (the irctls >>

Re: [PATCH 03/16] lirc_dev: correct error handling

On Sun, May 21, 2017 at 09:57:13AM +0100, Sean Young wrote: >On Mon, May 01, 2017 at 06:03:51PM +0200, David Härdeman wrote: >> If an error is generated, nonseekable_open() shouldn't be called. > >There is no harm in calling nonseekable_open(), so this commit is >misleading. I'm not sure why you