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 Aug 10 05:00:17 CEST 2017
media-tree git hash:ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0
media_build git hash:   3a2afb881d1efadba33831f9c56321c4bcbe7178
v4l-utils git hash: 8824782aaa2d22ca6ca21afb054c189caf3c3531
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.11.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
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: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.4.22-i686: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: WARNINGS
linux-4.9.26-i686: WARNINGS
linux-4.10.14-i686: WARNINGS
linux-4.11-i686: WARNINGS
linux-4.12.1-i686: WARNINGS
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: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
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: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.22-x86_64: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: ERRORS

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 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Carlos Santa]

On Tue, 2017-07-11 at 15:30 +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Implement support for this DisplayPort feature.
> 
> The cec device is created whenever it detects an adapter that
> has this feature. It is only removed when a new adapter is connected
> that does not support this. If a new adapter is connected that has
> different properties than the previous one, then the old cec device
> is
> unregistered and a new one is registered to replace the old one.
> 
> Signed-off-by: Hans Verkuil 
> ---

This was tested internally using the EE-PW700 adapter (DisplayPort/USB-
C to HDMI) from Samsung on a Skylake platform.

Several commands were tested including: 

# cec-ctl --playback

# turns the TV off
# cec-ctl -t=0 --standby

# turns the TV on
# cec-ctl -t=0 --image-view-on

The cec-compliance binary was also run and it reported no failures.

Tested-by: Carlos Santa 

>  drivers/gpu/drm/i915/intel_dp.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 64fa774c855b..fdb853d2c458 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp
> *intel_dp)
>  static void
>  intel_dp_aux_fini(struct intel_dp *intel_dp)
>  {
> + cec_unregister_adapter(intel_dp->aux.cec_adap);
>   kfree(intel_dp->aux.name);
>  }
>  
> @@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>   intel_connector->detect_edid = edid;
>  
>   intel_dp->has_audio = drm_detect_monitor_audio(edid);
> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>  }
>  
>  static void
> @@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>  
>   kfree(intel_connector->detect_edid);
>   intel_connector->detect_edid = NULL;
> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>  
>   intel_dp->has_audio = false;
>  }
> @@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector
> *intel_connector)
>   intel_display_power_get(to_i915(dev), intel_dp-
> >aux_power_domain);
>  
>   /* Can't disconnect eDP, but you can close the lid... */
> - if (is_edp(intel_dp))
> + if (is_edp(intel_dp)) {
>   status = edp_detect(intel_dp);
> - else if (intel_digital_port_connected(to_i915(dev),
> -   dp_to_dig_port(intel_d
> p)))
> + } else if (intel_digital_port_connected(to_i915(dev),
> + dp_to_dig_port(intel
> _dp))) {
>   status = intel_dp_detect_dpcd(intel_dp);
> - else
> + if (status == connector_status_connected)
> + drm_dp_cec_configure_adapter(_dp->aux,
> +  intel_dp->aux.name, dev->dev);
> + } else {
>   status = connector_status_disconnected;
> + }
>  
>   if (status == connector_status_disconnected) {
>   memset(_dp->compliance, 0, sizeof(intel_dp-
> >compliance));
> @@ -5011,6 +5019,8 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
>  
>   intel_display_power_get(dev_priv, intel_dp-
> >aux_power_domain);
>  
> + drm_dp_cec_irq(_dp->aux);
> +
>   if (intel_dp->is_mst) {
>   if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
> {
>   /*

Re: [PATCH 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Carlos Santa]

On Tue, 2017-07-11 at 15:30 +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.
> 
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this capability actually hook up the CEC pin, so
> even though a CEC device is created, it may not actually work.
> 
> Signed-off-by: Hans Verkuil 
> ---

This was tested internally using the EE-PW700 adapter (DisplayPort/USB-
C to HDMI) from Samsung on a Skylake platform.

Several commands were tested including: 

# cec-ctl --playback

# turns the TV off
# cec-ctl -t=0 --standby

# turns the TV on
# cec-ctl -t=0 --image-view-on

The cec-compliance binary was also run and it reported no failures.

Tested-by: Carlos Santa 


>  drivers/gpu/drm/Kconfig  |  10 ++
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/drm_dp_cec.c | 308
> +++
>  include/drm/drm_dp_helper.h  |  24 
>  4 files changed, 343 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83cb2a88c204..1f2708df5c4e 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
>     default case is N. Details and instructions how to build
> your own
>     EDID data are given in Documentation/EDID/HOWTO.txt.
>  
> +config DRM_DP_CEC
> + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI
> support"
> + select CEC_CORE
> + help
> +   Choose this option if you want to enable HDMI CEC support
> for
> +   DisplayPort/USB-C to HDMI adapters.
> +
> +   Note: not all adapters support this feature, and even for
> those
> +   that do support this they often do not hook up the CEC
> pin.
> +
>  config DRM_TTM
>   tristate
>   depends on DRM && MMU
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 24a066e1841c..c6552c62049e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) +=
> drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
>  
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
> diff --git a/drivers/gpu/drm/drm_dp_cec.c
> b/drivers/gpu/drm/drm_dp_cec.c
> new file mode 100644
> index ..7f2e298d45c0
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -0,0 +1,308 @@
> +/*
> + * DisplayPort CEC-Tunneling-over-AUX support
> + *
> + * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All
> rights reserved.
> + *
> + * This program is free software; you may redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License as published
> by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
> AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Unfortunately it turns out that we have a chicken-and-egg
> situation
> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI
> adapters
> + * have a converter chip that supports CEC-Tunneling-over-AUX
> (usually the
> + * Parade PS176), but they do not wire up the CEC pin, thus making
> CEC
> + * useless.
> + *
> + * Sadly there is no way for this driver to know this. What happens
> is
> + * that a /dev/cecX device is created that is isolated and unable to
> see
> + * any of the other CEC devices. Quite literally the CEC wire is cut
> + * (or in this case, never connected in the first place).
> + *
> + * I suspect that the reason so few adapters support this is that
> this
> + * tunneling protocol was never supported by any OS. So there was no
> + * easy way of testing it, and no incentive to correctly wire up the
> + * CEC pin.
> + *
> + * Hopefully by creating this driver it will be easier for vendors
> to
> + * finally fix their adapters and test the CEC functionality.
> + *
> + * I keep a list of known working adapters here:
> + *
> + * https://hverkuil.home.xs4all.nl/cec-status.txt
> + *
> + * Please mail me 

[PATCH v2] media: ov5670: Fix incorrect frame timing reported to user

[Chiranjeevi Rapolu]

Previously, pixel-rate/(pixels-per-line * lines-per-frame) was
yielding incorrect frame timing for the user.

OV sensor is using internal timing and this requires
conversion (internal timing -> PPL) for correct HBLANK calculation.

Now, change pixels-per-line domain from internal sensor clock to
pixels domain. Set HBLANK read-only because fixed PPL is used for all
resolutions. And, use more accurate link-frequency 422.4MHz instead of
rounding down to 420MHz.

Signed-off-by: Chiranjeevi Rapolu 
---
Changes in v2:
- Change subject to reflect frame timing info.
- Change OV5670_DEF_PPL so that it doesn't convey a register default
  value. And, add more comments to it.
 drivers/media/i2c/ov5670.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
index 8d8e16c..b9d4dd2 100644
--- a/drivers/media/i2c/ov5670.c
+++ b/drivers/media/i2c/ov5670.c
@@ -37,7 +37,13 @@
 
 /* horizontal-timings from sensor */
 #define OV5670_REG_HTS 0x380c
-#define OV5670_DEF_PPL 3360/* Default pixels per line */
+
+/*
+ * Pixels-per-line(PPL) = Time-per-line * pixel-rate
+ * In OV5670, Time-per-line = HTS/SCLK.
+ * HTS is fixed for all resolutions, not recommended to change.
+ */
+#define OV5670_FIXED_PPL   2724/* Pixels per line */
 
 /* Exposure controls from sensor */
 #define OV5670_REG_EXPOSURE0x3500
@@ -1705,12 +1711,12 @@ struct ov5670_mode {
 };
 
 /* Supported link frequencies */
-#define OV5670_LINK_FREQ_420MHZ42000
-#define OV5670_LINK_FREQ_420MHZ_INDEX  0
+#define OV5670_LINK_FREQ_422MHZ42240
+#define OV5670_LINK_FREQ_422MHZ_INDEX  0
 static const struct ov5670_link_freq_config link_freq_configs[] = {
{
/* pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
-   .pixel_rate = (OV5670_LINK_FREQ_420MHZ * 2 * 2) / 10,
+   .pixel_rate = (OV5670_LINK_FREQ_422MHZ * 2 * 2) / 10,
.reg_list = {
.num_of_regs = ARRAY_SIZE(mipi_data_rate_840mbps),
.regs = mipi_data_rate_840mbps,
@@ -1719,7 +1725,7 @@ struct ov5670_mode {
 };
 
 static const s64 link_freq_menu_items[] = {
-   OV5670_LINK_FREQ_420MHZ
+   OV5670_LINK_FREQ_422MHZ
 };
 
 /*
@@ -1736,7 +1742,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_2592x1944_regs),
.regs = mode_2592x1944_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 1296,
@@ -1746,7 +1752,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_1296x972_regs),
.regs = mode_1296x972_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 648,
@@ -1756,7 +1762,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_648x486_regs),
.regs = mode_648x486_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 2560,
@@ -1766,7 +1772,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_2560x1440_regs),
.regs = mode_2560x1440_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 1280,
@@ -1776,7 +1782,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_1280x720_regs),
.regs = mode_1280x720_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 640,
@@ -1786,7 +1792,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_640x360_regs),
.regs = mode_640x360_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
}
 };
 
@@ -2016,13 +2022,6 @@ static int ov5670_set_ctrl(struct v4l2_ctrl *ctrl)
   OV5670_REG_VALUE_16BIT,
   ov5670->cur_mode->height + ctrl->val);
break;
-   case V4L2_CID_HBLANK:
-   /* Update HTS that meets expected horizontal blanking */
-   ret = 

Re: [PATCH 2/2] cec: fix remote control passthrough

[Sean Young]

On Tue, Aug 08, 2017 at 10:11:13AM +0200, Hans Verkuil wrote:
> On 07/08/17 22:58, Sean Young wrote:
> > On Mon, Aug 07, 2017 at 03:31:24PM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> The 'Press and Hold' operation was not correctly implemented, in
> >> particular the requirement that the repeat doesn't start until
> >> the second identical keypress arrives. The REP_DELAY value also
> >> had to be adjusted (see the comment in the code) to achieve the
> >> desired behavior.
> > 
> > I'm afraid I've caused some confusion; I had not read your last message
> > about autorepeat on irc correctly, when I said "exactly".
> > 
> > So if the input layer has not received a key up event after a key down
> > event, after REP_DELAY it will generate another key down event every
> > REP_PERIOD. So for example, here I'm holding a button on a rc-5 device
> > for some time. Comments on lines with parentheses.
> > 
> > # ir-keytable -t
> > Testing events. Please, press CTRL-C to abort.
> > 1502138577.703695: event type EV_MSC(0x04): scancode = 0x1e11
> > (each time a driver receives something, scancode is reported.)
> > 1502138577.703695: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
> > 1502138577.703695: event type EV_SYN(0x00).
> > 1502138577.817682: event type EV_MSC(0x04): scancode = 0x1e11
> > 1502138577.817682: event type EV_SYN(0x00).
> > (rc-5 repeats the command after 115ms).
> > 1502138577.930676: event type EV_MSC(0x04): scancode = 0x1e11
> > 1502138577.930676: event type EV_SYN(0x00).
> > 1502138578.044682: event type EV_MSC(0x04): scancode = 0x1e11
> > 1502138578.044682: event type EV_SYN(0x00).
> > 1502138578.181690: event type EV_MSC(0x04): scancode = 0x1e11
> > 1502138578.181690: event type EV_SYN(0x00).
> > 1502138578.205667: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
> > (this is 500ms after the initial key down, so this key down is generated
> > by the input layer).
> > 1502138578.205667: event type EV_SYN(0x00).
> > 1502138578.333667: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072)
> > (this is 500 + 125 ms, so another key down event generated by input layer).
> > 1502138578.333667: event type EV_SYN(0x00).
> > 1502138578.437662: event type EV_KEY(0x01) key_up: KEY_VOLUMEDOWN(0x0072)
> > 1502138578.437662: event type EV_SYN(0x00).
> > (key up generated by rc-core after 250ms after last scancode received)
> > 
> > So I think the autorepeat can do exactly what you want, without cec
> > having any special code for it.
> 
> It comes close, but not quite, to what I need. It has more to do with the
> CEC peculiarities than the rc code.
> 
> Specifically the CEC spec strongly recommends that the first reported key
> press is always handled as a single non-repeating key press. Only if a second
> identical key press is received within 550 ms will the 'Press and Hold' 
> feature
> kick in and will the key start repeating. This until a Release message is
> received, a different key press is received or nothing is received for 550 ms.

Right, that make sense.

> Effectively the REP_DELAY is equal to the time between the first and second
> key press message, and it immediately switches to repeat mode once the second
> key press is received.
> 
> This code models this behavior exactly.

Ok, although you're sending a keyup directly after the first keydown.
Another way of doing this is to set REP_DELAY/REP_PERIOD to 0 and
sending the repeats yourself.

I'm not sure it's worth it just to prevent the keyup.


Sean

> 
> Regards,
> 
>   Hans
> 
> > 
> > On a side note, here you can see that for rc-5 the IR_KEYPRESS_TIMEOUT
> > should be 115ms (with a little extra margin). 
> > 
> > My apologies.
> > 
> > Sean
> > 
> >>
> >> The 'enabled_protocols' field was also never set, fix that too. Since
> >> CEC is a fixed protocol the driver has to set this field.
> >>
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >>  drivers/media/cec/cec-adap.c | 56 
> >> 
> >>  drivers/media/cec/cec-core.c | 13 ++
> >>  include/media/cec.h  |  5 
> >>  3 files changed, 69 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
> >> index 1a021828c8d4..6a2f38f000e8 100644
> >> --- a/drivers/media/cec/cec-adap.c
> >> +++ b/drivers/media/cec/cec-adap.c
> >> @@ -1766,6 +1766,9 @@ static int cec_receive_notify(struct cec_adapter 
> >> *adap, struct cec_msg *msg,
> >>int la_idx = cec_log_addr2idx(adap, dest_laddr);
> >>bool from_unregistered = init_laddr == 0xf;
> >>struct cec_msg tx_cec_msg = { };
> >> +#ifdef CONFIG_MEDIA_CEC_RC
> >> +  int scancode;
> >> +#endif
> >>  
> >>dprintk(2, "%s: %*ph\n", __func__, msg->len, msg->msg);
> >>  
> >> @@ -1854,11 +1857,9 @@ static int cec_receive_notify(struct cec_adapter 
> >> *adap, struct cec_msg *msg,
> >> */
> >>case 0x60:
> >>

Re: [PATCH v1] media: ov5670: Fix incorrect fps reported by user

[Sakari Ailus]

Hi Chiranjeevi,

On the subject --- this isn't fps as such, but frame timing information in
general. How about "Fix incorrect frame timing reported to user"?

On Wed, Aug 09, 2017 at 12:17:42PM -0700, Chiranjeevi Rapolu wrote:
> Previously, pixel-rate/(pixels-per-line * lines-per-frame) was
> yielding incorrect fps for the user. This results in much lower fps

Same here.

> reported by user than the actual fps on the bus.
> 
> OV sensor is using internal timing and this requires
> conversion (internal timing -> PPL) for correct HBLANK calculation.
> 
> Now, change pixels-per-line domain from internal sensor clock to
> pixels domain. Set HBLANK read-only because fixed PPL is used for all
> resolutions. And, use more accurate link-frequency 422.4MHz instead of
> rounding down to 420MHz.
> 
> Signed-off-by: Chiranjeevi Rapolu 
> ---
>  drivers/media/i2c/ov5670.c | 31 +--
>  1 file changed, 13 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
> index 8d8e16c..f42b21e 100644
> --- a/drivers/media/i2c/ov5670.c
> +++ b/drivers/media/i2c/ov5670.c
> @@ -37,7 +37,7 @@
>  
>  /* horizontal-timings from sensor */
>  #define OV5670_REG_HTS   0x380c
> -#define OV5670_DEF_PPL   3360/* Default pixels per 
> line */
> +#define OV5670_DEF_PPL   2724/* Default pixels per 
> line */

This isn't a register value, is it? And it reflects the configuration in
the register lists?

If the above is the case, could you add a comment on it? The way it's
written above implies that this would be a register value which is
confusing.

>  
>  /* Exposure controls from sensor */
>  #define OV5670_REG_EXPOSURE  0x3500
> @@ -1705,12 +1705,12 @@ struct ov5670_mode {
>  };
>  
>  /* Supported link frequencies */
> -#define OV5670_LINK_FREQ_420MHZ  42000
> -#define OV5670_LINK_FREQ_420MHZ_INDEX0
> +#define OV5670_LINK_FREQ_422MHZ  42240
> +#define OV5670_LINK_FREQ_422MHZ_INDEX0
>  static const struct ov5670_link_freq_config link_freq_configs[] = {
>   {
>   /* pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
> - .pixel_rate = (OV5670_LINK_FREQ_420MHZ * 2 * 2) / 10,
> + .pixel_rate = (OV5670_LINK_FREQ_422MHZ * 2 * 2) / 10,
>   .reg_list = {
>   .num_of_regs = ARRAY_SIZE(mipi_data_rate_840mbps),
>   .regs = mipi_data_rate_840mbps,
> @@ -1719,7 +1719,7 @@ struct ov5670_mode {
>  };
>  
>  static const s64 link_freq_menu_items[] = {
> - OV5670_LINK_FREQ_420MHZ
> + OV5670_LINK_FREQ_422MHZ
>  };
>  
>  /*
> @@ -1736,7 +1736,7 @@ struct ov5670_mode {
>   .num_of_regs = ARRAY_SIZE(mode_2592x1944_regs),
>   .regs = mode_2592x1944_regs,
>   },
> - .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
> + .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
>   },
>   {
>   .width = 1296,
> @@ -1746,7 +1746,7 @@ struct ov5670_mode {
>   .num_of_regs = ARRAY_SIZE(mode_1296x972_regs),
>   .regs = mode_1296x972_regs,
>   },
> - .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
> + .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
>   },
>   {
>   .width = 648,
> @@ -1756,7 +1756,7 @@ struct ov5670_mode {
>   .num_of_regs = ARRAY_SIZE(mode_648x486_regs),
>   .regs = mode_648x486_regs,
>   },
> - .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
> + .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
>   },
>   {
>   .width = 2560,
> @@ -1766,7 +1766,7 @@ struct ov5670_mode {
>   .num_of_regs = ARRAY_SIZE(mode_2560x1440_regs),
>   .regs = mode_2560x1440_regs,
>   },
> - .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
> + .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
>   },
>   {
>   .width = 1280,
> @@ -1776,7 +1776,7 @@ struct ov5670_mode {
>   .num_of_regs = ARRAY_SIZE(mode_1280x720_regs),
>   .regs = mode_1280x720_regs,
>   },
> - .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
> + .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
>   },
>   {
>   .width = 640,
> @@ -1786,7 +1786,7 @@ struct ov5670_mode {
>   .num_of_regs = ARRAY_SIZE(mode_640x360_regs),
>   .regs = mode_640x360_regs,
>   },
> - .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
> + .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
>   }
>  };
>  
> @@ -2016,13 +2016,6 @@ static int 

[PATCH v3 09/12] [media] ddbridge: fix impossible condition warning

[Daniel Scheller]

From: Daniel Scheller 

Smatch and gcc complained:

  drivers/media/pci/ddbridge/ddbridge-core.c:3491 bpsnr_show() warn: impossible 
condition '(snr[0] == 255) => ((-128)-127 == 255)'

  drivers/media/pci/ddbridge/ddbridge-core.c: In function ‘bpsnr_show’:
  drivers/media/pci/ddbridge/ddbridge-core.c:3491:13: warning: comparison is 
always false due to limited range of data type [-Wtype-limits]

Fix this by changing the type of snr to unsigned char.

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index ba2a2d987430..1ec3782a6c88 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -2992,7 +2992,7 @@ static ssize_t bpsnr_show(struct device *device,
 struct device_attribute *attr, char *buf)
 {
struct ddb *dev = dev_get_drvdata(device);
-   char snr[32];
+   unsigned char snr[32];
 
if (!dev->i2c_num)
return 0;
-- 
2.13.0

[PATCH v3 05/12] [media] ddbridge: check pointers before dereferencing

[Daniel Scheller]

From: Daniel Scheller 

Fixes two warnings reported by smatch:

  drivers/media/pci/ddbridge/ddbridge-core.c:240 ddb_redirect() warn: variable 
dereferenced before check 'idev' (see line 238)
  drivers/media/pci/ddbridge/ddbridge-core.c:240 ddb_redirect() warn: variable 
dereferenced before check 'pdev' (see line 238)

Fixed by moving the existing checks up before accessing members.

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 08440dcb5e6f..12bc8de980b5 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -170,10 +170,10 @@ static int ddb_redirect(u32 i, u32 p)
struct ddb *pdev = ddbs[(p >> 4) & 0x3f];
struct ddb_port *port;
 
-   if (!idev->has_dma || !pdev->has_dma)
-   return -EINVAL;
if (!idev || !pdev)
return -EINVAL;
+   if (!idev->has_dma || !pdev->has_dma)
+   return -EINVAL;
 
port = >port[p & 0x0f];
if (!port->output)
-- 
2.13.0

[PATCH v3 06/12] [media] ddbridge: only register frontends in fe2 if fe is not NULL

[Daniel Scheller]

From: Daniel Scheller 

Smatch reported:

  drivers/media/pci/ddbridge/ddbridge-core.c:1602 dvb_input_attach() error: we 
previously assumed 'dvb->fe' could be null (see line 1595)

dvb->fe2 will ever only be populated when dvb->fe is set. So only handle
registration of dvb->fe2 when dvb->fe got set beforehand by moving the
registration into the "if (dvb->fe)" conditional.

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 12bc8de980b5..d01d54159008 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -1506,23 +1506,25 @@ static int dvb_input_attach(struct ddb_input *input)
return 0;
}
dvb->attached = 0x30;
+
if (dvb->fe) {
if (dvb_register_frontend(adap, dvb->fe) < 0)
return -ENODEV;
+
+   if (dvb->fe2) {
+   if (dvb_register_frontend(adap, dvb->fe2) < 0)
+   return -ENODEV;
+   dvb->fe2->tuner_priv = dvb->fe->tuner_priv;
+   memcpy(>fe2->ops.tuner_ops,
+  >fe->ops.tuner_ops,
+  sizeof(struct dvb_tuner_ops));
+   }
}
-   if (dvb->fe2) {
-   if (dvb_register_frontend(adap, dvb->fe2) < 0)
-   return -ENODEV;
-   dvb->fe2->tuner_priv = dvb->fe->tuner_priv;
-   memcpy(>fe2->ops.tuner_ops,
-  >fe->ops.tuner_ops,
-  sizeof(struct dvb_tuner_ops));
-   }
+
dvb->attached = 0x31;
return 0;
 }
 
-
 static int port_has_encti(struct ddb_port *port)
 {
struct device *dev = port->dev->dev;
-- 
2.13.0

[PATCH v3 10/12] [media] ddbridge: fix dereference before check

[Daniel Scheller]

From: Daniel Scheller 

Both ts_release() and ts_open() can use "output" before check (smatch):

  drivers/media/pci/ddbridge/ddbridge-core.c:816 ts_release() warn: variable 
dereferenced before check 'output' (see line 809)
  drivers/media/pci/ddbridge/ddbridge-core.c:836 ts_open() warn: variable 
dereferenced before check 'output' (see line 828)

Fix by performing checks on those pointers.

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 1ec3782a6c88..05db3fb98a86 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -738,8 +738,13 @@ static unsigned int ts_poll(struct file *file, poll_table 
*wait)
 static int ts_release(struct inode *inode, struct file *file)
 {
struct dvb_device *dvbdev = file->private_data;
-   struct ddb_output *output = dvbdev->priv;
-   struct ddb_input *input = output->port->input[0];
+   struct ddb_output *output = NULL;
+   struct ddb_input *input = NULL;
+
+   if (dvbdev) {
+   output = dvbdev->priv;
+   input = output->port->input[0];
+   }
 
if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
if (!input)
@@ -757,8 +762,13 @@ static int ts_open(struct inode *inode, struct file *file)
 {
int err;
struct dvb_device *dvbdev = file->private_data;
-   struct ddb_output *output = dvbdev->priv;
-   struct ddb_input *input = output->port->input[0];
+   struct ddb_output *output = NULL;
+   struct ddb_input *input = NULL;
+
+   if (dvbdev) {
+   output = dvbdev->priv;
+   input = output->port->input[0];
+   }
 
if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
if (!input)
-- 
2.13.0

[PATCH v3 11/12] [media] ddbridge: Kconfig option to control the MSI modparam default

[Daniel Scheller]

From: Daniel Scheller 

It is known that MSI interrupts - while working quite well so far - can
still cause issues on some hardware platforms (causing I2C timeouts due
to unhandled interrupts). The msi variable/option is set to 1 by default.
So, add a Kconfig option prefixed with "EXPERIMENTAL" that will control
the default value of that modparam, defaulting to off for a better
user experience and (guaranteed) stable operation "per default".

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/Kconfig | 15 +++
 drivers/media/pci/ddbridge/ddbridge-main.c | 11 +--
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/ddbridge/Kconfig 
b/drivers/media/pci/ddbridge/Kconfig
index c79a58fa5fc3..1330b2ecc72a 100644
--- a/drivers/media/pci/ddbridge/Kconfig
+++ b/drivers/media/pci/ddbridge/Kconfig
@@ -26,3 +26,18 @@ config DVB_DDBRIDGE
  - CineS2 V7/V7A and DuoFlex S2 V4 (ST STV0910-based)
 
  Say Y if you own such a card and want to use it.
+
+config DVB_DDBRIDGE_MSIENABLE
+   bool "Enable Message Signaled Interrupts (MSI) per default 
(EXPERIMENTAL)"
+   depends on DVB_DDBRIDGE
+   depends on PCI_MSI
+   default n
+   ---help---
+ Use PCI MSI (Message Signaled Interrupts) per default. Enabling this
+ might lead to I2C errors originating from the bridge in conjunction
+ with certain SATA controllers, requiring a reload of the ddbridge
+ module. MSI can still be disabled by passing msi=0 as option, as
+ this will just change the msi option default value.
+
+ If you're unsure, concerned about stability and don't want to pass
+ module options in case of troubles, say N.
diff --git a/drivers/media/pci/ddbridge/ddbridge-main.c 
b/drivers/media/pci/ddbridge/ddbridge-main.c
index 5094d2ef79d6..5a930a6e9fb2 100644
--- a/drivers/media/pci/ddbridge/ddbridge-main.c
+++ b/drivers/media/pci/ddbridge/ddbridge-main.c
@@ -47,10 +47,17 @@ MODULE_PARM_DESC(adapter_alloc,
 "0-one adapter per io, 1-one per tab with io, 2-one per tab, 
3-one for all");
 
 #ifdef CONFIG_PCI_MSI
+#ifdef CONFIG_DVB_DDBRIDGE_MSIENABLE
 int msi = 1;
+#else
+int msi;
+#endif
 module_param(msi, int, 0444);
-MODULE_PARM_DESC(msi,
-" Control MSI interrupts: 0-disable, 1-enable (default)");
+#ifdef CONFIG_DVB_DDBRIDGE_MSIENABLE
+MODULE_PARM_DESC(msi, "Control MSI interrupts: 0-disable, 1-enable (default)");
+#else
+MODULE_PARM_DESC(msi, "Control MSI interrupts: 0-disable (default), 1-enable");
+#endif
 #endif
 
 int ci_bitrate = 7;
-- 
2.13.0

[PATCH v3 12/12] [media] MAINTAINERS: add entry for ddbridge

[Daniel Scheller]

From: Daniel Scheller 

Signed-off-by: Daniel Scheller 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 931abca006b7..0453a1365c3a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8421,6 +8421,14 @@ T:   git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/dvb-frontends/stv6111*
 
+MEDIA DRIVERS FOR DIGITAL DEVICES PCIE DEVICES
+M: Daniel Scheller 
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/pci/ddbridge/*
+
 MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
 M: Mauro Carvalho Chehab 
 M: Mauro Carvalho Chehab 
-- 
2.13.0

[PATCH v3 08/12] [media] ddbridge: remove unreachable code

[Daniel Scheller]

From: Daniel Scheller 

>From smatch:

  drivers/media/pci/ddbridge/ddbridge-core.c:3490 snr_store() info: ignoring 
unreachable code.

In fact, the function immediately returns zero, so remove it and update
ddb_attrs_snr[] to not reference it anymore.

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 27 ---
 1 file changed, 4 insertions(+), 23 deletions(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 2a4bb6ddf3a2..ba2a2d987430 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -2977,25 +2977,6 @@ static ssize_t snr_show(struct device *device,
return sprintf(buf, "%s\n", snr);
 }
 
-
-static ssize_t snr_store(struct device *device, struct device_attribute *attr,
-const char *buf, size_t count)
-{
-   struct ddb *dev = dev_get_drvdata(device);
-   int num = attr->attr.name[3] - 0x30;
-   u8 snr[34] = { 0x01, 0x00 };
-
-   return 0; /* NOE: remove completely? */
-   if (count > 31)
-   return -EINVAL;
-   if (dev->port[num].type >= DDB_TUNER_XO2)
-   return -EINVAL;
-   memcpy(snr + 2, buf, count);
-   i2c_write(>i2c[num].adap, 0x57, snr, 34);
-   i2c_write(>i2c[num].adap, 0x50, snr, 34);
-   return count;
-}
-
 static ssize_t bsnr_show(struct device *device,
 struct device_attribute *attr, char *buf)
 {
@@ -3135,10 +3116,10 @@ static struct device_attribute ddb_attrs_fan[] = {
 };
 
 static struct device_attribute ddb_attrs_snr[] = {
-   __ATTR(snr0, 0664, snr_show, snr_store),
-   __ATTR(snr1, 0664, snr_show, snr_store),
-   __ATTR(snr2, 0664, snr_show, snr_store),
-   __ATTR(snr3, 0664, snr_show, snr_store),
+   __ATTR_MRO(snr0, snr_show),
+   __ATTR_MRO(snr1, snr_show),
+   __ATTR_MRO(snr2, snr_show),
+   __ATTR_MRO(snr3, snr_show),
 };
 
 static struct device_attribute ddb_attrs_ctemp[] = {
-- 
2.13.0

[PATCH v3 07/12] [media] ddbridge: fix possible buffer overflow in ddb_ports_init()

[Daniel Scheller]

From: Daniel Scheller 

Report from smatch:

  drivers/media/pci/ddbridge/ddbridge-core.c:2659 ddb_ports_init() error: 
buffer overflow 'dev->port' 32 <= u32max

Fix by making sure "p" is greater than zero before checking for
"dev->port[].type == DDB_CI_EXTERNAL_XO2".

Cc: Ralph Metzler 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/ddbridge-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index d01d54159008..2a4bb6ddf3a2 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -2551,7 +2551,7 @@ void ddb_ports_init(struct ddb *dev)
port->dvb[0].adap = >adap[2 * p];
port->dvb[1].adap = >adap[2 * p + 1];
 
-   if ((port->class == DDB_PORT_NONE) && i &&
+   if ((port->class == DDB_PORT_NONE) && i && p &&
dev->port[p - 1].type == DDB_CI_EXTERNAL_XO2) {
port->class = DDB_PORT_CI;
port->type = DDB_CI_EXTERNAL_XO2_B;
-- 
2.13.0

[PATCH v3 00/12] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

From: Daniel Scheller 

Even without DDB IOCTLs, target: 4.14.

Changes from v2 to v3:
* (private) IOCTLs (temporarily) removed. Proper implementation via
  UAPI and some documentation will be (re)added with a separate patch.
  Even with this functionality removed (which most prominently is used
  to update the card FPGA) everything is still working as intended.
  With this, also temporarily removed the existing FLASHIO IOCTL.
* Code move/split already merged thus no longer part of the series

Changes from v1 to v2:
* I2C access functions (ie. i2c_read() et al) refactored from
  ddbridge-i2c.c into ddbridge-i2c.h and declared static, and needed
  include added to all .c files making use of them. This fixes symbol
  conflicts in the global namespace with other drivers (kbuild test
  robot reported a conflict with an infiniband driver) when compiling
  into the kernel blob. While at it, code style has been made proper
  (in ddbridge-i2c.h) and the 0.9.29 code bump patch was updated to
  re-use the "plural" functions from their "singular" equivalents.
* The IRQ_HANDLE_BYTE() macro was removed. It is used nowhere, even
  in the unmodified/unstripped upstream driver.
* Shortened the buffer overflow fix in ddb_ports_init() from checking
  "p > 0" to only check "p".

Changes from original series to the resend:
* rebased on latest mediatree-master wrt
commit 618e8aac3d7c ("media: ddbridge: constify i2c_algorithm structure")
* build error in ddbridge-core.c fixed wrt
commit dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by 
__GFP_RETRY_MAYFAIL with more useful semantic")
* useless return removed from void calc_con()
* UTF8 in ddbridge-regs.h removed
* Tested-by's added to commit messages

Previous Tested-by testimonials still apply, extensive retesting wrt
IOCTLs isn't neccessary.

Mauro/Media maintainers, this updates drivers/media/pci/ddbridge to the
very latest code that DD carry in their vendor driver package as of
version 0.9.29, in the "once, the big-bang-way is ok" way as discussed at
[2] (compared to the incremental, awkward to do variant since that
involves dissecting all available release archives and having to - try
to - build proper commits out of this, which will always be inaccurate;
a start was done at [3], however - and please understand - I definitely
don't want to continue doing that...)

In patch 14, I add myself to MAINTAINERS. This means I will care about
getting driver updates as they're released by DD into mainline,  starting
from this (0.9.29) version, which is definitely doable in an incremental
way. So, I'll make sure the in-kernel driver won't bit-rot again, and it
will receive new hardware support as it becomes available in a timely
manner.

While the driver code bump looks massive, judging from the diff, there's
mostly a whole lot of refactoring and restructuring of variables, port/
link management and all such stuff in it. Feature-wise, this is most
notable:

 - Support for all (PCIe) CI (single/duo) cards and Flex addons
 - Support for MSI (Message Signaled Interrupts), though disabled by
   default since there were still reports of problems with this
 - TS Loopback support (set up ports to behave as if a CI is connected,
   without decryption of course)
 - As mentioned: Heavy code reordering, and split up into multiple files

Stripped functionality compared to dddvb:

 - DVB-C modulator card support removed (requires DVB core API)
 - OctoNET SAT>IP server/box support removed (requires API aswell)
 - with this, GT link support was removed (only on OctoNET hardware)
 - MaxS8 4/8 DVB-S/S2 card support (temporarily) removed (requires an
   additional Demod driver; subject for another, later, series)

A note on the patches:

The bump starts by aligning the code "order-wise" to the updated driver,
to keep the diff a bit cleaner. Next, the code split is applied, without
actually changing any functionality. Compared to upstream, this isn't done
by moving functions into different C files and then do an include on them,
but we're handling them with the Makefile, building separate objects, and
having proper prototypes in ddbridge.h. After the code bump, further split
up is applied to increase readability and maintainability (also, for the
MaxS8 support, there will be another object with another ~400 LoC, which
originally lives in ddbridge-core aswell). Then, all issues found by W=1
and smatch are resolved, one by one. This is kept separate since those
fixes will be proposed for upstream inclusion. The last thing is the
addition of the MSI default Kconfig options which will mainly inform users
that there's something that might(!) cause issues but is still being
worked on - the default is "off" to provide a proper OotB experience.

To distinguish from the original unchanged vendor driver, "-integrated" is
suffixed to the version code.

Note on checkpatch:

First two patches are solely code-moving, so checkpatch will complain on
them. With the ddbridge code bump, 

[PATCH v3 03/12] [media] ddbridge: split off IRQ handling

[Daniel Scheller]

From: Daniel Scheller 

This not only helps keep the ddbridge-core tidy, but also gets rid of
defined-but-unused-function warnings which might be triggered depending of
CONFIG_PCI_MSI, without having to clutter the code with #ifdef'ery.

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/Makefile|   3 +-
 drivers/media/pci/ddbridge/ddbridge-core.c | 117 ---
 drivers/media/pci/ddbridge/ddbridge-irq.c  | 148 +
 drivers/media/pci/ddbridge/ddbridge.h  |  12 +--
 4 files changed, 155 insertions(+), 125 deletions(-)
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-irq.c

diff --git a/drivers/media/pci/ddbridge/Makefile 
b/drivers/media/pci/ddbridge/Makefile
index fe8ff0c681ad..0a7caa95a3b6 100644
--- a/drivers/media/pci/ddbridge/Makefile
+++ b/drivers/media/pci/ddbridge/Makefile
@@ -2,7 +2,8 @@
 # Makefile for the ddbridge device driver
 #
 
-ddbridge-objs := ddbridge-main.o ddbridge-core.o ddbridge-i2c.o
+ddbridge-objs := ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \
+   ddbridge-irq.o
 
 obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
 
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 15d7be4d..0799f7c5400c 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -2691,123 +2691,6 @@ void ddb_ports_release(struct ddb *dev)
 //
 //
 
-#define IRQ_HANDLE(_nr) \
-   do { if ((s & (1UL << ((_nr) & 0x1f))) && dev->handler[0][_nr]) \
-   dev->handler[0][_nr](dev->handler_data[0][_nr]); } \
-   while (0)
-
-static void irq_handle_msg(struct ddb *dev, u32 s)
-{
-   dev->i2c_irq++;
-   IRQ_HANDLE(0);
-   IRQ_HANDLE(1);
-   IRQ_HANDLE(2);
-   IRQ_HANDLE(3);
-}
-
-static void irq_handle_io(struct ddb *dev, u32 s)
-{
-   dev->ts_irq++;
-   if ((s & 0x00f0)) {
-   IRQ_HANDLE(4);
-   IRQ_HANDLE(5);
-   IRQ_HANDLE(6);
-   IRQ_HANDLE(7);
-   }
-   if ((s & 0xff00)) {
-   IRQ_HANDLE(8);
-   IRQ_HANDLE(9);
-   IRQ_HANDLE(10);
-   IRQ_HANDLE(11);
-   IRQ_HANDLE(12);
-   IRQ_HANDLE(13);
-   IRQ_HANDLE(14);
-   IRQ_HANDLE(15);
-   }
-   if ((s & 0x00ff)) {
-   IRQ_HANDLE(16);
-   IRQ_HANDLE(17);
-   IRQ_HANDLE(18);
-   IRQ_HANDLE(19);
-   IRQ_HANDLE(20);
-   IRQ_HANDLE(21);
-   IRQ_HANDLE(22);
-   IRQ_HANDLE(23);
-   }
-   if ((s & 0xff00)) {
-   IRQ_HANDLE(24);
-   IRQ_HANDLE(25);
-   IRQ_HANDLE(26);
-   IRQ_HANDLE(27);
-   IRQ_HANDLE(28);
-   IRQ_HANDLE(29);
-   IRQ_HANDLE(30);
-   IRQ_HANDLE(31);
-   }
-}
-
-#ifdef DDB_USE_MSI_IRQHANDLERS
-irqreturn_t irq_handler0(int irq, void *dev_id)
-{
-   struct ddb *dev = (struct ddb *) dev_id;
-   u32 s = ddbreadl(dev, INTERRUPT_STATUS);
-
-   do {
-   if (s & 0x8000)
-   return IRQ_NONE;
-   if (!(s & 0xf00))
-   return IRQ_NONE;
-   ddbwritel(dev, s & 0xf00, INTERRUPT_ACK);
-   irq_handle_io(dev, s);
-   } while ((s = ddbreadl(dev, INTERRUPT_STATUS)));
-
-   return IRQ_HANDLED;
-}
-
-irqreturn_t irq_handler1(int irq, void *dev_id)
-{
-   struct ddb *dev = (struct ddb *) dev_id;
-   u32 s = ddbreadl(dev, INTERRUPT_STATUS);
-
-   do {
-   if (s & 0x8000)
-   return IRQ_NONE;
-   if (!(s & 0xf))
-   return IRQ_NONE;
-   ddbwritel(dev, s & 0xf, INTERRUPT_ACK);
-   irq_handle_msg(dev, s);
-   } while ((s = ddbreadl(dev, INTERRUPT_STATUS)));
-
-   return IRQ_HANDLED;
-}
-#endif
-
-irqreturn_t irq_handler(int irq, void *dev_id)
-{
-   struct ddb *dev = (struct ddb *) dev_id;
-   u32 s = ddbreadl(dev, INTERRUPT_STATUS);
-   int ret = IRQ_HANDLED;
-
-   if (!s)
-   return IRQ_NONE;
-   do {
-   if (s & 0x8000)
-   return IRQ_NONE;
-   ddbwritel(dev, s, INTERRUPT_ACK);
-
-   if (s & 0x000f)
-   irq_handle_msg(dev, s);
-   if (s & 0x0f00)
-   irq_handle_io(dev, s);
-   } while ((s = ddbreadl(dev, 

[PATCH v3 02/12] [media] ddbridge: split I/O related functions off from ddbridge.h

[Daniel Scheller]

From: Daniel Scheller 

While it seems valid that headers can carry simple oneline static inline
annotated functions, move them into their own header file to have the
overall code more readable. Also, keep them as header (and don't put in
a separate object) and static inline to help the compiler avoid
generating function calls.

(Thanks to Jasmin J.  for valuable input on this!)

Cc: Jasmin J. 
Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/ddbridge-core.c |  1 +
 drivers/media/pci/ddbridge/ddbridge-i2c.c  |  1 +
 drivers/media/pci/ddbridge/ddbridge-io.h   | 71 ++
 drivers/media/pci/ddbridge/ddbridge-main.c |  1 +
 drivers/media/pci/ddbridge/ddbridge.h  | 43 --
 5 files changed, 74 insertions(+), 43 deletions(-)
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-io.h

diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 9d28448524de..15d7be4d 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -37,6 +37,7 @@
 #include "ddbridge.h"
 #include "ddbridge-i2c.h"
 #include "ddbridge-regs.h"
+#include "ddbridge-io.h"
 
 #include "tda18271c2dd.h"
 #include "stv6110x.h"
diff --git a/drivers/media/pci/ddbridge/ddbridge-i2c.c 
b/drivers/media/pci/ddbridge/ddbridge-i2c.c
index 376d8a7ca0b9..3d4fafb5db27 100644
--- a/drivers/media/pci/ddbridge/ddbridge-i2c.c
+++ b/drivers/media/pci/ddbridge/ddbridge-i2c.c
@@ -33,6 +33,7 @@
 #include "ddbridge.h"
 #include "ddbridge-i2c.h"
 #include "ddbridge-regs.h"
+#include "ddbridge-io.h"
 
 
/**/
 
diff --git a/drivers/media/pci/ddbridge/ddbridge-io.h 
b/drivers/media/pci/ddbridge/ddbridge-io.h
new file mode 100644
index ..ce92e9484075
--- /dev/null
+++ b/drivers/media/pci/ddbridge/ddbridge-io.h
@@ -0,0 +1,71 @@
+/*
+ * ddbridge-io.h: Digital Devices bridge I/O inline functions
+ *
+ * Copyright (C) 2010-2017 Digital Devices GmbH
+ * Ralph Metzler 
+ * Marcus Metzler 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __DDBRIDGE_IO_H__
+#define __DDBRIDGE_IO_H__
+
+#include 
+
+#include "ddbridge.h"
+
+/**/
+
+static inline u32 ddblreadl(struct ddb_link *link, u32 adr)
+{
+   return readl((char *) (link->dev->regs + (adr)));
+}
+
+static inline void ddblwritel(struct ddb_link *link, u32 val, u32 adr)
+{
+   writel(val, (char *) (link->dev->regs + (adr)));
+}
+
+static inline u32 ddbreadl(struct ddb *dev, u32 adr)
+{
+   return readl((char *) (dev->regs + (adr)));
+}
+
+static inline void ddbwritel(struct ddb *dev, u32 val, u32 adr)
+{
+   writel(val, (char *) (dev->regs + (adr)));
+}
+
+static inline void ddbcpyto(struct ddb *dev, u32 adr, void *src, long count)
+{
+   return memcpy_toio((char *) (dev->regs + adr), src, count);
+}
+
+static inline void ddbcpyfrom(struct ddb *dev, void *dst, u32 adr, long count)
+{
+   return memcpy_fromio(dst, (char *) (dev->regs + adr), count);
+}
+
+static inline u32 safe_ddbreadl(struct ddb *dev, u32 adr)
+{
+   u32 val = ddbreadl(dev, adr);
+
+   /* (ddb)readl returns (uint)-1 (all bits set) on failure, catch that */
+   if (val == ~0) {
+   dev_err(>pdev->dev, "ddbreadl failure, adr=%08x\n", adr);
+   return 0;
+   }
+
+   return val;
+}
+
+#endif /* __DDBRIDGE_IO_H__ */
diff --git a/drivers/media/pci/ddbridge/ddbridge-main.c 
b/drivers/media/pci/ddbridge/ddbridge-main.c
index dde938ad1247..5332fd89f359 100644
--- a/drivers/media/pci/ddbridge/ddbridge-main.c
+++ b/drivers/media/pci/ddbridge/ddbridge-main.c
@@ -35,6 +35,7 @@
 #include "ddbridge.h"
 #include "ddbridge-i2c.h"
 #include "ddbridge-regs.h"
+#include "ddbridge-io.h"
 
 //
 /* module parameters */
diff --git a/drivers/media/pci/ddbridge/ddbridge.h 
b/drivers/media/pci/ddbridge/ddbridge.h
index ab6364ae0711..3790fd8465a4 100644
--- a/drivers/media/pci/ddbridge/ddbridge.h
+++ b/drivers/media/pci/ddbridge/ddbridge.h
@@ -353,49 +353,6 @@ 

[PATCH v3 04/12] [media] ddbridge: split off hardware definitions and mappings

[Daniel Scheller]

From: Daniel Scheller 

Further cleanup of ddbridge-core and ddbridge-main, and moves all such
hw definitions into one single place, making things easier to maintain.

Signed-off-by: Daniel Scheller 
Tested-by: Richard Scobie 
Tested-by: Jasmin Jessich 
Tested-by: Dietmar Spingler 
Tested-by: Manfred Knick 
---
 drivers/media/pci/ddbridge/Makefile|   4 +-
 drivers/media/pci/ddbridge/ddbridge-core.c |  68 ---
 drivers/media/pci/ddbridge/ddbridge-hw.c   | 299 +
 drivers/media/pci/ddbridge/ddbridge-hw.h   |  52 +
 drivers/media/pci/ddbridge/ddbridge-main.c | 217 +
 drivers/media/pci/ddbridge/ddbridge.h  |   1 -
 6 files changed, 354 insertions(+), 287 deletions(-)
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-hw.c
 create mode 100644 drivers/media/pci/ddbridge/ddbridge-hw.h

diff --git a/drivers/media/pci/ddbridge/Makefile 
b/drivers/media/pci/ddbridge/Makefile
index 0a7caa95a3b6..c4d8d6261243 100644
--- a/drivers/media/pci/ddbridge/Makefile
+++ b/drivers/media/pci/ddbridge/Makefile
@@ -2,8 +2,8 @@
 # Makefile for the ddbridge device driver
 #
 
-ddbridge-objs := ddbridge-main.o ddbridge-core.o ddbridge-i2c.o \
-   ddbridge-irq.o
+ddbridge-objs := ddbridge-main.o ddbridge-core.o ddbridge-hw.o \
+   ddbridge-i2c.o ddbridge-irq.o
 
 obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
 
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
b/drivers/media/pci/ddbridge/ddbridge-core.c
index 0799f7c5400c..08440dcb5e6f 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -67,74 +67,6 @@ static struct ddb *ddbs[DDB_MAX_ADAPTER];
 //
 //
 
-static struct ddb_regset octopus_input = {
-   .base = 0x200,
-   .num  = 0x08,
-   .size = 0x10,
-};
-
-static struct ddb_regset octopus_output = {
-   .base = 0x280,
-   .num  = 0x08,
-   .size = 0x10,
-};
-
-static struct ddb_regset octopus_idma = {
-   .base = 0x300,
-   .num  = 0x08,
-   .size = 0x10,
-};
-
-static struct ddb_regset octopus_idma_buf = {
-   .base = 0x2000,
-   .num  = 0x08,
-   .size = 0x100,
-};
-
-static struct ddb_regset octopus_odma = {
-   .base = 0x380,
-   .num  = 0x04,
-   .size = 0x10,
-};
-
-static struct ddb_regset octopus_odma_buf = {
-   .base = 0x2800,
-   .num  = 0x04,
-   .size = 0x100,
-};
-
-static struct ddb_regset octopus_i2c = {
-   .base = 0x80,
-   .num  = 0x04,
-   .size = 0x20,
-};
-
-static struct ddb_regset octopus_i2c_buf = {
-   .base = 0x1000,
-   .num  = 0x04,
-   .size = 0x200,
-};
-
-//
-
-struct ddb_regmap octopus_map = {
-   .irq_base_i2c = 0,
-   .irq_base_idma = 8,
-   .irq_base_odma = 16,
-   .i2c = _i2c,
-   .i2c_buf = _i2c_buf,
-   .idma = _idma,
-   .idma_buf = _idma_buf,
-   .odma = _odma,
-   .odma_buf = _odma_buf,
-   .input = _input,
-   .output = _output,
-};
-
-//
-//
-//
-
 static void ddb_set_dma_table(struct ddb_io *io)
 {
struct ddb *dev = io->port->dev;
diff --git a/drivers/media/pci/ddbridge/ddbridge-hw.c 
b/drivers/media/pci/ddbridge/ddbridge-hw.c
new file mode 100644
index ..e35b41e8d860
--- /dev/null
+++ b/drivers/media/pci/ddbridge/ddbridge-hw.c
@@ -0,0 +1,299 @@
+/*
+ * ddbridge-hw.c: Digital Devices bridge hardware maps
+ *
+ * Copyright (C) 2010-2017 Digital Devices GmbH
+ * Ralph Metzler 
+ * Marcus Metzler 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include "ddbridge.h"
+
+/**/
+
+static struct ddb_regset octopus_input = {
+   .base = 0x200,
+   .num  = 0x08,
+   .size = 0x10,
+};
+
+static struct ddb_regset octopus_output = {
+   .base = 0x280,
+   .num  = 0x08,
+   .size = 0x10,
+};
+
+static struct ddb_regset 

[GIT PULL for 4.14] Omap3isp CCP2 support

[Sakari Ailus]

Hi Mauro,

These patches add functional CCP2 support for the omap3isp, as needed for
the Nokia N900.

Please pull.


The following changes since commit ec0c3ec497cabbf3bfa03a9eb5edcc252190a4e0:

  media: ddbridge: split code into multiple files (2017-08-09 12:17:01 -0400)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git ccp2

for you to fetch changes up to 1d3f6ca1c698441784755d40b441fd969e9b2303:

  omap3isp: Skip CSI-2 receiver initialisation in CCP2 configuration 
(2017-08-09 22:36:58 +0300)


Pavel Machek (2):
  omap3isp: Parse CSI1 configuration from the device tree
  omap3isp: Correctly set IO_OUT_SEL and VP_CLK_POL for CCP2 mode

Sakari Ailus (2):
  omap3isp: Always initialise isp and mutex for csiphy1
  omap3isp: Skip CSI-2 receiver initialisation in CCP2 configuration

 drivers/media/platform/omap3isp/isp.c   | 105 +---
 drivers/media/platform/omap3isp/ispccp2.c   |   9 ++-
 drivers/media/platform/omap3isp/ispcsi2.c   |   4 +-
 drivers/media/platform/omap3isp/ispcsiphy.c |  38 +-
 drivers/media/platform/omap3isp/ispcsiphy.h |   6 +-
 drivers/media/platform/omap3isp/ispreg.h|   4 ++
 drivers/media/platform/omap3isp/omap3isp.h  |   1 +
 7 files changed, 115 insertions(+), 52 deletions(-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[PATCH v1] media: ov5670: Fix incorrect fps reported by user

[Chiranjeevi Rapolu]

Previously, pixel-rate/(pixels-per-line * lines-per-frame) was
yielding incorrect fps for the user. This results in much lower fps
reported by user than the actual fps on the bus.

OV sensor is using internal timing and this requires
conversion (internal timing -> PPL) for correct HBLANK calculation.

Now, change pixels-per-line domain from internal sensor clock to
pixels domain. Set HBLANK read-only because fixed PPL is used for all
resolutions. And, use more accurate link-frequency 422.4MHz instead of
rounding down to 420MHz.

Signed-off-by: Chiranjeevi Rapolu 
---
 drivers/media/i2c/ov5670.c | 31 +--
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
index 8d8e16c..f42b21e 100644
--- a/drivers/media/i2c/ov5670.c
+++ b/drivers/media/i2c/ov5670.c
@@ -37,7 +37,7 @@
 
 /* horizontal-timings from sensor */
 #define OV5670_REG_HTS 0x380c
-#define OV5670_DEF_PPL 3360/* Default pixels per line */
+#define OV5670_DEF_PPL 2724/* Default pixels per line */
 
 /* Exposure controls from sensor */
 #define OV5670_REG_EXPOSURE0x3500
@@ -1705,12 +1705,12 @@ struct ov5670_mode {
 };
 
 /* Supported link frequencies */
-#define OV5670_LINK_FREQ_420MHZ42000
-#define OV5670_LINK_FREQ_420MHZ_INDEX  0
+#define OV5670_LINK_FREQ_422MHZ42240
+#define OV5670_LINK_FREQ_422MHZ_INDEX  0
 static const struct ov5670_link_freq_config link_freq_configs[] = {
{
/* pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
-   .pixel_rate = (OV5670_LINK_FREQ_420MHZ * 2 * 2) / 10,
+   .pixel_rate = (OV5670_LINK_FREQ_422MHZ * 2 * 2) / 10,
.reg_list = {
.num_of_regs = ARRAY_SIZE(mipi_data_rate_840mbps),
.regs = mipi_data_rate_840mbps,
@@ -1719,7 +1719,7 @@ struct ov5670_mode {
 };
 
 static const s64 link_freq_menu_items[] = {
-   OV5670_LINK_FREQ_420MHZ
+   OV5670_LINK_FREQ_422MHZ
 };
 
 /*
@@ -1736,7 +1736,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_2592x1944_regs),
.regs = mode_2592x1944_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 1296,
@@ -1746,7 +1746,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_1296x972_regs),
.regs = mode_1296x972_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 648,
@@ -1756,7 +1756,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_648x486_regs),
.regs = mode_648x486_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 2560,
@@ -1766,7 +1766,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_2560x1440_regs),
.regs = mode_2560x1440_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 1280,
@@ -1776,7 +1776,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_1280x720_regs),
.regs = mode_1280x720_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
},
{
.width = 640,
@@ -1786,7 +1786,7 @@ struct ov5670_mode {
.num_of_regs = ARRAY_SIZE(mode_640x360_regs),
.regs = mode_640x360_regs,
},
-   .link_freq_index = OV5670_LINK_FREQ_420MHZ_INDEX,
+   .link_freq_index = OV5670_LINK_FREQ_422MHZ_INDEX,
}
 };
 
@@ -2016,13 +2016,6 @@ static int ov5670_set_ctrl(struct v4l2_ctrl *ctrl)
   OV5670_REG_VALUE_16BIT,
   ov5670->cur_mode->height + ctrl->val);
break;
-   case V4L2_CID_HBLANK:
-   /* Update HTS that meets expected horizontal blanking */
-   ret = ov5670_write_reg(ov5670, OV5670_REG_HTS,
-  OV5670_REG_VALUE_16BIT,
-  (ov5670->cur_mode->width +
-   ctrl->val) / 2);
-   break;
case V4L2_CID_TEST_PATTERN:
ret = 

[PATCH 1/3] uapi: media-bus-format: Add Xilinx specific YCbCr 4:2:0 media bus format

[Rohit Athavale]

This commit adds Xilinx Video IP specific 8-bit color depth YCbCr 4:2:0
to the media bus format uapi.

Signed-off-by: Rohit Athavale 
---
 include/uapi/linux/media-bus-format.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index ef6fb30..6f65607 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -143,10 +143,12 @@
 /* JPEG compressed formats - next is   0x4002 */
 #define MEDIA_BUS_FMT_JPEG_1X8 0x4001
 
-/* Vendor specific formats - next is   0x5002 */
+/* Vendor specific formats - next is   0x5003 */
 
 /* S5C73M3 sensor specific interleaved UYVY and JPEG */
 #define MEDIA_BUS_FMT_S5C_UYVY_JPEG_1X80x5001
+/* Xilinx IP Specific 8-bit YCbCr 4:2:0 */
+#define MEDIA_BUS_FMT_XLNX8_VUY420_1X240x5002
 
 /* HSV - next is   0x6002 */
 #define MEDIA_BUS_FMT_AHSV_1X320x6001
-- 
1.9.1

[PATCH 3/3] Documentation: subdev-formats: Add Xilinx YCbCr to Vendor specific area

[Rohit Athavale]

This commit adds the custom Xilinx IP specific 8-bit YCbCr 4:2:0
to the custom formats area in the subdev-formats documentation.

Signed-off-by: Rohit Athavale 
---
 Documentation/media/uapi/v4l/subdev-formats.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index 8e73bb0..141a837 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -7483,3 +7483,8 @@ formats.
   - 0x5001
   - Interleaved raw UYVY and JPEG image format with embedded meta-data
used by Samsung S3C73MX camera sensors.
+* .. _MEDIA_BUS_FMT_XLNX8_VUY420_1X24:
+
+  - MEDIA_BUS_FMT_XLNX8_VUY420_1X24
+  - 0x5002
+  - Xilinx IP specific 8-bit color depth YCbCr 4:2:0 used by Xilinx Video 
IP.
-- 
1.9.1

[PATCH 0/3] Xilinx 8-bit color depth YCbCr 4:2:0 media bus format

[Rohit Athavale]

This patch set adds a vendor specific custom YCbCr 4:2:0 format. The way
Xilinx Video IP sends data over the bus makes it unrepresented by existing
media bus formats.

YCbCr 4:2:0 transmission over the bus does not slice Chroma and Luma
components over the bus width. Instead it sends sub-sampled Chroma when
present along with the Luma component, otherwise zero padded Luma only
data is sent.

The first patch  (1/3) adds the format to the uapi header file.
The second patch (2/3) adds the format to the table in xilinx-vip.c.
The third patch  (3/3) updates the subdev format doc file.

Rohit Athavale (3):
  uapi: media-bus-format: Add Xilinx specific YCbCr 4:2:0 media bus
format
  media: xilinx-vip: Add 8-bit YCbCr 4:2:0 to formats table
  Documentation: subdev-formats: Add Xilinx YCbCr to Vendor specific
area

 Documentation/media/uapi/v4l/subdev-formats.rst | 5 +
 drivers/media/platform/xilinx/xilinx-vip.c  | 3 +++
 include/uapi/linux/media-bus-format.h   | 4 +++-
 3 files changed, 11 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH 2/3] media: xilinx-vip: Add 8-bit YCbCr 4:2:0 to formats table

[Rohit Athavale]

Add Xilinx YCbCr 4:2:0 to xvip formats table. This commit
will allow driver to setup media pad codes to YUV 420
via DT properties.

Signed-off-by: Rohit Athavale 
---
 drivers/media/platform/xilinx/xilinx-vip.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/xilinx/xilinx-vip.c 
b/drivers/media/platform/xilinx/xilinx-vip.c
index 3112591..37b80bf 100644
--- a/drivers/media/platform/xilinx/xilinx-vip.c
+++ b/drivers/media/platform/xilinx/xilinx-vip.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -27,6 +28,8 @@
  */
 
 static const struct xvip_video_format xvip_video_formats[] = {
+   { XVIP_VF_YUV_420, 8, NULL, MEDIA_BUS_FMT_XLNX8_VUY420_1X24,
+ 2, V4L2_PIX_FMT_NV12, "4:2:0, semi-planar, YUYV" },
{ XVIP_VF_YUV_422, 8, NULL, MEDIA_BUS_FMT_UYVY8_1X16,
  2, V4L2_PIX_FMT_YUYV, "4:2:2, packed, YUYV" },
{ XVIP_VF_YUV_444, 8, NULL, MEDIA_BUS_FMT_VUY8_1X24,
-- 
1.9.1

[PATCH] [media] rc: per-protocol repeat period

[Sean Young]

CEC needs a keypress timeout of 550ms, which is too high for the IR
protocols. Also fill in known repeat times, with 50ms error margin.

Also, combine all protocol data into one structure.

Signed-off-by: Sean Young 
Suggested-by: Hans Verkuil 
---
 drivers/media/rc/rc-main.c | 138 +
 1 file changed, 65 insertions(+), 73 deletions(-)

diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index c494a4ddc138..981cccd6b988 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -30,8 +30,54 @@
 #define IR_TAB_MAX_SIZE8192
 #define RC_DEV_MAX 256
 
-/* FIXME: IR_KEYPRESS_TIMEOUT should be protocol specific */
-#define IR_KEYPRESS_TIMEOUT 250
+static const struct {
+   const char *name;
+   unsigned int repeat_period;
+   unsigned int scancode_bits;
+} protocols[] = {
+   [RC_PROTO_UNKNOWN] = { .name = "unknown", .repeat_period = 250 },
+   [RC_PROTO_OTHER] = { .name = "other", .repeat_period = 250 },
+   [RC_PROTO_RC5] = { .name = "rc-5",
+   .scancode_bits = 0x1f7f, .repeat_period = 164 },
+   [RC_PROTO_RC5X_20] = { .name = "rc-5x-20",
+   .scancode_bits = 0x1f7f3f, .repeat_period = 164 },
+   [RC_PROTO_RC5_SZ] = { .name = "rc-5-sz",
+   .scancode_bits = 0x2fff, .repeat_period = 164 },
+   [RC_PROTO_JVC] = { .name = "jvc",
+   .scancode_bits = 0x, .repeat_period = 250 },
+   [RC_PROTO_SONY12] = { .name = "sony-12",
+   .scancode_bits = 0x1f007f, .repeat_period = 100 },
+   [RC_PROTO_SONY15] = { .name = "sony-15",
+   .scancode_bits = 0xff007f, .repeat_period = 100 },
+   [RC_PROTO_SONY20] = { .name = "sony-20",
+   .scancode_bits = 0x1fff7f, .repeat_period = 100 },
+   [RC_PROTO_NEC] = { .name = "nec",
+   .scancode_bits = 0x, .repeat_period = 160 },
+   [RC_PROTO_NECX] = { .name = "nec-x",
+   .scancode_bits = 0xff, .repeat_period = 160 },
+   [RC_PROTO_NEC32] = { .name = "nec-32",
+   .scancode_bits = 0x, .repeat_period = 160 },
+   [RC_PROTO_SANYO] = { .name = "sanyo",
+   .scancode_bits = 0x1f, .repeat_period = 250 },
+   [RC_PROTO_MCIR2_KBD] = { .name = "mcir2-kbd",
+   .scancode_bits = 0x, .repeat_period = 150 },
+   [RC_PROTO_MCIR2_MSE] = { .name = "mcir2-mse",
+   .scancode_bits = 0x1f, .repeat_period = 150 },
+   [RC_PROTO_RC6_0] = { .name = "rc-6-0",
+   .scancode_bits = 0x, .repeat_period = 164 },
+   [RC_PROTO_RC6_6A_20] = { .name = "rc-6-6a-20",
+   .scancode_bits = 0xf, .repeat_period = 164 },
+   [RC_PROTO_RC6_6A_24] = { .name = "rc-6-6a-24",
+   .scancode_bits = 0xff, .repeat_period = 164 },
+   [RC_PROTO_RC6_6A_32] = { .name = "rc-6-6a-32",
+   .scancode_bits = 0x, .repeat_period = 164 },
+   [RC_PROTO_RC6_MCE] = { .name = "rc-6-mce",
+   .scancode_bits = 0x7fff, .repeat_period = 164 },
+   [RC_PROTO_SHARP] = { .name = "sharp",
+   .scancode_bits = 0x1fff, .repeat_period = 250 },
+   [RC_PROTO_XMP] = { .name = "xmp", .repeat_period = 250 },
+   [RC_PROTO_CEC] = { .name = "cec", .repeat_period = 550 },
+};
 
 /* Used to keep track of known keymaps */
 static LIST_HEAD(rc_map_list);
@@ -613,6 +659,7 @@ static void ir_timer_keyup(unsigned long cookie)
 void rc_repeat(struct rc_dev *dev)
 {
unsigned long flags;
+   unsigned int timeout = protocols[dev->last_protocol].repeat_period;
 
spin_lock_irqsave(>keylock, flags);
 
@@ -622,7 +669,7 @@ void rc_repeat(struct rc_dev *dev)
input_event(dev->input_dev, EV_MSC, MSC_SCAN, dev->last_scancode);
input_sync(dev->input_dev);
 
-   dev->keyup_jiffies = jiffies + msecs_to_jiffies(IR_KEYPRESS_TIMEOUT);
+   dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout);
mod_timer(>timer_keyup, dev->keyup_jiffies);
 
 out:
@@ -693,7 +740,8 @@ void rc_keydown(struct rc_dev *dev, enum rc_proto protocol, 
u32 scancode,
ir_do_keydown(dev, protocol, scancode, keycode, toggle);
 
if (dev->keypressed) {
-   dev->keyup_jiffies = jiffies + 
msecs_to_jiffies(IR_KEYPRESS_TIMEOUT);
+   dev->keyup_jiffies = jiffies +
+   msecs_to_jiffies(protocols[protocol].repeat_period);
mod_timer(>timer_keyup, dev->keyup_jiffies);
}
spin_unlock_irqrestore(>keylock, flags);
@@ -734,33 +782,14 @@ EXPORT_SYMBOL_GPL(rc_keydown_notimeout);
 static int rc_validate_filter(struct rc_dev *dev,
  struct rc_scancode_filter *filter)
 {
-   static const u32 masks[] = {
-   [RC_PROTO_RC5] = 0x1f7f,
-   [RC_PROTO_RC5X_20] = 0x1f7f3f,
-   [RC_PROTO_RC5_SZ] = 0x2fff,
-   

Re: [PATCH v2 03/14] [media] ddbridge: bump ddbridge code to version 0.9.29

[Daniel Scheller]

On Wed, 9 Aug 2017 13:47:31 -0300
Mauro Carvalho Chehab  wrote:

> Em Sat, 29 Jul 2017 13:28:37 +0200
> Daniel Scheller  escreveu:
> 
> > From: Daniel Scheller 
> > 
> > This huge patch bumps the ddbridge driver to version 0.9.29.
> > Compared to the vendor driver package, DD OctoNET including GTL
> > link support, and all DVB-C Modulator card support has been removed
> > since this requires large changes to the underlying DVB core API,
> > which should eventually be done separately, and, after that, the
> > functionality/device support can be added back rather easy.
> > 
> > While the diff is rather large, the bump is mostly a big refactor
> > of all data structures. Yet, the MSI support (message signaled
> > interrupts) is greatly improved, also all currently available CI
> > single/duo bridge cards are fully supported.
> > 
> > More changes compared to the upstream driver:
> >  - the DDB_USE_WORKER flag/define was removed, kernel worker
> > functionality will be used.
> >  - coding style is properly fixed (zero complaints from checkpatch)
> >  - all (not much though) CamelCase has been fixed to kernel_case
> > 
> > Great care has been taken to keep all previous changes and fixes
> > (e.g. kernel logging via dev_*(), pointer annotations and such)
> > intact.
> > 
> > Permission to reuse and mainline the driver code was formally
> > granted by Ralph Metzler .
> > 
> > Signed-off-by: Daniel Scheller 
> > Tested-by: Richard Scobie 
> > Tested-by: Jasmin Jessich 
> > Tested-by: Dietmar Spingler 
> > Tested-by: Manfred Knick 
> > ---
> >  drivers/media/pci/ddbridge/ddbridge-core.c | 3496
> > ++--
> > drivers/media/pci/ddbridge/ddbridge-i2c.c  |  217 +-
> > drivers/media/pci/ddbridge/ddbridge-i2c.h  |   41 +-
> > drivers/media/pci/ddbridge/ddbridge-main.c |  490 ++--
> > drivers/media/pci/ddbridge/ddbridge-regs.h |  138 +-
> > drivers/media/pci/ddbridge/ddbridge.h  |  366 ++- 6 files
> > changed, 3613 insertions(+), 1135 deletions(-)
> > 
> > diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
> > b/drivers/media/pci/ddbridge/ddbridge-core.c index
> > 7e164a370273..5045ad6c36fe 100644 ---
> > a/drivers/media/pci/ddbridge/ddbridge-core.c +++
> > b/drivers/media/pci/ddbridge/ddbridge-core.c @@ -1,7 +1,10 @@
> > [...]snip[...]
> > +struct ddb_i2c_msg {
> > +   __u8   bus;
> > +   __u8   adr;
> > +   __u8  *hdr;
> > +   __u32  hlen;
> > +   __u8  *msg;
> > +   __u32  mlen;
> >  };
> >  
> > -#define IOCTL_DDB_FLASHIO  _IOWR(DDB_MAGIC, 0x00, struct
> > ddb_flashio) +#define IOCTL_DDB_FLASHIO_IOWR(DDB_MAGIC, 0x00,
> > struct ddb_flashio) +#define IOCTL_DDB_GPIO_IN_IOWR(DDB_MAGIC,
> > 0x01, struct ddb_gpio) +#define IOCTL_DDB_GPIO_OUT
> > _IOWR(DDB_MAGIC, 0x02, struct ddb_gpio) +#define
> > IOCTL_DDB_ID _IOR(DDB_MAGIC, 0x03, struct ddb_id) +#define
> > IOCTL_DDB_READ_REG   _IOWR(DDB_MAGIC, 0x04, struct ddb_reg)
> > +#define IOCTL_DDB_WRITE_REG  _IOW(DDB_MAGIC, 0x05, struct ddb_reg)
> > +#define IOCTL_DDB_READ_MEM   _IOWR(DDB_MAGIC, 0x06, struct
> > ddb_mem) +#define IOCTL_DDB_WRITE_MEM  _IOR(DDB_MAGIC, 0x07, struct
> > ddb_mem) +#define IOCTL_DDB_READ_MDIO  _IOWR(DDB_MAGIC, 0x08,
> > struct ddb_mdio) +#define IOCTL_DDB_WRITE_MDIO _IOR(DDB_MAGIC,
> > 0x09, struct ddb_mdio) +#define IOCTL_DDB_READ_I2C
> > _IOWR(DDB_MAGIC, 0x0a, struct ddb_i2c_msg) +#define
> > IOCTL_DDB_WRITE_I2C  _IOR(DDB_MAGIC, 0x0b, struct ddb_i2c_msg)  
> 
> That part of the driver is not OK. Those are part of some
> proprietary API. We need to discuss carefully all APIs that we're
> willing to introduce, to be sure that, whatever is there won't
> conflict with an existing API on Linux, and if it makes sense.

Uhh. Hm, well, these are just some IOCTLs solely used
on /dev/ddbridge/cardX devnodes to ie. be able to flash updated FPGA
code onto the cards using the dddvb userspace apps (and other things),
nothing thats intended for global use throughout the rest of the
kernel. While we can strip this from this patchset (together with the
ioctl handler), I really "prefer" not to do so since this will cause
breakage for users wanting to perform such updates.

Ping Ralph, really need help on this one. Can "some" of these go or is
DDB_FLASHIO enough for all tuner cards?

> Even if we accept it, those new APIs should be well documented.

What and where should that go? As mentioned, this is stuff solely used
for DD card control...

> Btw, I noticed that even the existing driver has already one such
> API, with is currently undocumented (IOCTL_DDB_FLASHIO). What's its
> purpose?

FPGA flashing as described above.

> PS.: As patches 1 and 2 are just code rearrangements, I'm applying
> them.

Thanks.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: [PATCH v2 03/14] [media] ddbridge: bump ddbridge code to version 0.9.29

[Mauro Carvalho Chehab]

Em Sat, 29 Jul 2017 13:28:37 +0200
Daniel Scheller  escreveu:

> From: Daniel Scheller 
> 
> This huge patch bumps the ddbridge driver to version 0.9.29. Compared to
> the vendor driver package, DD OctoNET including GTL link support, and all
> DVB-C Modulator card support has been removed since this requires large
> changes to the underlying DVB core API, which should eventually be done
> separately, and, after that, the functionality/device support can be added
> back rather easy.
> 
> While the diff is rather large, the bump is mostly a big refactor of all
> data structures. Yet, the MSI support (message signaled interrupts) is
> greatly improved, also all currently available CI single/duo bridge cards
> are fully supported.
> 
> More changes compared to the upstream driver:
>  - the DDB_USE_WORKER flag/define was removed, kernel worker functionality
>will be used.
>  - coding style is properly fixed (zero complaints from checkpatch)
>  - all (not much though) CamelCase has been fixed to kernel_case
> 
> Great care has been taken to keep all previous changes and fixes (e.g.
> kernel logging via dev_*(), pointer annotations and such) intact.
> 
> Permission to reuse and mainline the driver code was formally granted by
> Ralph Metzler .
> 
> Signed-off-by: Daniel Scheller 
> Tested-by: Richard Scobie 
> Tested-by: Jasmin Jessich 
> Tested-by: Dietmar Spingler 
> Tested-by: Manfred Knick 
> ---
>  drivers/media/pci/ddbridge/ddbridge-core.c | 3496 
> ++--
>  drivers/media/pci/ddbridge/ddbridge-i2c.c  |  217 +-
>  drivers/media/pci/ddbridge/ddbridge-i2c.h  |   41 +-
>  drivers/media/pci/ddbridge/ddbridge-main.c |  490 ++--
>  drivers/media/pci/ddbridge/ddbridge-regs.h |  138 +-
>  drivers/media/pci/ddbridge/ddbridge.h  |  366 ++-
>  6 files changed, 3613 insertions(+), 1135 deletions(-)
> 
> diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c 
> b/drivers/media/pci/ddbridge/ddbridge-core.c
> index 7e164a370273..5045ad6c36fe 100644
> --- a/drivers/media/pci/ddbridge/ddbridge-core.c
> +++ b/drivers/media/pci/ddbridge/ddbridge-core.c
> @@ -1,7 +1,10 @@
>  /*
> - * ddbridge.c: Digital Devices PCIe bridge driver
> + * ddbridge-core.c: Digital Devices bridge core functions
> + *
> + * Copyright (C) 2010-2017 Digital Devices GmbH
> + * Marcus Metzler 
> + * Ralph Metzler 
>   *
> - * Copyright (C) 2010-2011 Digital Devices GmbH
>   *
>   * This program is free software; you can redistribute it and/or
>   * modify it under the terms of the GNU General Public License
> @@ -17,8 +20,6 @@
>   * http://www.gnu.org/copyleft/gpl.html
>   */
>  
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
>  #include 
>  #include 
>  #include 
> @@ -49,77 +50,290 @@
>  #include "stv0910.h"
>  #include "stv6111.h"
>  #include "lnbh25.h"
> +#include "cxd2099.h"
> +
> +//
> +
> +#define DDB_MAX_ADAPTER 64
>  
>  DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  
> -/**/
> -/**/
> -/**/
> +DEFINE_MUTEX(redirect_lock);
> +
> +static struct ddb *ddbs[DDB_MAX_ADAPTER];
> +
> +//
> +//
> +//
> +
> +static struct ddb_regset octopus_input = {
> + .base = 0x200,
> + .num  = 0x08,
> + .size = 0x10,
> +};
> +
> +static struct ddb_regset octopus_output = {
> + .base = 0x280,
> + .num  = 0x08,
> + .size = 0x10,
> +};
> +
> +static struct ddb_regset octopus_idma = {
> + .base = 0x300,
> + .num  = 0x08,
> + .size = 0x10,
> +};
> +
> +static struct ddb_regset octopus_idma_buf = {
> + .base = 0x2000,
> + .num  = 0x08,
> + .size = 0x100,
> +};
> +
> +static struct ddb_regset octopus_odma = {
> + .base = 0x380,
> + .num  = 0x04,
> + .size = 0x10,
> +};
> +
> +static struct ddb_regset octopus_odma_buf = {
> + .base = 0x2800,
> + .num  = 0x04,
> + .size = 0x100,
> +};
> +
> +static struct ddb_regset octopus_i2c = {
> + .base = 0x80,
> + .num  = 0x04,
> + .size = 0x20,
> +};
> +
> +static struct ddb_regset octopus_i2c_buf = {
> + .base = 0x1000,
> + .num  = 0x04,
> + .size = 0x200,
> +};
> +
> +//
> +
> +struct ddb_regmap octopus_map = {
> + .irq_base_i2c = 0,
> + 

Re: [PATCH v2 2/3] v4l2-flash-led-class: Create separate sub-devices for indicators

[Rui Miguel Silva]

Hi,
On Wed, Aug 09, 2017 at 02:15:54PM +0300, Sakari Ailus wrote:
> The V4L2 flash interface allows controlling multiple LEDs through a single
> sub-devices if, and only if, these LEDs are of different types. This
> approach scales badly for flash controllers that drive multiple flash LEDs
> or for LED specific associations. Essentially, the original assumption of a
> LED driver chip that drives a single flash LED and an indicator LED is no
> longer valid.
> 
> Address the matter by registering one sub-device per LED.
> 
> Signed-off-by: Sakari Ailus 
> Reviewed-by: Jacek Anaszewski 
> Acked-by: Pavel Machek 
> ---
>  drivers/leds/leds-aat1290.c|   4 +-
>  drivers/leds/leds-max77693.c   |   4 +-
>  drivers/media/v4l2-core/v4l2-flash-led-class.c | 113 
> +++--
>  drivers/staging/greybus/light.c|  23 +++--

For greybus/light:
Reviewed-by: Rui Miguel Silva 

---
Cheers,
Rui

Re: [PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Rui Miguel Silva]

Hi Sakari,
On Wed, Aug 09, 2017 at 06:36:59PM +0300, Sakari Ailus wrote:
> Hi Rui,
> 
> On Wed, Aug 09, 2017 at 02:20:02PM +0100, Rui Miguel Silva wrote:
> > Hi Sakari,
> > On Wed, Aug 09, 2017 at 02:15:53PM +0300, Sakari Ailus wrote:
> > > From: Rui Miguel Silva 
> > > 
> > > We are allocating memory for the v4l2 flash configuration structure and
> > > leak it in the normal path. Just use the stack for this as we do not
> > > use it outside of this function.
> > > 
> > > Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
> > > Reported-by: Sakari Ailus 
> > > Signed-off-by: Rui Miguel Silva 
> > > Reviewed-by: Viresh Kumar 
> > > ---
> > 
> > This patch is *not* the patch that I have send, here are the code
> > differences from my patch to the one in this series:
> > 
> > <   struct led_classdev_flash *iled = NULL;
> > ---
> > >   struct led_classdev *iled = NULL;
> > 51c57
> > <   iled = _ind->fled;
> > ---
> > >   iled = _ind->fled.led_cdev;
> > 89c95
> > 
> > So, this do not apply at all.
> > Maybe you change something in your side.
> 
> It's been rebased on linux-next and in particular, patch 85f7ff9702bc
> ("media: v4l2-flash: Use led_classdev instead of led_classdev_flash for
> indicator").

Yeah, I miss that patch also that touch greybus, thanks for the
rebase.

---
Cheers,
Rui

Re: [PATCH v1.1 1/1] omap3isp: Skip CSI-2 receiver initialisation in CCP2 configuration

[Pavel Machek]

> If the CSI-2 receiver isn't part of the pipeline (or isn't there to begin
> with), skip its initialisation.
> 
> Signed-off-by: Sakari Ailus 

Looks good to me.

Acked-by: Pavel Machek 

I should be able to test it later, but as Laurent already tested it, I
believe it is good to go.

Thanks,
Pavel

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

Re: [GIT PULL for 4.14] Stream control documentation

[Mauro Carvalho Chehab]

Em Wed, 9 Aug 2017 18:35:07 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Wed, Aug 09, 2017 at 12:29:17PM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 9 Aug 2017 11:03:40 +0300
> > Sakari Ailus  escreveu:
> >   
> > > Hi Mauro,
> > > 
> > > Add stream control documentation.
> > > 
> > > We have recently added support for hardware that makes it possible to have
> > > pipelines that are controlled by more than two drivers. This necessitates
> > > documenting V4L2 stream control behaviour for such pipelines.  
> > 
> > Perhaps I missed this one, but I'm not seeing any e-mail with
> > "docs-rst: media: Document s_stream() video op usage"
> > 
> > Please always submit patches via e-mail too, as it makes easier for
> > us to comment/review when needed.
> > 
> > In any case, I'm appending the patch contents here. I'll reply to it
> > on a next e-mail.  
> 
> The subject of the patch was changed based on the review comments. The
> patch used to be called "docs-rst: media: Document s_stream() core op
> usage".

On such cases, please send a version 2. The primary key to look for a patch
is the patch name :-)
> 
> The changes were rather trivial (core -> video) so I didn't send an update
> to the original one.
> 
> The patch is available here:
> 
> 

As I posted it at the reply, I replied with my comments to the one I
posted, with matches the version on your pull request.

Thanks,
Mauro

Re: [GIT PULL for 4.14] Stream control documentation

[Mauro Carvalho Chehab]

Em Wed, 9 Aug 2017 12:29:17 -0300
Mauro Carvalho Chehab  escreveu:

> Em Wed, 9 Aug 2017 11:03:40 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > Add stream control documentation.
> > 
> > We have recently added support for hardware that makes it possible to have
> > pipelines that are controlled by more than two drivers. This necessitates
> > documenting V4L2 stream control behaviour for such pipelines.  
> 
> Perhaps I missed this one, but I'm not seeing any e-mail with
>   "docs-rst: media: Document s_stream() video op usage"
> 
> Please always submit patches via e-mail too, as it makes easier for
> us to comment/review when needed.
> 
> In any case, I'm appending the patch contents here. I'll reply to it
> on a next e-mail.
> 
> > From ef8e5d20b45b05290c56450d2130a0dc3c021c5a Mon Sep 17 00:00:00 2001
> > From: Sakari Ailus 
> > Date: Thu, 9 Mar 2017 15:07:57 +0200
> > Subject: docs-rst: media: Document s_stream() video op usage
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> > Cc: Linux Media Mailing List ,
> > Mauro Carvalho Chehab 
> > 
> > As we begin to add support for systems with media pipelines controlled by
> > more than one device driver, it is essential that we precisely define the
> > responsibilities of each component in the stream control and common
> > practices.

Not sure what you meant here. Currently, there is support already
for multiple subdevs attached to a driver.

As we're talking here about kAPI, it is quite common that a V4L2 the
need to set multiple devices while stream. A typical non-MC device like
bttv can set up to 4 types of devices:
- tuner;
- audio decoder;
- video decoder;
- video enhancers.

> > Specifically, this patch documents two things:
> > 
> > 1) streaming control is done per sub-device and sub-device drivers
> > themselves are responsible for streaming setup in upstream sub-devices and

In the case of non-MC devices, it is the bridge driver that it is
responsible to pass a "broadcast" message to all subdevices for
them to be at "stream mode".

> > 
> > 2) broken frames should be tolerated at streaming stop. It is the
> > responsibility of the sub-device driver to stop the transmitter after
> > itself if it cannot handle broken frames (and it should be probably be
> > done anyway).

You should define what you mean by "transmitter".

> > 
> > Signed-off-by: Sakari Ailus 
> > Acked-by: Niklas Söderlund 
> > ---
> >  Documentation/media/kapi/v4l2-subdev.rst | 36 
> > 
> >  1 file changed, 36 insertions(+)
> > 
> > diff --git a/Documentation/media/kapi/v4l2-subdev.rst 
> > b/Documentation/media/kapi/v4l2-subdev.rst
> > index e1f0b726e438..100ffc783f72 100644
> > --- a/Documentation/media/kapi/v4l2-subdev.rst
> > +++ b/Documentation/media/kapi/v4l2-subdev.rst
> > @@ -262,6 +262,42 @@ is called. After all subdevices have been located the 
> > .complete() callback is
> >  called. When a subdevice is removed from the system the .unbind() method is
> >  called. All three callbacks are optional.
> >  
> > +Streaming control
> > +^
> > +
> > +Starting and stopping the stream are somewhat complex operations that
> > +often require walking the media graph to enable streaming on
> > +sub-devices which the pipeline consists of. This involves interaction
> > +between multiple drivers, sometimes more than two.
> > +
> > +The ``.s_stream()`` op in :c:type:`v4l2_subdev_video_ops` is responsible
> > +for starting and stopping the stream on the sub-device it is called on.
> > +Additionally, if there are sub-devices further up in the pipeline, i.e.
> > +connected to that sub-device's sink pads through enabled links, the
> > +sub-device driver must call the ``.s_stream()`` video op of all such
> > +sub-devices. The sub-device driver is thus in control of whether the
> > +upstream sub-devices start (or stop) streaming before or after the
> > +sub-device itself is set up for streaming.

Why the sub-device? Even in the MC case, the stream on operation is
usually called via the v4l devnode, where the DMA engine is.

> > +
> > +.. note::
> > +
> > +   As the ``.s_stream()`` callback is called recursively through the
> > +   sub-devices along the pipeline, it is important to keep the
> > +   recursion as short as possible. To this end, drivers are encouraged
> > +   not to internally call ``.s_stream()`` recursively in order to make
> > +   only a single additional recursion per driver in the pipeline. This
> > +   greatly reduces stack usage.

what "drivers" are encouraged not to ...?

> > +
> > +Stopping the transmitter
> > +

What is a transmitter? There are only two places inside kAPI that
uses the word "transmitter":

Re: [PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Sakari Ailus]

Hi Rui,

On Wed, Aug 09, 2017 at 02:20:02PM +0100, Rui Miguel Silva wrote:
> Hi Sakari,
> On Wed, Aug 09, 2017 at 02:15:53PM +0300, Sakari Ailus wrote:
> > From: Rui Miguel Silva 
> > 
> > We are allocating memory for the v4l2 flash configuration structure and
> > leak it in the normal path. Just use the stack for this as we do not
> > use it outside of this function.
> > 
> > Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
> > Reported-by: Sakari Ailus 
> > Signed-off-by: Rui Miguel Silva 
> > Reviewed-by: Viresh Kumar 
> > ---
> 
> This patch is *not* the patch that I have send, here are the code
> differences from my patch to the one in this series:
> 
> < struct led_classdev_flash *iled = NULL;
> ---
> > struct led_classdev *iled = NULL;
> 51c57
> < iled = _ind->fled;
> ---
> > iled = _ind->fled.led_cdev;
> 89c95
> 
> So, this do not apply at all.
> Maybe you change something in your side.

It's been rebased on linux-next and in particular, patch 85f7ff9702bc
("media: v4l2-flash: Use led_classdev instead of led_classdev_flash for
indicator").

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [GIT PULL for 4.14] Stream control documentation

[Sakari Ailus]

Hi Mauro,

On Wed, Aug 09, 2017 at 12:29:17PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 9 Aug 2017 11:03:40 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > Add stream control documentation.
> > 
> > We have recently added support for hardware that makes it possible to have
> > pipelines that are controlled by more than two drivers. This necessitates
> > documenting V4L2 stream control behaviour for such pipelines.
> 
> Perhaps I missed this one, but I'm not seeing any e-mail with
>   "docs-rst: media: Document s_stream() video op usage"
> 
> Please always submit patches via e-mail too, as it makes easier for
> us to comment/review when needed.
> 
> In any case, I'm appending the patch contents here. I'll reply to it
> on a next e-mail.

The subject of the patch was changed based on the review comments. The
patch used to be called "docs-rst: media: Document s_stream() core op
usage".

The changes were rather trivial (core -> video) so I didn't send an update
to the original one.

The patch is available here:



> 
> > From ef8e5d20b45b05290c56450d2130a0dc3c021c5a Mon Sep 17 00:00:00 2001
> > From: Sakari Ailus 
> > Date: Thu, 9 Mar 2017 15:07:57 +0200
> > Subject: docs-rst: media: Document s_stream() video op usage
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> > Cc: Linux Media Mailing List ,
> > Mauro Carvalho Chehab 
> > 
> > As we begin to add support for systems with media pipelines controlled by
> > more than one device driver, it is essential that we precisely define the
> > responsibilities of each component in the stream control and common
> > practices.
> > 
> > Specifically, this patch documents two things:
> > 
> > 1) streaming control is done per sub-device and sub-device drivers
> > themselves are responsible for streaming setup in upstream sub-devices and
> > 
> > 2) broken frames should be tolerated at streaming stop. It is the
> > responsibility of the sub-device driver to stop the transmitter after
> > itself if it cannot handle broken frames (and it should be probably be
> > done anyway).
> > 
> > Signed-off-by: Sakari Ailus 
> > Acked-by: Niklas Söderlund 
> > ---
> >  Documentation/media/kapi/v4l2-subdev.rst | 36 
> > 
> >  1 file changed, 36 insertions(+)
> > 
> > diff --git a/Documentation/media/kapi/v4l2-subdev.rst 
> > b/Documentation/media/kapi/v4l2-subdev.rst
> > index e1f0b726e438..100ffc783f72 100644
> > --- a/Documentation/media/kapi/v4l2-subdev.rst
> > +++ b/Documentation/media/kapi/v4l2-subdev.rst
> > @@ -262,6 +262,42 @@ is called. After all subdevices have been located the 
> > .complete() callback is
> >  called. When a subdevice is removed from the system the .unbind() method is
> >  called. All three callbacks are optional.
> >  
> > +Streaming control
> > +^
> > +
> > +Starting and stopping the stream are somewhat complex operations that
> > +often require walking the media graph to enable streaming on
> > +sub-devices which the pipeline consists of. This involves interaction
> > +between multiple drivers, sometimes more than two.
> > +
> > +The ``.s_stream()`` op in :c:type:`v4l2_subdev_video_ops` is responsible
> > +for starting and stopping the stream on the sub-device it is called on.
> > +Additionally, if there are sub-devices further up in the pipeline, i.e.
> > +connected to that sub-device's sink pads through enabled links, the
> > +sub-device driver must call the ``.s_stream()`` video op of all such
> > +sub-devices. The sub-device driver is thus in control of whether the
> > +upstream sub-devices start (or stop) streaming before or after the
> > +sub-device itself is set up for streaming.
> > +
> > +.. note::
> > +
> > +   As the ``.s_stream()`` callback is called recursively through the
> > +   sub-devices along the pipeline, it is important to keep the
> > +   recursion as short as possible. To this end, drivers are encouraged
> > +   not to internally call ``.s_stream()`` recursively in order to make
> > +   only a single additional recursion per driver in the pipeline. This
> > +   greatly reduces stack usage.
> > +
> > +Stopping the transmitter
> > +
> > +
> > +A transmitter stops sending the stream of images as a result of
> > +calling the ``.s_stream()`` callback. Some transmitters may stop the
> > +stream at a frame boundary whereas others stop immediately,
> > +effectively leaving the current frame unfinished. The receiver driver
> > +should not make assumptions either way, but function properly in both
> > +cases.
> > +
> >  V4L2 sub-device userspace API
> >  -
> >  
> > -- 
> > 2.13.3
> > 
> 
> 
> Thanks,
> Mauro

-- 
Sakari Ailus
e-mail: 

Re: [GIT PULL for 4.14] Stream control documentation

[Mauro Carvalho Chehab]

Em Wed, 9 Aug 2017 11:03:40 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> Add stream control documentation.
> 
> We have recently added support for hardware that makes it possible to have
> pipelines that are controlled by more than two drivers. This necessitates
> documenting V4L2 stream control behaviour for such pipelines.

Perhaps I missed this one, but I'm not seeing any e-mail with
"docs-rst: media: Document s_stream() video op usage"

Please always submit patches via e-mail too, as it makes easier for
us to comment/review when needed.

In any case, I'm appending the patch contents here. I'll reply to it
on a next e-mail.

> From ef8e5d20b45b05290c56450d2130a0dc3c021c5a Mon Sep 17 00:00:00 2001
> From: Sakari Ailus 
> Date: Thu, 9 Mar 2017 15:07:57 +0200
> Subject: docs-rst: media: Document s_stream() video op usage
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> Cc: Linux Media Mailing List ,
> Mauro Carvalho Chehab 
> 
> As we begin to add support for systems with media pipelines controlled by
> more than one device driver, it is essential that we precisely define the
> responsibilities of each component in the stream control and common
> practices.
> 
> Specifically, this patch documents two things:
> 
> 1) streaming control is done per sub-device and sub-device drivers
> themselves are responsible for streaming setup in upstream sub-devices and
> 
> 2) broken frames should be tolerated at streaming stop. It is the
> responsibility of the sub-device driver to stop the transmitter after
> itself if it cannot handle broken frames (and it should be probably be
> done anyway).
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Niklas Söderlund 
> ---
>  Documentation/media/kapi/v4l2-subdev.rst | 36 
> 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/Documentation/media/kapi/v4l2-subdev.rst 
> b/Documentation/media/kapi/v4l2-subdev.rst
> index e1f0b726e438..100ffc783f72 100644
> --- a/Documentation/media/kapi/v4l2-subdev.rst
> +++ b/Documentation/media/kapi/v4l2-subdev.rst
> @@ -262,6 +262,42 @@ is called. After all subdevices have been located the 
> .complete() callback is
>  called. When a subdevice is removed from the system the .unbind() method is
>  called. All three callbacks are optional.
>  
> +Streaming control
> +^
> +
> +Starting and stopping the stream are somewhat complex operations that
> +often require walking the media graph to enable streaming on
> +sub-devices which the pipeline consists of. This involves interaction
> +between multiple drivers, sometimes more than two.
> +
> +The ``.s_stream()`` op in :c:type:`v4l2_subdev_video_ops` is responsible
> +for starting and stopping the stream on the sub-device it is called on.
> +Additionally, if there are sub-devices further up in the pipeline, i.e.
> +connected to that sub-device's sink pads through enabled links, the
> +sub-device driver must call the ``.s_stream()`` video op of all such
> +sub-devices. The sub-device driver is thus in control of whether the
> +upstream sub-devices start (or stop) streaming before or after the
> +sub-device itself is set up for streaming.
> +
> +.. note::
> +
> +   As the ``.s_stream()`` callback is called recursively through the
> +   sub-devices along the pipeline, it is important to keep the
> +   recursion as short as possible. To this end, drivers are encouraged
> +   not to internally call ``.s_stream()`` recursively in order to make
> +   only a single additional recursion per driver in the pipeline. This
> +   greatly reduces stack usage.
> +
> +Stopping the transmitter
> +
> +
> +A transmitter stops sending the stream of images as a result of
> +calling the ``.s_stream()`` callback. Some transmitters may stop the
> +stream at a frame boundary whereas others stop immediately,
> +effectively leaving the current frame unfinished. The receiver driver
> +should not make assumptions either way, but function properly in both
> +cases.
> +
>  V4L2 sub-device userspace API
>  -
>  
> -- 
> 2.13.3
> 


Thanks,
Mauro

Re: [GIT PULL for 4.14] Sensor driver patches for 4.14

[Mauro Carvalho Chehab]

Em Wed, 9 Aug 2017 10:59:38 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> Here are a bunch of sensor driver fixes and improvements for 4.14.
> 
> Please pull.
> 
> 
> The following changes since commit da48c948c263c9d87dfc64566b3373a858cc8aa2:
> 
>   media: fix warning on v4l2_subdev_call() result interpreted as bool 
> (2017-07-26 13:43:17 -0400)
> 
> are available in the git repository at:
> 
>   ssh://linuxtv.org/git/sailus/media_tree.git for-4.14-3
> 
> for you to fetch changes up to f95a6413a07c372cd586b9087a1425b6c216978a:
> 
>   ov9650: fix missing mutex_destroy() (2017-08-09 10:39:13 +0300)
> 
> 
> Arnd Bergmann (1):
>   media: i2c: add KConfig dependencies for ov5670
> 
> Chiranjeevi Rapolu (4):
>   ov13858: Set default fps as current fps
>   ov13858: Fix initial expsoure max
>   ov13858: Correct link-frequency and pixel-rate
>   ov13858: Increase digital gain granularity, range
> 
> Fabio Estevam (2):
>   ov7670: Return the real error code
>   ov7670: Check the return value from clk_prepare_enable()
> 
> Hugues Fruchet (2):
>   ov9650: fix coding style
>   ov9650: fix missing mutex_destroy()
> 
> Julia Lawall (1):
>   vs6624: constify vs6624_default_fmt

Hi Sakari,

Patches 6 to 10 of this series seem to have already be applied. I suspect
that they were on a pull request from Hans.

The ones that applied fine were:

8593f82c01af media: vs6624: constify vs6624_default_fmt
dcadb26976a0 media: ov13858: Increase digital gain granularity, range
36b0d33bfeec media: ov13858: Correct link-frequency and pixel-rate
e1b84da2fa3e media: ov13858: Fix initial expsoure max
973e9b1109d8 media: ov13858: Set default fps as current fps

Please check if something is missing.

Regards,
Mauro

Thanks,
Mauro

Re: [PATCH 3/3] [media] cx231xx: only unregister successfully registered i2c adapters

[Mauro Carvalho Chehab]

Em Wed, 9 Aug 2017 16:43:03 +0200
Peter Rosin  escreveu:

> On 2017-08-09 16:27, Mauro Carvalho Chehab wrote:
> > Em Mon, 31 Jul 2017 15:38:52 +0200
> > Peter Rosin  escreveu:
> >   
> >> This prevents potentially scary debug messages from the i2c core.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/media/usb/cx231xx/cx231xx-core.c | 3 +++
> >>  drivers/media/usb/cx231xx/cx231xx-i2c.c  | 3 ++-
> >>  2 files changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/usb/cx231xx/cx231xx-core.c 
> >> b/drivers/media/usb/cx231xx/cx231xx-core.c
> >> index 46646ecd2dbc..f372ad3917a8 100644
> >> --- a/drivers/media/usb/cx231xx/cx231xx-core.c
> >> +++ b/drivers/media/usb/cx231xx/cx231xx-core.c
> >> @@ -1311,6 +1311,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
> >>dev->i2c_bus[0].i2c_period = I2C_SPEED_100K;/* 100 KHz */
> >>dev->i2c_bus[0].i2c_nostop = 0;
> >>dev->i2c_bus[0].i2c_reserve = 0;
> >> +  dev->i2c_bus[0].i2c_rc = -ENODEV;
> >>  
> >>/* External Master 2 Bus */
> >>dev->i2c_bus[1].nr = 1;
> >> @@ -1318,6 +1319,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
> >>dev->i2c_bus[1].i2c_period = I2C_SPEED_100K;/* 100 KHz */
> >>dev->i2c_bus[1].i2c_nostop = 0;
> >>dev->i2c_bus[1].i2c_reserve = 0;
> >> +  dev->i2c_bus[1].i2c_rc = -ENODEV;
> >>  
> >>/* Internal Master 3 Bus */
> >>dev->i2c_bus[2].nr = 2;
> >> @@ -1325,6 +1327,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
> >>dev->i2c_bus[2].i2c_period = I2C_SPEED_100K;/* 100kHz */
> >>dev->i2c_bus[2].i2c_nostop = 0;
> >>dev->i2c_bus[2].i2c_reserve = 0;
> >> +  dev->i2c_bus[2].i2c_rc = -ENODEV;
> >>  
> >>/* register I2C buses */
> >>errCode = cx231xx_i2c_register(>i2c_bus[0]);
> >> diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c 
> >> b/drivers/media/usb/cx231xx/cx231xx-i2c.c
> >> index 3e49517cb5e0..8ce6b815d16d 100644
> >> --- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
> >> +++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
> >> @@ -553,7 +553,8 @@ int cx231xx_i2c_register(struct cx231xx_i2c *bus)
> >>   */
> >>  void cx231xx_i2c_unregister(struct cx231xx_i2c *bus)
> >>  {
> >> -  i2c_del_adapter(>i2c_adap);
> >> +  if (!bus->i2c_rc)
> >> +  i2c_del_adapter(>i2c_adap);  
> > 
> > That doesn't sound right. what happens if i2c_rc is 1 or 2?
> > 
> > IMHO, the right would would be, instead:
> > 
> > if (bus->i2c_rc >= 0)
> > i2c_del_adapter(>i2c_adap);  
> 
> In theory, yes. But in practice i2c_add_adapter never returns >0, and is
> also documented so.

Good point. Just applied the patch.
> 
> Let me know if you still want an update. In that case I'll also fix the
> precedent present in the context of patch 1/3, i.e.
> 
>   if (0 != bus->i2c_rc)
>   ...
> 
> Cheers,
> peda



Thanks,
Mauro

Re: [PATCH 3/3] [media] cx231xx: only unregister successfully registered i2c adapters

[Peter Rosin]

On 2017-08-09 16:27, Mauro Carvalho Chehab wrote:
> Em Mon, 31 Jul 2017 15:38:52 +0200
> Peter Rosin  escreveu:
> 
>> This prevents potentially scary debug messages from the i2c core.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/media/usb/cx231xx/cx231xx-core.c | 3 +++
>>  drivers/media/usb/cx231xx/cx231xx-i2c.c  | 3 ++-
>>  2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-core.c 
>> b/drivers/media/usb/cx231xx/cx231xx-core.c
>> index 46646ecd2dbc..f372ad3917a8 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-core.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-core.c
>> @@ -1311,6 +1311,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
>>  dev->i2c_bus[0].i2c_period = I2C_SPEED_100K;/* 100 KHz */
>>  dev->i2c_bus[0].i2c_nostop = 0;
>>  dev->i2c_bus[0].i2c_reserve = 0;
>> +dev->i2c_bus[0].i2c_rc = -ENODEV;
>>  
>>  /* External Master 2 Bus */
>>  dev->i2c_bus[1].nr = 1;
>> @@ -1318,6 +1319,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
>>  dev->i2c_bus[1].i2c_period = I2C_SPEED_100K;/* 100 KHz */
>>  dev->i2c_bus[1].i2c_nostop = 0;
>>  dev->i2c_bus[1].i2c_reserve = 0;
>> +dev->i2c_bus[1].i2c_rc = -ENODEV;
>>  
>>  /* Internal Master 3 Bus */
>>  dev->i2c_bus[2].nr = 2;
>> @@ -1325,6 +1327,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
>>  dev->i2c_bus[2].i2c_period = I2C_SPEED_100K;/* 100kHz */
>>  dev->i2c_bus[2].i2c_nostop = 0;
>>  dev->i2c_bus[2].i2c_reserve = 0;
>> +dev->i2c_bus[2].i2c_rc = -ENODEV;
>>  
>>  /* register I2C buses */
>>  errCode = cx231xx_i2c_register(>i2c_bus[0]);
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c 
>> b/drivers/media/usb/cx231xx/cx231xx-i2c.c
>> index 3e49517cb5e0..8ce6b815d16d 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
>> @@ -553,7 +553,8 @@ int cx231xx_i2c_register(struct cx231xx_i2c *bus)
>>   */
>>  void cx231xx_i2c_unregister(struct cx231xx_i2c *bus)
>>  {
>> -i2c_del_adapter(>i2c_adap);
>> +if (!bus->i2c_rc)
>> +i2c_del_adapter(>i2c_adap);
> 
> That doesn't sound right. what happens if i2c_rc is 1 or 2?
> 
> IMHO, the right would would be, instead:
> 
>   if (bus->i2c_rc >= 0)
>   i2c_del_adapter(>i2c_adap);

In theory, yes. But in practice i2c_add_adapter never returns >0, and is
also documented so.

Let me know if you still want an update. In that case I'll also fix the
precedent present in the context of patch 1/3, i.e.

if (0 != bus->i2c_rc)
...

Cheers,
peda

Re: [PATCH v2 3/3] rc: add zx-irdec remote control driver

[Sean Young]

Hi Shawn,

On Wed, Aug 09, 2017 at 09:48:18PM +0800, Shawn Guo wrote:
> On Wed, Aug 09, 2017 at 02:00:29PM +0100, Sean Young wrote:
> > On Sun, Jul 30, 2017 at 09:23:13PM +0800, Shawn Guo wrote:
> > > From: Shawn Guo 
> > > 
> > > It adds the remote control driver and corresponding keymap file for
> > > IRDEC block found on ZTE ZX family SoCs.
> > > 
> > > Signed-off-by: Shawn Guo 
> > > ---
> > >  drivers/media/rc/Kconfig   |  11 ++
> > >  drivers/media/rc/Makefile  |   1 +
> > >  drivers/media/rc/keymaps/Makefile  |   3 +-
> > >  drivers/media/rc/keymaps/rc-zx-irdec.c |  79 ++
> > >  drivers/media/rc/zx-irdec.c| 183 
> > > +
> > >  include/media/rc-map.h |   1 +
> > >  6 files changed, 277 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/media/rc/keymaps/rc-zx-irdec.c
> > >  create mode 100644 drivers/media/rc/zx-irdec.c
> > 
> > We're missing an MAINTAINERS entry for this driver. Could this be added
> > please as a separate patch?
> 
> We are using 'ARM/ZTE ARCHITECTURE' entry in MAINTAINERS for ZTE ZX
> drivers.  I plan to send a separate patch going through arm-soc tree,
> updating MAINTAINERS for those new ZTE ZX drivers landed on mainline
> during 4.14 merge window.  IRDEC will be covered by that patch.  Is that
> okay?

Of course.

Thanks,

Sean

Re: [GIT PULL FOR v4.14] Fixes, fixes, ever more fixes :-)

[Mauro Carvalho Chehab]

Em Fri, 4 Aug 2017 13:40:18 +0200
Hans Verkuil  escreveu:

> Lots of constify patches and some random other fixes. Except for the solo 
> patch
> which is an actual feature enhancement.
> 
> Regards,
> 
>   Hans
> 
> 
> The following changes since commit da48c948c263c9d87dfc64566b3373a858cc8aa2:
> 
>   media: fix warning on v4l2_subdev_call() result interpreted as bool 
> (2017-07-26 13:43:17 -0400)
> 
> are available in the git repository at:
> 
>   git://linuxtv.org/hverkuil/media_tree.git for-v4.14e
> 
> for you to fetch changes up to 09408627c4d001f4df6ede6d22eb27c2945c455c:
> 
>   v4l2-compat-ioctl32: Fix timespec conversion (2017-08-04 13:27:18 +0200)
> 
> 
> Anton Sviridenko (1):
>   solo6x10: export hardware GPIO pins 8:31 to gpiolib interface
> 
> Arvind Yadav (27):
>   marvell-ccic: constify pci_device_id.
>   netup_unidvb: constify pci_device_id.
>   cx23885: constify pci_device_id.
>   meye: constify pci_device_id.
>   pluto2: constify pci_device_id.
>   dm1105: constify pci_device_id.
>   zoran: constify pci_device_id.
>   bt8xx: constify pci_device_id.
>   bt8xx: bttv: constify pci_device_id.
>   ivtv: constify pci_device_id.
>   cobalt: constify pci_device_id.
>   b2c2: constify pci_device_id.
>   saa7164: constify pci_device_id.
>   pt1: constify pci_device_id.
>   mantis: constify pci_device_id.
>   mantis: hopper_cards: constify pci_device_id.
>   cx18: constify pci_device_id.
>   radio: constify pci_device_id.
>   drv-intf: saa7146: constify pci_device_id.
>   ttpci: budget: constify pci_device_id.
>   ttpci: budget-patch: constify pci_device_id.
>   ttpci: budget-ci: constify pci_device_id.
>   ttpci: budget-av: constify pci_device_id.
>   ttpci: av7110: constify pci_device_id.
>   saa7146: mxb: constify pci_device_id.
>   saa7146: hexium_orion: constify pci_device_id.
>   saa7146: hexium_gemini: constify pci_device_id.
> 
> Dan Carpenter (1):
>   adv7604: Prevent out of bounds access
> 
> Daniel Mentz (2):
>   v4l2-compat-ioctl32: Copy v4l2_window->global_alpha
>   v4l2-compat-ioctl32: Fix timespec conversion
> 
> Julia Lawall (1):
>   DaVinci-VPBE: constify vpbe_dev_ops
> 
> Peter Rosin (3):
>   cx231xx: fail probe if i2c_add_adapter fails
>   cx231xx: drop return value of cx231xx_i2c_unregister


>   cx231xx: only unregister successfully registered i2c adapters

IMHO, this fix is wrong: it will prevent the driver to unregister RC
if the I2C bus is not zero.

The remaining patches are OK, and were applied.

Regards,
Mauro

Thanks,
Mauro

Re: [PATCH 3/3] [media] cx231xx: only unregister successfully registered i2c adapters

[Mauro Carvalho Chehab]

Em Mon, 31 Jul 2017 15:38:52 +0200
Peter Rosin  escreveu:

> This prevents potentially scary debug messages from the i2c core.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/media/usb/cx231xx/cx231xx-core.c | 3 +++
>  drivers/media/usb/cx231xx/cx231xx-i2c.c  | 3 ++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/cx231xx/cx231xx-core.c 
> b/drivers/media/usb/cx231xx/cx231xx-core.c
> index 46646ecd2dbc..f372ad3917a8 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-core.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-core.c
> @@ -1311,6 +1311,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
>   dev->i2c_bus[0].i2c_period = I2C_SPEED_100K;/* 100 KHz */
>   dev->i2c_bus[0].i2c_nostop = 0;
>   dev->i2c_bus[0].i2c_reserve = 0;
> + dev->i2c_bus[0].i2c_rc = -ENODEV;
>  
>   /* External Master 2 Bus */
>   dev->i2c_bus[1].nr = 1;
> @@ -1318,6 +1319,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
>   dev->i2c_bus[1].i2c_period = I2C_SPEED_100K;/* 100 KHz */
>   dev->i2c_bus[1].i2c_nostop = 0;
>   dev->i2c_bus[1].i2c_reserve = 0;
> + dev->i2c_bus[1].i2c_rc = -ENODEV;
>  
>   /* Internal Master 3 Bus */
>   dev->i2c_bus[2].nr = 2;
> @@ -1325,6 +1327,7 @@ int cx231xx_dev_init(struct cx231xx *dev)
>   dev->i2c_bus[2].i2c_period = I2C_SPEED_100K;/* 100kHz */
>   dev->i2c_bus[2].i2c_nostop = 0;
>   dev->i2c_bus[2].i2c_reserve = 0;
> + dev->i2c_bus[2].i2c_rc = -ENODEV;
>  
>   /* register I2C buses */
>   errCode = cx231xx_i2c_register(>i2c_bus[0]);
> diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c 
> b/drivers/media/usb/cx231xx/cx231xx-i2c.c
> index 3e49517cb5e0..8ce6b815d16d 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
> @@ -553,7 +553,8 @@ int cx231xx_i2c_register(struct cx231xx_i2c *bus)
>   */
>  void cx231xx_i2c_unregister(struct cx231xx_i2c *bus)
>  {
> - i2c_del_adapter(>i2c_adap);
> + if (!bus->i2c_rc)
> + i2c_del_adapter(>i2c_adap);

That doesn't sound right. what happens if i2c_rc is 1 or 2?

IMHO, the right would would be, instead:

if (bus->i2c_rc >= 0)
i2c_del_adapter(>i2c_adap);

Regards

Thanks,
Mauro

Re: [PATCH v2 3/3] rc: add zx-irdec remote control driver

[Shawn Guo]

Hi Sean,

On Wed, Aug 09, 2017 at 02:00:29PM +0100, Sean Young wrote:
> On Sun, Jul 30, 2017 at 09:23:13PM +0800, Shawn Guo wrote:
> > From: Shawn Guo 
> > 
> > It adds the remote control driver and corresponding keymap file for
> > IRDEC block found on ZTE ZX family SoCs.
> > 
> > Signed-off-by: Shawn Guo 
> > ---
> >  drivers/media/rc/Kconfig   |  11 ++
> >  drivers/media/rc/Makefile  |   1 +
> >  drivers/media/rc/keymaps/Makefile  |   3 +-
> >  drivers/media/rc/keymaps/rc-zx-irdec.c |  79 ++
> >  drivers/media/rc/zx-irdec.c| 183 
> > +
> >  include/media/rc-map.h |   1 +
> >  6 files changed, 277 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/media/rc/keymaps/rc-zx-irdec.c
> >  create mode 100644 drivers/media/rc/zx-irdec.c
> 
> We're missing an MAINTAINERS entry for this driver. Could this be added
> please as a separate patch?

We are using 'ARM/ZTE ARCHITECTURE' entry in MAINTAINERS for ZTE ZX
drivers.  I plan to send a separate patch going through arm-soc tree,
updating MAINTAINERS for those new ZTE ZX drivers landed on mainline
during 4.14 merge window.  IRDEC will be covered by that patch.  Is that
okay?

Shawn

Re: [PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Rui Miguel Silva]

Hi Sakari,
On Wed, Aug 09, 2017 at 02:15:53PM +0300, Sakari Ailus wrote:
> From: Rui Miguel Silva 
> 
> We are allocating memory for the v4l2 flash configuration structure and
> leak it in the normal path. Just use the stack for this as we do not
> use it outside of this function.
> 
> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
> Reported-by: Sakari Ailus 
> Signed-off-by: Rui Miguel Silva 
> Reviewed-by: Viresh Kumar 
> ---

This patch is *not* the patch that I have send, here are the code
differences from my patch to the one in this series:

<   struct led_classdev_flash *iled = NULL;
---
>   struct led_classdev *iled = NULL;
51c57
<   iled = _ind->fled;
---
>   iled = _ind->fled.led_cdev;
89c95

So, this do not apply at all.
Maybe you change something in your side.

---
Cheers,
Rui


>  drivers/staging/greybus/light.c | 29 +
>  1 file changed, 9 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
> index 129ceed39829..0771db418f84 100644
> --- a/drivers/staging/greybus/light.c
> +++ b/drivers/staging/greybus/light.c
> @@ -534,25 +534,20 @@ static int gb_lights_light_v4l2_register(struct 
> gb_light *light)
>  {
>   struct gb_connection *connection = get_conn_from_light(light);
>   struct device *dev = >bundle->dev;
> - struct v4l2_flash_config *sd_cfg;
> + struct v4l2_flash_config sd_cfg = { {0} };
>   struct led_classdev_flash *fled;
>   struct led_classdev *iled = NULL;
>   struct gb_channel *channel_torch, *channel_ind, *channel_flash;
> - int ret = 0;
> -
> - sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
> - if (!sd_cfg)
> - return -ENOMEM;
>  
>   channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
>   if (channel_torch)
>   __gb_lights_channel_v4l2_config(_torch->intensity_uA,
> - _cfg->torch_intensity);
> + _cfg.torch_intensity);
>  
>   channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
>   if (channel_ind) {
>   __gb_lights_channel_v4l2_config(_ind->intensity_uA,
> - _cfg->indicator_intensity);
> + _cfg.indicator_intensity);
>   iled = _ind->fled.led_cdev;
>   }
>  
> @@ -561,27 +556,21 @@ static int gb_lights_light_v4l2_register(struct 
> gb_light *light)
>  
>   fled = _flash->fled;
>  
> - snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
> + snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
>  
>   /* Set the possible values to faults, in our case all faults */
> - sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
> + sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
>   LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
>   LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
>   LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
>   LED_FAULT_LED_OVER_TEMPERATURE;
>  
>   light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
> - _flash_ops, sd_cfg);
> - if (IS_ERR_OR_NULL(light->v4l2_flash)) {
> - ret = PTR_ERR(light->v4l2_flash);
> - goto out_free;
> - }
> + _flash_ops, _cfg);
> + if (IS_ERR_OR_NULL(light->v4l2_flash))
> + return PTR_ERR(light->v4l2_flash);
>  
> - return ret;
> -
> -out_free:
> - kfree(sd_cfg);
> - return ret;
> + return 0;
>  }
>  
>  static void gb_lights_light_v4l2_unregister(struct gb_light *light)
> -- 
> 2.11.0
> 

Re: [PATCH v2 3/3] rc: add zx-irdec remote control driver

[Sean Young]

On Sun, Jul 30, 2017 at 09:23:13PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> It adds the remote control driver and corresponding keymap file for
> IRDEC block found on ZTE ZX family SoCs.
> 
> Signed-off-by: Shawn Guo 
> ---
>  drivers/media/rc/Kconfig   |  11 ++
>  drivers/media/rc/Makefile  |   1 +
>  drivers/media/rc/keymaps/Makefile  |   3 +-
>  drivers/media/rc/keymaps/rc-zx-irdec.c |  79 ++
>  drivers/media/rc/zx-irdec.c| 183 
> +
>  include/media/rc-map.h |   1 +
>  6 files changed, 277 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/rc/keymaps/rc-zx-irdec.c
>  create mode 100644 drivers/media/rc/zx-irdec.c

We're missing an MAINTAINERS entry for this driver. Could this be added
please as a separate patch?

Thanks
Sean

Re: [PATCH 0/4] drm/bridge/adv7511: add CEC support

[Archit Taneja]

On 07/30/2017 06:37 PM, Hans Verkuil wrote:

From: Hans Verkuil 

This patch series adds CEC support to the drm adv7511/adv7533 drivers.

I have tested this with the Qualcomm Dragonboard C410 (adv7533 based)
and the Renesas R-Car Koelsch board (adv7511 based).

Note: the Dragonboard needs this patch:

https://patchwork.kernel.org/patch/9824773/

Archit, can you confirm that this patch will go to kernel 4.14?


Yes, it's been queued to clk-next.

Thanks,
Archit



And the Koelsch board needs this 4.13 fix:

https://patchwork.kernel.org/patch/9836865/

I only have the Koelsch board to test with, but it looks like other
R-Car boards use the same adv7511. It would be nice if someone can
add CEC support to the other R-Car boards as well. The main thing
to check is if they all use the same 12 MHz fixed CEC clock source.

Anyone who wants to test this will need the CEC utilities that
are part of the v4l-utils git repository:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh
./configure
make
sudo make install

Now configure the CEC adapter as a Playback device:

cec-ctl --playback

Discover other CEC devices:

cec-ctl -S

Regards,

Hans

Hans Verkuil (4):
   dt-bindings: adi,adv7511.txt: document cec clock
   arm: dts: qcom: add cec clock for apq8016 board
   arm: dts: renesas: add cec clock for Koelsch board
   drm: adv7511/33: add HDMI CEC support

  .../bindings/display/bridge/adi,adv7511.txt|   4 +
  arch/arm/boot/dts/r8a7791-koelsch.dts  |   8 +
  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |   2 +
  drivers/gpu/drm/bridge/adv7511/Kconfig |   8 +
  drivers/gpu/drm/bridge/adv7511/Makefile|   1 +
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  45 ++-
  drivers/gpu/drm/bridge/adv7511/adv7511_cec.c   | 314 +
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 152 +-
  drivers/gpu/drm/bridge/adv7511/adv7533.c   |  30 +-
  9 files changed, 514 insertions(+), 50 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] media: i2c: adv748x: Export I2C device table entries as module aliases

[Javier Martinez Canillas]

On 08/09/2017 01:05 PM, Kieran Bingham wrote:
> On 09/08/17 11:58, Javier Martinez Canillas wrote:
>> Hi Kieran,
>>
>> On 08/09/2017 12:29 PM, Kieran Bingham wrote:
>>> Hi Javier,
>>>
>>> Thankyou for the patch
>>
>> You are welcome.
>>  
>>> On 09/08/17 10:37, Javier Martinez Canillas wrote:
 The I2C core always reports a MODALIAS of the form i2c: even if the
 device was registered via OF, and the driver is only exporting the OF ID
 table entries as module aliases.

 So if the driver is built as module, autoload won't work since udev/kmod
 won't be able to match the registered OF device with its driver module.
>>>
>>> Good catch, and perhaps I should have known better :D
>>>
>>> I've only worked on this driver as a built-in so far :-) #BadExcuses
>>>
>>
>> A better excuse I think is that after all these years, one would had thought
>> that the I2C OF modalias issue would had been finally fixed, but not yet :)
> 
> Quite! Let's try to bubble that back up the todo list.
> Now - where did I put my free time. I'm sure I left it around here somewhere 
> :-)
> 

We are getting there though. I'm just waiting for the patches in this [0] series
to land and then I'll be able to post the I2C core uevent modalias patch.

I've asked Wolfram if he can at least pick the driver patches [1], but he didn't
answer me yet...

[0]: https://www.spinics.net/lists/arm-kernel/msg588431.html
[1]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1457427.html

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

[PATCH v2 3/3] v4l2-flash-led-class: Document v4l2_flash_init() references

[Sakari Ailus]

The v4l2_flash_init() keeps a reference to the ops struct but not to the
config struct (nor anything it contains). Document this.

Signed-off-by: Sakari Ailus 
Acked-by: Pavel Machek 
---
 include/media/v4l2-flash-led-class.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/media/v4l2-flash-led-class.h 
b/include/media/v4l2-flash-led-class.h
index c3f39992f3fa..6f4825b6a352 100644
--- a/include/media/v4l2-flash-led-class.h
+++ b/include/media/v4l2-flash-led-class.h
@@ -112,6 +112,9 @@ static inline struct v4l2_flash 
*v4l2_ctrl_to_v4l2_flash(struct v4l2_ctrl *c)
  * @config:initialization data for V4L2 Flash sub-device
  *
  * Create V4L2 Flash sub-device wrapping given LED subsystem device.
+ * The ops pointer is stored by the V4L2 flash framework. No
+ * references are held to config nor its contents once this function
+ * has returned.
  *
  * Returns: A valid pointer, or, when an error occurs, the return
  * value is encoded using ERR_PTR(). Use IS_ERR() to check and
@@ -130,6 +133,9 @@ struct v4l2_flash *v4l2_flash_init(
  * @config:initialization data for V4L2 Flash sub-device
  *
  * Create V4L2 Flash sub-device wrapping given LED subsystem device.
+ * The ops pointer is stored by the V4L2 flash framework. No
+ * references are held to config nor its contents once this function
+ * has returned.
  *
  * Returns: A valid pointer, or, when an error occurs, the return
  * value is encoded using ERR_PTR(). Use IS_ERR() to check and
-- 
2.11.0

[PATCH v2 2/3] v4l2-flash-led-class: Create separate sub-devices for indicators

[Sakari Ailus]

The V4L2 flash interface allows controlling multiple LEDs through a single
sub-devices if, and only if, these LEDs are of different types. This
approach scales badly for flash controllers that drive multiple flash LEDs
or for LED specific associations. Essentially, the original assumption of a
LED driver chip that drives a single flash LED and an indicator LED is no
longer valid.

Address the matter by registering one sub-device per LED.

Signed-off-by: Sakari Ailus 
Reviewed-by: Jacek Anaszewski 
Acked-by: Pavel Machek 
---
 drivers/leds/leds-aat1290.c|   4 +-
 drivers/leds/leds-max77693.c   |   4 +-
 drivers/media/v4l2-core/v4l2-flash-led-class.c | 113 +++--
 drivers/staging/greybus/light.c|  23 +++--
 include/media/v4l2-flash-led-class.h   |  41 ++---
 5 files changed, 117 insertions(+), 68 deletions(-)

diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index a21e19297745..424898e6c69d 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -432,7 +432,7 @@ static void aat1290_init_v4l2_flash_config(struct 
aat1290_led *led,
strlcpy(v4l2_sd_cfg->dev_name, led_cdev->name,
sizeof(v4l2_sd_cfg->dev_name));
 
-   s = _sd_cfg->torch_intensity;
+   s = _sd_cfg->intensity;
s->min = led->mm_current_scale[0];
s->max = led_cfg->max_mm_current;
s->step = 1;
@@ -504,7 +504,7 @@ static int aat1290_led_probe(struct platform_device *pdev)
 
/* Create V4L2 Flash subdev. */
led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
- fled_cdev, NULL, _flash_ops,
+ fled_cdev, _flash_ops,
  _sd_cfg);
if (IS_ERR(led->v4l2_flash)) {
ret = PTR_ERR(led->v4l2_flash);
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
index 2d3062d53325..adf0f191f794 100644
--- a/drivers/leds/leds-max77693.c
+++ b/drivers/leds/leds-max77693.c
@@ -856,7 +856,7 @@ static void max77693_init_v4l2_flash_config(struct 
max77693_sub_led *sub_led,
 "%s %d-%04x", sub_led->fled_cdev.led_cdev.name,
 i2c_adapter_id(i2c->adapter), i2c->addr);
 
-   s = _sd_cfg->torch_intensity;
+   s = _sd_cfg->intensity;
s->min = TORCH_IOUT_MIN;
s->max = sub_led->fled_cdev.led_cdev.max_brightness * TORCH_IOUT_STEP;
s->step = TORCH_IOUT_STEP;
@@ -931,7 +931,7 @@ static int max77693_register_led(struct max77693_sub_led 
*sub_led,
 
/* Register in the V4L2 subsystem. */
sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
- fled_cdev, NULL, _flash_ops,
+ fled_cdev, _flash_ops,
  _sd_cfg);
if (IS_ERR(sub_led->v4l2_flash)) {
ret = PTR_ERR(sub_led->v4l2_flash);
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c 
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
index aabc85dbb8b5..4ceef217de83 100644
--- a/drivers/media/v4l2-core/v4l2-flash-led-class.c
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -197,7 +197,7 @@ static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
 {
struct v4l2_flash *v4l2_flash = v4l2_ctrl_to_v4l2_flash(c);
struct led_classdev_flash *fled_cdev = v4l2_flash->fled_cdev;
-   struct led_classdev *led_cdev = _cdev->led_cdev;
+   struct led_classdev *led_cdev = fled_cdev ? _cdev->led_cdev : NULL;
struct v4l2_ctrl **ctrls = v4l2_flash->ctrls;
bool external_strobe;
int ret = 0;
@@ -299,10 +299,26 @@ static void __fill_ctrl_init_data(struct v4l2_flash 
*v4l2_flash,
  struct v4l2_flash_ctrl_data *ctrl_init_data)
 {
struct led_classdev_flash *fled_cdev = v4l2_flash->fled_cdev;
-   struct led_classdev *led_cdev = _cdev->led_cdev;
+   struct led_classdev *led_cdev = fled_cdev ? _cdev->led_cdev : NULL;
struct v4l2_ctrl_config *ctrl_cfg;
u32 mask;
 
+   /* Init INDICATOR_INTENSITY ctrl data */
+   if (v4l2_flash->iled_cdev) {
+   ctrl_init_data[INDICATOR_INTENSITY].cid =
+   V4L2_CID_FLASH_INDICATOR_INTENSITY;
+   ctrl_cfg = _init_data[INDICATOR_INTENSITY].config;
+   __lfs_to_v4l2_ctrl_config(_cfg->intensity,
+ ctrl_cfg);
+   ctrl_cfg->id = V4L2_CID_FLASH_INDICATOR_INTENSITY;
+   ctrl_cfg->min = 0;
+   ctrl_cfg->flags = V4L2_CTRL_FLAG_VOLATILE |
+ V4L2_CTRL_FLAG_EXECUTE_ON_WRITE;
+   }
+
+   if (!led_cdev || WARN_ON(!(led_cdev->flags & LED_DEV_CAP_FLASH)))
+   

[PATCH v2 0/3] Create sub-device per LED

[Sakari Ailus]

Hi folks,

The original design decision in the V4L2 flash API allows controlling a two
LEDs (an indicator and a flash) through a single sub-device. This covered
virtually all flash driver chips back then but this no longer holds as
there are many LED driver chips with multiple flash LED outputs. This
necessitates creating as many sub-devices as there are flash LEDs.

Additionally the flash LEDs can be associated to different sensors. This is
not unconceivable although not very probable.

This patchset splits the indicator and flash LEDs exposed by the V4L2 flash
class framework into multiple sub-devices. This way the driver creates the
sub-devices individually for each LED which will also facilitate fwnode
matching (e.g. will you refer to LED or a LED driver chip with a phandle?).

since v1:

- Drop patch "staging: greybus: light: Don't leak memory for no gain" in
  favour of Rui's "staging: greybus: light: fix memory leak in v4l2
  register".

- Rebase "staging: greybus: light: fix memory leak in v4l2 register" on
  "media: v4l2-flash: Use led_classdev instead of led_classdev_flash for
  indicator" already in mediatree.

- Add "v4l2-flash-led-class: Document v4l2_flash_init() references" to the
  set.

Rui Miguel Silva (1):
  staging: greybus: light: fix memory leak in v4l2 register

Sakari Ailus (2):
  v4l2-flash-led-class: Create separate sub-devices for indicators
  v4l2-flash-led-class: Document v4l2_flash_init() references

 drivers/leds/leds-aat1290.c|   4 +-
 drivers/leds/leds-max77693.c   |   4 +-
 drivers/media/v4l2-core/v4l2-flash-led-class.c | 113 +++--
 drivers/staging/greybus/light.c|  42 -
 include/media/v4l2-flash-led-class.h   |  47 +++---
 5 files changed, 127 insertions(+), 83 deletions(-)

-- 
2.11.0

[PATCH v2 1/3] staging: greybus: light: fix memory leak in v4l2 register

[Sakari Ailus]

From: Rui Miguel Silva 

We are allocating memory for the v4l2 flash configuration structure and
leak it in the normal path. Just use the stack for this as we do not
use it outside of this function.

Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
Reported-by: Sakari Ailus 
Signed-off-by: Rui Miguel Silva 
Reviewed-by: Viresh Kumar 
---
 drivers/staging/greybus/light.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
index 129ceed39829..0771db418f84 100644
--- a/drivers/staging/greybus/light.c
+++ b/drivers/staging/greybus/light.c
@@ -534,25 +534,20 @@ static int gb_lights_light_v4l2_register(struct gb_light 
*light)
 {
struct gb_connection *connection = get_conn_from_light(light);
struct device *dev = >bundle->dev;
-   struct v4l2_flash_config *sd_cfg;
+   struct v4l2_flash_config sd_cfg = { {0} };
struct led_classdev_flash *fled;
struct led_classdev *iled = NULL;
struct gb_channel *channel_torch, *channel_ind, *channel_flash;
-   int ret = 0;
-
-   sd_cfg = kcalloc(1, sizeof(*sd_cfg), GFP_KERNEL);
-   if (!sd_cfg)
-   return -ENOMEM;
 
channel_torch = get_channel_from_mode(light, GB_CHANNEL_MODE_TORCH);
if (channel_torch)
__gb_lights_channel_v4l2_config(_torch->intensity_uA,
-   _cfg->torch_intensity);
+   _cfg.torch_intensity);
 
channel_ind = get_channel_from_mode(light, GB_CHANNEL_MODE_INDICATOR);
if (channel_ind) {
__gb_lights_channel_v4l2_config(_ind->intensity_uA,
-   _cfg->indicator_intensity);
+   _cfg.indicator_intensity);
iled = _ind->fled.led_cdev;
}
 
@@ -561,27 +556,21 @@ static int gb_lights_light_v4l2_register(struct gb_light 
*light)
 
fled = _flash->fled;
 
-   snprintf(sd_cfg->dev_name, sizeof(sd_cfg->dev_name), "%s", light->name);
+   snprintf(sd_cfg.dev_name, sizeof(sd_cfg.dev_name), "%s", light->name);
 
/* Set the possible values to faults, in our case all faults */
-   sd_cfg->flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
+   sd_cfg.flash_faults = LED_FAULT_OVER_VOLTAGE | LED_FAULT_TIMEOUT |
LED_FAULT_OVER_TEMPERATURE | LED_FAULT_SHORT_CIRCUIT |
LED_FAULT_OVER_CURRENT | LED_FAULT_INDICATOR |
LED_FAULT_UNDER_VOLTAGE | LED_FAULT_INPUT_VOLTAGE |
LED_FAULT_LED_OVER_TEMPERATURE;
 
light->v4l2_flash = v4l2_flash_init(dev, NULL, fled, iled,
-   _flash_ops, sd_cfg);
-   if (IS_ERR_OR_NULL(light->v4l2_flash)) {
-   ret = PTR_ERR(light->v4l2_flash);
-   goto out_free;
-   }
+   _flash_ops, _cfg);
+   if (IS_ERR_OR_NULL(light->v4l2_flash))
+   return PTR_ERR(light->v4l2_flash);
 
-   return ret;
-
-out_free:
-   kfree(sd_cfg);
-   return ret;
+   return 0;
 }
 
 static void gb_lights_light_v4l2_unregister(struct gb_light *light)
-- 
2.11.0

Re: [PATCH] media: i2c: adv748x: Export I2C device table entries as module aliases

[Kieran Bingham]

On 09/08/17 11:58, Javier Martinez Canillas wrote:
> Hi Kieran,
> 
> On 08/09/2017 12:29 PM, Kieran Bingham wrote:
>> Hi Javier,
>>
>> Thankyou for the patch
> 
> You are welcome.
>  
>> On 09/08/17 10:37, Javier Martinez Canillas wrote:
>>> The I2C core always reports a MODALIAS of the form i2c: even if the
>>> device was registered via OF, and the driver is only exporting the OF ID
>>> table entries as module aliases.
>>>
>>> So if the driver is built as module, autoload won't work since udev/kmod
>>> won't be able to match the registered OF device with its driver module.
>>
>> Good catch, and perhaps I should have known better :D
>>
>> I've only worked on this driver as a built-in so far :-) #BadExcuses
>>
> 
> A better excuse I think is that after all these years, one would had thought
> that the I2C OF modalias issue would had been finally fixed, but not yet :)

Quite! Let's try to bubble that back up the todo list.
Now - where did I put my free time. I'm sure I left it around here somewhere :-)

--
Kieran

Re: [PATCH] media: i2c: adv748x: Export I2C device table entries as module aliases

[Javier Martinez Canillas]

Hi Kieran,

On 08/09/2017 12:29 PM, Kieran Bingham wrote:
> Hi Javier,
> 
> Thankyou for the patch
>

You are welcome.
 
> On 09/08/17 10:37, Javier Martinez Canillas wrote:
>> The I2C core always reports a MODALIAS of the form i2c: even if the
>> device was registered via OF, and the driver is only exporting the OF ID
>> table entries as module aliases.
>>
>> So if the driver is built as module, autoload won't work since udev/kmod
>> won't be able to match the registered OF device with its driver module.
> 
> Good catch, and perhaps I should have known better :D
> 
> I've only worked on this driver as a built-in so far :-) #BadExcuses
>

A better excuse I think is that after all these years, one would had thought
that the I2C OF modalias issue would had been finally fixed, but not yet :)
 
>> Before this patch:
>>
>> $ modinfo drivers/media/i2c/adv748x/adv748x.ko | grep alias
>> alias:  of:N*T*Cadi,adv7482C*
>> alias:  of:N*T*Cadi,adv7482
>> alias:  of:N*T*Cadi,adv7481C*
>> alias:  of:N*T*Cadi,adv7481
>>
>> After this patch:
>>
>> modinfo drivers/media/i2c/adv748x/adv748x.ko | grep alias
>> alias:  of:N*T*Cadi,adv7482C*
>> alias:  of:N*T*Cadi,adv7482
>> alias:  of:N*T*Cadi,adv7481C*
>> alias:  of:N*T*Cadi,adv7481
>> alias:  i2c:adv7482
>> alias:  i2c:adv7481
>>
>> Signed-off-by: Javier Martinez Canillas 
> 
> Reviewed-by: Kieran Bingham 
> 

Thanks!

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [PATCH] media: i2c: adv748x: Export I2C device table entries as module aliases

[Kieran Bingham]

Hi Javier,

Thankyou for the patch

On 09/08/17 10:37, Javier Martinez Canillas wrote:
> The I2C core always reports a MODALIAS of the form i2c: even if the
> device was registered via OF, and the driver is only exporting the OF ID
> table entries as module aliases.
> 
> So if the driver is built as module, autoload won't work since udev/kmod
> won't be able to match the registered OF device with its driver module.

Good catch, and perhaps I should have known better :D

I've only worked on this driver as a built-in so far :-) #BadExcuses

> Before this patch:
> 
> $ modinfo drivers/media/i2c/adv748x/adv748x.ko | grep alias
> alias:  of:N*T*Cadi,adv7482C*
> alias:  of:N*T*Cadi,adv7482
> alias:  of:N*T*Cadi,adv7481C*
> alias:  of:N*T*Cadi,adv7481
> 
> After this patch:
> 
> modinfo drivers/media/i2c/adv748x/adv748x.ko | grep alias
> alias:  of:N*T*Cadi,adv7482C*
> alias:  of:N*T*Cadi,adv7482
> alias:  of:N*T*Cadi,adv7481C*
> alias:  of:N*T*Cadi,adv7481
> alias:  i2c:adv7482
> alias:  i2c:adv7481
> 
> Signed-off-by: Javier Martinez Canillas 

Reviewed-by: Kieran Bingham 

> ---
> 
>  drivers/media/i2c/adv748x/adv748x-core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index aeb6ae80cb18..5ee14f2c2747 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -807,6 +807,7 @@ static const struct i2c_device_id adv748x_id[] = {
>   { "adv7482", 0 },
>   { },
>  };
> +MODULE_DEVICE_TABLE(i2c, adv748x_id);
>  
>  static const struct of_device_id adv748x_of_table[] = {
>   { .compatible = "adi,adv7481", },
> 

Re: [PATCH 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

On 11/07/17 15:30, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature. This patch series is based on the latest mainline kernel (as of 
> today)
> which has all the needed cec and drm 4.13 patches merged.
> 
> This patch series has been tested with my NUC7i5BNK and a Samsung USB-C to 
> HDMI adapter.

Ping?

> Please note this comment at the start of drm_dp_cec.c:
> 
> --
> Unfortunately it turns out that we have a chicken-and-egg situation
> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> Parade PS176), but they do not wire up the CEC pin, thus making CEC
> useless.
> 
> Sadly there is no way for this driver to know this. What happens is 
> that a /dev/cecX device is created that is isolated and unable to see
> any of the other CEC devices. Quite literally the CEC wire is cut
> (or in this case, never connected in the first place).
> 
> I suspect that the reason so few adapters support this is that this
> tunneling protocol was never supported by any OS. So there was no 
> easy way of testing it, and no incentive to correctly wire up the
> CEC pin.

I got confirmation of this suspicion. This is indeed the reason why so
few adapters hook this up. Having native linux support for this feature
will definitely help the adoption of CEC over DP.

Regards,

Hans

> Hopefully by creating this driver it will be easier for vendors to 
> finally fix their adapters and test the CEC functionality.
> 
> I keep a list of known working adapters here:
> 
> https://hverkuil.home.xs4all.nl/cec-status.txt
> 
> Please mail me (hverk...@xs4all.nl) if you find an adapter that works
> and is not yet listed there.
> --
> 
> I really hope that this work will provide an incentive for vendors to
> finally connect the CEC pin. It's a shame that there are so few adapters
> that work (I found only two USB-C to HDMI adapters that work, and no
> (mini-)DP to HDMI adapters at all).
> 
> Daniel, I incorporated all your suggestions/comments from the RFC patch
> series from about 2 months ago.
> 
> Regards,
> 
> Hans
> 
> Hans Verkuil (3):
>   drm: add support for DisplayPort CEC-Tunneling-over-AUX
>   drm-kms-helpers.rst: document the DP CEC helpers
>   drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
> 
>  Documentation/gpu/drm-kms-helpers.rst |   9 +
>  drivers/gpu/drm/Kconfig   |  10 ++
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/drm_dp_cec.c  | 308 
> ++
>  drivers/gpu/drm/i915/intel_dp.c   |  18 +-
>  include/drm/drm_dp_helper.h   |  24 +++
>  6 files changed, 366 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
> 

[PATCH] media: i2c: adv748x: Export I2C device table entries as module aliases

[Javier Martinez Canillas]

The I2C core always reports a MODALIAS of the form i2c: even if the
device was registered via OF, and the driver is only exporting the OF ID
table entries as module aliases.

So if the driver is built as module, autoload won't work since udev/kmod
won't be able to match the registered OF device with its driver module.

Before this patch:

$ modinfo drivers/media/i2c/adv748x/adv748x.ko | grep alias
alias:  of:N*T*Cadi,adv7482C*
alias:  of:N*T*Cadi,adv7482
alias:  of:N*T*Cadi,adv7481C*
alias:  of:N*T*Cadi,adv7481

After this patch:

modinfo drivers/media/i2c/adv748x/adv748x.ko | grep alias
alias:  of:N*T*Cadi,adv7482C*
alias:  of:N*T*Cadi,adv7482
alias:  of:N*T*Cadi,adv7481C*
alias:  of:N*T*Cadi,adv7481
alias:  i2c:adv7482
alias:  i2c:adv7481

Signed-off-by: Javier Martinez Canillas 
---

 drivers/media/i2c/adv748x/adv748x-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
b/drivers/media/i2c/adv748x/adv748x-core.c
index aeb6ae80cb18..5ee14f2c2747 100644
--- a/drivers/media/i2c/adv748x/adv748x-core.c
+++ b/drivers/media/i2c/adv748x/adv748x-core.c
@@ -807,6 +807,7 @@ static const struct i2c_device_id adv748x_id[] = {
{ "adv7482", 0 },
{ },
 };
+MODULE_DEVICE_TABLE(i2c, adv748x_id);
 
 static const struct of_device_id adv748x_of_table[] = {
{ .compatible = "adi,adv7481", },
-- 
2.13.3

[bug report] v4l: vsp1: Add support for the BRS entity

[Dan Carpenter]

Hello Laurent Pinchart,

This is a semi-automatic email about new static checker warnings.

The patch 6134148f6098: "v4l: vsp1: Add support for the BRS entity"
from May 25, 2017, leads to the following Smatch complaint:

drivers/media/platform/vsp1/vsp1_wpf.c:456 wpf_configure()
error: we previously assumed 'pipe->bru' could be null (see line 450)

drivers/media/platform/vsp1/vsp1_wpf.c
   449  
   450  srcrpf |= (!pipe->bru && pipe->num_inputs == 1)
   451  ? 
VI6_WPF_SRCRPF_RPF_ACT_MST(input->entity.index)
   452  : 
VI6_WPF_SRCRPF_RPF_ACT_SUB(input->entity.index);
   453  }
   454  
   455  if (pipe->bru || pipe->num_inputs > 1)
^
Check for NULL.

   456  srcrpf |= pipe->bru->type == VSP1_ENTITY_BRU
  ^^^
Patch adds new unchecked dereference.

   457  ? VI6_WPF_SRCRPF_VIRACT_MST
   458  : VI6_WPF_SRCRPF_VIRACT2_MST;

regards,
dan carpenter

Re: [PATCH] media: i2c: add KConfig dependencies

[Arnd Bergmann]

On Wed, Aug 9, 2017 at 9:48 AM, Sakari Ailus  wrote:
> Hi Arnd,
>
> Thanks for the patch.
>
> On Tue, Jul 25, 2017 at 05:36:45PM +0200, Arnd Bergmann wrote:
>> @@ -618,8 +618,9 @@ config VIDEO_OV6650
>>
>>  config VIDEO_OV5670
>>   tristate "OmniVision OV5670 sensor support"
>> - depends on I2C && VIDEO_V4L2
>> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>>   depends on MEDIA_CAMERA_SUPPORT
>> + depends on MEDIA_CONTROLLER
>>   select V4L2_FWNODE
>>   ---help---
>> This is a Video4Linux2 sensor-level driver for the OmniVision
>
> Applied, with dropping explicit MEDIA_CONTROLLER. VIDEO_V4L2_SUBDEV_API
> already depends on MEDIA_CONTROLLER.

makes sense, thanks!

   Arnd

Re: [PATCH -next] media: ov5670: add depends to fix build errors

[Sakari Ailus]

On Thu, Jul 20, 2017 at 04:47:38PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix build errors by adding dependency on VIDEO_V4L2_SUBDEV_API:

Thanks for the patch, Randy, but I've already applied Arnd's patch with
very similar content.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[GIT PULL for 4.14] Stream control documentation

[Sakari Ailus]

Hi Mauro,

Add stream control documentation.

We have recently added support for hardware that makes it possible to have
pipelines that are controlled by more than two drivers. This necessitates
documenting V4L2 stream control behaviour for such pipelines.

Please pull.


The following changes since commit da48c948c263c9d87dfc64566b3373a858cc8aa2:

  media: fix warning on v4l2_subdev_call() result interpreted as bool 
(2017-07-26 13:43:17 -0400)

are available in the git repository at:

  https://linuxtv.org/git/sailus/media_tree.git v4l2-stream-doc

for you to fetch changes up to ef8e5d20b45b05290c56450d2130a0dc3c021c5a:

  docs-rst: media: Document s_stream() video op usage (2017-08-08 17:31:25 
+0300)


Sakari Ailus (1):
  docs-rst: media: Document s_stream() video op usage

 Documentation/media/kapi/v4l2-subdev.rst | 36 
 1 file changed, 36 insertions(+)


-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[GIT PULL for 4.14] Sensor driver patches for 4.14

[Sakari Ailus]

Hi Mauro,

Here are a bunch of sensor driver fixes and improvements for 4.14.

Please pull.


The following changes since commit da48c948c263c9d87dfc64566b3373a858cc8aa2:

  media: fix warning on v4l2_subdev_call() result interpreted as bool 
(2017-07-26 13:43:17 -0400)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git for-4.14-3

for you to fetch changes up to f95a6413a07c372cd586b9087a1425b6c216978a:

  ov9650: fix missing mutex_destroy() (2017-08-09 10:39:13 +0300)


Arnd Bergmann (1):
  media: i2c: add KConfig dependencies for ov5670

Chiranjeevi Rapolu (4):
  ov13858: Set default fps as current fps
  ov13858: Fix initial expsoure max
  ov13858: Correct link-frequency and pixel-rate
  ov13858: Increase digital gain granularity, range

Fabio Estevam (2):
  ov7670: Return the real error code
  ov7670: Check the return value from clk_prepare_enable()

Hugues Fruchet (2):
  ov9650: fix coding style
  ov9650: fix missing mutex_destroy()

Julia Lawall (1):
  vs6624: constify vs6624_default_fmt

 drivers/media/i2c/Kconfig   |  2 +-
 drivers/media/i2c/ov13858.c | 70 -
 drivers/media/i2c/ov7670.c  |  6 ++--
 drivers/media/i2c/ov9650.c  | 67 +--
 drivers/media/i2c/vs6624.c  |  2 +-
 5 files changed, 83 insertions(+), 64 deletions(-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[GIT PULL for 4.14] Atomisp cleanups

[Sakari Ailus]

Hi Mauro,

Here's a usual bunch of atomisp cleanups.

Please pull.


The following changes since commit da48c948c263c9d87dfc64566b3373a858cc8aa2:

  media: fix warning on v4l2_subdev_call() result interpreted as bool 
(2017-07-26 13:43:17 -0400)

are available in the git repository at:

  https://linuxtv.org/git/sailus/media_tree.git atomisp

for you to fetch changes up to c06f41fb60389ef7bc59ee58ed07bab444fd5455:

  staging: media: atomisp: constify video_subdev structures (2017-08-08 
15:55:05 +0300)


Geliang Tang (1):
  staging: media: atomisp: use kvmalloc/kvzalloc

Julia Lawall (2):
  staging: media: atomisp: constify videobuf_queue_ops structures
  staging: media: atomisp: constify video_subdev structures

Rene Hickersberger (1):
  staging: media: atomisp: i2c: gc0310: fixed brace coding style issue

Stephen Brennan (1):
  staging: media: atomisp: remove trailing whitespace

 drivers/staging/media/atomisp/i2c/ap1302.c |  2 +-
 drivers/staging/media/atomisp/i2c/gc0310.c |  3 +--
 drivers/staging/media/atomisp/i2c/mt9m114.c|  2 +-
 drivers/staging/media/atomisp/i2c/ov2680.c | 17 ++--
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   | 31 +-
 .../media/atomisp/pci/atomisp2/atomisp_cmd.h   |  2 --
 .../atomisp/pci/atomisp2/atomisp_compat_css20.c|  4 +--
 .../media/atomisp/pci/atomisp2/atomisp_fops.c  |  4 +--
 .../media/atomisp/pci/atomisp2/atomisp_internal.h  |  2 --
 9 files changed, 16 insertions(+), 51 deletions(-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[GIT PULL for 4.13] atomisp bugfix

[Sakari Ailus]

Hi Mauro,

The atomisp was broken by da22013f7df4 ("atomisp: remove indirection from
sh_css_malloc") which caused that sh_css_calloc() wrapper function always
returned NULL.

Please pull.


The following changes since commit da48c948c263c9d87dfc64566b3373a858cc8aa2:

  media: fix warning on v4l2_subdev_call() result interpreted as bool 
(2017-07-26 13:43:17 -0400)

are available in the git repository at:

  https://linuxtv.org/git/sailus/media_tree.git atomisp-fix

for you to fetch changes up to c1d6d0506602b707696d024e989ce90d8970b1e8:

  media: staging: atomisp: sh_css_calloc shall return a pointer to the 
allocated space (2017-08-08 15:54:06 +0300)


Sergei A. Trusov (1):
  media: staging: atomisp: sh_css_calloc shall return a pointer to the 
allocated space

 drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c | 1 +
 1 file changed, 1 insertion(+)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v1 1/2] uapi: media: New fourcc codes needed by Xilinx Video IP

[Laurent Pinchart]

Hi Jeffrey,

Thank you for the patch.

On Tuesday 08 Aug 2017 18:31:17 Jeffrey Mouroux wrote:
> The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP
> support video memory formats that are not represented in the
> current V4L2 fourcc library.  This patch adds those missing
> fourcc codes.

Could you please also document the new formats in 
Documentation/media/uapi/v4l/ ? You can have a look at pixfmt-*.rst for 
examples. Please make sure that the documentation compiles without any error 
("make htmldocs") before submitting the patch.

> Signed-off-by: Jeffrey Mouroux 
> ---
>  include/uapi/linux/videodev2.h | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 45cf735..a059439 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -509,6 +509,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R', 'G', 'B', '4') /* 32 
> RGB-8-8-8-8   */ #define V4L2_PIX_FMT_ARGB32  v4l2_fourcc('B', 'A', '2',
> '4') /* 32  ARGB-8-8-8-8  */ #define V4L2_PIX_FMT_XRGB32  v4l2_fourcc('B',
> 'X', '2', '4') /* 32  XRGB-8-8-8-8  */ +#define V4L2_PIX_FMT_XBGR30 
> v4l2_fourcc('R', 'X', '3', '0') /* 32  XBGR-2-10-10-10 */
> 
>  /* Grey formats */
>  #define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /*  8 
> Greyscale */ @@ -536,12 +537,16 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_VYUYv4l2_fourcc('V', 'Y', 'U', 'Y') /* 16  YUV
> 4:2:2 */ #define V4L2_PIX_FMT_Y41Pv4l2_fourcc('Y', '4', '1', 'P')
> /* 12  YUV 4:1:1 */ #define V4L2_PIX_FMT_YUV444  v4l2_fourcc('Y', '4',
> '4', '4') /* 16    */ +#define V4L2_PIX_FMT_XVUY32 
> v4l2_fourcc('X', 'V', '3', '2') /* 32  XVUY 8:8:8:8 */ +#define
> V4L2_PIX_FMT_AVUY32  v4l2_fourcc('A', 'V', '3', '2') /* 32  AVUY 8:8:8:8 */
> +#define V4L2_PIX_FMT_VUY24   v4l2_fourcc('V', 'U', '2', '4') /* 24  VUY
> 8:8:8 */ #define V4L2_PIX_FMT_YUV555  v4l2_fourcc('Y', 'U', 'V', 'O') /* 16
>  YUV-5-5-5 */ #define V4L2_PIX_FMT_YUV565  v4l2_fourcc('Y', 'U', 'V',
> 'P') /* 16  YUV-5-6-5 */ #define V4L2_PIX_FMT_YUV32   v4l2_fourcc('Y',
> 'U', 'V', '4') /* 32  YUV-8-8-8-8   */ #define V4L2_PIX_FMT_HI240  
> v4l2_fourcc('H', 'I', '2', '4') /*  8  8-bit color   */ #define
> V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 4:2:0 16x16
> macroblocks */ #define V4L2_PIX_FMT_M420v4l2_fourcc('M', '4', '2', '0')
> /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */ +#define
> V4L2_PIX_FMT_XVUY10  v4l2_fourcc('X', 'Y', '1', '0') /* 32  XVUY 2-10-10-10
> */
> 
>  /* two planes -- one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr
> 4:2:0  */ @@ -550,6 +555,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb
> 4:2:2  */ #define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /*
> 24  Y/CbCr 4:4:4  */ #define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V',
> '4', '2') /* 24  Y/CrCb 4:4:4  */ +#define V4L2_PIX_FMT_XV20   
> v4l2_fourcc('X', 'V', '2', '0') /* 32 XY/UV 4:2:2 10-bit */ +#define
> V4L2_PIX_FMT_XV15v4l2_fourcc('X', 'V', '1', '5') /* 32 XY/UV 4:2:0
> 10-bit */
> 
>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr
> 4:2:0  */ @@ -557,6 +564,8 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV16M   v4l2_fourcc('N', 'M', '1', '6') /* 16  Y/CbCr
> 4:2:2  */ #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /*
> 16  Y/CrCb 4:2:2  */ #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M',
> '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */ +#define
> V4L2_PIX_FMT_XV20M   v4l2_fourcc('X', 'M', '2', '0') /* 32 XY/UV 4:2:2
> 10-bit */ +#define V4L2_PIX_FMT_XV15M   v4l2_fourcc('X', 'M', '1', '5') /*
> 32 XY/UV 4:2:0 10-bit */ #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V',
> 'M', '1', '2') /* 12  Y/CbCr 4:2:0 16x16 macroblocks */
> 
>  /* three planes - Y Cb, Cr */

-- 
Regards,

Laurent Pinchart

Re: [PATCH] media: i2c: add KConfig dependencies

[Sakari Ailus]

Hi Arnd,

Thanks for the patch.

On Tue, Jul 25, 2017 at 05:36:45PM +0200, Arnd Bergmann wrote:
> @@ -618,8 +618,9 @@ config VIDEO_OV6650
>  
>  config VIDEO_OV5670
>   tristate "OmniVision OV5670 sensor support"
> - depends on I2C && VIDEO_V4L2
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>   depends on MEDIA_CAMERA_SUPPORT
> + depends on MEDIA_CONTROLLER
>   select V4L2_FWNODE
>   ---help---
> This is a Video4Linux2 sensor-level driver for the OmniVision

Applied, with dropping explicit MEDIA_CONTROLLER. VIDEO_V4L2_SUBDEV_API
already depends on MEDIA_CONTROLLER.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk