date:20170530


On 05/31/2017 01:57 AM, Clint Taylor wrote:



On 05/26/2017 12:18 AM, Daniel Vetter wrote:

On Thu, May 25, 2017 at 05:06:25PM +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 
---
   drivers/gpu/drm/Kconfig  |   3 +
   drivers/gpu/drm/Makefile |   1 +
   drivers/gpu/drm/drm_dp_cec.c | 196 
+++
   include/drm/drm_dp_helper.h  |  24 ++
   4 files changed, 224 insertions(+)
   create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 78d7fc0ebb57..dd771ce8a3d0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,9 @@ 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

We generally don't bother with a Kconfig for every little bit in drm, not
worth the trouble (yes I know there's some exceptions, but somehow they're
all from soc people). Just smash this into the KMS_HELPER one and live is
much easier for drivers. Also allows you to drop the dummy inline
functions.

All of the functions like cec_register_adapter() require
CONFIG_MEDIA_CEC_SUPPORT.
This will add a new dependency to the DRM drivers. All instances of
CONFIG_DRM_DP_CEC should be changed to CONFIG_MEDIA_CEC_SUPPORT so drm
can still be used without the media CEC drivers.


This has changed in the next version. I realized the same thing and there
are CEC core patches pending for 4.12 to solve this.

I plan on posting a new patch series for this later this week, and that
will include those patches for 4.12 so it is easier to test this.

Regards,

Hans

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

On 05/31/2017 01:25 AM, Clint Taylor wrote:

On 05/30/2017 02:29 PM, Hans Verkuil wrote:

On 05/30/2017 10:32 PM, Clint Taylor wrote:

On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:

On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete
newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst
thing (a
simple dp port multiplexer is what I use for testing here, then
plug in a
converter dongle or cable into that) then probably better to not
wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on
buying a
dp multiplexer to make sure there is nothing special I need to do
for mst.

The CEC Tunneling is all in the branch device, so if I understand
things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output
they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to
their
datasheet is supposed to implement CEC Tunneling, but if they do
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware
issue
or something else. The BIOS is able to do some CEC, but whether
they hook
into the MegaChip or have the CEC pin connected to a GPIO or
something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would
be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support
HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for
us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't
support
that in i915.

I don't know about the CEC on that.

My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over
Aux.
The release notes for the NUC state that there is a BIOS
configuration
option for enabling support. My doesn't have the option but the
LSPCON
fully supports CEC.

What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your
NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have
actually
tested it somehow? The only working solution I have seen mentioned
for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC
pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.

If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info

Connector info
--
connector 48: type DP-1, status: connected
name:
physical dimensions: 700x400mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: 175IB0
HW: 1.0
SW: 7.32
Max TMDS clock: 60 kHz
Max bpc: 12

Huh. Based on this document:

https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf

this is the internal DP-to-HDMI adapter and it has the PS175. So it is a
Parade chipset, and I have seen that work before (at least the PS176).

This is the PS175 LSPCON on the NUC6.

connector 55: type DP-2, status: connected
name:
physical dimensions: 620x340mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: BCTRC0
HW: 2.0
SW: 0.26

And is this from a USB-C to HDMI adapter? Which one? I don't recognize
the ID.

This is a LSPCON inside the Google USB-C->HDMI dongle. This is actually
a MC2850 with what appears to be a custom ID. Datasheet claims CEC over
Aux and the pin is wired, but FW has it currently disabled.

OK, in other words the Parade chipsets work and the Megachip chipsets
don't. And Intel in their wisdom decided to go with Megachip for the new
NUCs.

I have no idea if you have any ins with the NUC team, but it would be so
nice if there would be a Megachip firmware update enabling this feature.

Regards,

Hans

Re: [RFC PATCH] [media] v4l2-subdev: check colorimetry in link validate

2017-05-30 Thread Sakari Ailus

Hi Helen,

On Tue, May 30, 2017 at 04:08:08PM -0300, Helen Koike wrote:
> colorspace, ycbcr_enc, quantization and xfer_func must match across the
> link.
> Check if they match in v4l2_subdev_link_validate_default unless they are
> set as _DEFAULT.
> 
> Signed-off-by: Helen Koike 
> 
> ---
> 
> Hi,
> 
> I think we should validate colorimetry as having different colorimetry
> across a link doesn't make sense.
> But I am confused about what to do when they are set to _DEFAULT, what
> do you think?

These fields were added at various points over the course of the past three
years or so. User space code that was written before that will certainly not
set anything and I'm not sure many drivers care about these fields nor they
are relevant for many formats. In practice that means that they are very
likely zero in many cases.

Driver changes will probably be necessary for removing the explicit checks
for the default value.

The same applies to checking the colour space: drivers should enforce using
the correct colour space before the check can be merged. I might move that
to a separate patch.

> 
> Thanks
> ---
>  drivers/media/v4l2-core/v4l2-subdev.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
> b/drivers/media/v4l2-core/v4l2-subdev.c
> index da78497..784ae92 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -502,10 +502,27 @@ int v4l2_subdev_link_validate_default(struct 
> v4l2_subdev *sd,
> struct v4l2_subdev_format *source_fmt,
> struct v4l2_subdev_format *sink_fmt)
>  {
> - /* The width, height and code must match. */
> + /* The width, height, code and colorspace must match. */
>   if (source_fmt->format.width != sink_fmt->format.width
>   || source_fmt->format.height != sink_fmt->format.height
> - || source_fmt->format.code != sink_fmt->format.code)
> + || source_fmt->format.code != sink_fmt->format.code
> + || source_fmt->format.colorspace != sink_fmt->format.colorspace)
> + return -EPIPE;
> +
> + /* Colorimetry must match if they are not set to DEFAULT */
> + if (source_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
> + && sink_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
> + && source_fmt->format.ycbcr_enc != sink_fmt->format.ycbcr_enc)
> + return -EPIPE;
> +
> + if (source_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT
> + && sink_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT
> + && source_fmt->format.quantization != sink_fmt->format.quantization)
> + return -EPIPE;
> +
> + if (source_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT
> + && sink_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT
> + && source_fmt->format.xfer_func != sink_fmt->format.xfer_func)
>   return -EPIPE;
>  
>   /* The field order must match, or the sink field order must be NONE

-- 
Regards,

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

cron job: media_tree daily build: WARNINGS

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:   Wed May 31 05:00:16 CEST 2017
media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030
media_build git hash:   0d8b3274e29b597780719e7ce1b3b460241a5395
v4l-utils git hash: ef074cf5500b7dd62e6eb3527ec47a914c7189ca
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12-rc1-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs

2017-05-30 Thread Joe Perches

On Wed, 2017-05-31 at 12:28 +0900, Hirokazu Honda wrote:
> If I understand a bitmap correctly, it is necessary to change the log level
> for each message.
> I didn't mean a bitmap will take a long CPU time.
> I mean the work to change so takes a long time.

No, none of the messages or levels need change,
only the >= test changes to & so that for instance,
level 1 and level 3 messages could be emitted
without also emitting level 2 messages.

The patch suggested is all that would be required.

Re: [PATCH 04/19] [media] dvb-frontends/cxd2841er: support CXD2837/38/43ER demods/Chip IDs

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Those demods are programmed in the same way as the CXD2841ER/54ER and can
> be handled by this driver. Support added in a way matching the existing
> code, supported delivery systems are set according to what each demod
> supports.
>
> Updates the type string setting used for printing the "attaching..." log
> line aswell.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c  | 24 +++-
>  drivers/media/dvb-frontends/cxd2841er_priv.h |  3 +++
>  2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 09c25d7..72a27cc 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -3733,16 +3733,39 @@ static struct dvb_frontend *cxd2841er_attach(struct 
> cxd2841er_config *cfg,
> priv->i2c_addr_slvx, priv->i2c_addr_slvt);
> chip_id = cxd2841er_chip_id(priv);
> switch (chip_id) {
> +   case CXD2837ER_CHIP_ID:
> +   snprintf(cxd2841er_t_c_ops.info.name, 128,
> +   "Sony CXD2837ER DVB-T/T2/C demodulator");
> +   name = "CXD2837ER";
> +   type = "C/T/T2";
> +   break;
> +   case CXD2838ER_CHIP_ID:
> +   snprintf(cxd2841er_t_c_ops.info.name, 128,
> +   "Sony CXD2838ER ISDB-T demodulator");
> +   cxd2841er_t_c_ops.delsys[0] = SYS_ISDBT;
> +   cxd2841er_t_c_ops.delsys[1] = SYS_UNDEFINED;
> +   cxd2841er_t_c_ops.delsys[2] = SYS_UNDEFINED;
> +   name = "CXD2838ER";
> +   type = "ISDB-T";
> +   break;
> case CXD2841ER_CHIP_ID:
> snprintf(cxd2841er_t_c_ops.info.name, 128,
> "Sony CXD2841ER DVB-T/T2/C demodulator");
> name = "CXD2841ER";
> +   type = "T/T2/C/ISDB-T";
> +   break;
> +   case CXD2843ER_CHIP_ID:
> +   snprintf(cxd2841er_t_c_ops.info.name, 128,
> +   "Sony CXD2843ER DVB-T/T2/C/C2 demodulator");
> +   name = "CXD2843ER";
> +   type = "C/C2/T/T2";
> break;
> case CXD2854ER_CHIP_ID:
> snprintf(cxd2841er_t_c_ops.info.name, 128,
> "Sony CXD2854ER DVB-T/T2/C and ISDB-T 
> demodulator");
> cxd2841er_t_c_ops.delsys[3] = SYS_ISDBT;
> name = "CXD2854ER";
> +   type = "C/C2/T/T2/ISDB-T";
> break;
> default:
> dev_err(&priv->i2c->dev, "%s(): invalid chip ID 0x%02x\n",
> @@ -3762,7 +3785,6 @@ static struct dvb_frontend *cxd2841er_attach(struct 
> cxd2841er_config *cfg,
> memcpy(&priv->frontend.ops,
> &cxd2841er_t_c_ops,
> sizeof(struct dvb_frontend_ops));
> -   type = "T/T2/C/ISDB-T";
> }
>
> dev_info(&priv->i2c->dev,
> diff --git a/drivers/media/dvb-frontends/cxd2841er_priv.h 
> b/drivers/media/dvb-frontends/cxd2841er_priv.h
> index 0bbce45..6a71264 100644
> --- a/drivers/media/dvb-frontends/cxd2841er_priv.h
> +++ b/drivers/media/dvb-frontends/cxd2841er_priv.h
> @@ -25,7 +25,10 @@
>  #define I2C_SLVX   0
>  #define I2C_SLVT   1
>
> +#define CXD2837ER_CHIP_ID  0xb1
> +#define CXD2838ER_CHIP_ID  0xb0
>  #define CXD2841ER_CHIP_ID  0xa7
> +#define CXD2843ER_CHIP_ID  0xa4
>  #define CXD2854ER_CHIP_ID  0xc1
>
>  #define CXD2841ER_DVBS_POLLING_INVL10
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs

2017-05-30 Thread Joe Perches

On Wed, 2017-05-31 at 11:05 +0900, Hirokazu Honda wrote:
> Although bitmap is useful, there is need to change the log level for each
> log.
> Because it will take a longer time, it should be done in another patch.

I have no idea what you mean.

A bit & comparison is typically an identical instruction
cycle count to a >= comparison.

media_build: fails to install

2017-05-30 Thread Olli Salonen

It seems that I'm able to build the media_build correctly on Ubuntu
16.04.2 with kernel 4.8, but make install fails:

~/src/media_build$ sudo make install
make -C /home/olli/src/media_build/v4l install
make[1]: Entering directory '/home/olli/src/media_build/v4l'
make[1]: *** No rule to make target 'media-install', needed by 'install'.  Stop.
make[1]: Leaving directory '/home/olli/src/media_build/v4l'
Makefile:15: recipe for target 'install' failed
make: *** [install] Error 2

Full console log here:
http://paste.ubuntu.com/24720478/

Cheers,
-olli

Re: [PATCH 03/19] [media] dvb-frontends/cxd2841er: immediately unfreeze regs when done

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Do unfreeze_regs() directly when accessing the demod registers is done,
> and don't have multiple unfreeze's on different conditions, which even
> can get prone to errors.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 23 ++-
>  1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 525d006..09c25d7 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -1410,11 +1410,11 @@ static int cxd2841er_read_ber_i(struct cxd2841er_priv 
> *priv,
> cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x60);
> cxd2841er_read_regs(priv, I2C_SLVT, 0x5B, pktnum, sizeof(pktnum));
> cxd2841er_read_regs(priv, I2C_SLVT, 0x16, data, sizeof(data));
> +   cxd2841er_unfreeze_regs(priv);
>
> if (!pktnum[0] && !pktnum[1]) {
> dev_dbg(&priv->i2c->dev,
> "%s(): no valid BER data\n", __func__);
> -   cxd2841er_unfreeze_regs(priv);
> return -EINVAL;
> }
>
> @@ -1424,7 +1424,6 @@ static int cxd2841er_read_ber_i(struct cxd2841er_priv 
> *priv,
> dev_dbg(&priv->i2c->dev, "%s(): bit_error=%u bit_count=%u\n",
> __func__, *bit_error, *bit_count);
>
> -   cxd2841er_unfreeze_regs(priv);
> return 0;
>  }
>
> @@ -1634,6 +1633,8 @@ static u32 cxd2841er_dvbs_read_snr(struct 
> cxd2841er_priv *priv,
>  * A1h   12h   [7:0]   ICPM_QUICKCNDT[7:0]
>  */
> cxd2841er_read_regs(priv, I2C_SLVT, 0x10, data, 3);
> +   cxd2841er_unfreeze_regs(priv);
> +
> if (data[0] & 0x01) {
> value = ((u32)(data[1] & 0x1F) << 8) | (u32)(data[2] & 0xFF);
> min_index = 0;
> @@ -1676,11 +1677,9 @@ static u32 cxd2841er_dvbs_read_snr(struct 
> cxd2841er_priv *priv,
> } else {
> dev_dbg(&priv->i2c->dev,
> "%s(): no data available\n", __func__);
> -   cxd2841er_unfreeze_regs(priv);
> return -EINVAL;
> }
>  done:
> -   cxd2841er_unfreeze_regs(priv);
> *snr = res;
> return 0;
>  }
> @@ -1709,12 +1708,12 @@ static int cxd2841er_read_snr_c(struct cxd2841er_priv 
> *priv, u32 *snr)
> cxd2841er_read_regs(priv, I2C_SLVT, 0x19, data, 1);
> qam = (enum sony_dvbc_constellation_t) (data[0] & 0x07);
> cxd2841er_read_regs(priv, I2C_SLVT, 0x4C, data, 2);
> +   cxd2841er_unfreeze_regs(priv);
>
> reg = ((u32)(data[0]&0x1f) << 8) | (u32)data[1];
> if (reg == 0) {
> dev_dbg(&priv->i2c->dev,
> "%s(): reg value out of range\n", __func__);
> -   cxd2841er_unfreeze_regs(priv);
> return 0;
> }
>
> @@ -1735,11 +1734,9 @@ static int cxd2841er_read_snr_c(struct cxd2841er_priv 
> *priv, u32 *snr)
> *snr = -88 * (int32_t)sony_log(reg) + 86999;
> break;
> default:
> -   cxd2841er_unfreeze_regs(priv);
> return -EINVAL;
> }
>
> -   cxd2841er_unfreeze_regs(priv);
> return 0;
>  }
>
> @@ -1758,17 +1755,17 @@ static int cxd2841er_read_snr_t(struct cxd2841er_priv 
> *priv, u32 *snr)
> cxd2841er_freeze_regs(priv);
> cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x10);
> cxd2841er_read_regs(priv, I2C_SLVT, 0x28, data, sizeof(data));
> +   cxd2841er_unfreeze_regs(priv);
> +
> reg = ((u32)data[0] << 8) | (u32)data[1];
> if (reg == 0) {
> dev_dbg(&priv->i2c->dev,
> "%s(): reg value out of range\n", __func__);
> -   cxd2841er_unfreeze_regs(priv);
> return 0;
> }
> if (reg > 4996)
> reg = 4996;
> *snr = 1 * ((intlog10(reg) - intlog10(5350 - reg)) >> 24) + 28500;
> -   cxd2841er_unfreeze_regs(priv);
> return 0;
>  }
>
> @@ -1787,18 +1784,18 @@ static int cxd2841er_read_snr_t2(struct 
> cxd2841er_priv *priv, u32 *snr)
> cxd2841er_freeze_regs(priv);
> cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x20);
> cxd2841er_read_regs(priv, I2C_SLVT, 0x28, data, sizeof(data));
> +   cxd2841er_unfreeze_regs(priv);
> +
> reg = ((u32)data[0] << 8) | (u32)data[1];
> if (reg == 0) {
> dev_dbg(&priv->i2c->dev,
> "%s(): reg value out of range\n", __func__);
> -   cxd2841er_unfreeze_regs(priv);
> return 0;
> }
> if (reg > 10876)
> reg = 10876;
> *snr = 1 * ((intlog10(reg) -
> intlog10(12600 - reg)) >> 24) + 32000;
> -   cxd2841er_unfreeze_regs(priv);
>

Re: [RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX




On 05/26/2017 12:18 AM, Daniel Vetter wrote:

On Thu, May 25, 2017 at 05:06:25PM +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 
---
  drivers/gpu/drm/Kconfig  |   3 +
  drivers/gpu/drm/Makefile |   1 +
  drivers/gpu/drm/drm_dp_cec.c | 196 +++
  include/drm/drm_dp_helper.h  |  24 ++
  4 files changed, 224 insertions(+)
  create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 78d7fc0ebb57..dd771ce8a3d0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,9 @@ 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

We generally don't bother with a Kconfig for every little bit in drm, not
worth the trouble (yes I know there's some exceptions, but somehow they're
all from soc people). Just smash this into the KMS_HELPER one and live is
much easier for drivers. Also allows you to drop the dummy inline
functions.
All of the functions like cec_register_adapter() require 
CONFIG_MEDIA_CEC_SUPPORT.
This will add a new dependency to the DRM drivers. All instances of 
CONFIG_DRM_DP_CEC should be changed to CONFIG_MEDIA_CEC_SUPPORT so drm 
can still be used without the media CEC drivers.


-Clint



The other nitpick: Pls kernel-doc the functions exported to drivers, and
then pull them into Documentation/gpu/drm-kms-helpers.rst, next to the
existing DP helper section.

Thanks, Daniel


+
  config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59f0f9b696eb..22f1a17dfc8a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -34,6 +34,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
drm_scdc_helper.o
  
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o

  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
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..44c544ba53cb
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,196 @@
+/*
+ * 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 
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   ssize_t err = 0;
+
+   if (enable)
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL,
+DP_CEC_TUNNELING_ENABLE);
+   else
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, 0);
+   return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   u8 mask[2] = { 0x00, 0x80 };
+   ssize_t err;
+
+   if (addr != CEC_LOG_ADDR_INVALID) {
+   u16 la_mask = adap->log_addrs.log_addr_mask;
+
+   la_mask |= 0x8000 | (1 << addr);
+   mask[0] = la_mask & 0xff;
+   mask[1] = la_mask >> 8;
+   }
+   err = drm_dp_dpcd_write(aux, DP_CEC_LOGICAL_ADDRESS_MASK, mask, 2);
+   return (addr != CEC_LOG_ADDR_INVALID && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
+   u32 signal_free_time, struct cec_msg *msg)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   unsigned in

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

2017-05-30 Thread Shuah Khan

Hi Sailus/Mauro,

On 01/26/2017 02:10 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 25 Jan 2017 13:02:31 +0200
> Sakari Ailus  escreveu:
> 
>> Hi Mauro,
>>
>> On Tue, Jan 24, 2017 at 08:49:02AM -0200, Mauro Carvalho Chehab wrote:
>>> Hi Sakari,
>>>
>>> Just returned this week from vacations. I'm reading my long e-mail backlog,
>>> starting from my main inbox...
>>>
>>> Em Mon, 2 Jan 2017 09:53:49 +0200
>>> Sakari Ailus  escreveu:
>>>   
 Hi Mauro,

 On Mon, Dec 19, 2016 at 07:46:55AM -0200, Mauro Carvalho Chehab wrote:  
> Em Fri, 16 Dec 2016 17:07:23 +0200
> Sakari Ailus  escreveu:
> 
>> Hi Hans,
> 
>>> chrdev_open in fs/char_dev.c increases the refcount on open() and 
>>> decreases it
>>> on release(). Thus ensuring that the cdev can never be removed while in 
>>> an
>>> ioctl.  
>>
>> It does, but it does not affect memory which is allocated separately of 
>> that.
>>
>> See this:
>>
>> https://www.mail-archive.com/linux-media@vger.kernel.org/msg106390.html>
>> 
>
> That sounds promising. If this bug issues other drivers than OMAP3,
> then indeed the core has a bug.
>
> I'll see if I can reproduce it here with some USB drivers later this 
> week.

 It's not a driver problem so yes, it is reproducible on other hardware.  
>>>
>>> Didn't have time to test it before entering into vacations.
>>>
>>> I guess I won't have any time this week to test those issues on
>>> my hardware, as I suspect that my patch queue is full. Also, we're
>>> approaching the next merge window. So, unfortunately, I won't have
>>> much time those days to do much testing. 
>>>
>>> Btw, Hans commented that you were planning to working on it this month.
>>>
>>> Do you have some news with regards to the media controller bind/unbind
>>> fixes?  
>>
>> I have a bunch of meeting notes to send from the Oslo meeting with Hans and
>> Laurent; I should have that ready by the end of the week. The RFC patchset
>> certainly needs changes based on that.
> 
> OK. I'll wait for your notes and the new patchset.

What is the status of this patch series? Did I miss RFC v4?

As you might remember, my resource sharing work for snd-usb-audio
and the shared media object API which is necessary for media
driver and snd-usb-audio to share the media device are pending
waiting for this RFC series to go from RFC to a version that can
be merged.

I would like to get the snd-usb-audio work done soon and target it
for an upcoming release in the near future!

Could you please send an update on the status on when the next RFC
version might be sent out.

thanks,
-- Shuah

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

On 05/30/2017 02:29 PM, Hans Verkuil wrote:

On 05/30/2017 10:32 PM, Clint Taylor wrote:

On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:

On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete
newbie when it
comes to mst.

I think my NUC already uses mst internally. But I was planning on
buying a
dp multiplexer to make sure there is nothing special I need to do
for mst.

The CEC Tunneling is all in the branch device, so if I understand
things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output
they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to
their

datasheet is supposed to implement CEC Tunneling, but if they do
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware
issue
or something else. The BIOS is able to do some CEC, but whether
they hook
into the MegaChip or have the CEC pin connected to a GPIO or
something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would
be very
helpful.
It's called LSPCON, see i915/intel_lspcon.c, basically to support
HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for
us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't
support

that in i915.

I don't know about the CEC on that.

fully supports CEC.

What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your
NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have
actually
tested it somehow? The only working solution I have seen mentioned
for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC
pin to

some microcontroller.

The only working chipset I have seen is the Parade PS176.

If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info

Huh. Based on this document:

https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf

this is the internal DP-to-HDMI adapter and it has the PS175. So it is a
Parade chipset, and I have seen that work before (at least the PS176).

This is the PS175 LSPCON on the NUC6.

And is this from a USB-C to HDMI adapter? Which one? I don't recognize
the ID.

-Clint

For the record, this is the internal HDMI output of my NUC7i5BNK:

connector 48: type DP-1, status: connected
name:
physical dimensions: 1050x590mm
subpixel order: Unknown
CEA rev: 3
DPCD rev: 12
audio support: yes
DP branch device present: yes
Type: HDMI
ID: MC2800
HW: 2.2
SW: 1.66
Max TMDS clock: 60 kHz
Max bpc: 16

Clearly a Megachip.

Regards,

Hans

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

On 05/30/2017 10:32 PM, Clint Taylor wrote:

On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:

On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete
newbie when it
comes to mst.

I think my NUC already uses mst internally. But I was planning on
buying a
dp multiplexer to make sure there is nothing special I need to do
for mst.

The CEC Tunneling is all in the branch device, so if I understand
things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output
they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware
issue
or something else. The BIOS is able to do some CEC, but whether
they hook
into the MegaChip or have the CEC pin connected to a GPIO or
something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would
be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.

My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.

What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have
actually
tested it somehow? The only working solution I have seen mentioned
for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.

If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info

Huh. Based on this document:

https://downloadmirror.intel.com/26061/eng/NUC6i7KYK%20HDMI%202.0%20Firmware%20update%20Instructions.pdf

this is the internal DP-to-HDMI adapter and it has the PS175. So it is a
Parade chipset, and I have seen that work before (at least the PS176).

And is this from a USB-C to HDMI adapter? Which one? I don't recognize the ID.

For the record, this is the internal HDMI output of my NUC7i5BNK:

Clearly a Megachip.

Regards,

Hans

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




On 05/30/2017 09:54 AM, Hans Verkuil wrote:

On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete 
newbie when it

comes to mst.
I don't really have more clue, but yeah if you don't have an mst 
thing (a
simple dp port multiplexer is what I use for testing here, then 
plug in a
converter dongle or cable into that) then probably better to not 
wire up

the code for it.
I think my NUC already uses mst internally. But I was planning on 
buying a
dp multiplexer to make sure there is nothing special I need to do 
for mst.


The CEC Tunneling is all in the branch device, so if I understand 
things

correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output 
they

use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do 
it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware 
issue
or something else. The BIOS is able to do some CEC, but whether 
they hook
into the MegaChip or have the CEC pin connected to a GPIO or 
something and

have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would 
be very

helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have 
actually
tested it somehow? The only working solution I have seen mentioned 
for the

NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.


If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?


[root@localhost cec-ctl]# cat /sys/kernel/debug/dri/0/i915_display_info
CRTC info
-
CRTC 32: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24
fb: 115, pos: 0x0, size: 3840x2160
encoder 47: type: DDI B, connectors:
connector 48: type: DP-1, status: connected, mode:
id 0:"1920x1080" freq 60 clock 148500 hdisp 1920 hss 2008 hse 
2052 htot 2200 vdisp 1080 vss 1084 vse 1089 vtot 1125 type 0x48 flags 0x5

cursor visible? no, position (0, 0), size 0x0, addr 0x
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, 
mode=0, scalers[1]: use=no, mode=0
--Plane id 26: type=PRI, crtc_pos=   0x   0, crtc_size=1920x1080, 
src_pos=0.x0., src_size=1920.x1080., format=XR24 
little-endian (0x34325258), rotation=0 (0x0001)
--Plane id 28: type=OVL, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)
--Plane id 30: type=CUR, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)

underrun reporting: cpu=yes pch=yes
CRTC 39: pipe: B, active=yes, (size=3840x2160), dither=no, bpp=36
fb: 115, pos: 0x0, size: 3840x2160
encoder 54: type: DDI C, connectors:
connector 55: type: DP-2, status: connected, mode:
id 0:"3840x2160" freq 30 clock 296703 hdisp 3840 hss 4016 hse 
4104 htot 4400 vdisp 2160 vss 2168 vse 2178 vtot 2250 type 0x48 flags 0x5

cursor visible? no, position (0, 0), size 0x0, addr 0x
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, 
mode=0, scalers[1]: use=no, mode=0
--Plane id 33: type=PRI, crtc_pos=   0x   0, crtc_size=3840x2160, 
src_pos=0.x0., src_size=3840.x2160., format=XR24 
little-endian (0x34325258), rotation=0 (0x0001)
--Plane id 35: type=OVL, crtc_pos=   0x   0, crtc_size=   0x 0, 
src_pos=0.x0., src_size=0.x0., format=N/A, rotation=0 
(0x0001)
--Plane

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




On 05/30/2017 09:49 AM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete 
newbie when it

comes to mst.
I don't really have more clue, but yeah if you don't have an mst 
thing (a
simple dp port multiplexer is what I use for testing here, then 
plug in a
converter dongle or cable into that) then probably better to not 
wire up

the code for it.
I think my NUC already uses mst internally. But I was planning on 
buying a
dp multiplexer to make sure there is nothing special I need to do 
for mst.


The CEC Tunneling is all in the branch device, so if I understand 
things

correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output 
they

use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it 
is not
exposed as a capability. I'm not sure if it is a MegaChip firmware 
issue
or something else. The BIOS is able to do some CEC, but whether 
they hook
into the MegaChip or have the CEC pin connected to a GPIO or 
something and

have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be 
very

helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

slightly different command, but it still dumps DPCD 0x3000 for 48 bytes.

sudo dd if=/dev/drm_dp_aux0 bs=1 skip=12288 count=48 | hexdump -C
  07 00 00 00 00 00 00 00  00 00 00 00 00 00 00 80 
||
0010  f8 23 c4 8f 06 d8 59 7b  37 bb 1e 14 9c cb cd 88 
|.#Y{7...|
0020  4e 84 10 00 04 00 f7 f5  e2 fa a3 30 ad 42 ed 19 
|N..0.B..|





When you say "it does support CEC over Aux", does that mean you have 
actually
tested it somehow? The only working solution I have seen mentioned for 
the

NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.
I have a couple PS176 based devices that I purchased from Amazon that do 
not work even though they advertise support at DPCD 0x3000.


Club 3D USB-C->HDMI 2.0 UHD
UptabUSB-C->HDMI 2.0

-Clint




Regards,

Hans



-Clint




BR,
Jani.

It would be so nice to get MegaChip CEC Tunneling working on the 
NUC, because
then you have native CEC support without requiring any Pulse Eight 
adapter.


And add a CEC-capable USB-C to HDMI adapter and you have it on the 
USB-C

output as well.

Regards,

Hans

Re: [PATCH] dtv-scan-tables - dvb-s - add the config file for Eutelsat 5 West A - 5.0W - C Band

2017-05-30 Thread Olliver Schinagl

Hey Lenny,

On 01/11/17 14:54, l...@netcourrier.com wrote:
> Hello,
>
> There is no config scan file for Eutelsat 5 West A - 5.0W - C Band 
> transponders at https://git.linuxtv.org/dtv-scan-tables.git/tree/dvb-s/
> Attached is a config scan file for  Eutelsat 5 West A - 5.0W - C Band 
> transponders in dvbv5 format.
> Could you please ensure that this new patch is committed into the DVB source 
> code tree repositery ?
>
> Thank you
>
> Best regards
>
>
>
Is this the same satellite as in your previous patch? Should it not
simply have been a git mv? If you can do those 2 patches in one
patch-series/pull request that'd be great.

Olliver

Re: [PATCH] dtv-scan-tables - dvb-t - add file for France Paris Eiffel Tower DVB-T transmitters

2017-05-30 Thread Olliver Schinagl

Hey Lenny,

On 01/11/17 14:51, l...@netcourrier.com wrote:
> Hello,
>
> There is no file for Paris Eiffel Tower DVB-T transmitters at 
> https://git.linuxtv.org/dtv-scan-tables.git/tree/dvb-t/ .
> Attached is a config scan file for Paris Eiffel Tower transmitters in dvbv5 
> format.
> Could you please ensure that this new file is committed into the DVB source 
> code tree repositery ?

Sorry for the long delay. I did some fixes and it has been pushed now.
>
> Thank you
>
> Best regards
>
>

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

2017-05-30 Thread Karl Wallin

Oh and it is the same running as my normal user as well as "root".
Med vänlig hälsning / Best Regards - Karl Wallin

karl.wallin...@gmail.com

P.S. Om mitt mail bör vidarebefodras, vänligen gör detta istället för
att återkomma med en email-adress i ett svar till mig. / If my mail
should be forwarded then please forward it instead of replying to me
with an email address. P.S.


2017-05-30 21:35 GMT+02:00 Karl Wallin :
> Hi!
>
> Sorry for not replying earlier, work.
> I came so far as to download the patches (via n00bishly pasting the
> actual content of the .patch-files into .patch-files since my git
> cherry-pick command didn't work) but then after trying to apply them I
> got a prompt with specifying the path of the file and didn't research
> that further.
>
> I downloaded the latest release from GIT and now it actually builds!!! :D :D
>
> However it does not install :(
>
> "root@nuc-d54250wyk:/home/ubuntu/media_build# make install
> make -C /home/ubuntu/media_build/v4l install
> make[1]: Entering directory '/home/ubuntu/media_build/v4l'
> make[1]: *** No rule to make target 'media-install', needed by 'install'.  
> Stop.
> make[1]: Leaving directory '/home/ubuntu/media_build/v4l'
> Makefile:15: recipe for target 'install' failed
> make: *** [install] Error 2"
>
> I've gone into "v4l" and looked for a "media-install" file but haven't
> found any.
>
> Perhaps this is something I've misunderstood and easy to fix so I
> finally can install it?
>
> Best Regards - Karl
> Med vänlig hälsning / Best Regards - Karl Wallin
>
> karl.wallin...@gmail.com
>
> P.S. Om mitt mail bör vidarebefodras, vänligen gör detta istället för
> att återkomma med en email-adress i ett svar till mig. / If my mail
> should be forwarded then please forward it instead of replying to me
> with an email address. P.S.
>
>
> 2017-05-28 23:42 GMT+02:00 Daniel Scheller :
>> Am Sun, 28 May 2017 21:06:33 +0200
>> schrieb Karl Wallin :
>>
>> All,
>>
>>> In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from:
>>> "ret = cdev_device_add(&devnode->cdev, &devnode->dev);" to:
>>> "ret = device_add(&devnode->dev);"
>>> and row 186 from:
>>> "cdev_device_del(&devnode->cdev, &devnode->dev);" to:
>>> "device_del(&devnode->dev);"
>>
>> Until the upstream media_build repository gets the neccessary backport
>> patch treatment, you can apply [1] and [2] to media_build which should
>> fix all build issues.
>>
>> Best regards,
>> Daniel
>>
>> [1]
>> https://github.com/herrnst/media_build/commit/4766a716c629707d58d625c6cdfd8c395fd6ed61
>> [2]
>> https://github.com/herrnst/media_build/commit/01507a9c32a301c8fc021dcaf1b943799ff3da51

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

2017-05-30 Thread Karl Wallin

Hi!

Sorry for not replying earlier, work.
I came so far as to download the patches (via n00bishly pasting the
actual content of the .patch-files into .patch-files since my git
cherry-pick command didn't work) but then after trying to apply them I
got a prompt with specifying the path of the file and didn't research
that further.

I downloaded the latest release from GIT and now it actually builds!!! :D :D

However it does not install :(

"root@nuc-d54250wyk:/home/ubuntu/media_build# make install
make -C /home/ubuntu/media_build/v4l install
make[1]: Entering directory '/home/ubuntu/media_build/v4l'
make[1]: *** No rule to make target 'media-install', needed by 'install'.  Stop.
make[1]: Leaving directory '/home/ubuntu/media_build/v4l'
Makefile:15: recipe for target 'install' failed
make: *** [install] Error 2"

I've gone into "v4l" and looked for a "media-install" file but haven't
found any.

Perhaps this is something I've misunderstood and easy to fix so I
finally can install it?

Best Regards - Karl
Med vänlig hälsning / Best Regards - Karl Wallin

karl.wallin...@gmail.com

P.S. Om mitt mail bör vidarebefodras, vänligen gör detta istället för
att återkomma med en email-adress i ett svar till mig. / If my mail
should be forwarded then please forward it instead of replying to me
with an email address. P.S.


2017-05-28 23:42 GMT+02:00 Daniel Scheller :
> Am Sun, 28 May 2017 21:06:33 +0200
> schrieb Karl Wallin :
>
> All,
>
>> In "/home/ubuntu/media_build/v4l/cec-core.c" changed row 142 from:
>> "ret = cdev_device_add(&devnode->cdev, &devnode->dev);" to:
>> "ret = device_add(&devnode->dev);"
>> and row 186 from:
>> "cdev_device_del(&devnode->cdev, &devnode->dev);" to:
>> "device_del(&devnode->dev);"
>
> Until the upstream media_build repository gets the neccessary backport
> patch treatment, you can apply [1] and [2] to media_build which should
> fix all build issues.
>
> Best regards,
> Daniel
>
> [1]
> https://github.com/herrnst/media_build/commit/4766a716c629707d58d625c6cdfd8c395fd6ed61
> [2]
> https://github.com/herrnst/media_build/commit/01507a9c32a301c8fc021dcaf1b943799ff3da51

[RFC PATCH] [media] v4l2-subdev: check colorimetry in link validate

2017-05-30 Thread Helen Koike

colorspace, ycbcr_enc, quantization and xfer_func must match across the
link.
Check if they match in v4l2_subdev_link_validate_default unless they are
set as _DEFAULT.

Signed-off-by: Helen Koike 

---

Hi,

I think we should validate colorimetry as having different colorimetry
across a link doesn't make sense.
But I am confused about what to do when they are set to _DEFAULT, what
do you think?

Thanks
---
 drivers/media/v4l2-core/v4l2-subdev.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
b/drivers/media/v4l2-core/v4l2-subdev.c
index da78497..784ae92 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -502,10 +502,27 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev 
*sd,
  struct v4l2_subdev_format *source_fmt,
  struct v4l2_subdev_format *sink_fmt)
 {
-   /* The width, height and code must match. */
+   /* The width, height, code and colorspace must match. */
if (source_fmt->format.width != sink_fmt->format.width
|| source_fmt->format.height != sink_fmt->format.height
-   || source_fmt->format.code != sink_fmt->format.code)
+   || source_fmt->format.code != sink_fmt->format.code
+   || source_fmt->format.colorspace != sink_fmt->format.colorspace)
+   return -EPIPE;
+
+   /* Colorimetry must match if they are not set to DEFAULT */
+   if (source_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
+   && sink_fmt->format.ycbcr_enc != V4L2_YCBCR_ENC_DEFAULT
+   && source_fmt->format.ycbcr_enc != sink_fmt->format.ycbcr_enc)
+   return -EPIPE;
+
+   if (source_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT
+   && sink_fmt->format.quantization != V4L2_QUANTIZATION_DEFAULT
+   && source_fmt->format.quantization != sink_fmt->format.quantization)
+   return -EPIPE;
+
+   if (source_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT
+   && sink_fmt->format.xfer_func != V4L2_XFER_FUNC_DEFAULT
+   && source_fmt->format.xfer_func != sink_fmt->format.xfer_func)
return -EPIPE;
 
/* The field order must match, or the sink field order must be NONE
-- 
2.7.4

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


On 05/30/2017 06:49 PM, Hans Verkuil wrote:

On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have actually
tested it somehow? The only working solution I have seen mentioned for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.


If it really is working on your NUC, then can you add the output of
/sys/kernel/debug/dri/0/i915_display_info?

Thanks,

Hans

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


On 05/30/2017 04:19 PM, Clint Taylor wrote:



On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux.
The release notes for the NUC state that there is a BIOS configuration
option for enabling support. My doesn't have the option but the LSPCON
fully supports CEC.


What is the output of:

dd if=/dev/drm_dp_aux0 of=aux0 skip=12288 ibs=1 count=48
od -t x1 aux0

Assuming drm_dp_aux0 is the aux channel for the HDMI output on your NUC.

If the first byte is != 0x00, then it advertises CEC over Aux.

For me it says 0x00.

When you say "it does support CEC over Aux", does that mean you have actually
tested it somehow? The only working solution I have seen mentioned for the
NUC6i7KYK is a Pulse-Eight adapter.

With the NUC7i Intel made BIOS support for CEC, but it is not at all
clear to me if they used CEC tunneling or just hooked up the CEC pin to
some microcontroller.

The only working chipset I have seen is the Parade PS176.

Regards,

Hans



-Clint




BR,
Jani.


It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
then you have native CEC support without requiring any Pulse Eight adapter.

And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
output as well.

Regards,

Hans

Re: [PATCH 02/19] [media] dvb-frontends/cxd2841er: do I2C reads in one go

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> Doing the I2C read operation with two calls to i2c_transfer() causes the
> exclusive I2C bus lock of the underlying adapter to be released. While this
> isn't an issue if only one demodulator is attached to the bus, having two
> or even more causes troubles in that concurrent accesses to the different
> demods will cause all kinds of issues due to wrong data being returned on
> read operations (for example, the TS config register will be set wrong).
> This changes the read_regs() function to do the operation in one go (by
> calling i2c_transfer with the whole msg list instead of one by one) to not
> loose the I2C bus lock, fixing all sorts of random runtime failures.
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 13 ++---
>  1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 60d85ce..525d006 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -282,17 +282,8 @@ static int cxd2841er_read_regs(struct cxd2841er_priv 
> *priv,
> }
> };
>
> -   ret = i2c_transfer(priv->i2c, &msg[0], 1);
> -   if (ret >= 0 && ret != 1)
> -   ret = -EIO;
> -   if (ret < 0) {
> -   dev_warn(&priv->i2c->dev,
> -   "%s: i2c rw failed=%d addr=%02x reg=%02x\n",
> -   KBUILD_MODNAME, ret, i2c_addr, reg);
> -   return ret;
> -   }
> -   ret = i2c_transfer(priv->i2c, &msg[1], 1);
> -   if (ret >= 0 && ret != 1)
> +   ret = i2c_transfer(priv->i2c, msg, 2);
> +   if (ret >= 0 && ret != 2)
> ret = -EIO;
> if (ret < 0) {
> dev_warn(&priv->i2c->dev,
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

Re: Firmware for staging atomisp driver

2017-05-30 Thread Alan Cox

On Sun, 2017-05-28 at 14:30 +0200, Hans de Goede wrote:
> I started with an Asus T100TA after fixing 2 oopses in the sensor
> driver there I found out that the BIOS does not allow to put the
> ISP in PCI mode and that there is no code to drive it in ACPI
> enumerated mode.

In ACPI mode it's enumerated as part of the GPU but beyond that I don't
know how it works and haven't been able to find out. I am guessing at
this point that the extra node in the acpidump under the GPU gives the
base address, but no idea where the IRQ comes from. Power management on
the BYT devices via PCI is broken anyway so that bit shouldn't matter.

> So I moved to a generic Insyde T701 tablet which does allow
> this. After fixing some more sensor driver issues there I was
> ready to actually load the atomisp driver, but I could not
> find the exact firmware required, I did find a version which
> is close: "irci_stable_candrpv_0415_20150423_1753"
> and tried that but that causes the atomisp driver to explode
> in a backtrace which contains atomisp_load_firmware() so that
> one seems no good.

The firmware has to exactly match. If you look in the atomisp code
you'll see that there are offsets which basically appear to be memory
addresses in the firmware as built that time.

> Can someone help me to get the right firmware ?

Yep.

> The TODO says: "can also be extracted from the upgrade kit"
> about the firmware files, but it is not clear to me what /
> where the "upgrade kit" is.

The Android upgrade kit for your device. So your platforms equivalent
of

https://www.asus.com/Tablets/ASUS_MeMO_Pad_7_ME176C/HelpDesk_Download/

> More in general it would be a good idea if someone inside Intel
> would try to get permission to add the firmware to linux-firmware.

I spent 6 months trying, but even though you can go to your product
vendors website and download it I've not been able to 8(.

> 
> Anyways I will send out the patches I've currently, once I've
> the right firmware I will continue working on this.

Really appreciate the work you are doing on this.

Alan

Re: [PATCH 01/19] [media] dvb-frontends/cxd2841er: remove kernel log spam in non-debug levels

Acked-by: Abylay Ospan 

2017-04-09 15:38 GMT-04:00 Daniel Scheller :
> From: Daniel Scheller 
>
> This moves the I2C debug dump into the preceding dev_dbg() call by
> utilising the %*ph format macro and removes the call to
> print_hex_debug_bytes().
>
> Signed-off-by: Daniel Scheller 
> ---
>  drivers/media/dvb-frontends/cxd2841er.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 614bfb3..60d85ce 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -214,10 +214,8 @@ static void cxd2841er_i2c_debug(struct cxd2841er_priv 
> *priv,
> const u8 *data, u32 len)
>  {
> dev_dbg(&priv->i2c->dev,
> -   "cxd2841er: I2C %s addr %02x reg 0x%02x size %d\n",
> -   (write == 0 ? "read" : "write"), addr, reg, len);
> -   print_hex_dump_bytes("cxd2841er: I2C data: ",
> -   DUMP_PREFIX_OFFSET, data, len);
> +   "cxd2841er: I2C %s addr %02x reg 0x%02x size %d data %*ph\n",
> +   (write == 0 ? "read" : "write"), addr, reg, len, len, data);
>  }
>
>  static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
> --
> 2.10.2
>



-- 
Abylay Ospan,
NetUP Inc.
http://www.netup.tv

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




On 05/30/2017 12:11 AM, Jani Nikula wrote:

On Tue, 30 May 2017, Hans Verkuil  wrote:

On 05/29/2017 09:00 PM, Daniel Vetter wrote:

On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:

On 05/26/2017 09:15 AM, Daniel Vetter wrote:

Did you look into also wiring this up for dp mst chains?

Isn't this sufficient? I have no way of testing mst chains.

I think I need some pointers from you, since I am a complete newbie when it
comes to mst.

I don't really have more clue, but yeah if you don't have an mst thing (a
simple dp port multiplexer is what I use for testing here, then plug in a
converter dongle or cable into that) then probably better to not wire up
the code for it.

I think my NUC already uses mst internally. But I was planning on buying a
dp multiplexer to make sure there is nothing special I need to do for mst.

The CEC Tunneling is all in the branch device, so if I understand things
correctly it is not affected by mst.

BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
datasheet is supposed to implement CEC Tunneling, but if they do it is not
exposed as a capability. I'm not sure if it is a MegaChip firmware issue
or something else. The BIOS is able to do some CEC, but whether they hook
into the MegaChip or have the CEC pin connected to a GPIO or something and
have their own controller is something I do not know.

If anyone can clarify what Intel did on the NUC, then that would be very
helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


My NUC6i7KYK has the MCDP2850 LSPCON and it does support CEC over Aux. 
The release notes for the NUC state that there is a BIOS configuration 
option for enabling support. My doesn't have the option but the LSPCON 
fully supports CEC.


-Clint




BR,
Jani.


It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
then you have native CEC support without requiring any Pulse Eight adapter.

And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
output as well.

Regards,

Hans

Re: [PATCH v4 1/4] media-ctl: add pad support to set/get_frame_interval

2017-05-30 Thread Sakari Ailus

On Tue, May 30, 2017 at 03:04:39PM +0200, Philipp Zabel wrote:
> Hi,
> 
> On Thu, 2017-03-30 at 18:51 +0200, Philipp Zabel wrote:
> > This allows to set and get the frame interval on pads other than pad 0.
> > 
> > Signed-off-by: Philipp Zabel 
> > Acked-by: Sakari Ailus 
> 
> any more comments on these?

Apparently not. Pushed to master.

-- 
Regards,

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

Re: [PATCH 0/3] Fix failure of media_build build script

2017-05-30 Thread Vincent McIntyre

Before sending I ran one-more-test... which failed.
Will respin and try again later.

Vince

[GIT PULL FOR v4.12] RC race condition

2017-05-30 Thread Sean Young

Hi Mauro,

Just a fix for an issue which the 0day robot found. I think the bug has always
been present.

Thanks
Sean

The following changes since commit dd8245f445f5e751b38126140b6ba1723f06c60b:

  [media] atomisp: don't treat warnings as errors (2017-05-18 05:44:00 -0300)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.12f

for you to fetch changes up to e19c5c0b6f4a46e0d489a9134c3b96f93d669be2:

  [media] rc-core: race condition during ir_raw_event_register() (2017-05-30 
14:31:39 +0100)


Sean Young (1):
  [media] rc-core: race condition during ir_raw_event_register()

 drivers/media/rc/rc-ir-raw.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

Re: [PATCH v4 1/4] media-ctl: add pad support to set/get_frame_interval

2017-05-30 Thread Philipp Zabel

Hi,

On Thu, 2017-03-30 at 18:51 +0200, Philipp Zabel wrote:
> This allows to set and get the frame interval on pads other than pad 0.
> 
> Signed-off-by: Philipp Zabel 
> Acked-by: Sakari Ailus 

any more comments on these?

regards
Philipp

> ---
>  utils/media-ctl/libv4l2subdev.c | 24 ++--
>  utils/media-ctl/v4l2subdev.h|  4 ++--
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/utils/media-ctl/libv4l2subdev.c b/utils/media-ctl/libv4l2subdev.c
> index 3dcf943c..2f2ac8ee 100644
> --- a/utils/media-ctl/libv4l2subdev.c
> +++ b/utils/media-ctl/libv4l2subdev.c
> @@ -262,7 +262,8 @@ int v4l2_subdev_set_dv_timings(struct media_entity 
> *entity,
>  }
>  
>  int v4l2_subdev_get_frame_interval(struct media_entity *entity,
> -struct v4l2_fract *interval)
> +struct v4l2_fract *interval,
> +unsigned int pad)
>  {
>   struct v4l2_subdev_frame_interval ival;
>   int ret;
> @@ -272,6 +273,7 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
> *entity,
>   return ret;
>  
>   memset(&ival, 0, sizeof(ival));
> + ival.pad = pad;
>  
>   ret = ioctl(entity->fd, VIDIOC_SUBDEV_G_FRAME_INTERVAL, &ival);
>   if (ret < 0)
> @@ -282,7 +284,8 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
> *entity,
>  }
>  
>  int v4l2_subdev_set_frame_interval(struct media_entity *entity,
> -struct v4l2_fract *interval)
> +struct v4l2_fract *interval,
> +unsigned int pad)
>  {
>   struct v4l2_subdev_frame_interval ival;
>   int ret;
> @@ -292,6 +295,7 @@ int v4l2_subdev_set_frame_interval(struct media_entity 
> *entity,
>   return ret;
>  
>   memset(&ival, 0, sizeof(ival));
> + ival.pad = pad;
>   ival.interval = *interval;
>  
>   ret = ioctl(entity->fd, VIDIOC_SUBDEV_S_FRAME_INTERVAL, &ival);
> @@ -617,7 +621,7 @@ static int set_selection(struct media_pad *pad, unsigned 
> int target,
>   return 0;
>  }
>  
> -static int set_frame_interval(struct media_entity *entity,
> +static int set_frame_interval(struct media_pad *pad,
> struct v4l2_fract *interval)
>  {
>   int ret;
> @@ -625,20 +629,20 @@ static int set_frame_interval(struct media_entity 
> *entity,
>   if (interval->numerator == 0)
>   return 0;
>  
> - media_dbg(entity->media,
> -   "Setting up frame interval %u/%u on entity %s\n",
> + media_dbg(pad->entity->media,
> +   "Setting up frame interval %u/%u on pad %s/%u\n",
> interval->numerator, interval->denominator,
> -   entity->info.name);
> +   pad->entity->info.name, pad->index);
>  
> - ret = v4l2_subdev_set_frame_interval(entity, interval);
> + ret = v4l2_subdev_set_frame_interval(pad->entity, interval, pad->index);
>   if (ret < 0) {
> - media_dbg(entity->media,
> + media_dbg(pad->entity->media,
> "Unable to set frame interval: %s (%d)",
> strerror(-ret), ret);
>   return ret;
>   }
>  
> - media_dbg(entity->media, "Frame interval set: %u/%u\n",
> + media_dbg(pad->entity->media, "Frame interval set: %u/%u\n",
> interval->numerator, interval->denominator);
>  
>   return 0;
> @@ -685,7 +689,7 @@ static int v4l2_subdev_parse_setup_format(struct 
> media_device *media,
>   return ret;
>   }
>  
> - ret = set_frame_interval(pad->entity, &interval);
> + ret = set_frame_interval(pad, &interval);
>   if (ret < 0)
>   return ret;
>  
> diff --git a/utils/media-ctl/v4l2subdev.h b/utils/media-ctl/v4l2subdev.h
> index 9c8fee89..413094d5 100644
> --- a/utils/media-ctl/v4l2subdev.h
> +++ b/utils/media-ctl/v4l2subdev.h
> @@ -200,7 +200,7 @@ int v4l2_subdev_set_dv_timings(struct media_entity 
> *entity,
>   */
>  
>  int v4l2_subdev_get_frame_interval(struct media_entity *entity,
> - struct v4l2_fract *interval);
> + struct v4l2_fract *interval, unsigned int pad);
>  
>  /**
>   * @brief Set the frame interval on a sub-device.
> @@ -217,7 +217,7 @@ int v4l2_subdev_get_frame_interval(struct media_entity 
> *entity,
>   * @return 0 on success, or a negative error code on failure.
>   */
>  int v4l2_subdev_set_frame_interval(struct media_entity *entity,
> - struct v4l2_fract *interval);
> + struct v4l2_fract *interval, unsigned int pad);
>  
>  /**
>   * @brief Parse a string and apply format, crop and frame interval settings.

[PATCH 0/3] Fix failure of media_build build script

2017-05-30 Thread Vincent McIntyre

Hi

I was trying to run build --main-git without the --depth option and
it went splat. The attached series fixes my problem, possibly not
entirely correctly for all cases, in the first patch. The other two
patches are small cleanups that should make things more legible.

Vincent McIntyre (3):
  Use a better name for the upstream remote.
  Add a helper to simplify all the system-or-die calls
  Convert remaining system-or-die calls

 build | 76 +++
 1 file changed, 44 insertions(+), 32 deletions(-)

-- 
2.7.4

Re: [PATCH] davinci: vpif_capture: fix default pixel format for BT.656/BT.1120 video

2017-05-30 Thread Benoit Parrot

Sekhar Nori  wrote on Fri [2017-May-26 16:25:27 +0530]:
> For both BT.656 and BT.1120 video, the pixel format
> used by VPIF is Y/CbCr 4:2:2 in semi-planar format
> (Luma in one plane and Chroma in another). This
> corresponds to NV16 pixel format.
> 
> This is documented in section 36.2.3 of OMAP-L138
> Technical Reference Manual, SPRUH77A.
> 
> The VPIF driver incorrectly sets the default format
> to V4L2_PIX_FMT_YUV422P. Fix it.
> 
> Reported-by: Alejandro Hernandez 
> Signed-off-by: Sekhar Nori 
> ---
>  drivers/media/platform/davinci/vpif_capture.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Acked-by: Benoit Parrot

Re: [PATCH] davinci: vpif_capture: fix default pixel format for BT.656/BT.1120 video

2017-05-30 Thread Sekhar Nori

On Tuesday 30 May 2017 03:10 PM, Lad, Prabhakar wrote:
> Hi Sekhar,
> 
> Thanks for the patch.
> 
> On Fri, May 26, 2017 at 11:55 AM, Sekhar Nori  wrote:
>> For both BT.656 and BT.1120 video, the pixel format
>> used by VPIF is Y/CbCr 4:2:2 in semi-planar format
>> (Luma in one plane and Chroma in another). This
>> corresponds to NV16 pixel format.
>>
>> This is documented in section 36.2.3 of OMAP-L138
>> Technical Reference Manual, SPRUH77A.
>>
>> The VPIF driver incorrectly sets the default format
>> to V4L2_PIX_FMT_YUV422P. Fix it.
>>
>> Reported-by: Alejandro Hernandez 
>> Signed-off-by: Sekhar Nori 
> 
> Acked-by: Lad, Prabhakar 

Thanks!

> 
> Can you also post a similar patch for vpif_display as well ?

Sure. The LCDK board I am working on does not have the VPIF display. But
I should be able to test that on the EVM.

Thanks,
Sekhar

Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs

2017-05-30 Thread Joe Perches

On Tue, 2017-05-30 at 18:49 +0900, Hirokazu Honda wrote:
> Some debug output whose log level is set 1 flooded the log.
> Their log level is lowered to find the important log easily.

Maybe use pr_debug instead?

Perhaps it would be better to change the level to a bitmap
so these can be more individually controlled.

Maybe add MODULE_PARM_DESC too.

Perhaps something like below (without the pr_debug conversion)

---
 drivers/media/v4l2-core/videobuf2-core.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 94afbbf92807..88ae2b238115 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -31,12 +31,13 @@
 
 static int debug;
 module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debugging output control bitmap (values from 0-31)")
 
-#define dprintk(level, fmt, arg...)  \
-   do {  \
-   if (debug >= level)   \
-   pr_info("vb2-core: %s: " fmt, __func__, ## arg); \
-   } while (0)
+#define dprintk(level, fmt, ...)   \
+do {   \
+   if (debug & BIT(level)) \
+   pr_info("vb2-core: %s: " fmt, __func__, ##__VA_ARGS__); \
+} while (0)
 
 #ifdef CONFIG_VIDEO_ADV_DEBUG

Re: [PATCH v7 2/3] [media] add mux and video interface bridge entity functions

2017-05-30 Thread Philipp Zabel

Hi Sakari,

On Mon, 2017-05-29 at 23:38 +0300, Sakari Ailus wrote:
[...]
> > diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
> > b/Documentation/media/uapi/mediactl/media-types.rst
> > index 2a5164aea2b40..1d15542f447c1 100644
> > --- a/Documentation/media/uapi/mediactl/media-types.rst
> > +++ b/Documentation/media/uapi/mediactl/media-types.rst
> > @@ -299,6 +299,28 @@ Types and flags used to represent the media graph 
> > elements
> >   received on its sink pad and outputs the statistics data on
> >   its source pad.
> >  
> > +-  ..  row 29
> > +
> > +   ..  _MEDIA-ENT-F-VID-MUX:
> > +
> > +   -  ``MEDIA_ENT_F_VID_MUX``
> > +
> > +   - Video multiplexer. An entity capable of multiplexing must have at
> > + least two sink pads and one source pad, and must pass the video
> > + frame(s) received from the active sink pad to the source pad. 
> > Video
> > + frame(s) from the inactive sink pads are discarded.
> 
> I don't think the last sentence is needed, I'd drop it as redundant. Up to
> you.

Thanks, I'll drop this sentence ...

> > +
> > +-  ..  row 30
> > +
> > +   ..  _MEDIA-ENT-F-VID-IF-BRIDGE:
> > +
> > +   -  ``MEDIA_ENT_F_VID_IF_BRIDGE``
> > +
> > +   - Video interface bridge. A video interface bridge entity must have 
> > at
> > + least one sink pad and one source pad. It receives video frames on
> 
> It's not clear whether there must be at least one source pad or one source
> pad. How about either:
> 
> "must have at least one sink pad and at least one source pad" or

... and change this to specify "at least one source pad".

> "must have at least one sink pad and exactly one source pad"?
> 
> With this considered,
> 
> Acked-by: Sakari Ailus 
[...]

regards
Philipp

[PATCH v2] [media] mtk-vcodec: Show mtk driver error without DEBUG definition

2017-05-30 Thread Hirokazu Honda

A driver error message is shown without DEBUG definition
to find an error and debug easily.

Signed-off-by: Hirokazu Honda 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 237e144c194f..06c254f5c171 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
 extern bool mtk_vcodec_dbg;
 
 
+#define mtk_v4l2_err(fmt, args...)\
+   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
+  ##args)
+
+#define mtk_vcodec_err(h, fmt, args...)
\
+   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
+  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
+
+
 #if defined(DEBUG)
 
 #define mtk_v4l2_debug(level, fmt, args...) \
@@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
level, __func__, __LINE__, ##args);  \
} while (0)
 
-#define mtk_v4l2_err(fmt, args...)\
-   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
-  ##args)
-
-
 #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
 #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
 
@@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
__func__, ##args);  \
} while (0)
 
-#define mtk_vcodec_err(h, fmt, args...)
\
-   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
-  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
-
 #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
 #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
 
 #else
 
 #define mtk_v4l2_debug(level, fmt, args...) {}
-#define mtk_v4l2_err(fmt, args...) {}
 #define mtk_v4l2_debug_enter() {}
 #define mtk_v4l2_debug_leave() {}
 
 #define mtk_vcodec_debug(h, fmt, args...) {}
-#define mtk_vcodec_err(h, fmt, args...) {}
 #define mtk_vcodec_debug_enter(h) {}
 #define mtk_vcodec_debug_leave(h) {}
 
-- 
2.13.0.219.gdb65acc882-goog

[PATCH v2] [media] vb2: core: Lower the log level of debug outputs

2017-05-30 Thread Hirokazu Honda

Some debug output whose log level is set 1 flooded the log.
Their log level is lowered to find the important log easily.

Signed-off-by: Hirokazu Honda 
---
 drivers/media/v4l2-core/videobuf2-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 94afbbf92807..25257f92bbcf 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1139,7 +1139,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
continue;
}
 
-   dprintk(1, "buffer for plane %d changed\n", plane);
+   dprintk(3, "buffer for plane %d changed\n", plane);
 
if (!reacquired) {
reacquired = true;
@@ -1294,7 +1294,7 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
int index, void *pb)
/* Fill buffer information for the userspace */
call_void_bufop(q, fill_user_buffer, vb, pb);
 
-   dprintk(1, "prepare of buffer %d succeeded\n", vb->index);
+   dprintk(2, "prepare of buffer %d succeeded\n", vb->index);
 
return ret;
 }
@@ -1424,7 +1424,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
index, void *pb)
return ret;
}
 
-   dprintk(1, "qbuf of buffer %d succeeded\n", vb->index);
+   dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
 }
 EXPORT_SYMBOL_GPL(vb2_core_qbuf);
@@ -1472,7 +1472,7 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q, 
int nonblocking)
}
 
if (nonblocking) {
-   dprintk(1, "nonblocking and no buffers to dequeue, will 
not wait\n");
+   dprintk(3, "nonblocking and no buffers to dequeue, will 
not wait\n");
return -EAGAIN;
}
 
@@ -1619,7 +1619,7 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
*pindex, void *pb,
/* go back to dequeued state */
__vb2_dqbuf(vb);
 
-   dprintk(1, "dqbuf of buffer %d, with state %d\n",
+   dprintk(2, "dqbuf of buffer %d, with state %d\n",
vb->index, vb->state);
 
return 0;
-- 
2.13.0.219.gdb65acc882-goog

Re: [PATCH] davinci: vpif_capture: fix default pixel format for BT.656/BT.1120 video

2017-05-30 Thread Lad, Prabhakar

Hi Sekhar,

Thanks for the patch.

On Fri, May 26, 2017 at 11:55 AM, Sekhar Nori  wrote:
> For both BT.656 and BT.1120 video, the pixel format
> used by VPIF is Y/CbCr 4:2:2 in semi-planar format
> (Luma in one plane and Chroma in another). This
> corresponds to NV16 pixel format.
>
> This is documented in section 36.2.3 of OMAP-L138
> Technical Reference Manual, SPRUH77A.
>
> The VPIF driver incorrectly sets the default format
> to V4L2_PIX_FMT_YUV422P. Fix it.
>
> Reported-by: Alejandro Hernandez 
> Signed-off-by: Sekhar Nori 

Acked-by: Lad, Prabhakar 

Can you also post a similar patch for vpif_display as well ?

Cheers,
--Prabhakar Lad

[PATCH] mtk-vcodec: Show mtk driver error without DEBUG definition

2017-05-30 Thread Hirokazu Honda

A driver error message is shown without DEBUG definition
to find an error and debug easily.

Signed-off-by: Hirokazu Honda 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 237e144c194f..06c254f5c171 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -32,6 +32,15 @@ extern int mtk_v4l2_dbg_level;
 extern bool mtk_vcodec_dbg;
 
 
+#define mtk_v4l2_err(fmt, args...)\
+   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
+  ##args)
+
+#define mtk_vcodec_err(h, fmt, args...)
\
+   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
+  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
+
+
 #if defined(DEBUG)
 
 #define mtk_v4l2_debug(level, fmt, args...) \
@@ -41,11 +50,6 @@ extern bool mtk_vcodec_dbg;
level, __func__, __LINE__, ##args);  \
} while (0)
 
-#define mtk_v4l2_err(fmt, args...)\
-   pr_err("[MTK_V4L2][ERROR] %s:%d: " fmt "\n", __func__, __LINE__, \
-  ##args)
-
-
 #define mtk_v4l2_debug_enter()  mtk_v4l2_debug(3, "+")
 #define mtk_v4l2_debug_leave()  mtk_v4l2_debug(3, "-")
 
@@ -57,22 +61,16 @@ extern bool mtk_vcodec_dbg;
__func__, ##args);  \
} while (0)
 
-#define mtk_vcodec_err(h, fmt, args...)
\
-   pr_err("[MTK_VCODEC][ERROR][%d]: %s() " fmt "\n",   \
-  ((struct mtk_vcodec_ctx *)h->ctx)->id, __func__, ##args)
-
 #define mtk_vcodec_debug_enter(h)  mtk_vcodec_debug(h, "+")
 #define mtk_vcodec_debug_leave(h)  mtk_vcodec_debug(h, "-")
 
 #else
 
 #define mtk_v4l2_debug(level, fmt, args...) {}
-#define mtk_v4l2_err(fmt, args...) {}
 #define mtk_v4l2_debug_enter() {}
 #define mtk_v4l2_debug_leave() {}
 
 #define mtk_vcodec_debug(h, fmt, args...) {}
-#define mtk_vcodec_err(h, fmt, args...) {}
 #define mtk_vcodec_debug_enter(h) {}
 #define mtk_vcodec_debug_leave(h) {}
 
-- 
2.13.0.219.gdb65acc882-goog

Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition

2017-05-30 Thread Alexandre Courbot

On Tue, May 30, 2017 at 5:30 PM, Sylwester Nawrocki
 wrote:
> Hi,
>
> On 05/29/2017 09:08 PM, Jacek Anaszewski wrote:
>>
>> This patch seems to have lost somehow. Could you help merging it?
>
>
> It's not lost, it has been on my todo queue. I have applied it now.

Awesome, thanks!

Re: [PATCH v3 0/4] r8a7793 Gose video input support

2017-05-30 Thread Simon Horman

On Fri, May 26, 2017 at 08:49:07AM +0200, Simon Horman wrote:
> On Fri, May 19, 2017 at 03:07:00PM +0200, Ulrich Hecht wrote:
> > Hi!
> > 
> > This is a by-the-datasheet implementation of analog and digital video input
> > on the Gose board.
> > 
> > This revision adds new bindings that distinguish between ADV7180 variants
> > with three and six input ports. There are numerous variants of this chip,
> > but since all that have "CP" in their names have three inputs, and all that
> > have "ST" have six, I have limited myself to two new compatible strings,
> > "adv7180cp" and "adv7180st".
> > 
> > The digital input patch has received minor tweaks of the port names for
> > consistency, and the Gose analog input patch has been modified to use the
> > new bindings, and a composite video connector has been added.
> > 
> > CU
> > Uli
> > 
> > 
> > Changes since v2:
> > - hdmi: port hdmi_con renamed to hdmi_con_out
> > - adv7180: added new compatibility strings and bindings
> > - composite: added connector, use new bindings
> > 
> > Changes since v1:
> > - r8a7793.dtsi: added VIN2
> > - modeled HDMI decoder input/output and connector
> > - added "renesas,rcar-gen2-vin" compat strings
> > - removed unnecessary "remote" node and aliases
> > - set ADV7612 interrupt to GP4_2
> > 
> > 
> > Ulrich Hecht (4):
> >   ARM: dts: gose: add HDMI input
> 
> I have queued-up the above patch for v4.13.
> 
> >   media: adv7180: add adv7180cp, adv7180st compatible strings
> >   media: adv7180: Add adv7180cp, adv7180st bindings
> >   ARM: dts: gose: add composite video input
> 
> I have marked the above dts patch as "deferred" pending acceptance
> of the binding. Please repost or otherwise ping me once that has happened.

It looks like Hans will pick up the driver patches.
Accordingly I have queued-up the last dts patch above.

Re: [PATCH v3 0/4] r8a7793 Gose video input support

2017-05-30 Thread Simon Horman

On Mon, May 29, 2017 at 11:08:12AM +0200, Hans Verkuil wrote:
> On 05/19/2017 03:07 PM, Ulrich Hecht wrote:
> >Hi!
> >
> >This is a by-the-datasheet implementation of analog and digital video input
> >on the Gose board.
> >
> >This revision adds new bindings that distinguish between ADV7180 variants
> >with three and six input ports. There are numerous variants of this chip,
> >but since all that have "CP" in their names have three inputs, and all that
> >have "ST" have six, I have limited myself to two new compatible strings,
> >"adv7180cp" and "adv7180st".
> >
> >The digital input patch has received minor tweaks of the port names for
> >consistency, and the Gose analog input patch has been modified to use the
> >new bindings, and a composite video connector has been added.
> 
> Looks good. I assume the dts changes go through 
> linux-renesas-...@vger.kernel.org?

Yes, I will pick up the dts changes.

> I'll pick up the adv7180 changes.

Thanks!

Re: [ANN] HDMI CEC Status Update

On 05/30/17 09:21, Neil Armstrong wrote:
> Hi Hans,
> 
> On 05/30/2017 08:53 AM, Hans Verkuil wrote:
>> For those who are interested in HDMI CEC support I made a little status
>> document that I intend to keep up to date:
>>
>> https://hverkuil.home.xs4all.nl/cec-status.txt
>>
>> My goal is to get CEC supported for any mainlined HDMI driver where the 
>> hardware
>> supports CEC.
>>
>> If anyone is working on a CEC driver that I don't know already about, just 
>> drop
>> me an email so I can update the status.
>>
>> I also started maintaining a list of DisplayPort to HDMI adapters that 
>> support
>> CEC. If you have one that works and is not on the list, then please let me 
>> know.
>> Seeing /dev/cecX is not enough, some adapters do not connect the CEC pin, so 
>> they
>> won't be able to detect any other CEC devices. See the test instructions in 
>> the
>> cec-status.txt file on how to make sure the adapter has a working CEC pin. I
>> plan to do some more testing this week, so hopefully the list will expand.
>>
>> Thanks!
>>
>> Hans
> 
> Following our discussion on IRC,
> I'm working on a CEC driver for the standalone Amlogic CEC Controller that is 
> able
> to wake up the device from Suspend or Power Off mode by passing infos to the 
> FW.

FYI: the Pulse Eight linux driver has similar support. It has to be enabled via 
a
module option (persistent_config=1).

I have no public API for this, mostly because I would first like to get more 
information
about how these things are typically implemented in hardware.

Regards,

Hans

> I initially planned to use the DW-HDMI CEC controller but I recently found 
> out that
> on the Amlogic Meson GX SoCs, the CEC line can be pinmuxed to either an 
> Amlogic custom
> controller or either to a Synopsys IP.
> 
> But it's connected to the Synopsys HDMI-RX controller... so my plan to use 
> Russell's code
> is now dead.
> 
> Anyway, I'll still need to have the CEC notifier suport for DW-HDMI, so I 
> made a rebase/cleanup
> of Russell's driver on 4.12-rc3 :
> https://github.com/superna/linux/commits/amlogic/v4.12/rmk-dw-hdmi-cec
> The rebase is aligned on dw-hdmi-i2s to use the bridge read/write ops.
> 
> Neil
>

Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition

2017-05-30 Thread Sylwester Nawrocki


Hi,

On 05/29/2017 09:08 PM, Jacek Anaszewski wrote:

This patch seems to have lost somehow. Could you help merging it?


It's not lost, it has been on my todo queue. I have applied it now.

--
Thanks,
Sylwester

Re: [PATCH] Lower the log level of debug outputs

2017-05-30 Thread Alexandre Courbot

On Tue, May 30, 2017 at 3:54 PM, Hirokazu Honda  wrote:
> Some debug output whose log level is set 1 flooded the log.
> Their log level is lowered to find the important log easily.
>
> Signed-off-by: Hirokazu Honda 

Your patch title should specify the subsystem of your patch. Something
like "[media] vb2: core: Lower the log level of debug outputs"

Otherwise,

Acked-by: Alexandre Courbot 


> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 94afbbf92807..25257f92bbcf 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1139,7 +1139,7 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
> void *pb)
> continue;
> }
>
> -   dprintk(1, "buffer for plane %d changed\n", plane);
> +   dprintk(3, "buffer for plane %d changed\n", plane);
>
> if (!reacquired) {
> reacquired = true;
> @@ -1294,7 +1294,7 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned 
> int index, void *pb)
> /* Fill buffer information for the userspace */
> call_void_bufop(q, fill_user_buffer, vb, pb);
>
> -   dprintk(1, "prepare of buffer %d succeeded\n", vb->index);
> +   dprintk(2, "prepare of buffer %d succeeded\n", vb->index);
>
> return ret;
>  }
> @@ -1424,7 +1424,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int 
> index, void *pb)
> return ret;
> }
>
> -   dprintk(1, "qbuf of buffer %d succeeded\n", vb->index);
> +   dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(vb2_core_qbuf);
> @@ -1472,7 +1472,7 @@ static int __vb2_wait_for_done_vb(struct vb2_queue *q, 
> int nonblocking)
> }
>
> if (nonblocking) {
> -   dprintk(1, "nonblocking and no buffers to dequeue, 
> will not wait\n");
> +   dprintk(3, "nonblocking and no buffers to dequeue, 
> will not wait\n");
> return -EAGAIN;
> }
>
> @@ -1619,7 +1619,7 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int 
> *pindex, void *pb,
> /* go back to dequeued state */
> __vb2_dqbuf(vb);
>
> -   dprintk(1, "dqbuf of buffer %d, with state %d\n",
> +   dprintk(2, "dqbuf of buffer %d, with state %d\n",
> vb->index, vb->state);
>
> return 0;
> --
> 2.13.0.219.gdb65acc882-goog
>

Re: [ANN] HDMI CEC Status Update

2017-05-30 Thread Neil Armstrong

Hi Hans,

On 05/30/2017 08:53 AM, Hans Verkuil wrote:
> For those who are interested in HDMI CEC support I made a little status
> document that I intend to keep up to date:
> 
> https://hverkuil.home.xs4all.nl/cec-status.txt
> 
> My goal is to get CEC supported for any mainlined HDMI driver where the 
> hardware
> supports CEC.
> 
> If anyone is working on a CEC driver that I don't know already about, just 
> drop
> me an email so I can update the status.
> 
> I also started maintaining a list of DisplayPort to HDMI adapters that support
> CEC. If you have one that works and is not on the list, then please let me 
> know.
> Seeing /dev/cecX is not enough, some adapters do not connect the CEC pin, so 
> they
> won't be able to detect any other CEC devices. See the test instructions in 
> the
> cec-status.txt file on how to make sure the adapter has a working CEC pin. I
> plan to do some more testing this week, so hopefully the list will expand.
> 
> Thanks!
> 
> Hans

Following our discussion on IRC,
I'm working on a CEC driver for the standalone Amlogic CEC Controller that is 
able
to wake up the device from Suspend or Power Off mode by passing infos to the FW.

I initially planned to use the DW-HDMI CEC controller but I recently found out 
that
on the Amlogic Meson GX SoCs, the CEC line can be pinmuxed to either an Amlogic 
custom
controller or either to a Synopsys IP.

But it's connected to the Synopsys HDMI-RX controller... so my plan to use 
Russell's code
is now dead.

Anyway, I'll still need to have the CEC notifier suport for DW-HDMI, so I made 
a rebase/cleanup
of Russell's driver on 4.12-rc3 :
https://github.com/superna/linux/commits/amlogic/v4.12/rmk-dw-hdmi-cec
The rebase is aligned on dw-hdmi-i2s to use the bridge read/write ops.

Neil

Re: [PATCH v2 5/7] [media] vimc: cap: Support several image formats


On 05/29/2017 07:48 PM, Helen Koike wrote:

Hi Hans,

Thank you for your review. I just have a question for this one.

On 2017-05-08 08:53 AM, Hans Verkuil wrote:

On 04/08/2017 12:37 AM, Helen Koike wrote:

Allow user space to change the image format as the frame size, the
pixel format, colorspace, quantization, field YCbCr encoding
and the transfer function

Signed-off-by: Helen Koike 

---

Changes in v2:
[media] vimc: cap: Support several image formats
- this is a new commit in the serie (the old one was splitted in two)
- allow user space to change all fields from struct v4l2_pix_format
  (e.g. colospace, quantization, field, xfer_func, ycbcr_enc)
- link_validate and try_fmt: also checks colospace, quantization, 
field, xfer_func, ycbcr_enc
- add struct v4l2_pix_format fmt_default
- add enum_framesizes
- enum_fmt_vid_cap: enumerate all formats from vimc_pix_map_table
- add mode dev_dbg


---
  drivers/media/platform/vimc/vimc-capture.c | 167 -
  1 file changed, 139 insertions(+), 28 deletions(-)

diff --git a/drivers/media/platform/vimc/vimc-capture.c 
b/drivers/media/platform/vimc/vimc-capture.c
index 93f6a09..a6441f7 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -40,6 +40,16 @@ struct vimc_cap_device {
struct media_pipeline pipe;
  };

+static const struct v4l2_pix_format fmt_default = {
+   .width = 640,
+   .height = 480,
+   .pixelformat = V4L2_PIX_FMT_RGB24,
+   .field = V4L2_FIELD_NONE,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .quantization = V4L2_QUANTIZATION_FULL_RANGE,
+   .xfer_func = V4L2_XFER_FUNC_SRGB,


I actually think we should keep .quantization and .xfer_func to 0 (DEFAULT).
It's what most drivers will do. Same for the previous patch (I didn't mention
it there).


+};
+
  struct vimc_cap_buffer {
/*
 * struct vb2_v4l2_buffer must be the first element
@@ -64,7 +74,7 @@ static int vimc_cap_querycap(struct file *file, void *priv,
return 0;
  }

-static int vimc_cap_fmt_vid_cap(struct file *file, void *priv,
+static int vimc_cap_g_fmt_vid_cap(struct file *file, void *priv,
  struct v4l2_format *f)
  {
struct vimc_cap_device *vcap = video_drvdata(file);
@@ -74,16 +84,112 @@ static int vimc_cap_fmt_vid_cap(struct file *file, void 
*priv,
return 0;
  }

+static int vimc_cap_try_fmt_vid_cap(struct file *file, void *priv,
+   struct v4l2_format *f)
+{
+   struct v4l2_pix_format *format = &f->fmt.pix;
+   const struct vimc_pix_map *vpix;
+
+   format->width = clamp_t(u32, format->width, VIMC_FRAME_MIN_WIDTH,
+   VIMC_FRAME_MAX_WIDTH);
+   format->height = clamp_t(u32, format->height, VIMC_FRAME_MIN_HEIGHT,
+VIMC_FRAME_MAX_HEIGHT);
+
+   /* Don't accept a pixelformat that is not on the table */
+   vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
+   if (!vpix) {
+   format->pixelformat = fmt_default.pixelformat;
+   vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
+   }
+   /* TODO: Add support for custom bytesperline values */
+   format->bytesperline = format->width * vpix->bpp;
+   format->sizeimage = format->bytesperline * format->height;
+
+   if (format->field == V4L2_FIELD_ANY)
+   format->field = fmt_default.field;
+
+   /* Check if values are out of range */
+   if (format->colorspace == V4L2_COLORSPACE_DEFAULT
+   || format->colorspace > V4L2_COLORSPACE_DCI_P3)
+   format->colorspace = fmt_default.colorspace;
+   if (format->ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT
+   || format->ycbcr_enc > V4L2_YCBCR_ENC_SMPTE240M)
+   format->ycbcr_enc = fmt_default.ycbcr_enc;
+   if (format->quantization == V4L2_QUANTIZATION_DEFAULT
+   || format->quantization > V4L2_QUANTIZATION_LIM_RANGE)
+   format->quantization = fmt_default.quantization;
+   if (format->xfer_func == V4L2_XFER_FUNC_DEFAULT
+   || format->xfer_func > V4L2_XFER_FUNC_SMPTE2084)
+   format->xfer_func = fmt_default.xfer_func;


Same comments in the previous patch regarding width/height and the colorspace
information apply here as well.


+
+   return 0;
+}
+
+static int vimc_cap_s_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+   struct vimc_cap_device *vcap = video_drvdata(file);
+
+   /* Do not change the format while stream is on */
+   if (vb2_is_busy(&vcap->queue))
+   return -EBUSY;
+
+   vimc_cap_try_fmt_vid_cap(file, priv, f);
+
+   dev_dbg(vcap->vdev.v4l2_dev->dev, "%s: format update: "
+   "old:%dx%d (0x%x, %d, %d, %d, %d) "
+   "new:%dx%d (0x%x, %d, %d, %d, %d)\

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

2017-05-30 Thread Jani Nikula

On Tue, 30 May 2017, Hans Verkuil  wrote:
> On 05/29/2017 09:00 PM, Daniel Vetter wrote:
>> On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
>>> On 05/26/2017 09:15 AM, Daniel Vetter wrote:
 Did you look into also wiring this up for dp mst chains?
>>>
>>> Isn't this sufficient? I have no way of testing mst chains.
>>>
>>> I think I need some pointers from you, since I am a complete newbie when it
>>> comes to mst.
>> 
>> I don't really have more clue, but yeah if you don't have an mst thing (a
>> simple dp port multiplexer is what I use for testing here, then plug in a
>> converter dongle or cable into that) then probably better to not wire up
>> the code for it.
>
> I think my NUC already uses mst internally. But I was planning on buying a
> dp multiplexer to make sure there is nothing special I need to do for mst.
>
> The CEC Tunneling is all in the branch device, so if I understand things
> correctly it is not affected by mst.
>
> BTW, I did a bit more testing on my NUC7i5BNK: for the HDMI output they
> use a MegaChip MCDP2800 DP-to-HDMI converter which according to their
> datasheet is supposed to implement CEC Tunneling, but if they do it is not
> exposed as a capability. I'm not sure if it is a MegaChip firmware issue
> or something else. The BIOS is able to do some CEC, but whether they hook
> into the MegaChip or have the CEC pin connected to a GPIO or something and
> have their own controller is something I do not know.
>
> If anyone can clarify what Intel did on the NUC, then that would be very
> helpful.

It's called LSPCON, see i915/intel_lspcon.c, basically to support HDMI
2.0. Currently we only use it in PCON mode, shows up as DP for us. It
could be used in LS mode, showing up as HDMI 1.4, but we don't support
that in i915.

I don't know about the CEC on that.


BR,
Jani.

>
> It would be so nice to get MegaChip CEC Tunneling working on the NUC, because
> then you have native CEC support without requiring any Pulse Eight adapter.
>
> And add a CEC-capable USB-C to HDMI adapter and you have it on the USB-C
> output as well.
>
> Regards,
>
>   Hans

-- 
Jani Nikula, Intel Open Source Technology Center

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