cron job: media_tree daily build: ERRORS

[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:   Thu Apr 20 05:00:17 CEST 2017
media-tree git hash:9eb9db3a0f92b75ec710066202e0b2accb45afa9
media_build git hash:   1af19680bde3e227d64d99ff5fdc43eb343a3b28
v4l-utils git hash: b514d615166bdc0901a4c71261b87db31e89f464
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
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: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
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: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Laura Abbott]

On 04/19/2017 12:36 PM, Logan Gunthorpe wrote:

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 
---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

  drivers/dma-buf/dma-buf.c  | 16 
  drivers/gpu/drm/armada/armada_gem.c|  8 
  drivers/gpu/drm/drm_prime.c|  8 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
  drivers/gpu/drm/tegra/gem.c|  8 
  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
  drivers/staging/android/ion/ion.c  |  8 
  include/linux/dma-buf.h| 22 +++---
  14 files changed, 61 insertions(+), 61 deletions(-)



For Ion,

Acked-by: Laura Abbott 

I did some major Ion refactoring but I don't think this
will conflict.

Thanks,
Laura

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

Hi Russell, and Marek,

On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote:
> On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
 This would be however quite large task, especially taking into account
 all current users of DMA-buf framework...
>>> Yeah it will be a large task.
>>
>> Maybe once scatterlist are switched to pfns, changing dmabuf internal
>> memory representation to pfn array might be much easier.
> 
> Switching to a PFN array won't work either as we have no cross-arch
> way to translate PFNs to a DMA address and vice versa.  Yes, we have
> them in ARM, but they are an _implementation detail_ of ARM's
> DMA API support, they are not for use by drivers.
> 
> So, the very first problem that needs solving is this:
> 
>   How do we go from a coherent DMA allocation for device X to a set
>   of DMA addresses for device Y.
> 
> Essentially, we need a way of remapping the DMA buffer for use with
> another device, and returning a DMA address suitable for that device.
> This could well mean that we need to deal with setting up an IOMMU
> mapping.  My guess is that this needs to happen at the DMA coherent
> API level - the DMA coherent API needs to be augmented with support
> for this.  I'll call this "DMA coherent remap".
> 
> We then need to think about how to pass this through the dma-buf API.
> dma_map_sg() is done by the exporter, who should know what kind of
> memory is being exported.  The exporter can avoid calling dma_map_sg()
> if it knows in advance that it is exporting DMA coherent memory.
> Instead, the exporter can simply create a scatterlist with the DMA
> address and DMA length prepopulated with the results of the DMA
> coherent remap operation above.

As Russell pointed to armama-drm case, I looked at that closely.
armada-drm is creating sg_table and populating it with DMA-address in
its map_dma_buf ops and unmap_dma_buf ops handles the special case and
doesn't call dma_unmap_sg().

In the case of drm, gem_prime_map_dma_buf interfaces and the common
drm_gem_map_dma_buf() will need modification to not do dma_map_sg()
and create scatterlist with the DMA address and DMA length instead.
We have to get drm_gem_map_dma_buf() info. to have it not do dma_map_sg()
and create scatterlist.

Focusing on drm for now, looks like there are probably about 15 or so
map_dma_buf interfaces will need to handle coherent memory case.

> 
> What the scatterlist can't carry in this case is a set of valid
> struct page pointers, and an importer must not walk the scatterlist
> expecting to get at the virtual address parameters or struct page
> pointers.

Right - importers need handling to not walk the sg_list and handle
it differently. Is there a good example drm you can point me to for
this? aramda-drm seems to special case this in armada_gem_map_import()
if I am not mistaken.

> 
> On the mmap() side of things, remember that DMA coherent allocations
> may require special mapping into userspace, and which can only be
> mapped by the DMA coherent mmap support.  kmap etc will also need to
> be different.  So it probably makes sense for DMA coherent dma-buf
> exports to use a completely separate set of dma_buf_ops from the
> streaming version.
> 

I agree. It would make is easier and also limits the scope of changes.

> I think this is the easiest approach to solving the problem without
> needing massive driver changes all over the kernel.
> 

Anyway this is a quick note to say that I am looking into this and
haven't drooped it :)

thanks,
-- Shuah

[PATCH 03/12] au8522: rework setup of audio routing

[Devin Heitmueller]

The original code was based on my reverse engineering of an I2C trace
of the Windows driver.  Now that I know what the registers actually do,
restructure the code a bit, removing some unneeded register programming
and fixing the sequencing of operations.

This reduces the time it takes to change inputs from 1300ms down to
600ms (as measured by "time v4l2-ctl -i 0")

Note this does not address outstanding issues related to the management
of the module clocks and power control for the various blocks, which
will be done in a separate patch.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_decoder.c | 29 ++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/media/dvb-frontends/au8522_decoder.c 
b/drivers/media/dvb-frontends/au8522_decoder.c
index 7811717..281b5ac 100644
--- a/drivers/media/dvb-frontends/au8522_decoder.c
+++ b/drivers/media/dvb-frontends/au8522_decoder.c
@@ -418,28 +418,29 @@ static void set_audio_input(struct au8522_state *state)
lpfilter_coef[i].reg_val[0]);
}
 
-   /* Setup audio */
-   au8522_writereg(state, AU8522_AUDIO_VOLUME_L_REG0F2H, 0x00);
-   au8522_writereg(state, AU8522_AUDIO_VOLUME_R_REG0F3H, 0x00);
-   au8522_writereg(state, AU8522_AUDIO_VOLUME_REG0F4H, 0x00);
-   msleep(150);
-   au8522_writereg(state, AU8522_SYSTEM_MODULE_CONTROL_0_REG0A4H, 0x00);
-   msleep(10);
-   au8522_writereg(state, AU8522_SYSTEM_MODULE_CONTROL_0_REG0A4H,
-   AU8522_SYSTEM_MODULE_CONTROL_0_REG0A4H_CVBS);
-   msleep(50);
+   /* Set the volume */
au8522_writereg(state, AU8522_AUDIO_VOLUME_L_REG0F2H, 0x7F);
au8522_writereg(state, AU8522_AUDIO_VOLUME_R_REG0F3H, 0x7F);
au8522_writereg(state, AU8522_AUDIO_VOLUME_REG0F4H, 0xff);
-   msleep(80);
-   au8522_writereg(state, AU8522_AUDIO_VOLUME_L_REG0F2H, 0x7F);
-   au8522_writereg(state, AU8522_AUDIO_VOLUME_R_REG0F3H, 0x7F);
+
+   /* Not sure what this does */
au8522_writereg(state, AU8522_REG0F9H, AU8522_REG0F9H_AUDIO);
+
+   /* Setup the audio mode to stereo DBX */
au8522_writereg(state, AU8522_AUDIO_MODE_REG0F1H, 0x82);
msleep(70);
-   au8522_writereg(state, AU8522_SYSTEM_MODULE_CONTROL_1_REG0A5H, 0x09);
+
+   /* Start the audio processing module */
+   au8522_writereg(state, AU8522_SYSTEM_MODULE_CONTROL_0_REG0A4H, 0x9d);
+
+   /* Set the audio frequency to 48 KHz */
au8522_writereg(state, AU8522_AUDIOFREQ_REG606H, 0x03);
+
+   /* Set the I2S parameters (WS, LSB, mode, sample rate */
au8522_writereg(state, AU8522_I2S_CTRL_2_REG112H, 0xc2);
+
+   /* Enable the I2S output */
+   au8522_writereg(state, AU8522_SYSTEM_MODULE_CONTROL_1_REG0A5H, 0x09);
 }
 
 /* --- */
-- 
1.9.1

[PATCH 09/12] xc5000: Don't spin waiting for analog lock

[Devin Heitmueller]

The xc5000 driver should not be spinning waiting for an analog lock.
The ioctl() should be returning immediately and the application is
responsible for polling for lock status.

This behavior isn't very visible in cases where you tune to a valid
channel, since lock is usually achieved much faster than 400ms.
However it is highly visible where doing things like changing video
standards, which sends tuning request for a frequency that is
almost never going to have an actual channel on it.

Also fixup the return values to treat zero as success and an actual
error code on error (to be consistent with other functions).  Note
this change has no practical effect at this time as none of the
callers inspect the return value.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/tuners/xc5000.c | 26 ++
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index e823aaf..e144627 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -565,38 +565,16 @@ static int xc_get_totalgain(struct xc5000_priv *priv, u16 
*totalgain)
return xc5000_readreg(priv, XREG_TOTALGAIN, totalgain);
 }
 
-static u16 wait_for_lock(struct xc5000_priv *priv)
-{
-   u16 lock_state = 0;
-   int watch_dog_count = 40;
-
-   while ((lock_state == 0) && (watch_dog_count > 0)) {
-   xc_get_lock_status(priv, _state);
-   if (lock_state != 1) {
-   msleep(5);
-   watch_dog_count--;
-   }
-   }
-   return lock_state;
-}
-
 #define XC_TUNE_ANALOG  0
 #define XC_TUNE_DIGITAL 1
 static int xc_tune_channel(struct xc5000_priv *priv, u32 freq_hz, int mode)
 {
-   int found = 0;
-
dprintk(1, "%s(%u)\n", __func__, freq_hz);
 
if (xc_set_rf_frequency(priv, freq_hz) != 0)
-   return 0;
-
-   if (mode == XC_TUNE_ANALOG) {
-   if (wait_for_lock(priv) == 1)
-   found = 1;
-   }
+   return -EREMOTEIO;
 
-   return found;
+   return 0;
 }
 
 static int xc_set_xtal(struct dvb_frontend *fe)
-- 
1.9.1

[PATCH 11/12] Fix breakage in "make menuconfig" for media_build

[Devin Heitmueller]

The Kconfig format is strict enough where if the indentation isn't
correct then the "make menuconfig" will break.

Fix the indentation to match all the other entries.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/rc/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index e422f3d..5e83b76 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -169,11 +169,11 @@ config IR_HIX5HD2
tristate "Hisilicon hix5hd2 IR remote control"
depends on RC_CORE
help
-Say Y here if you want to use hisilicon hix5hd2 remote control.
-To compile this driver as a module, choose M here: the module will be
-called ir-hix5hd2.
+  Say Y here if you want to use hisilicon hix5hd2 remote control.
+  To compile this driver as a module, choose M here: the module will be
+  called ir-hix5hd2.
 
-If you're not sure, select N here
+  If you're not sure, select N here
 
 config IR_IMON
tristate "SoundGraph iMON Receiver and Display"
-- 
1.9.1

[PATCH 10/12] au8522: Set the initial modulation

[Devin Heitmueller]

We need to set the initial modulation on driver setup, or else any
calls to GET_FRONTEND prior to the first SET_FRONTEND call will get
back garbage.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/dvb-frontends/au8522_common.c 
b/drivers/media/dvb-frontends/au8522_common.c
index cf4ac24..6722838 100644
--- a/drivers/media/dvb-frontends/au8522_common.c
+++ b/drivers/media/dvb-frontends/au8522_common.c
@@ -234,6 +234,7 @@ int au8522_init(struct dvb_frontend *fe)
   chip, so that when it gets powered back up it won't think
   that it is already tuned */
state->current_frequency = 0;
+   state->current_modulation = VSB_8;
 
au8522_writereg(state, 0xa4, 1 << 5);
 
-- 
1.9.1

[PATCH 02/12] au8522: don't touch i2c master registers on au8522

[Devin Heitmueller]

Some stray lines got inserted into the driver when I reverse engineered
the I2C traffic (at the time I didn't know what the registers did).

It turns up these registers muck with the onboard I2C master, which
we don't use since we instead use the I2C gate.  Remove the lines
which can actually interfere with the operation of the bus.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_decoder.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/au8522_decoder.c 
b/drivers/media/dvb-frontends/au8522_decoder.c
index 12a5c2c..7811717 100644
--- a/drivers/media/dvb-frontends/au8522_decoder.c
+++ b/drivers/media/dvb-frontends/au8522_decoder.c
@@ -422,8 +422,6 @@ static void set_audio_input(struct au8522_state *state)
au8522_writereg(state, AU8522_AUDIO_VOLUME_L_REG0F2H, 0x00);
au8522_writereg(state, AU8522_AUDIO_VOLUME_R_REG0F3H, 0x00);
au8522_writereg(state, AU8522_AUDIO_VOLUME_REG0F4H, 0x00);
-   au8522_writereg(state, AU8522_I2C_CONTROL_REG1_REG091H, 0x80);
-   au8522_writereg(state, AU8522_I2C_CONTROL_REG0_REG090H, 0x84);
msleep(150);
au8522_writereg(state, AU8522_SYSTEM_MODULE_CONTROL_0_REG0A4H, 0x00);
msleep(10);
-- 
1.9.1

[PATCH 08/12] Add USB quirk for HVR-950q to avoid intermittent device resets

[Devin Heitmueller]

The USB core and sysfs will attempt to enumerate certain parameters
which are unsupported by the au0828 - causing inconsistent behavior
and sometimes causing the chip to reset.  Avoid making these calls.

This problem manifested as intermittent cases where the au8522 would
be reset on analog video startup, in particular when starting up ALSA
audio streaming in parallel - the sysfs entries created by
snd-usb-audio on streaming startup would result in unsupported control
messages being sent during tuning which would put the chip into an
unknown state.

Signed-off-by: Devin Heitmueller 
---
 drivers/usb/core/quirks.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 96b21b0..3116edf 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -223,6 +223,10 @@
/* Blackmagic Design UltraStudio SDI */
{ USB_DEVICE(0x1edb, 0xbd4f), .driver_info = USB_QUIRK_NO_LPM },
 
+   /* Hauppauge HVR-950q */
+   { USB_DEVICE(0x2040, 0x7200), .driver_info =
+   USB_QUIRK_CONFIG_INTF_STRINGS },
+
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
 
-- 
1.9.1

[PATCH 01/12] au8522: don't attempt to configure unsupported VBI slicer

[Devin Heitmueller]

Since we don't suppoort sliced VBI with the au0828/au8522, there is
no need to configure the au8522 VBI slicer, which because of the
coefficients requires a large amount of i2c traffic.

Remove the relevant code.  Note that this has no effect on raw VBI
support, which is currently the only supported way to access VBI on
this device.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_decoder.c | 38 
 1 file changed, 38 deletions(-)

diff --git a/drivers/media/dvb-frontends/au8522_decoder.c 
b/drivers/media/dvb-frontends/au8522_decoder.c
index a2e7713..12a5c2c 100644
--- a/drivers/media/dvb-frontends/au8522_decoder.c
+++ b/drivers/media/dvb-frontends/au8522_decoder.c
@@ -179,42 +179,6 @@ static inline struct au8522_state *to_state(struct 
v4l2_subdev *sd)
return container_of(sd, struct au8522_state, sd);
 }
 
-static void setup_vbi(struct au8522_state *state, int aud_input)
-{
-   int i;
-
-   /* These are set to zero regardless of what mode we're in */
-   au8522_writereg(state, AU8522_TVDEC_VBI_CTRL_H_REG017H, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_CTRL_L_REG018H, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_TOTAL_BITS_REG019H, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_TUNIT_H_REG01AH, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_TUNIT_L_REG01BH, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_THRESH1_REG01CH, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_FRAME_PAT2_REG01EH, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_FRAME_PAT1_REG01FH, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_FRAME_PAT0_REG020H, 0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_FRAME_MASK2_REG021H,
-   0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_FRAME_MASK1_REG022H,
-   0x00);
-   au8522_writereg(state, AU8522_TVDEC_VBI_USER_FRAME_MASK0_REG023H,
-   0x00);
-
-   /* Setup the VBI registers */
-   for (i = 0x30; i < 0x60; i++)
-   au8522_writereg(state, i, 0x40);
-
-   /* For some reason, every register is 0x40 except register 0x44
-  (confirmed via the HVR-950q USB capture) */
-   au8522_writereg(state, 0x44, 0x60);
-
-   /* Enable VBI (we always do this regardless of whether the user is
-  viewing closed caption info) */
-   au8522_writereg(state, AU8522_TVDEC_VBI_CTRL_H_REG017H,
-   AU8522_TVDEC_VBI_CTRL_H_REG017H_CCON);
-
-}
-
 static void setup_decoder_defaults(struct au8522_state *state, bool is_svideo)
 {
int i;
@@ -317,8 +281,6 @@ static void setup_decoder_defaults(struct au8522_state 
*state, bool is_svideo)
AU8522_TOREGAAGC_REG0E5H_CVBS);
au8522_writereg(state, AU8522_REG016H, AU8522_REG016H_CVBS);
 
-   setup_vbi(state, 0);
-
if (is_svideo) {
/* Despite what the table says, for the HVR-950q we still need
   to be in CVBS mode for the S-Video input (reason unknown). */
-- 
1.9.1

[PATCH 04/12] au8522: remove note about VBI not being implemented

[Devin Heitmueller]

I got this working a couple of years ago.  Remove it from the
list of known issues.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_decoder.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/au8522_decoder.c 
b/drivers/media/dvb-frontends/au8522_decoder.c
index 281b5ac..5e21640 100644
--- a/drivers/media/dvb-frontends/au8522_decoder.c
+++ b/drivers/media/dvb-frontends/au8522_decoder.c
@@ -17,7 +17,6 @@
 
 /* Developer notes:
  *
- * VBI support is not yet working
  * Enough is implemented here for CVBS and S-Video inputs, but the actual
  *  analog demodulator code isn't implemented (not needed for xc5000 since it
  *  has its own demodulator and outputs CVBS)
-- 
1.9.1

[PATCH 05/12] au8522: remove leading bit for register writes

[Devin Heitmueller]

The leading bit in register values is actually an indicator as to
whether to perform a read or write, so remove the bit from the
register values, since the au8522_writereg() is now responsible
for adding this bit automatically.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_dig.c | 200 +++
 1 file changed, 100 insertions(+), 100 deletions(-)

diff --git a/drivers/media/dvb-frontends/au8522_dig.c 
b/drivers/media/dvb-frontends/au8522_dig.c
index 7ed326e..d117ddb 100644
--- a/drivers/media/dvb-frontends/au8522_dig.c
+++ b/drivers/media/dvb-frontends/au8522_dig.c
@@ -271,9 +271,9 @@ static int au8522_set_if(struct dvb_frontend *fe, enum 
au8522_if_freq if_freq)
return -EINVAL;
}
dprintk("%s() %s MHz\n", __func__, ifmhz);
-   au8522_writereg(state, 0x80b5, r0b5);
-   au8522_writereg(state, 0x80b6, r0b6);
-   au8522_writereg(state, 0x80b7, r0b7);
+   au8522_writereg(state, 0x00b5, r0b5);
+   au8522_writereg(state, 0x00b6, r0b6);
+   au8522_writereg(state, 0x00b7, r0b7);
 
return 0;
 }
@@ -283,33 +283,33 @@ static int au8522_set_if(struct dvb_frontend *fe, enum 
au8522_if_freq if_freq)
u16 reg;
u16 data;
 } VSB_mod_tab[] = {
-   { 0x8090, 0x84 },
+   { 0x0090, 0x84 },
{ 0x4092, 0x11 },
{ 0x2005, 0x00 },
-   { 0x8091, 0x80 },
-   { 0x80a3, 0x0c },
-   { 0x80a4, 0xe8 },
-   { 0x8081, 0xc4 },
-   { 0x80a5, 0x40 },
-   { 0x80a7, 0x40 },
-   { 0x80a6, 0x67 },
-   { 0x8262, 0x20 },
-   { 0x821c, 0x30 },
-   { 0x80d8, 0x1a },
-   { 0x8227, 0xa0 },
-   { 0x8121, 0xff },
-   { 0x80a8, 0xf0 },
-   { 0x80a9, 0x05 },
-   { 0x80aa, 0x77 },
-   { 0x80ab, 0xf0 },
-   { 0x80ac, 0x05 },
-   { 0x80ad, 0x77 },
-   { 0x80ae, 0x41 },
-   { 0x80af, 0x66 },
-   { 0x821b, 0xcc },
-   { 0x821d, 0x80 },
-   { 0x80a4, 0xe8 },
-   { 0x8231, 0x13 },
+   { 0x0091, 0x80 },
+   { 0x00a3, 0x0c },
+   { 0x00a4, 0xe8 },
+   { 0x0081, 0xc4 },
+   { 0x00a5, 0x40 },
+   { 0x00a7, 0x40 },
+   { 0x00a6, 0x67 },
+   { 0x0262, 0x20 },
+   { 0x021c, 0x30 },
+   { 0x00d8, 0x1a },
+   { 0x0227, 0xa0 },
+   { 0x0121, 0xff },
+   { 0x00a8, 0xf0 },
+   { 0x00a9, 0x05 },
+   { 0x00aa, 0x77 },
+   { 0x00ab, 0xf0 },
+   { 0x00ac, 0x05 },
+   { 0x00ad, 0x77 },
+   { 0x00ae, 0x41 },
+   { 0x00af, 0x66 },
+   { 0x021b, 0xcc },
+   { 0x021d, 0x80 },
+   { 0x00a4, 0xe8 },
+   { 0x0231, 0x13 },
 };
 
 /* QAM64 Modulation table */
@@ -396,78 +396,78 @@ static int au8522_set_if(struct dvb_frontend *fe, enum 
au8522_if_freq if_freq)
u16 reg;
u16 data;
 } QAM256_mod_tab[] = {
-   { 0x80a3, 0x09 },
-   { 0x80a4, 0x00 },
-   { 0x8081, 0xc4 },
-   { 0x80a5, 0x40 },
-   { 0x80aa, 0x77 },
-   { 0x80ad, 0x77 },
-   { 0x80a6, 0x67 },
-   { 0x8262, 0x20 },
-   { 0x821c, 0x30 },
-   { 0x80b8, 0x3e },
-   { 0x80b9, 0xf0 },
-   { 0x80ba, 0x01 },
-   { 0x80bb, 0x18 },
-   { 0x80bc, 0x50 },
-   { 0x80bd, 0x00 },
-   { 0x80be, 0xea },
-   { 0x80bf, 0xef },
-   { 0x80c0, 0xfc },
-   { 0x80c1, 0xbd },
-   { 0x80c2, 0x1f },
-   { 0x80c3, 0xfc },
-   { 0x80c4, 0xdd },
-   { 0x80c5, 0xaf },
-   { 0x80c6, 0x00 },
-   { 0x80c7, 0x38 },
-   { 0x80c8, 0x30 },
-   { 0x80c9, 0x05 },
-   { 0x80ca, 0x4a },
-   { 0x80cb, 0xd0 },
-   { 0x80cc, 0x01 },
-   { 0x80cd, 0xd9 },
-   { 0x80ce, 0x6f },
-   { 0x80cf, 0xf9 },
-   { 0x80d0, 0x70 },
-   { 0x80d1, 0xdf },
-   { 0x80d2, 0xf7 },
-   { 0x80d3, 0xc2 },
-   { 0x80d4, 0xdf },
-   { 0x80d5, 0x02 },
-   { 0x80d6, 0x9a },
-   { 0x80d7, 0xd0 },
-   { 0x8250, 0x0d },
-   { 0x8251, 0xcd },
-   { 0x8252, 0xe0 },
-   { 0x8253, 0x05 },
-   { 0x8254, 0xa7 },
-   { 0x8255, 0xff },
-   { 0x8256, 0xed },
-   { 0x8257, 0x5b },
-   { 0x8258, 0xae },
-   { 0x8259, 0xe6 },
-   { 0x825a, 0x3d },
-   { 0x825b, 0x0f },
-   { 0x825c, 0x0d },
-   { 0x825d, 0xea },
-   { 0x825e, 0xf2 },
-   { 0x825f, 0x51 },
-   { 0x8260, 0xf5 },
-   { 0x8261, 0x06 },
-   { 0x821a, 0x00 },
-   { 0x8546, 0x40 },
-   { 0x8210, 0x26 },
-   { 0x8211, 0xf6 },
-   { 0x8212, 0x84 },
-   { 0x8213, 0x02 },
-   { 0x8502, 0x01 },
-   { 0x8121, 0x04 },
-   { 0x8122, 0x04 },
-   { 0x852e, 0x10 },
-   { 0x80a4, 0xca },
-   { 0x80a7, 0x40 },
-   { 0x8526, 0x01 },
+   { 0x00a3, 0x09 },
+   { 0x00a4, 0x00 },
+   { 0x0081, 0xc4 },
+   { 0x00a5, 0x40 },
+   { 0x00aa, 0x77 },
+   { 0x00ad, 0x77 },
+   { 0x00a6, 0x67 },
+   { 0x0262, 0x20 },
+   { 0x021c, 0x30 },
+   { 0x00b8, 0x3e },
+   { 

[PATCH 07/12] au8522: fix lock detection to be more reliable.

[Devin Heitmueller]

Only looking at the lock register causes the status to float
between locked and not locked when there is no signal.  So improve
the logic to also examine the state of the FSC PLL, which results
in the lock status being consistently reported.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_decoder.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/au8522_decoder.c 
b/drivers/media/dvb-frontends/au8522_decoder.c
index 5e21640..343dc92 100644
--- a/drivers/media/dvb-frontends/au8522_decoder.c
+++ b/drivers/media/dvb-frontends/au8522_decoder.c
@@ -623,10 +623,12 @@ static int au8522_g_tuner(struct v4l2_subdev *sd, struct 
v4l2_tuner *vt)
int val = 0;
struct au8522_state *state = to_state(sd);
u8 lock_status;
+   u8 pll_status;
 
/* Interrogate the decoder to see if we are getting a real signal */
lock_status = au8522_readreg(state, 0x00);
-   if (lock_status == 0xa2)
+   pll_status = au8522_readreg(state, 0x7e);
+   if ((lock_status == 0xa2) && (pll_status & 0x10))
vt->signal = 0x;
else
vt->signal = 0x00;
-- 
1.9.1

[PATCH 12/12] au0828: Add timer to restart TS stream if no data arrives on bulk endpoint

[Devin Heitmueller]

For reasons unclear, we intermittently see a case where the tune
is successful but the bulk stream fails to deliver any packets.

Add a timer to automatically stop/start the data pump if we
encounter such a case.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/usb/au0828/au0828-dvb.c | 30 ++
 drivers/media/usb/au0828/au0828.h |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/media/usb/au0828/au0828-dvb.c 
b/drivers/media/usb/au0828/au0828-dvb.c
index 7e0c9b7..34dc7e0 100644
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -105,6 +105,15 @@
 
 static void au0828_restart_dvb_streaming(struct work_struct *work);
 
+static void au0828_bulk_timeout(unsigned long data)
+{
+   struct au0828_dev *dev = (struct au0828_dev *) data;
+
+   dprintk(1, "%s called\n", __func__);
+   dev->bulk_timeout_running = 0;
+   schedule_work(>restart_streaming);
+}
+
 /*---*/
 static void urb_completion(struct urb *purb)
 {
@@ -138,6 +147,13 @@ static void urb_completion(struct urb *purb)
ptr[0], purb->actual_length);
schedule_work(>restart_streaming);
return;
+   } else if (dev->bulk_timeout_running == 1) {
+   /* The URB handler has fired, so cancel timer which would
+* restart endpoint if we hadn't
+*/
+   dprintk(1, "%s cancelling bulk timeout\n", __func__);
+   dev->bulk_timeout_running = 0;
+   del_timer(>bulk_timeout);
}
 
/* Feed the transport payload into the kernel demux */
@@ -160,6 +176,11 @@ static int stop_urb_transfer(struct au0828_dev *dev)
if (!dev->urb_streaming)
return 0;
 
+   if (dev->bulk_timeout_running == 1) {
+   dev->bulk_timeout_running = 0;
+   del_timer(>bulk_timeout);
+   }
+
dev->urb_streaming = false;
for (i = 0; i < URB_COUNT; i++) {
if (dev->urbs[i]) {
@@ -232,6 +253,11 @@ static int start_urb_transfer(struct au0828_dev *dev)
}
 
dev->urb_streaming = true;
+
+   /* If we don't valid data within 1 second, restart stream */
+   mod_timer(>bulk_timeout, jiffies + (HZ));
+   dev->bulk_timeout_running = 1;
+
return 0;
 }
 
@@ -622,6 +648,10 @@ int au0828_dvb_register(struct au0828_dev *dev)
return ret;
}
 
+   dev->bulk_timeout.function = au0828_bulk_timeout;
+   dev->bulk_timeout.data = (unsigned long) dev;
+   init_timer(>bulk_timeout);
+
return 0;
 }
 
diff --git a/drivers/media/usb/au0828/au0828.h 
b/drivers/media/usb/au0828/au0828.h
index 88e5974..05e445f 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -195,6 +195,8 @@ struct au0828_dev {
/* Digital */
struct au0828_dvb   dvb;
struct work_struct  restart_streaming;
+   struct timer_list   bulk_timeout;
+   int bulk_timeout_running;
 
 #ifdef CONFIG_VIDEO_AU0828_V4L2
/* Analog */
-- 
1.9.1

[PATCH 00/12] minor cleanups for HVR-950q

[Devin Heitmueller]

This is a series of mostly minor cleanups/fixes for the HVR-950q
driver.  We'll get this stuff merged since it's non-controversial,
and then we can argue about the more invasive patches to follow.

Devin Heitmueller (12):
  au8522: don't attempt to configure unsupported VBI slicer
  au8522: don't touch i2c master registers on au8522
  au8522: rework setup of audio routing
  au8522: remove note about VBI not being implemented
  au8522: remove leading bit for register writes
  au8522 Remove 0x4 bit for register reads
  au8522: fix lock detection to be more reliable.
  Add USB quirk for HVR-950q to avoid intermittent device resets
  xc5000: Don't spin waiting for analog lock
  au8522: Set the initial modulation
  Fix breakage in "make menuconfig" for media_build
  au0828: Add timer to restart TS stream if no data arrives on bulk
endpoint

 drivers/media/dvb-frontends/au8522_common.c  |   1 +
 drivers/media/dvb-frontends/au8522_decoder.c |  74 +++--
 drivers/media/dvb-frontends/au8522_dig.c | 215 +--
 drivers/media/rc/Kconfig |   8 +-
 drivers/media/tuners/xc5000.c|  26 +---
 drivers/media/usb/au0828/au0828-dvb.c|  30 
 drivers/media/usb/au0828/au0828.h|   2 +
 drivers/usb/core/quirks.c|   4 +
 8 files changed, 168 insertions(+), 192 deletions(-)

-- 
1.9.1

[PATCH 06/12] au8522 Remove 0x4 bit for register reads

[Devin Heitmueller]

The second highest bit in the register value is an indicator to do
a register read, so remove it since now au8522_regread() inserts
the bit automatically.

Also remove a stray instance where we were actually trying to write
to the I2C status register, which was actually a read.

Signed-off-by: Devin Heitmueller 
---
 drivers/media/dvb-frontends/au8522_dig.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/media/dvb-frontends/au8522_dig.c 
b/drivers/media/dvb-frontends/au8522_dig.c
index d117ddb..3f3635f 100644
--- a/drivers/media/dvb-frontends/au8522_dig.c
+++ b/drivers/media/dvb-frontends/au8522_dig.c
@@ -284,7 +284,6 @@ static int au8522_set_if(struct dvb_frontend *fe, enum 
au8522_if_freq if_freq)
u16 data;
 } VSB_mod_tab[] = {
{ 0x0090, 0x84 },
-   { 0x4092, 0x11 },
{ 0x2005, 0x00 },
{ 0x0091, 0x80 },
{ 0x00a3, 0x0c },
@@ -654,12 +653,12 @@ static int au8522_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
 
if (state->current_modulation == VSB_8) {
dprintk("%s() Checking VSB_8\n", __func__);
-   reg = au8522_readreg(state, 0x4088);
+   reg = au8522_readreg(state, 0x0088);
if ((reg & 0x03) == 0x03)
*status |= FE_HAS_LOCK | FE_HAS_SYNC | FE_HAS_VITERBI;
} else {
dprintk("%s() Checking QAM\n", __func__);
-   reg = au8522_readreg(state, 0x4541);
+   reg = au8522_readreg(state, 0x0541);
if (reg & 0x80)
*status |= FE_HAS_VITERBI;
if (reg & 0x20)
@@ -745,17 +744,17 @@ static int au8522_read_snr(struct dvb_frontend *fe, u16 
*snr)
if (state->current_modulation == QAM_256)
ret = au8522_mse2snr_lookup(qam256_mse2snr_tab,
ARRAY_SIZE(qam256_mse2snr_tab),
-   au8522_readreg(state, 0x4522),
+   au8522_readreg(state, 0x0522),
snr);
else if (state->current_modulation == QAM_64)
ret = au8522_mse2snr_lookup(qam64_mse2snr_tab,
ARRAY_SIZE(qam64_mse2snr_tab),
-   au8522_readreg(state, 0x4522),
+   au8522_readreg(state, 0x0522),
snr);
else /* VSB_8 */
ret = au8522_mse2snr_lookup(vsb_mse2snr_tab,
ARRAY_SIZE(vsb_mse2snr_tab),
-   au8522_readreg(state, 0x4311),
+   au8522_readreg(state, 0x0311),
snr);
 
if (state->config.led_cfg)
@@ -804,9 +803,9 @@ static int au8522_read_ucblocks(struct dvb_frontend *fe, 
u32 *ucblocks)
struct au8522_state *state = fe->demodulator_priv;
 
if (state->current_modulation == VSB_8)
-   *ucblocks = au8522_readreg(state, 0x4087);
+   *ucblocks = au8522_readreg(state, 0x0087);
else
-   *ucblocks = au8522_readreg(state, 0x4543);
+   *ucblocks = au8522_readreg(state, 0x0543);
 
return 0;
 }
-- 
1.9.1

Re: [PATCH] [media] rainshadow-cec: use strlcat instead of strncat

[Arnd Bergmann]

On Wed, Apr 19, 2017 at 11:14 PM, Hans Verkuil  wrote:
> On 19/04/17 19:15, Arnd Bergmann wrote:
>> gcc warns about an obviously incorrect use of strncat():
>>
>> drivers/media/usb/rainshadow-cec/rainshadow-cec.c: In function 
>> 'rain_cec_adap_transmit':
>> drivers/media/usb/rainshadow-cec/rainshadow-cec.c:299:4: error: specified 
>> bound 48 equals the size of the destination [-Werror=stringop-overflow=]
>>
>> It seems that strlcat was intended here, and using that makes the
>> code correct.
>
> Oops! You're right, it should be strlcat.
>
> Which gcc version do you use? Mine (6.3.0) didn't give an error (or warning, 
> for that matter).

I think the warning was only added in gcc-7.0.1.

 Arnd

Re: [PATCH v4] [media] uvcvideo: Add iFunction or iInterface to device names.

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Wednesday 19 Apr 2017 16:45:27 Peter Boström wrote:
> Permits distinguishing between two /dev/videoX entries from the same
> physical UVC device (that naturally share the same iProduct name).
> 
> This change matches current Windows behavior by prioritizing iFunction
> over iInterface, but unlike Windows it displays both iProduct and
> iFunction/iInterface strings when both are available.
> 
> Signed-off-by: Peter Boström 
> ---
>  drivers/media/usb/uvc/uvc_driver.c | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index 04bf35063c4c..ae22fcf0a529
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -1998,6 +1998,7 @@ static int uvc_probe(struct usb_interface *intf,
>  {
>   struct usb_device *udev = interface_to_usbdev(intf);
>   struct uvc_device *dev;
> + int function;
>   int ret;
> 
>   if (id->idVendor && id->idProduct)
> @@ -2029,9 +2030,26 @@ static int uvc_probe(struct usb_interface *intf,
>   strlcpy(dev->name, udev->product, sizeof dev->name);
>   else
>   snprintf(dev->name, sizeof dev->name,
> - "UVC Camera (%04x:%04x)",
> - le16_to_cpu(udev->descriptor.idVendor),
> - le16_to_cpu(udev->descriptor.idProduct));
> +  "UVC Camera (%04x:%04x)",
> +  le16_to_cpu(udev->descriptor.idVendor),
> +  le16_to_cpu(udev->descriptor.idProduct));
> +
> + /*
> +  * Add iFunction or iInterface to names when available as additional
> +  * distinguishers between interfaces. iFunction is prioritized over
> +  * iInterface which matches Windows behavior at the point of writing.
> +  */
> + function = intf->cur_altsetting->desc.iInterface;
> + if (intf->intf_assoc && intf->intf_assoc->iFunction != 0)
> + function = intf->intf_assoc->iFunction;

Nitpicking, I'd prefer writing this as

if (intf->intf_assoc && intf->intf_assoc->iFunction != 0)
function = intf->intf_assoc->iFunction;
else
function = intf->cur_altsetting->desc.iInterface;

to clearly show what is the preferred case and what is the fallback. I'll fix 
that when applying, no need to resubmit the patch.

Reviewed-by: Laurent Pinchart 

> + if (function != 0) {
> + size_t len;
> +
> + strlcat(dev->name, ": ", sizeof(dev->name));
> + len = strlen(dev->name);
> + usb_string(udev, function, dev->name + len,
> +sizeof(dev->name) - len);
> + }
> 
>   /* Parse the Video Class control descriptor. */
>   if (uvc_parse_control(dev) < 0) {

-- 
Regards,

Laurent Pinchart

Re: [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree

[Rob Herring]

On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> If the mdp_* nodes are under an mdp sub-node, their corresponding
> platform device does not automatically get its iommu assigned properly.
> 
> Fix this by moving the mdp component nodes up a level such that they are
> siblings of mdp and all other SoC subsystems.  This also simplifies the
> device tree.

It may simplify the DT, but it also breaks compatibility with old DT. 
Not sure if that's a problem on Mediatek platforms, but please be 
explicit here that you are breaking compatibility and why that is okay.

> 
> Signed-off-by: Daniel Kurtz 
> Signed-off-by: Minghsiu Tsai 

Should this have Daniel as the author?

> 
> ---
>  Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> index 4182063..0d03e3a 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> @@ -2,7 +2,7 @@
>  
>  Media Data Path is used for scaling and color space conversion.
>  
> -Required properties (controller (parent) node):
> +Required properties (controller node):
>  - compatible: "mediatek,mt8173-mdp"
>  - mediatek,vpu: the node of video processor unit, see
>Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
>for details.
>  
>  Example:
> -mdp {
> - compatible = "mediatek,mt8173-mdp";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> - mediatek,vpu = <>;
> -
>   mdp_rdma0: rdma@14001000 {
>   compatible = "mediatek,mt8173-mdp-rdma";
> +  "mediatek,mt8173-mdp";
>   reg = <0 0x14001000 0 0x1000>;
>   clocks = < CLK_MM_MDP_RDMA0>,
>< CLK_MM_MUTEX_32K>;
>   power-domains = < MT8173_POWER_DOMAIN_MM>;
>   iommus = < M4U_PORT_MDP_RDMA0>;
>   mediatek,larb = <>;
> + mediatek,vpu = <>;
>   };
>  
>   mdp_rdma1: rdma@14002000 {
> @@ -106,4 +101,3 @@ mdp {
>   iommus = < M4U_PORT_MDP_WROT1>;
>   mediatek,larb = <>;
>   };
> -};
> -- 
> 1.9.1
> 

Re: [PATCH] [media] rainshadow-cec: use strlcat instead of strncat

[Hans Verkuil]

On 19/04/17 19:15, Arnd Bergmann wrote:
> gcc warns about an obviously incorrect use of strncat():
> 
> drivers/media/usb/rainshadow-cec/rainshadow-cec.c: In function 
> 'rain_cec_adap_transmit':
> drivers/media/usb/rainshadow-cec/rainshadow-cec.c:299:4: error: specified 
> bound 48 equals the size of the destination [-Werror=stringop-overflow=]
> 
> It seems that strlcat was intended here, and using that makes the
> code correct.

Oops! You're right, it should be strlcat.

Which gcc version do you use? Mine (6.3.0) didn't give an error (or warning, 
for that matter).

Regards,

Hans

> 
> Fixes: 0f314f6c2e77 ("[media] rainshadow-cec: new RainShadow Tech HDMI CEC 
> driver")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c 
> b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> index 541ca543f71f..dc1f64f904cd 100644
> --- a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> +++ b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> @@ -296,7 +296,7 @@ static int rain_cec_adap_transmit(struct cec_adapter 
> *adap, u8 attempts,
>cec_msg_destination(msg), msg->msg[1]);
>   for (i = 2; i < msg->len; i++) {
>   snprintf(hex, sizeof(hex), "%02x", msg->msg[i]);
> - strncat(cmd, hex, sizeof(cmd));
> + strlcat(cmd, hex, sizeof(cmd));
>   }
>   }
>   mutex_lock(>write_lock);
> 

Re: [PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

[Hans Verkuil]

Hi Arnd,

On 19/04/17 18:59, Arnd Bergmann wrote:
> When the media subsystem is built as a loadable module, a built-in
> DRM driver cannot use the cec notifiers:
> 
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove':
> sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to 
> `cec_notifier_set_phys_addr'
> sti_hdmi.c:(.text.sti_hdmi_remove+0x50): undefined reference to 
> `cec_notifier_put'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_get_modes':
> sti_hdmi.c:(.text.sti_hdmi_connector_get_modes+0x84): undefined reference to 
> `cec_notifier_set_phys_addr_from_edid'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_probe':
> sti_hdmi.c:(.text.sti_hdmi_probe+0x1a8): undefined reference to 
> `cec_notifier_get'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_detect':
> sti_hdmi.c:(.text.sti_hdmi_connector_detect+0x68): undefined reference to 
> `cec_notifier_set_phys_addr'
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_disable':
> sti_hdmi.c:(.text.sti_hdmi_disable+0xec): undefined reference to 
> `cec_notifier_set_phys_addr'
> 
> This adds a Kconfig dependency to enforce the HDMI driver to also
> be a loadable module in this case.

I've marked this patch and the exynos_hdmi patch as 'Obsoleted' in patchwork:
today several CEC Kconfig cleanup patches were merged that invalidate these
two patches. I expect they'll turn up soon in -next.

Regards,

Hans

> 
> Fixes: bca55958ea87 ("[media] sti: hdmi: add CEC notifier support")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/sti/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index acd72865feac..adac4c3e142e 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_STI
>   tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
>   depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
> + depends on (MEDIA_SUPPORT && MEDIA_CEC_NOTIFIER) || !MEDIA_CEC_NOTIFIER
>   select RESET_CONTROLLER
>   select DRM_KMS_HELPER
>   select DRM_GEM_CMA_HELPER
> 

[PATCH] cx88: Fix regression in initial video standard setting

[Devin Heitmueller]

Setting initial standard at the top of cx8800_initdev would cause the
first call to cx88_set_tvnorm() to return without programming any
registers (leaving the driver saying it's set to NTSC but the hardware
isn't programmed).  Even worse, any subsequent attempt to explicitly
set it to NTSC-M will return success but actually fail to program the
underlying registers unless first changing the standard to something
other than NTSC-M.

Set the initial standard later in the process, and make sure the field
is zero at the beginning to ensure that the call always goes through.

This regression was introduced in the following commit:

commit ccd6f1d488e7 ("[media] cx88: move width, height and field to core
struct")

Author: Hans Verkuil 
Date:   Sat Sep 20 09:23:44 2014 -0300

[media] cx88: move width, height and field to core struct

Signed-off-by: Devin Heitmueller 
---
 drivers/media/pci/cx88/cx88-cards.c | 9 -
 drivers/media/pci/cx88/cx88-video.c | 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/cx88/cx88-cards.c 
b/drivers/media/pci/cx88/cx88-cards.c
index 73cc7a6..b7a8c8c 100644
--- a/drivers/media/pci/cx88/cx88-cards.c
+++ b/drivers/media/pci/cx88/cx88-cards.c
@@ -3681,7 +3681,14 @@ struct cx88_core *cx88_core_create(struct pci_dev *pci, 
int nr)
core->nr = nr;
sprintf(core->name, "cx88[%d]", core->nr);
 
-   core->tvnorm = V4L2_STD_NTSC_M;
+   /*
+* Note: Setting initial standard here would cause first call to
+* cx88_set_tvnorm() to return without programming any registers.  Leave
+* it blank for at this point and it will get set later in
+* cx8800_inittdev()
+*/
+   core->tvnorm  = 0;
+
core->width   = 320;
core->height  = 240;
core->field   = V4L2_FIELD_INTERLACED;
diff --git a/drivers/media/pci/cx88/cx88-video.c 
b/drivers/media/pci/cx88/cx88-video.c
index c7d4e87..3c529dd 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -1435,7 +1435,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
 
/* initial device configuration */
mutex_lock(>lock);
-   cx88_set_tvnorm(core, core->tvnorm);
+   cx88_set_tvnorm(core, V4L2_STD_NTSC_M);
v4l2_ctrl_handler_setup(>video_hdl);
v4l2_ctrl_handler_setup(>audio_hdl);
cx88_video_mux(core, 0);
-- 
1.9.1

[PATCH v4] [media] uvcvideo: Add iFunction or iInterface to device names.

[Peter Boström]

Permits distinguishing between two /dev/videoX entries from the same
physical UVC device (that naturally share the same iProduct name).

This change matches current Windows behavior by prioritizing iFunction
over iInterface, but unlike Windows it displays both iProduct and
iFunction/iInterface strings when both are available.

Signed-off-by: Peter Boström 
---
 drivers/media/usb/uvc/uvc_driver.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 04bf35063c4c..ae22fcf0a529 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1998,6 +1998,7 @@ static int uvc_probe(struct usb_interface *intf,
 {
struct usb_device *udev = interface_to_usbdev(intf);
struct uvc_device *dev;
+   int function;
int ret;
 
if (id->idVendor && id->idProduct)
@@ -2029,9 +2030,26 @@ static int uvc_probe(struct usb_interface *intf,
strlcpy(dev->name, udev->product, sizeof dev->name);
else
snprintf(dev->name, sizeof dev->name,
-   "UVC Camera (%04x:%04x)",
-   le16_to_cpu(udev->descriptor.idVendor),
-   le16_to_cpu(udev->descriptor.idProduct));
+"UVC Camera (%04x:%04x)",
+le16_to_cpu(udev->descriptor.idVendor),
+le16_to_cpu(udev->descriptor.idProduct));
+
+   /*
+* Add iFunction or iInterface to names when available as additional
+* distinguishers between interfaces. iFunction is prioritized over
+* iInterface which matches Windows behavior at the point of writing.
+*/
+   function = intf->cur_altsetting->desc.iInterface;
+   if (intf->intf_assoc && intf->intf_assoc->iFunction != 0)
+   function = intf->intf_assoc->iFunction;
+   if (function != 0) {
+   size_t len;
+
+   strlcat(dev->name, ": ", sizeof(dev->name));
+   len = strlen(dev->name);
+   usb_string(udev, function, dev->name + len,
+  sizeof(dev->name) - len);
+   }
 
/* Parse the Video Class control descriptor. */
if (uvc_parse_control(dev) < 0) {
-- 
2.12.2.816.g281164-goog

[PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Logan Gunthorpe]

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 
---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

 drivers/dma-buf/dma-buf.c  | 16 
 drivers/gpu/drm/armada/armada_gem.c|  8 
 drivers/gpu/drm/drm_prime.c|  8 
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
 drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
 drivers/gpu/drm/tegra/gem.c|  8 
 drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
 drivers/staging/android/ion/ion.c  |  8 
 include/linux/dma-buf.h| 22 +++---
 14 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f72aaac..512bdbc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
  || !exp_info->ops->map_dma_buf
  || !exp_info->ops->unmap_dma_buf
  || !exp_info->ops->release
- || !exp_info->ops->kmap_atomic
- || !exp_info->ops->kmap
+ || !exp_info->ops->map_atomic
+ || !exp_info->ops->map
  || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num)
 {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
+   return dmabuf->ops->map_atomic(dmabuf, page_num);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);

@@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num,
 {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap_atomic)
-   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap_atomic)
+   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);

@@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
page_num)
 {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap(dmabuf, page_num);
+   return dmabuf->ops->map(dmabuf, page_num);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kmap);

@@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
page_num,
 {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap)
-   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap)
+   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap);

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 1597458..d6c2a5d 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -529,10 +529,10 @@ static const struct dma_buf_ops 
armada_gem_prime_dmabuf_ops = {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
-   .kmap_atomic= armada_gem_dmabuf_no_kmap,
-   .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
-   .kmap   = armada_gem_dmabuf_no_kmap,
-   .kunmap = armada_gem_dmabuf_no_kunmap,
+   .map_atomic = armada_gem_dmabuf_no_kmap,
+   .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
+   .map= armada_gem_dmabuf_no_kmap,
+   .unmap  = armada_gem_dmabuf_no_kunmap,
.mmap   = armada_gem_dmabuf_mmap,
 };

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..954eb84 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -403,10 +403,10 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
=  {
.map_dma_buf = 

RFC: Power states and VIDIOC_STREAMON

[Devin Heitmueller]

Hello all,

I'm in the process of putting together a bunch of long-standing fixes
for HVR-950q driver, and I ran into a regression related to the way
the video decoder is being managed.  Before we dig into the details
here's the general question:

Should a user be able to interrogate video decoder properties after
doing a tune without having first called VIDIOC_STREAMON?

A long-standing use case is to be able to use a command-line tool like
v4l2-ctl to set the input, set the standard, issue a tuning request,
poll for a lock status, and once you see a signal lock then start
streaming.  This means that prior to starting streaming the tuner,
analog demodulator, and video decoder are all running even though
you're not actually receiving video buffers.

The problem comes down to these two patches:

https://git.linuxtv.org/media_tree.git/commit/drivers/media/dvb-frontends/au8522_decoder.c?id=38fe3510fa8fb5e75ee3b196e44a7b717d167e5d
https://git.linuxtv.org/media_tree.git/commit/drivers/media/dvb-frontends/au8522_decoder.c?id=d289cdf022c5bebf09c73097404aa9faf2211381

Prior to these patches, I would power up the IP blocks for the analog
demodulator and decoder when the video routing was setup (typically
when setting the input).  However as a result of these patches
powering up of those IP blocks is deferred until STREAMON is called.
Hence if you just set the input and issue a tuning request, and poll
for lock then you will never see the tuner in a locked state
regardless of the actual signal state.

I can appreciate the motivation behind Mauro's change in wanting to
constrain the window that the analog decoder is powered up to reduce
the risk of having it powered up at the same time as the digital
demodulator, but if it breaks long-standing ABI behavior then that
probably isn't going to work.

I did take a look at the the VIDIOC_STREAMON docs, which state that
the "Capture hardware is disabled and no buffers are filled" prior to
calling STREAMON:

https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-streamon.html

However that language would suggest that even the tuner would be
powered down prior to calling STREAMON, which we know is almost never
the case.

I suspect the ambiguity lies in what is defined by "capture hardware":

The DMA engine or other mechanism of transferring completed video
buffers to userland?
The DMA engine and the video decoder?
The DMA engine, video decoder, and analog demodulator?
The DMA engine, video decoder, analog demodulator, and tuner?

I had always interpreted it such that the STREAMON call just
controlled whether the DMA engine was running, and thus you could do
anything else with the decoder before calling STREAMON other than
actually receiving video buffers.

My instinct would be to revert the patch in question since it breaks
ABI behavior which has been present for over a decade, but I suspect
such a patch would be rejected since it was Mauro himself who
introduced the change in behavior.

I look forward to hearing from the V4L2 maintainers with regards to
what the expected ABI behavior should be, at which point I can figure
out how to adjust the driver code to accommodate such behavior (and if
that means I cannot query for a signal lock prior to calling STREAMON,
going back and changing a bunch of userland code which expects such).

Thanks,

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

[PATCH] [media] rainshadow-cec: use strlcat instead of strncat

[Arnd Bergmann]

gcc warns about an obviously incorrect use of strncat():

drivers/media/usb/rainshadow-cec/rainshadow-cec.c: In function 
'rain_cec_adap_transmit':
drivers/media/usb/rainshadow-cec/rainshadow-cec.c:299:4: error: specified bound 
48 equals the size of the destination [-Werror=stringop-overflow=]

It seems that strlcat was intended here, and using that makes the
code correct.

Fixes: 0f314f6c2e77 ("[media] rainshadow-cec: new RainShadow Tech HDMI CEC 
driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c 
b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
index 541ca543f71f..dc1f64f904cd 100644
--- a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
+++ b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
@@ -296,7 +296,7 @@ static int rain_cec_adap_transmit(struct cec_adapter *adap, 
u8 attempts,
 cec_msg_destination(msg), msg->msg[1]);
for (i = 2; i < msg->len; i++) {
snprintf(hex, sizeof(hex), "%02x", msg->msg[i]);
-   strncat(cmd, hex, sizeof(cmd));
+   strlcat(cmd, hex, sizeof(cmd));
}
}
mutex_lock(>write_lock);
-- 
2.9.0

[PATCH] [media] exynos_hdmi: improve MEDIA_CEC_NOTIFIER dependency

[Arnd Bergmann]

When the media subsystem is built as a loadable module, a built-in
DRM driver cannot use the cec notifiers:

drivers/gpu/drm/exynos/exynos_hdmi.o: In function `hdmi_get_modes':
exynos_hdmi.c:(.text.hdmi_get_modes+0x80): undefined reference to 
`cec_notifier_set_phys_addr_from_edid'
drivers/gpu/drm/exynos/exynos_hdmi.o: In function `hdmi_remove':
exynos_hdmi.c:(.text.hdmi_remove+0x24): undefined reference to 
`cec_notifier_set_phys_addr'
exynos_hdmi.c:(.text.hdmi_remove+0x38): undefined reference to 
`cec_notifier_put'

This adds a Kconfig dependency to enforce the HDMI driver to also
be a loadable module in this case.

Fixes: 278c811c5d05 ("[media] exynos_hdmi: add CEC notifier support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/exynos/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 1d185347c64c..65ba292f8e40 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,6 +1,7 @@
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC EXYNOS Series"
depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
+   depends on (MEDIA_SUPPORT && MEDIA_CEC_NOTIFIER) || !MEDIA_CEC_NOTIFIER
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
help
-- 
2.9.0

[PATCH] [media] sti: hdmi: improve MEDIA_CEC_NOTIFIER dependency

[Arnd Bergmann]

When the media subsystem is built as a loadable module, a built-in
DRM driver cannot use the cec notifiers:

drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove':
sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to 
`cec_notifier_set_phys_addr'
sti_hdmi.c:(.text.sti_hdmi_remove+0x50): undefined reference to 
`cec_notifier_put'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_get_modes':
sti_hdmi.c:(.text.sti_hdmi_connector_get_modes+0x84): undefined reference to 
`cec_notifier_set_phys_addr_from_edid'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_probe':
sti_hdmi.c:(.text.sti_hdmi_probe+0x1a8): undefined reference to 
`cec_notifier_get'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_connector_detect':
sti_hdmi.c:(.text.sti_hdmi_connector_detect+0x68): undefined reference to 
`cec_notifier_set_phys_addr'
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_disable':
sti_hdmi.c:(.text.sti_hdmi_disable+0xec): undefined reference to 
`cec_notifier_set_phys_addr'

This adds a Kconfig dependency to enforce the HDMI driver to also
be a loadable module in this case.

Fixes: bca55958ea87 ("[media] sti: hdmi: add CEC notifier support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/sti/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd72865feac..adac4c3e142e 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,7 @@
 config DRM_STI
tristate "DRM Support for STMicroelectronics SoC stiH4xx Series"
depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM)
+   depends on (MEDIA_SUPPORT && MEDIA_CEC_NOTIFIER) || !MEDIA_CEC_NOTIFIER
select RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
-- 
2.9.0

Re: [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sinclair Yeh]

Minor nits, otherwise the vmwgfx part,
  Reviewed-by: Sinclair Yeh 

On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_op shares the same name with a macro
s^

> in higmem.h, the former can be aliased if any dma-buf user includes
   h^
> that header.
> 
> I'm personally trying to include highmem.h inside scatterlist.h and this
> breaks the dma-buf code proper.
> 
> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
> 
> To maintain consistency I've renamed all four of kmap* and kunmap* to be
> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_target-2Ddevel_msg15070.html=DwIBAg=uilaK90D4TOVoH58JNXRgQ=HaJ2a6NYExoV0cntAYcoqA=QP_jolGTC4ofBnHRnAs0tFIXHnVWaTT0AdMyCL9SM64=un2hxBL1283iOTtJeJnvyyvtAu1d5Imyh5Q7AzljrfQ=
>  
> 
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/dma-buf/dma-buf.c  | 16 
>  drivers/gpu/drm/armada/armada_gem.c|  8 
>  drivers/gpu/drm/drm_prime.c|  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>  drivers/gpu/drm/tegra/gem.c|  4 ++--
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>  drivers/staging/android/ion/ion.c  |  8 
>  include/linux/dma-buf.h| 22 +++---
>  13 files changed, 55 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..7cc2bfe 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->kmap_atomic
> -   || !exp_info->ops->kmap
> +   || !exp_info->ops->map_atomic
> +   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>  
> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap_atomic)
> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap_atomic)
> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>  
> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
> page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap(dmabuf, page_num);
> + return dmabuf->ops->map(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>  
> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
> page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap)
> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap)
> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>  
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 1597458..d6c2a5d 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
> armada_gem_prime_dmabuf_ops = {
>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>   .release= drm_gem_dmabuf_release,
> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
> - .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
> - .kmap   = armada_gem_dmabuf_no_kmap,
> - .kunmap = armada_gem_dmabuf_no_kunmap,
> + .map_atomic = armada_gem_dmabuf_no_kmap,
> + .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
> + .map= armada_gem_dmabuf_no_kmap,
> + .unmap  = armada_gem_dmabuf_no_kunmap,
>   .mmap   = armada_gem_dmabuf_mmap,
>  };
>  
> diff --git 

Re: [PATCH] [media] ov2640: make GPIOLIB an optional dependency

[Mauro Carvalho Chehab]

Em Wed, 19 Apr 2017 15:23:39 +0200
Pavel Machek  escreveu:

> Hi!
> 
> > As warned by kbuild test robot:
> > warning: (VIDEO_EM28XX_V4L2) selects VIDEO_OV2640 which has unmet 
> > direct dependencies (MEDIA_SUPPORT && VIDEO_V4L2 && I2C && GPIOLIB && 
> > MEDIA_CAMERA_SUPPORT)
> > 
> > The em28xx driver can use ov2640, but it doesn't depend
> > (or use) the GPIOLIB in order to power off/on the sensor.
> > 
> > So, as we want to allow both usages with and without
> > GPIOLIB, make its dependency optional.  
> 
> Umm. The driver will not work too well with sensor powered off, no?
> Will this result in some tricky-to-debug situations?
> 
> >  config VIDEO_OV2640
> > tristate "OmniVision OV2640 sensor support"
> > -   depends on VIDEO_V4L2 && I2C && GPIOLIB
> > +   depends on VIDEO_V4L2 && I2C
> > depends on MEDIA_CAMERA_SUPPORT
> > help
> >   This is a Video4Linux2 sensor-level driver for the
> > OmniVision  
> 
> Better solution would be for VIDEO_EM28XX_V4L2 to depend on GPIOLIB,
> too, no? If not, should there be BUG_ON(priv->pwdn_gpio);
> BUG_ON(priv->resetb_gpio);?

Pavel,

The em28xx driver was added upstream several years the gpio driver. 
It controls GPIO using a different logic. It makes no sense to make
it dependent on GPIOLIB, except if someone converts it to use it.

Besides that, I won't doubt that, at least on some em28xx webcams,
the sensor is always on.

Converting it to use the gpiolib not an easy task, as it supports a
hundred different device models and several different types of devices:
webcams, analog TV, digital TV, hybrid devices (plus devices with FM
radio too).

Too much work for no gain and a high risk of regressions.


Thanks,
Mauro

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Mauro Carvalho Chehab]

Em Sun, 16 Apr 2017 12:12:10 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Fri, Apr 14, 2017 at 11:23:32PM -0300, Mauro Carvalho Chehab wrote:
> > Hi Sakari,
> > 
> > Em Tue, 14 Feb 2017 14:20:22 +0200
> > Sakari Ailus  escreveu:
> >   
> > > Add a V4L2 control class for voice coil lens driver devices. These are
> > > simple devices that are used to move a camera lens from its resting
> > > position.  
> > 
> > From some past threads with this patch, you mentioned that:
> > 
> > "The FOCUS_ABSOLUTE control really is not a best control ID to
> >  control a voice coil driver's current."
> > 
> > However, I'm not seeing any explanation there at the thread, at
> > the patch description or at the documentation explaining why, and,
> > more important, when someone should use the focus control or the
> > camera voice coil control.  
> 
> It should be available in the thread.

The email thread is not registered at git logs nor at the API spec.

> Nevertheless, V4L2_CID_FOCUS_ABSOLUTE
> is documented as follows (emphasis mine):
> 
>   This control sets the *focal point* of the camera to the specified
>   position. The unit is undefined. Positive values set the focus
>   closer to the camera, negative values towards infinity.
> 
> What you control in voice coil devices is current (in Ampères) and the
> current only has a relatively loose relation to the focal point.

The real problem I'm seeing here is that this control is already
used by voice coil motor (VCM). Several UVC-based Logitech cameras
come with VCM, like their QuickCam Pro-series webcams:

https://secure.logitech.com/en-hk/articles/3231

The voice coil can be seen on this picture:

https://photo.stackexchange.com/questions/48678/can-i-modify-a-logitech-c615-webcam-for-infinity-focus

> Additionally, increasing the current brings the focus closer, not farther.

That's just a hardware/software implementation detail. One could use
a voice coil to do just the reverse: without any current, it would
be getting a minimal focus distance; with max current it would
go to infinite, or may have some firmware inside the hardware that
would be inverting the signal.

I have here a C920 camera. This model has V4L2_CID_FOCUS_ABSOLUTE:

ioctl(3, VIDIOC_G_EXT_CTRLS, {ctrl_class=V4L2_CTRL_CLASS_CAMERA, count=1, 
controls=[{id=V4L2_CID_FOCUS_ABSOLUTE, size=0, value=0, value64=0}]}) = 0
write(1, " focus_absolute "..., 97 
focus_absolute (int): min=0 max=250 step=5 default=0 value=0 flags=inactive

On this model, V4L2_CID_FOCUS_ABSOLUTE == infinite.

On a quick check at uvc driver, it seems that the driver itself
doesn't invert the value before sending to the device. So, 
I guess that, either the camera firmware do something like:
current = 250 - control_value
Or the VCM here is mounted, in hardware, to use less current
when focusing on a close object.

Looking on it on another side, this control was added on this changeset:

commit f9bd5843658e18a7097fc7258c60fb840109eaa8
Author: Brandon Philips 
Date:   Tue Apr 22 14:42:02 2008 -0300

V4L/DVB (7167): [v4l] Add camera class control definitions

Meant to be used on USB cameras. Until this changeset:

commit bee3d51156113363e952674504833b4bc92cf15e
Author: Pavel Machek 
Date:   Fri Aug 5 07:26:11 2016 -0300

[media] ad5820: Add driver for auto-focus coil

The only driver that were using it were uvcvideo.

As far as I remember, Brandon was working together with a Logitech
developer, in order to add support for those Quickcam Pro cameras.
So, what this control actually sets is the VCM.

That's why I don't see any need to add another control to do the same
thing.

> I anticipate adding controls for ringing compensation in the future.
> Virtually all other devices except this one do ringing compensation and
> there's some control to be done for that.

Hmm... if the idea is to have a control that doesn't do ringing
compensation, then it should be clear at the control's descriptions
that:

- V4L2_CID_FOCUS_ABSOLUTE should be used if the VCM has ringing
  compensation;
- V4L2_CID_VOICE_COIL_CURRENT and V4L2_CID_VOICE_COIL_RING_COMPENSATION
  should be used otherwise.

Btw, if the rationale for this patch is to support devices without
ring compensation, so, both controls and their descriptions should
be added at the same time, together with a patchset that would be
using both.

> How about adding such an explanation added to the commit message?

It is not enough. Documentation should be clear that VCM devices
with ring compensation should use V4L2_CID_FOCUS_ABSOLUTE.

> 
> > 
> > Worse than that, patch 2/2 gives the false sensation that both
> > controls are equal.
> > 
> > Ok, I understand that they need to be identical on the existing
> > driver, in order to keep backward compatibility, but I'm afraid
> > that, without a clear 

Re: [PATCH] [media] ov2640: make GPIOLIB an optional dependency

[Pavel Machek]

Hi!

> As warned by kbuild test robot:
>   warning: (VIDEO_EM28XX_V4L2) selects VIDEO_OV2640 which has unmet 
> direct dependencies (MEDIA_SUPPORT && VIDEO_V4L2 && I2C && GPIOLIB && 
> MEDIA_CAMERA_SUPPORT)
> 
> The em28xx driver can use ov2640, but it doesn't depend
> (or use) the GPIOLIB in order to power off/on the sensor.
> 
> So, as we want to allow both usages with and without
> GPIOLIB, make its dependency optional.

Umm. The driver will not work too well with sensor powered off, no?
Will this result in some tricky-to-debug situations?

>  config VIDEO_OV2640
>   tristate "OmniVision OV2640 sensor support"
> - depends on VIDEO_V4L2 && I2C && GPIOLIB
> + depends on VIDEO_V4L2 && I2C
>   depends on MEDIA_CAMERA_SUPPORT
>   help
> This is a Video4Linux2 sensor-level driver for the
>   OmniVision

Better solution would be for VIDEO_EM28XX_V4L2 to depend on GPIOLIB,
too, no? If not, should there be BUG_ON(priv->pwdn_gpio);
BUG_ON(priv->resetb_gpio);?


> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index d55ca37dc12f..9c00ed3543f8 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -743,13 +743,16 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int 
> on)
>   struct i2c_client *client = v4l2_get_subdevdata(sd);
>   struct ov2640_priv *priv = to_ov2640(client);
>  
> - gpiod_direction_output(priv->pwdn_gpio, !on);
> +#ifdef CONFIG_GPIOLIB
> + if (priv->pwdn_gpio)
> + gpiod_direction_output(priv->pwdn_gpio, !on);
>   if (on && priv->resetb_gpio) {
>   /* Active the resetb pin to perform a reset pulse */
>   gpiod_direction_output(priv->resetb_gpio, 1);
>   usleep_range(3000, 5000);
>   gpiod_direction_output(priv->resetb_gpio, 0);
>   }
> +#endif
>   return 0;
>  }

What is going on there? Should that be

  gpiod_direction_output(priv->resetb_gpio, 1);
  usleep_range(3000, 5000);
  gpiod_set_value(priv->resetb_gpio, 0);

for readability's sake?

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] staging: media: atomisp: fix misspelled word in comment

[Luis Oliveira]

This fix "overrided", the correct past tense form of "override" is
"overridden".

Signed-off-by: Luis Oliveira 
---
 drivers/staging/media/atomisp/i2c/ov2680.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/i2c/ov2680.c 
b/drivers/staging/media/atomisp/i2c/ov2680.c
index c08dd0b18fbb..566091035c64 100644
--- a/drivers/staging/media/atomisp/i2c/ov2680.c
+++ b/drivers/staging/media/atomisp/i2c/ov2680.c
@@ -1122,7 +1122,7 @@ static int ov2680_set_fmt(struct v4l2_subdev *sd,
}
 
/*recall flip functions to avoid flip registers
-* were overrided by default setting
+* were overridden by default setting
 */
if (h_flag)
ov2680_h_flip(sd, h_flag);
-- 
2.11.0

Re: [PATCH 1/6] drm: Add writeback connector type

[Brian Starkey]

On Wed, Apr 19, 2017 at 01:34:34PM +0200, Boris Brezillon wrote:

On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey  wrote:


[snip]


Could you expand a bit on how you think planes fit better?


Just had the impression that the writeback feature was conceptually
closer to a plane object (which is attached buffers and expose ways to
specify which portion of the buffer should be used, provides way to
atomically switch 2 buffers, ...).


Yeah sort-of, except that SRC_X/Y/W/H doesn't mean the same for an
"output" plane as an "input" plane (and CRTC_X/Y/W/H similarly,
probably other properties too).

In atomic land, the swapping of buffers is really just the swapping of
object IDs via properties - I don't think planes actually have
anything special in terms of buffer handling, except for all the
legacy state handling cruft.




It is
something we've previously talked about internally, but so far I'm not
convinced :-)


Okay, as I said, I don't know all the history, hence my questions ;-).



I think that history was here in our office rather than on the list
anyway.



>By doing that, we would also get rid of these fake connector/encoder
>objects as well as the fake modes we are returning in
>connector->get_modes().

What makes the connector/encoder fake? They represent a real piece of
hardware just the same as a drm_plane would.


Well, that's probably subject to interpretation, but I don't consider
these writeback encoders/connectors as real encoders/connectors. They
are definitely real HW blocks, but not what we usually consider as an
encoder/connector.



This is true



I don't mind dropping the mode list and letting userspace just make
up whatever timing it wants - it'd need to do the same if writeback
was a plane - but in some respects giving it a list of modes the same
way we normally do seems nicer for userspace.

>
>As far as I can tell, the VC4 and Atmel HLCDC IP should fit pretty well
>in this model, not sure about the mali-dp though.
>
>Brian, did you consider this approach, and if you did, can you detail
>why you decided to expose this feature as a connector?
>
>Daniel (or anyone else), please step in if you think this is a stupid
>idea :-).

Ville originally suggested using a connector, which Eric followed up
by saying that's what he was thinking of for VC4 writeback too[1].


Thanks for the pointer.


That was my initial reason for focussing on a connector-based
approach.

I prefer connector over plane conceptually because it keeps with the
established data flow: planes are sources, connectors are sinks.


Okay, it's a valid point.



In some respects the plane _object_ looks like it would fit - it has a
pixel format list and an FB_ID. But everything else would be acting
the exact opposite to a normal plane, and I think there's a bunch of
baked-in assumptions in the kernel and userspace around CRTCs always
having at least one connector.


Yep, but writeback connectors are already different enough to not be
considered as regular connectors, so userspace programs will have to
handle them differently anyway (pass a framebuffer and pixel format to
it before adding them to the display pipeline).

Anyway, I see this approach has already been suggested in [1], and you
all agreed that the writeback feature should be exposed as a connector,
so I'll just stop here :-).

Thanks for taking the time to explain the rationale behind this
decision.



No problem, now is the right time to be discussing the decision before
we merge something wrong.

Are you happy enough with the connector approach then? Any concerns
with going ahead with it?

Cheers,
-Brian

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

[Laurent Pinchart]

Hi Daniel,

On Wednesday 19 Apr 2017 10:36:55 Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> > Most of the items have been taken care of by a clean up series. Remove
> > the completed items and add a few new ones.
> > 
> > Signed-off-by: Laura Abbott 
> > ---
> > 
> >  drivers/staging/android/TODO | 21 -
> >  1 file changed, 4 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> > index 8f3ac37..5f14247 100644
> > --- a/drivers/staging/android/TODO
> > +++ b/drivers/staging/android/TODO
> > 
> > @@ -7,23 +7,10 @@ TODO:
> >  ion/
> > 
> > - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel
> > internal -   interface on top of dma-buf. flush_for_device needs to be
> > added to dma-buf -   first.
> > - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in
> > some -   vendor trees. Should be replaced with an ioctl on the dma-buf to
> > expose the -   begin/end_cpu_access hooks to userspace.
> > - - Clarify the tricks ion plays with explicitly managing coherency behind
> > the -   dma api's back (this is absolutely needed for high-perf gpu
> > drivers): Add an -   explicit coherency management mode to
> > flush_for_device to be used by drivers -   which want to manage caches
> > themselves and which indicates whether cpu caches -   need flushing.
> > - - With those removed there's probably no use for ION_IOC_IMPORT anymore
> > either -   since ion would just be the central allocator for shared
> > buffers. - - Add dt-binding to expose cma regions as ion heaps, with the
> > rule that any -   such cma regions must already be used by some device
> > for dma. I.e. ion only -   exposes existing cma regions and doesn't
> > reserve unecessarily memory when -   booting a system which doesn't use
> > ion.
> > + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This
> > would +   involve putting appropriate bindings in a memory node for Ion
> > to find. + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> > + - Better test framework (integration with VGEM was suggested)
> 
> Found another one: Integrate the ion kernel-doc into
> Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.

If ion is a generic-purpose allocator, should its documentation really reside 
in Documentation/gpu/ ?

> There's a lot of api and overview stuff already around, would be great to
> make this more accessible.
> 
> But I wouldn't put this as a de-staging blocker, just an idea.
> 
> On the series: Acked-by: Daniel Vetter 
> 
> No full review since a bunch of stuff I'm not too familiar with, but I
> like where this is going.
> -Daniel
> 
> >  Please send patches to Greg Kroah-Hartman  and Cc:
> >  Arve Hjønnevåg  and Riley Andrews
> >  

-- 
Regards,

Laurent Pinchart

[PATCH] [media] ov2640: make GPIOLIB an optional dependency

[Mauro Carvalho Chehab]

As warned by kbuild test robot:
warning: (VIDEO_EM28XX_V4L2) selects VIDEO_OV2640 which has unmet 
direct dependencies (MEDIA_SUPPORT && VIDEO_V4L2 && I2C && GPIOLIB && 
MEDIA_CAMERA_SUPPORT)

The em28xx driver can use ov2640, but it doesn't depend
(or use) the GPIOLIB in order to power off/on the sensor.

So, as we want to allow both usages with and without
GPIOLIB, make its dependency optional.

Reported-by: kbuild test robot 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/Kconfig  | 2 +-
 drivers/media/i2c/ov2640.c | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 40bb4bdc51da..fd181c99ce11 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -519,7 +519,7 @@ config VIDEO_SMIAPP_PLL
 
 config VIDEO_OV2640
tristate "OmniVision OV2640 sensor support"
-   depends on VIDEO_V4L2 && I2C && GPIOLIB
+   depends on VIDEO_V4L2 && I2C
depends on MEDIA_CAMERA_SUPPORT
help
  This is a Video4Linux2 sensor-level driver for the OmniVision
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index d55ca37dc12f..9c00ed3543f8 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -743,13 +743,16 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct ov2640_priv *priv = to_ov2640(client);
 
-   gpiod_direction_output(priv->pwdn_gpio, !on);
+#ifdef CONFIG_GPIOLIB
+   if (priv->pwdn_gpio)
+   gpiod_direction_output(priv->pwdn_gpio, !on);
if (on && priv->resetb_gpio) {
/* Active the resetb pin to perform a reset pulse */
gpiod_direction_output(priv->resetb_gpio, 1);
usleep_range(3000, 5000);
gpiod_direction_output(priv->resetb_gpio, 0);
}
+#endif
return 0;
 }
 
-- 
2.9.3

Re: [PATCH 1/6] drm: Add writeback connector type

[Boris Brezillon]

On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey  wrote:

> On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:
> >Hi Brian,
> >
> >On Tue, 18 Apr 2017 18:34:43 +0100
> >Brian Starkey  wrote:
> >  
> >> >> @@ -214,6 +214,19 @@ struct drm_connector_state {
> >> >> struct drm_encoder *best_encoder;
> >> >>
> >> >> struct drm_atomic_state *state;
> >> >> +
> >> >> +   /**
> >> >> +* @writeback_job: Writeback job for writeback connectors
> >> >> +*
> >> >> +* Holds the framebuffer for a writeback connector. As the 
> >> >> writeback
> >> >> +* completion may be asynchronous to the normal commit cycle, 
> >> >> the
> >> >> +* writeback job lifetime is managed separately from the normal 
> >> >> atomic
> >> >> +* state by this object.
> >> >> +*
> >> >> +* See also: drm_writeback_queue_job() and
> >> >> +* drm_writeback_signal_completion()
> >> >> +*/
> >> >> +   struct drm_writeback_job *writeback_job;  
> >> >
> >> >Maybe I'm wrong, but is feels weird to have the writeback_job field
> >> >directly embedded in drm_connector_state, while drm_writeback_connector
> >> >inherits from drm_connector.
> >> >
> >> >IMO, either you decide to directly put the drm_writeback_connector's
> >> >job_xxx fields in drm_connector and keep the drm_connector_state as is,
> >> >or you create a drm_writeback_connector_state which inherits from
> >> >drm_connector_state and embeds the writeback_job field.  
> >>
> >> I did spend a decent amount of time looking at tracking the writeback
> >> state along with the normal connector state. I couldn't come up with
> >> anything I liked.
> >>
> >> As the comment mentions, one of the problems is that you have to make
> >> sure the relevant parts of the connector_state stay around until the
> >> writeback is finished. That means you've got to block before
> >> "swap_state()" until the previous writeback is done, and that
> >> effectively limits your frame rate to refresh/2.
> >>
> >> The Mali-DP HW doesn't have that limitation - we can queue up a new
> >> commit while the current writeback is ongoing. For that reason I
> >> didn't want to impose such a limitation in the framework.
> >>
> >> In v1 I allowed that by making the Mali-DP driver hold its own
> >> references to the relevant bits of the state for as long as it needed
> >> them. In v3 I moved most of that code back to the core (in part
> >> because Gustavo didn't like me signalling the DRM-"owned" fence from
> >> my driver code directly). I think the new approach of "queue_job()"
> >> and "signal_job()" reduces the amount of tricky code in drivers, and
> >> is generally more clear (also familiar, when compared to vsync
> >> events).
> >>
> >> I'm certain there's other ways to do it (refcount atomic states?), but
> >> it seemed like a biggish overhaul to achieve what would basically be
> >> the same thing.
> >>
> >> I was expecting each driver supporting writeback to have its own
> >> different requirements around writeback lifetime/duration. For example
> >> I think VC4 specifically came up, in that its writeback could take
> >> several frames, whereas on Mali-DP we either finish within the frame
> >> or we fail.
> >>
> >> Letting the driver manage its writeback_job lifetime seemed like a
> >> reasonable way to handle all that, with the documentation stating the
> >> only behaviour which is guaranteed to work on all drivers:
> >>
> >>* Userspace should wait for this fence to signal before making 
> >> another
> >>* commit affecting any of the same CRTCs, Planes or Connectors.
> >>* **Failure to do so will result in undefined behaviour.**
> >>* For this reason it is strongly recommended that all userspace
> >>* applications making use of writeback connectors *always* retrieve 
> >> an
> >>* out-fence for the commit and use it appropriately.
> >>
> >>
> >>
> >> ... so all of that is why the _job fields don't live in a *_state
> >> structure directly, and instead have to live in the separately-managed
> >> structure pointed to by ->writeback_job.
> >>
> >> Now, I did look at creating drm_writeback_connector_state, but as it
> >> would only be holding the job pointer (see above) it didn't seem worth
> >> scattering around the
> >>
> >> if (conn_state->connector->connector_type ==
> >> DRM_MODE_CONNECTOR_WRITEBACK)
> >>
> >> checks everywhere before up-casting - {clear,reset,duplicate}_state(),
> >> prepare_signalling(), complete_signalling(), etc. It just touched a
> >> lot of code for the sake of an extra pointer field in each connector
> >> state.
> >>
> >> I can easily revisit that part if you like.  
> >
> >I think there's a misunderstanding. I was just suggesting to be
> >consistent in the inheritance vs 'one object to handle everything'
> >approach.  
> 
> doh.. right yeah I misread. Sorry for the tangent. :-)
> 

Re: [PATCH] [media] Order the Makefile alphabetically

[Mauro Carvalho Chehab]

Em Thu,  6 Apr 2017 16:40:51 +0200
Maxime Ripard  escreveu:

> The Makefiles were a free for all without a clear order defined. Sort all the
> options based on the Kconfig symbol.
> 
> Signed-off-by: Maxime Ripard 
> 
> ---
> 
> Hi Mauro,
> 
> Here is my makefile ordering patch again, this time with all the Makefiles
> in drivers/media that needed ordering.
> 
> Since we're already pretty late in the release period, I guess there won't
> be any major conflicts between now and the merge window.
> 

The thing with patches like that is that they almost never apply fine.
By the time I review such patches, it was already broken. Also,
once applied, it breaks for everybody that have pending work to merge.

This patch is broken (see attached).

So, I prefer not applying stuff like that.

Regards,
Mauro


testing if patches/lmml_40670_media_order_the_makefile_alphabetically.patch 
applies
patch -p1 -i patches/lmml_40670_media_order_the_makefile_alphabetically.patch 
--dry-run -t -N
checking file drivers/media/common/Makefile
checking file drivers/media/dvb-frontends/Makefile
checking file drivers/media/i2c/Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
checking file drivers/media/pci/Makefile
checking file drivers/media/platform/Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED
checking file drivers/media/radio/Makefile
checking file drivers/media/rc/Makefile
checking file drivers/media/tuners/Makefile
checking file drivers/media/usb/Makefile
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED
checking file drivers/media/v4l2-core/Makefile
 drivers/media/common/Makefile|2 
 drivers/media/dvb-frontends/Makefile |  220 +--
 drivers/media/i2c/Makefile   |  162 -
 drivers/media/pci/Makefile   |   34 ++---
 drivers/media/platform/Makefile  |   92 +-
 drivers/media/radio/Makefile |   62 -
 drivers/media/rc/Makefile|   74 +--
 drivers/media/tuners/Makefile|   73 +--
 drivers/media/usb/Makefile   |   34 ++---
 drivers/media/v4l2-core/Makefile |   36 ++---
 10 files changed, 381 insertions(+), 408 deletions(-)

Thanks,
Mauro

Re: [PATCH] [media] pixfmt-meta-vsp1-hgo.rst: remove spurious '-'

[Sakari Ailus]

On 04/19/17 14:04, Mauro Carvalho Chehab wrote:
> Remove spurious '-' in the VSP1 hgo table.
> 
> This resulted in a weird dot character that also caused
> the row to be double-height.
> 
> We used to have it on other tables, but we got rid of them
> on changeset 8ed29e302dd1 ("[media] subdev-formats.rst: remove
> spurious '-'").
> 
> Fixes: 14d665387165 ("[media] v4l: Define a pixel format for the R-Car VSP1 
> 1-D histogram engine")
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH 13/38] Annotate hardware config module parameters in drivers/media/

[Mauro Carvalho Chehab]

Em Wed, 05 Apr 2017 17:58:41 +0100
David Howells  escreveu:

> When the kernel is running in secure boot mode, we lock down the kernel to
> prevent userspace from modifying the running kernel image.  Whilst this
> includes prohibiting access to things like /dev/mem, it must also prevent
> access by means of configuring driver modules in such a way as to cause a
> device to access or modify the kernel image.
> 
> To this end, annotate module_param* statements that refer to hardware
> configuration and indicate for future reference what type of parameter they
> specify.  The parameter parser in the core sees this information and can
> skip such parameters with an error message if the kernel is locked down.
> The module initialisation then runs as normal, but just sees whatever the
> default values for those parameters is.
> 
> Note that we do still need to do the module initialisation because some
> drivers have viable defaults set in case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in addition
> to manually coded parameters.
> 
> This patch annotates drivers in drivers/media/.
> 
> Suggested-by: Alan Cox 
> Signed-off-by: David Howells 
> cc: Mauro Carvalho Chehab 

Acked-by: Mauro Carvalho Chehab 

> cc: mjpeg-us...@lists.sourceforge.net
> cc: linux-media@vger.kernel.org
> ---
> 
>  drivers/media/pci/zoran/zoran_card.c |2 +-
>  drivers/media/rc/serial_ir.c |   10 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/pci/zoran/zoran_card.c 
> b/drivers/media/pci/zoran/zoran_card.c
> index 5266755add63..4680f001653a 100644
> --- a/drivers/media/pci/zoran/zoran_card.c
> +++ b/drivers/media/pci/zoran/zoran_card.c
> @@ -69,7 +69,7 @@ MODULE_PARM_DESC(card, "Card type");
>   */
>  
>  static unsigned long vidmem; /* default = 0 - Video memory base address */
> -module_param(vidmem, ulong, 0444);
> +module_param_hw(vidmem, ulong, iomem, 0444);
>  MODULE_PARM_DESC(vidmem, "Default video memory base address");
>  
>  /*
> diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
> index 41b54e40176c..40d305842a9b 100644
> --- a/drivers/media/rc/serial_ir.c
> +++ b/drivers/media/rc/serial_ir.c
> @@ -833,11 +833,11 @@ MODULE_LICENSE("GPL");
>  module_param(type, int, 0444);
>  MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 = IRdeo, 2 = IRdeo 
> Remote, 3 = AnimaX, 4 = IgorPlug");
>  
> -module_param(io, int, 0444);
> +module_param_hw(io, int, ioport, 0444);
>  MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
>  
>  /* some architectures (e.g. intel xscale) have memory mapped registers */
> -module_param(iommap, bool, 0444);
> +module_param_hw(iommap, bool, other, 0444);
>  MODULE_PARM_DESC(iommap, "physical base for memory mapped I/O (0 = no memory 
> mapped io)");
>  
>  /*
> @@ -845,13 +845,13 @@ MODULE_PARM_DESC(iommap, "physical base for memory 
> mapped I/O (0 = no memory map
>   * on 32bit word boundaries.
>   * See linux-kernel/drivers/tty/serial/8250/8250.c serial_in()/out()
>   */
> -module_param(ioshift, int, 0444);
> +module_param_hw(ioshift, int, other, 0444);
>  MODULE_PARM_DESC(ioshift, "shift I/O register offset (0 = no shift)");
>  
> -module_param(irq, int, 0444);
> +module_param_hw(irq, int, irq, 0444);
>  MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
>  
> -module_param(share_irq, bool, 0444);
> +module_param_hw(share_irq, bool, other, 0444);
>  MODULE_PARM_DESC(share_irq, "Share interrupts (0 = off, 1 = on)");
>  
>  module_param(sense, int, 0444);
> 



Thanks,
Mauro

Re: [PATCH 28/38] Annotate hardware config module parameters in drivers/staging/media/

[Mauro Carvalho Chehab]

Em Wed, 05 Apr 2017 18:01:01 +0100
David Howells  escreveu:

> When the kernel is running in secure boot mode, we lock down the kernel to
> prevent userspace from modifying the running kernel image.  Whilst this
> includes prohibiting access to things like /dev/mem, it must also prevent
> access by means of configuring driver modules in such a way as to cause a
> device to access or modify the kernel image.
> 
> To this end, annotate module_param* statements that refer to hardware
> configuration and indicate for future reference what type of parameter they
> specify.  The parameter parser in the core sees this information and can
> skip such parameters with an error message if the kernel is locked down.
> The module initialisation then runs as normal, but just sees whatever the
> default values for those parameters is.
> 
> Note that we do still need to do the module initialisation because some
> drivers have viable defaults set in case parameters aren't specified and
> some drivers support automatic configuration (e.g. PNP or PCI) in addition
> to manually coded parameters.
> 
> This patch annotates drivers in drivers/staging/media/.
> 
> Suggested-by: Alan Cox 
> Signed-off-by: David Howells 
> cc: Mauro Carvalho Chehab 

Acked-by: Mauro Carvalho Chehab 

> cc: Greg Kroah-Hartman 
> cc: linux-media@vger.kernel.org
> cc: de...@driverdev.osuosl.org
> ---
> 
>  drivers/staging/media/lirc/lirc_sir.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/lirc/lirc_sir.c 
> b/drivers/staging/media/lirc/lirc_sir.c
> index c6c3de94adaa..dde46dd8cabb 100644
> --- a/drivers/staging/media/lirc/lirc_sir.c
> +++ b/drivers/staging/media/lirc/lirc_sir.c
> @@ -826,10 +826,10 @@ MODULE_AUTHOR("Milan Pikula");
>  #endif
>  MODULE_LICENSE("GPL");
>  
> -module_param(io, int, S_IRUGO);
> +module_param_hw(io, int, ioport, S_IRUGO);
>  MODULE_PARM_DESC(io, "I/O address base (0x3f8 or 0x2f8)");
>  
> -module_param(irq, int, S_IRUGO);
> +module_param_hw(irq, int, irq, S_IRUGO);
>  MODULE_PARM_DESC(irq, "Interrupt (4 or 3)");
>  
>  module_param(threshold, int, S_IRUGO);
> 



Thanks,
Mauro

[PATCH] [media] pixfmt-meta-vsp1-hgo.rst: remove spurious '-'

[Mauro Carvalho Chehab]

Remove spurious '-' in the VSP1 hgo table.

This resulted in a weird dot character that also caused
the row to be double-height.

We used to have it on other tables, but we got rid of them
on changeset 8ed29e302dd1 ("[media] subdev-formats.rst: remove
spurious '-'").

Fixes: 14d665387165 ("[media] v4l: Define a pixel format for the R-Car VSP1 1-D 
histogram engine")
Signed-off-by: Mauro Carvalho Chehab 
---
 .../media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst| 24 +++---
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst 
b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
index 8d37bb313493..67796594fd48 100644
--- a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgo.rst
@@ -53,19 +53,19 @@ contains one byte.
   - [15:8]
   - [7:0]
 * - 0
-  - -
+  -
   - R/Cr/H max [7:0]
-  - -
+  -
   - R/Cr/H min [7:0]
 * - 4
-  - -
+  -
   - G/Y/S max [7:0]
-  - -
+  -
   - G/Y/S min [7:0]
 * - 8
-  - -
+  -
   - B/Cb/V max [7:0]
-  - -
+  -
   - B/Cb/V min [7:0]
 * - 12
   - :cspan:`4` R/Cr/H sum [31:0]
@@ -104,9 +104,9 @@ contains one byte.
   - [15:8]
   - [7:0]
 * - 0
-  - -
+  -
   - max(R,G,B) max [7:0]
-  - -
+  -
   - max(R,G,B) min [7:0]
 * - 4
   - :cspan:`4` max(R,G,B) sum [31:0]
@@ -129,9 +129,9 @@ contains one byte.
   - [15:8]
   - [7:0]
 * - 0
-  - -
+  -
   - Y max [7:0]
-  - -
+  -
   - Y min [7:0]
 * - 4
   - :cspan:`4` Y sum [31:0]
@@ -154,9 +154,9 @@ contains one byte.
   - [15:8]
   - [7:0]
 * - 0
-  - -
+  -
   - max(R,G,B) max [7:0]
-  - -
+  -
   - max(R,G,B) min [7:0]
 * - 4
   - :cspan:`4` max(R,G,B) sum [31:0]
-- 
2.9.3

[PATCH] [media] mtk-vcodec: avoid warnings because of empty macros

[Mauro Carvalho Chehab]

Remove those gcc warnings:

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 
'mtk_vcodec_dec_pw_on':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: 
suggest braces around empty body in an 'if' statement [-Wempty-body]
   mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
   ^

By adding braces.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 12480837ff2e..237e144c194f 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -66,15 +66,15 @@ extern bool mtk_vcodec_dbg;
 
 #else
 
-#define mtk_v4l2_debug(level, fmt, args...)
-#define mtk_v4l2_err(fmt, args...)
-#define mtk_v4l2_debug_enter()
-#define mtk_v4l2_debug_leave()
+#define mtk_v4l2_debug(level, fmt, args...) {}
+#define mtk_v4l2_err(fmt, args...) {}
+#define mtk_v4l2_debug_enter() {}
+#define mtk_v4l2_debug_leave() {}
 
-#define mtk_vcodec_debug(h, fmt, args...)
-#define mtk_vcodec_err(h, fmt, args...)
-#define mtk_vcodec_debug_enter(h)
-#define mtk_vcodec_debug_leave(h)
+#define mtk_vcodec_debug(h, fmt, args...) {}
+#define mtk_vcodec_err(h, fmt, args...) {}
+#define mtk_vcodec_debug_enter(h) {}
+#define mtk_vcodec_debug_leave(h) {}
 
 #endif
 
-- 
2.9.3

Re: [PATCH] media: mtk-vcodec: remove informative log

[Mauro Carvalho Chehab]

Em Wed, 5 Apr 2017 19:09:59 +0800
Tiffany Lin  escreveu:

> On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > Driver is stable. Remove DEBUG definition from driver.
> > 
> > There are debug message in /var/log/messages if DEBUG is defined,
> > such as:
> > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > [MTK_V4L2] level=0 fops_vcodec_open(),177: 1600.vcodec decoder [0]
> > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> > 
> > Signed-off-by: Minghsiu Tsai   
> Acked-by:Tiffany Lin 
> 
> > ---
> >  drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
> > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > index 7d55975..1248083 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> >  extern int mtk_v4l2_dbg_level;
> >  extern bool mtk_vcodec_dbg;
> >  
> > -#define DEBUG  1
> >  
> >  #if defined(DEBUG)
> >

After this patch, building the Kernel with W=1 now shows warnings:

drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 
'mtk_vcodec_dec_pw_on':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest 
braces around empty body in an 'if' statement [-Wempty-body]
   mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
   ^

I wrote a patch fixing it, as this is really a trivial issue.

Yet, after that, this one still remains:


drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 
'mtk_vdec_pic_info_update':
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 
'ret' set but not used [-Wunused-but-set-variable]
  int ret;
  ^~~


Shouldn't be mtk_vdec_pic_info_update() returning an error code?


Also, IMHO, at least errors should be shown at dmesg.

Thanks,
Mauro

Re: [PATCH 3/3] [media] cobalt: Use v4l2_calc_timeperframe helper

[Jose Abreu]

Hi Hans,


On 31-03-2017 09:59, Jose Abreu wrote:
> Hi Hans,
>
>
> On 30-03-2017 14:42, Hans Verkuil wrote:
>> Hi Jose,
>>
>> On 21/03/17 12:49, Jose Abreu wrote:
>>> Currently, cobalt driver always returns 60fps in g_parm.
>>> This patch uses the new v4l2_calc_timeperframe helper to
>>> calculate the time per frame value.
>> I can verify that g_parm works, so:
>>
>> Tested-by: Hans Verkuil 
>>
>> However, the adv7604 pixelclock detection resolution is only 0.25 MHz, so it
>> can't tell the difference between 24 and 23.97 Hz. I can't set the new
>> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS flag there.
>>
>> It might be possible to implement this for the adv7842 receiver, I think that
>> that hardware is much more precise.
>>
>> I would have to try this, but that will have to wait until Friday next week.
> Thanks! Yes, maybe its better to test with a different receiver,
> if it has more precision then its great. Let me know if you need
> any help :)

Any news regarding this?

Best regards,
Jose Miguel Abreu

>
> Best regards,
> Jose Miguel Abreu
>
>> Regards,
>>
>>  Hans
>>
>>> Signed-off-by: Jose Abreu 
>>> Cc: Carlos Palminha 
>>> Cc: Mauro Carvalho Chehab 
>>> Cc: Hans Verkuil 
>>> Cc: linux-media@vger.kernel.org
>>> Cc: linux-ker...@vger.kernel.org
>>> ---
>>>  drivers/media/pci/cobalt/cobalt-v4l2.c | 9 +++--
>>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/media/pci/cobalt/cobalt-v4l2.c 
>>> b/drivers/media/pci/cobalt/cobalt-v4l2.c
>>> index def4a3b..25532ae 100644
>>> --- a/drivers/media/pci/cobalt/cobalt-v4l2.c
>>> +++ b/drivers/media/pci/cobalt/cobalt-v4l2.c
>>> @@ -1076,10 +1076,15 @@ static int cobalt_subscribe_event(struct v4l2_fh 
>>> *fh,
>>>  
>>>  static int cobalt_g_parm(struct file *file, void *fh, struct 
>>> v4l2_streamparm *a)
>>>  {
>>> +   struct cobalt_stream *s = video_drvdata(file);
>>> +   struct v4l2_fract fps;
>>> +
>>> if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
>>> return -EINVAL;
>>> -   a->parm.capture.timeperframe.numerator = 1;
>>> -   a->parm.capture.timeperframe.denominator = 60;
>>> +
>>> +   fps = v4l2_calc_timeperframe(>timings);
>>> +   a->parm.capture.timeperframe.numerator = fps.numerator;
>>> +   a->parm.capture.timeperframe.denominator = fps.denominator;
>>> a->parm.capture.readbuffers = 3;
>>> return 0;
>>>  }
>>>

Re: [PATCH 0/9] Unify i2c_mux_add_adapter error reporting

[Mauro Carvalho Chehab]

Em Mon, 3 Apr 2017 13:27:48 +0200
Peter Rosin  escreveu:

> On 2017-04-03 12:27, Wolfram Sang wrote:
> > On Mon, Apr 03, 2017 at 10:38:29AM +0200, Peter Rosin wrote:  
> >> Hi!
> >>
> >> Many users of the i2c_mux_add_adapter interface log a message
> >> on failure, but the function already logs such a message. One
> >> or two of those users actually add more information than already
> >> provided by the central failure message.
> >>
> >> So, first fix the central error reporting to provide as much
> >> information as any current user, and then remove the surplus
> >> error reporting at the call sites.  
> > 
> > Yes, I like.
> > 
> > Reviewed-by: Wolfram Sang   
> 
> Thanks!
> 
> BTW, the improved error reporting in patch 1/9 is not needed for
> patches 8/9 and 9/9 to make sense, the existing central error
> message is already good enough. So, iio and media maintainers,
> feel free to just grab those two patches. Or, they can go via
> Wolfram and the i2c tree with the rest of the series. Either way
> is fine with me, just let me know.

Feel free to submit via I2C tree, together with the patch series:

Reviewed-by: Mauro Carvalho Chehab 

> 
> Cheers,
> peda



Thanks,
Mauro

Re: [PATCH 1/6] drm: Add writeback connector type

[Brian Starkey]

On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:

Hi Brian,

On Tue, 18 Apr 2017 18:34:43 +0100
Brian Starkey  wrote:


>> @@ -214,6 +214,19 @@ struct drm_connector_state {
>>struct drm_encoder *best_encoder;
>>
>>struct drm_atomic_state *state;
>> +
>> +  /**
>> +   * @writeback_job: Writeback job for writeback connectors
>> +   *
>> +   * Holds the framebuffer for a writeback connector. As the writeback
>> +   * completion may be asynchronous to the normal commit cycle, the
>> +   * writeback job lifetime is managed separately from the normal atomic
>> +   * state by this object.
>> +   *
>> +   * See also: drm_writeback_queue_job() and
>> +   * drm_writeback_signal_completion()
>> +   */
>> +  struct drm_writeback_job *writeback_job;
>
>Maybe I'm wrong, but is feels weird to have the writeback_job field
>directly embedded in drm_connector_state, while drm_writeback_connector
>inherits from drm_connector.
>
>IMO, either you decide to directly put the drm_writeback_connector's
>job_xxx fields in drm_connector and keep the drm_connector_state as is,
>or you create a drm_writeback_connector_state which inherits from
>drm_connector_state and embeds the writeback_job field.

I did spend a decent amount of time looking at tracking the writeback
state along with the normal connector state. I couldn't come up with
anything I liked.

As the comment mentions, one of the problems is that you have to make
sure the relevant parts of the connector_state stay around until the
writeback is finished. That means you've got to block before
"swap_state()" until the previous writeback is done, and that
effectively limits your frame rate to refresh/2.

The Mali-DP HW doesn't have that limitation - we can queue up a new
commit while the current writeback is ongoing. For that reason I
didn't want to impose such a limitation in the framework.

In v1 I allowed that by making the Mali-DP driver hold its own
references to the relevant bits of the state for as long as it needed
them. In v3 I moved most of that code back to the core (in part
because Gustavo didn't like me signalling the DRM-"owned" fence from
my driver code directly). I think the new approach of "queue_job()"
and "signal_job()" reduces the amount of tricky code in drivers, and
is generally more clear (also familiar, when compared to vsync
events).

I'm certain there's other ways to do it (refcount atomic states?), but
it seemed like a biggish overhaul to achieve what would basically be
the same thing.

I was expecting each driver supporting writeback to have its own
different requirements around writeback lifetime/duration. For example
I think VC4 specifically came up, in that its writeback could take
several frames, whereas on Mali-DP we either finish within the frame
or we fail.

Letting the driver manage its writeback_job lifetime seemed like a
reasonable way to handle all that, with the documentation stating the
only behaviour which is guaranteed to work on all drivers:

   * Userspace should wait for this fence to signal before making another
   * commit affecting any of the same CRTCs, Planes or Connectors.
   * **Failure to do so will result in undefined behaviour.**
   * For this reason it is strongly recommended that all userspace
   * applications making use of writeback connectors *always* retrieve an
   * out-fence for the commit and use it appropriately.



... so all of that is why the _job fields don't live in a *_state
structure directly, and instead have to live in the separately-managed
structure pointed to by ->writeback_job.

Now, I did look at creating drm_writeback_connector_state, but as it
would only be holding the job pointer (see above) it didn't seem worth
scattering around the

if (conn_state->connector->connector_type ==
DRM_MODE_CONNECTOR_WRITEBACK)

checks everywhere before up-casting - {clear,reset,duplicate}_state(),
prepare_signalling(), complete_signalling(), etc. It just touched a
lot of code for the sake of an extra pointer field in each connector
state.

I can easily revisit that part if you like.


I think there's a misunderstanding. I was just suggesting to be
consistent in the inheritance vs 'one object to handle everything'
approach.


doh.. right yeah I misread. Sorry for the tangent. :-)



I'm perfectly fine with embedding the writeback_job pointer directly in
drm_connector_state, but then it would IMO make more sense to do the
same for the drm_connector object (embed drm_writeback_connector fields
into drm_connector instead of making drm_writeback_connector inherit
from drm_connector).



I agree that it's inconsistent. I guess I did it out of pragmatism -
there's quite a lot of new fields in drm_writeback_connector, and the
code needed to support it was comparatively small. On the other hand
there's only one additional field in drm_connector_state and the code
required to subclass 

Re: [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list

[Daniel Vetter]

On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> Most of the items have been taken care of by a clean up series. Remove
> the completed items and add a few new ones.
> 
> Signed-off-by: Laura Abbott 
> ---
>  drivers/staging/android/TODO | 21 -
>  1 file changed, 4 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> index 8f3ac37..5f14247 100644
> --- a/drivers/staging/android/TODO
> +++ b/drivers/staging/android/TODO
> @@ -7,23 +7,10 @@ TODO:
>  
>  
>  ion/
> - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel 
> internal
> -   interface on top of dma-buf. flush_for_device needs to be added to dma-buf
> -   first.
> - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some
> -   vendor trees. Should be replaced with an ioctl on the dma-buf to expose 
> the
> -   begin/end_cpu_access hooks to userspace.
> - - Clarify the tricks ion plays with explicitly managing coherency behind the
> -   dma api's back (this is absolutely needed for high-perf gpu drivers): Add 
> an
> -   explicit coherency management mode to flush_for_device to be used by 
> drivers
> -   which want to manage caches themselves and which indicates whether cpu 
> caches
> -   need flushing.
> - - With those removed there's probably no use for ION_IOC_IMPORT anymore 
> either
> -   since ion would just be the central allocator for shared buffers.
> - - Add dt-binding to expose cma regions as ion heaps, with the rule that any
> -   such cma regions must already be used by some device for dma. I.e. ion 
> only
> -   exposes existing cma regions and doesn't reserve unecessarily memory when
> -   booting a system which doesn't use ion.
> + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
> +   involve putting appropriate bindings in a memory node for Ion to find.
> + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> + - Better test framework (integration with VGEM was suggested)

Found another one: Integrate the ion kernel-doc into
Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.
There's a lot of api and overview stuff already around, would be great to
make this more accessible.

But I wouldn't put this as a de-staging blocker, just an idea.

On the series: Acked-by: Daniel Vetter 

No full review since a bunch of stuff I'm not too familiar with, but I
like where this is going.
-Daniel

>  
>  Please send patches to Greg Kroah-Hartman  and Cc:
>  Arve Hjønnevåg  and Riley Andrews 
> -- 
> 2.7.4
> 
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Linaro-mm-sig] [PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client

[Daniel Vetter]

On Tue, Apr 18, 2017 at 11:27:12AM -0700, Laura Abbott wrote:
> ion_handle was introduced as an abstraction to represent a reference to
> a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
> emerged as the preferred standard for use in the kernel. This has made
> the ion_handle an unnecessary abstraction and prone to race
> conditions. ion_client is also now only used internally. We have enough
> mechanisms for race conditions and leaks already so just drop ion_handle
> and ion_client. This also includes ripping out most of the debugfs
> infrastructure since much of that was tied to clients and handles.
> The debugfs infrastructure was prone to give confusing data (orphaned
> allocations) so it can be replaced with something better if people
> actually want it.
> 
> Signed-off-by: Laura Abbott 

Yeah I think improving the dma-buf debugfs stuff (maybe with an allocator
callback to dump additional data) is the better option.

Acked-by: Daniel Vetter 
> ---
>  drivers/staging/android/ion/ion-ioctl.c |  53 +--
>  drivers/staging/android/ion/ion.c   | 701 
> ++--
>  drivers/staging/android/ion/ion.h   |  77 +---
>  drivers/staging/android/uapi/ion.h  |  25 +-
>  4 files changed, 51 insertions(+), 805 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion-ioctl.c 
> b/drivers/staging/android/ion/ion-ioctl.c
> index 4e7bf16..76427e4 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -21,9 +21,7 @@
>  #include "ion.h"
>  
>  union ion_ioctl_arg {
> - struct ion_fd_data fd;
>   struct ion_allocation_data allocation;
> - struct ion_handle_data handle;
>   struct ion_heap_query query;
>  };
>  
> @@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
> ion_ioctl_arg *arg)
>  static unsigned int ion_ioctl_dir(unsigned int cmd)
>  {
>   switch (cmd) {
> - case ION_IOC_FREE:
> - return _IOC_WRITE;
>   default:
>   return _IOC_DIR(cmd);
>   }
> @@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
>  
>  long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  {
> - struct ion_client *client = filp->private_data;
> - struct ion_handle *cleanup_handle = NULL;
>   int ret = 0;
>   unsigned int dir;
>   union ion_ioctl_arg data;
> @@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
> unsigned long arg)
>   switch (cmd) {
>   case ION_IOC_ALLOC:
>   {
> - struct ion_handle *handle;
> + int fd;
>  
> - handle = ion_alloc(client, data.allocation.len,
> + fd = ion_alloc(data.allocation.len,
>   data.allocation.heap_id_mask,
>   data.allocation.flags);
> - if (IS_ERR(handle))
> - return PTR_ERR(handle);
> + if (fd < 0)
> + return fd;
>  
> - data.allocation.handle = handle->id;
> + data.allocation.fd = fd;
>  
> - cleanup_handle = handle;
> - break;
> - }
> - case ION_IOC_FREE:
> - {
> - struct ion_handle *handle;
> -
> - mutex_lock(>lock);
> - handle = ion_handle_get_by_id_nolock(client,
> -  data.handle.handle);
> - if (IS_ERR(handle)) {
> - mutex_unlock(>lock);
> - return PTR_ERR(handle);
> - }
> - ion_free_nolock(client, handle);
> - ion_handle_put_nolock(handle);
> - mutex_unlock(>lock);
> - break;
> - }
> - case ION_IOC_SHARE:
> - {
> - struct ion_handle *handle;
> -
> - handle = ion_handle_get_by_id(client, data.handle.handle);
> - if (IS_ERR(handle))
> - return PTR_ERR(handle);
> - data.fd.fd = ion_share_dma_buf_fd(client, handle);
> - ion_handle_put(handle);
> - if (data.fd.fd < 0)
> - ret = data.fd.fd;
>   break;
>   }
>   case ION_IOC_HEAP_QUERY:
> - ret = ion_query_heaps(client, );
> + ret = ion_query_heaps();
>   break;
>   default:
>   return -ENOTTY;
>   }
>  
>   if (dir & _IOC_READ) {
> - if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd))) {
> - if (cleanup_handle)
> - ion_free(client, cleanup_handle);
> + if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
>   return -EFAULT;
> - }
>   }
>   return ret;
>  }
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 

Re: [Linaro-mm-sig] [PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress

[Daniel Vetter]

On Tue, Apr 18, 2017 at 11:27:07AM -0700, Laura Abbott wrote:
> Several of the Ion ioctls were designed in such a way that they
> necessitate compat ioctls. We're breaking a bunch of other ABIs and
> cleaning stuff up anyway so let's follow the ioctl guidelines and clean
> things up while everyone is busy converting things over anyway. As part
> of this, also remove the useless alignment field from the allocation
> structure.
> 
> Signed-off-by: Laura Abbott 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/staging/android/ion/Makefile |   3 -
>  drivers/staging/android/ion/compat_ion.c | 152 
> ---
>  drivers/staging/android/ion/compat_ion.h |  29 --
>  drivers/staging/android/ion/ion-ioctl.c  |   1 -
>  drivers/staging/android/ion/ion.c|   5 +-
>  drivers/staging/android/uapi/ion.h   |  19 ++--
>  6 files changed, 11 insertions(+), 198 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/compat_ion.c
>  delete mode 100644 drivers/staging/android/ion/compat_ion.h
> 
> diff --git a/drivers/staging/android/ion/Makefile 
> b/drivers/staging/android/ion/Makefile
> index 66d0c4a..a892afa 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -2,6 +2,3 @@ obj-$(CONFIG_ION) +=  ion.o ion-ioctl.o ion_heap.o \
>   ion_page_pool.o ion_system_heap.o \
>   ion_carveout_heap.o ion_chunk_heap.o
>  obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> -ifdef CONFIG_COMPAT
> -obj-$(CONFIG_ION) += compat_ion.o
> -endif
> diff --git a/drivers/staging/android/ion/compat_ion.c 
> b/drivers/staging/android/ion/compat_ion.c
> deleted file mode 100644
> index 5037ddd..000
> --- a/drivers/staging/android/ion/compat_ion.c
> +++ /dev/null
> @@ -1,152 +0,0 @@
> -/*
> - * drivers/staging/android/ion/compat_ion.c
> - *
> - * Copyright (C) 2013 Google, Inc.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * 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.
> - *
> - */
> -
> -#include 
> -#include 
> -#include 
> -
> -#include "ion.h"
> -#include "compat_ion.h"
> -
> -/* See drivers/staging/android/uapi/ion.h for the definition of these 
> structs */
> -struct compat_ion_allocation_data {
> - compat_size_t len;
> - compat_size_t align;
> - compat_uint_t heap_id_mask;
> - compat_uint_t flags;
> - compat_int_t handle;
> -};
> -
> -struct compat_ion_handle_data {
> - compat_int_t handle;
> -};
> -
> -#define COMPAT_ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
> -   struct compat_ion_allocation_data)
> -#define COMPAT_ION_IOC_FREE  _IOWR(ION_IOC_MAGIC, 1, \
> -   struct compat_ion_handle_data)
> -
> -static int compat_get_ion_allocation_data(
> - struct compat_ion_allocation_data __user *data32,
> - struct ion_allocation_data __user *data)
> -{
> - compat_size_t s;
> - compat_uint_t u;
> - compat_int_t i;
> - int err;
> -
> - err = get_user(s, >len);
> - err |= put_user(s, >len);
> - err |= get_user(s, >align);
> - err |= put_user(s, >align);
> - err |= get_user(u, >heap_id_mask);
> - err |= put_user(u, >heap_id_mask);
> - err |= get_user(u, >flags);
> - err |= put_user(u, >flags);
> - err |= get_user(i, >handle);
> - err |= put_user(i, >handle);
> -
> - return err;
> -}
> -
> -static int compat_get_ion_handle_data(
> - struct compat_ion_handle_data __user *data32,
> - struct ion_handle_data __user *data)
> -{
> - compat_int_t i;
> - int err;
> -
> - err = get_user(i, >handle);
> - err |= put_user(i, >handle);
> -
> - return err;
> -}
> -
> -static int compat_put_ion_allocation_data(
> - struct compat_ion_allocation_data __user *data32,
> - struct ion_allocation_data __user *data)
> -{
> - compat_size_t s;
> - compat_uint_t u;
> - compat_int_t i;
> - int err;
> -
> - err = get_user(s, >len);
> - err |= put_user(s, >len);
> - err |= get_user(s, >align);
> - err |= put_user(s, >align);
> - err |= get_user(u, >heap_id_mask);
> - err |= put_user(u, >heap_id_mask);
> - err |= get_user(u, >flags);
> - err |= put_user(u, >flags);
> - err |= get_user(i, >handle);
> - err |= put_user(i, >handle);
> -
> - return err;
> -}
> -
> -long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> -{
> - long ret;
> -
> - if 

[GIT PULL FOR v4.12] cec: clean up Kconfig, headers

[Hans Verkuil]

Hi Mauro,

This should be merged for 4.12 before more CEC drivers are merged.

>From the cover letter of the patch series:

-
This patch series cleans up the various CEC config options.

In particular it adds a CEC_CORE config option which is what CEC drivers
should depend on, and it removes the MEDIA_CEC_EDID config option which
was rather pointless.

Finally it adds a new option to explicitly enable the RC passthrough
support in CEC.

It also moves cec-edid.c and cec-notifier.c to the media/cec directory
and merges them into the cec module instead of having separate modules
for these. And the cec-edid.h header is merged into cec.h.

CEC drivers now just depend on CEC_CORE. And if the CEC drivers needs
the CEC notifier framework, then it has to select CEC_NOTIFIER.
-

Now is a good time to merge this since all CEC drivers are currently in
media. For 4.13 I expect CEC drivers to appear in drm as well (omap4 among
others), so cleaning this up now while we don't have to deal with
cross-subsystem complications make this a lot easier.

Regards,

Hans


The following changes since commit ee0fe833d96793853335844b6d99fb76bd12cbeb:

  [media] zr364xx: enforce minimum size when reading header (2017-04-18 
12:57:29 -0300)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git cec

for you to fetch changes up to 27f54990cf6beec89e439e21e532fab15d973af4:

  cec: add MEDIA_CEC_RC config option (2017-04-18 23:26:03 +0200)


Hans Verkuil (3):
  cec: Kconfig cleanup
  cec.h: merge cec-edid.h into cec.h
  cec: add MEDIA_CEC_RC config option

 MAINTAINERS  |   3 --
 drivers/media/Kconfig|  26 ---
 drivers/media/Makefile   |  14 ++--
 drivers/media/cec/Kconfig|  19 +++
 drivers/media/cec/Makefile   |   8 +++--
 drivers/media/cec/cec-adap.c |   4 +--
 drivers/media/cec/cec-core.c |  12 +++
 drivers/media/{ => cec}/cec-edid.c   |   6 +---
 drivers/media/{ => cec}/cec-notifier.c   |   1 +
 drivers/media/i2c/Kconfig|   9 ++
 drivers/media/platform/Kconfig   |  56 
 drivers/media/platform/s5p-cec/s5p_cec.c |   1 -
 drivers/media/platform/vivid/Kconfig |   3 +-
 drivers/media/usb/pulse8-cec/Kconfig |   2 +-
 drivers/media/usb/rainshadow-cec/Kconfig |   2 +-
 include/media/cec-edid.h | 104 
---
 include/media/cec-notifier.h |   2 +-
 include/media/cec.h  | 104 
+--
 18 files changed, 180 insertions(+), 196 deletions(-)
 create mode 100644 drivers/media/cec/Kconfig
 rename drivers/media/{ => cec}/cec-edid.c (96%)
 rename drivers/media/{ => cec}/cec-notifier.c (99%)
 delete mode 100644 include/media/cec-edid.h