Re: [Intel-gfx] Color management in DRM framework

Hi Shashank, I have been working on support for colorspace handling for V4L2 (video capture), basically the flip-side of the coin that you are working on. While both the V4L2 and DRM/KMS APIs are completely different, the part that does the matrix calculations can be shared between the two. I

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On 07/13/2015 11:18 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: From: Kausal

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On 07/13/2015 11:54 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: On 07/13/2015 11:18 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 10:29:32AM +0200, Hans Verkuil wrote: On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On 07/14/15 11:11, Daniel Vetter wrote: On Tue, Jul 14, 2015 at 10:17:09AM +0200, Hans Verkuil wrote: On 07/13/15 16:07, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote: On 07/13/2015 11:54 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 11:43:31AM +0200

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On 07/13/15 16:07, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 12:11:08PM +0200, Hans Verkuil wrote: On 07/13/2015 11:54 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 11:43:31AM +0200, Hans Verkuil wrote: On 07/13/2015 11:18 AM, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 10:29:32AM

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On 07/14/15 12:16, Daniel Vetter wrote: cut away old quotes I would guess that a LUT supporting 16 bit color components would need a precision of 0.20 or so (assuming the resulting values are used in further calculations). High dynamic range video will be an important driving force

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On 07/15/15 14:35, Hans Verkuil wrote: On 07/14/15 12:16, Daniel Vetter wrote: cut away old quotes I would guess that a LUT supporting 16 bit color components would need a precision of 0.20 or so (assuming the resulting values are used in further calculations). High dynamic range

Re: [Intel-gfx] [PATCH v2 00/10] Color Manager Implementation

On 06/15/2015 08:53 AM, Daniel Vetter wrote: On Tue, Jun 09, 2015 at 01:50:48PM +0100, Damien Lespiau wrote: On Thu, Jun 04, 2015 at 07:12:31PM +0530, Kausal Malladi wrote: From: Kausal Malladi kausal.mall...@intel.com This patch set adds color manager implementation in drm/i915 layer. Color

Re: [Intel-gfx] [PATCH] dma-buf: Update docs for SYNC ioctl

-de...@lists.freedesktop.org > Cc: linaro-mm-...@lists.linaro.org > Cc: intel-gfx@lists.freedesktop.org > Cc: de...@driverdev.osuosl.org > Cc: Hans Verkuil <hverk...@xs4all.nl> > Acked-by: Sumit Semwal <sumit.sem...@linaro.org> > Signed-off-by: Daniel Vetter <

[Intel-gfx] [RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions

From: Clint Taylor Adding DPCD register definitions from the DP 1.3 specification for CEC over AUX support. V2: Add DP_ prefix to all defines. V3: missed prefixes from the ESI1 defines Cc: Jani Nikula Reviewed-by: Jani Nikula

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

From: Hans Verkuil <hans.verk...@cisco.com> 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, s

[Intel-gfx] [RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD

From: Hans Verkuil <hans.verk...@cisco.com> Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set then the hardware can only use CEC if the HDMI Hotplug Detect pin is high. Such hardware cannot handle the corner case in the CEC specification where it is possible to transmit me

[Intel-gfx] [RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD

From: Hans Verkuil <hans.verk...@cisco.com> Document the new CEC_CAP_NEEDS_HPD capability. Signed-off-by: Hans Verkuil <hans.verk...@cisco.com> --- Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/media/

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

From: Hans Verkuil <hans.verk...@cisco.com> Implement support for this DisplayPort feature. The cec device is created whenever it detects an adapter that has this feature. It is only removed when a new adapter is connected that does not support this. If a new adapter is connected th

[Intel-gfx] [RFC PATCH 3/7] cec: add cec_s_phys_addr_from_edid helper function

From: Hans Verkuil <hans.verk...@cisco.com> This function simplifies the integration of CEC in DRM drivers. Signed-off-by: Hans Verkuil <hans.verk...@cisco.com> --- drivers/media/cec/cec-adap.c | 14 ++ include/media/cec.h | 9 + 2 files changed, 2

[Intel-gfx] [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX

From: Hans Verkuil <hans.verk...@cisco.com> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX protocol. This patch series is based on v4.12-rc2. The first four patches add support for a new CEC capability which is needed for these devices and for two helper fun

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

On 05/26/2017 12:13 PM, Jani Nikula wrote: > On Thu, 25 May 2017, Hans Verkuil <hverk...@xs4all.nl> wrote: >> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp) >> return -EINVAL; >> } >> >> +static bool >> +intel_

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

On 05/26/2017 09:15 AM, Daniel Vetter wrote: > On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote: >> From: Hans Verkuil <hans.verk...@cisco.com> >> >> Implement support for this DisplayPort feature. >> >> The cec device is created whenever it dete

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

On 05/26/2017 09:18 AM, Daniel Vetter wrote: > On Thu, May 25, 2017 at 05:06:25PM +0200, Hans Verkuil wrote: >> From: Hans Verkuil <hans.verk...@cisco.com> >> >> This adds support for the DisplayPort CEC-Tunneling-over-AUX >> feature that is par

Re: [Intel-gfx] [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 <hverk...@xs4all.nl> wrote:

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

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

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

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 <hans.verk...@cisco.com> This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that i

Re: [Intel-gfx] [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

Re: [Intel-gfx] [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 <hverk...@xs4all.nl> 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,

Re: [Intel-gfx] [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 <hverk...@xs4all.nl> wrote: On 05/29/2017 09:00 PM, Daniel Vetter wrote: On Fri, May 26, 2017 at 12:20:48PM +0200

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

On 12/05/2017 06:15 AM, Sean Paul wrote: > This patch adds a new optional connector property to allow userspace to enable > protection over the content it is displaying. This will typically be > implemented > by the driver using HDCP. > > The property is a tri-state with the following values: >

Re: [Intel-gfx] [PATCH v2 0/8] drm/i915: Implement HDCP

Hi Sean, On 12/01/2017 06:20 PM, Sean Paul wrote: > Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO > list I set out in the first version (Annotated below for convenience). > > The big changes to take note of in v2 is locking. To account for atomic async > + > the

Re: [Intel-gfx] [PATCH 10/10] video/hdmi: Pass buffer size to infoframe unpack functions

On 11/13/2017 06:04 PM, Ville Syrjala wrote: > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > To make sure the infoframe unpack functions don't end up examining > stack garbage or oopsing, let's pass in the size of the buffer. > > Cc: Thierry Reding <thierry.r

Re: [Intel-gfx] [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name

Hi Neil, Thanks for this patch series! Some comments below: On 05/15/2018 12:40 AM, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function

Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 05/15/2018 12:40 AM, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to

Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 05/15/2018 12:40 AM, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/2018 12:40 AM, Neil Armstrong wrote: > The Chrome OS Embedded Controller can expose a CEC bus, this patch add the > driver for such feature of the Embedded Controller. > > This driver is part of the cros-ec MFD and will be add as a sub-device when > the feature bit is exposed by the EC.

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/18 09:25, Neil Armstrong wrote: > Hi Hans, > > Thanks for the extensive review. > > On 15/05/2018 08:58, Hans Verkuil wrote: >> On 05/15/2018 12:40 AM, Neil Armstrong wrote: >>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add t

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

HPD changes > to an eventual CEC adapter. > > Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> Reviewed-by: Hans Verkuil <hans.verk...@cisco.com> Thanks! Hans > --- > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/intel_drv.h | 2 ++

Re: [Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function by using the device name > instead and will not create a

Re: [Intel-gfx] [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 05/15/18 14:46, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to an

Re: [Intel-gfx] [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

Some small comments below: On 05/15/18 14:47, Neil Armstrong wrote: > The Chrome OS Embedded Controller can expose a CEC bus, this patch add the > driver for such feature of the Embedded Controller. > > This driver is part of the cros-ec MFD and will be add as a sub-device when > the feature bit

Re: [Intel-gfx] [PATCH 1/5] media: cec-notifier: Get notifier by device and connector name

Hi Neil, Two small comments below: On 05/15/18 14:46, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function by using the device name >

Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > The Chrome OS Embedded Controller can expose a CEC bus, this patch add the > driver for such feature of the Embedded Controller. > > This driver is part of the cros-ec MFD and will be add as a sub-device when > the feature bit is exposed by the EC.

Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > Having a 16 byte mkbp event size makes it possible to send CEC > messages from the EC to the AP directly inside the mkbp event > instead of

Re: [Intel-gfx] [PATCH v5 1/6] media: cec-notifier: Get notifier by device and connector name

gned-off-by: Neil Armstrong <narmstr...@baylibre.com> Reviewed-by: Hans Verkuil <hans.verk...@cisco.com> Regards, Hans > --- > drivers/media/cec/cec-notifier.c | 11 --- > include/media/cec-notifier.h | 27 --- > 2 files changed

Re: [Intel-gfx] [PATCH v5 6/6] media: platform: Add ChromeOS EC CEC driver

or name. > > Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> > Reviewed-by: Enric Balletbo i Serra <enric.balle...@collabora.com> Reviewed-by: Hans Verkuil <hans.verk...@cisco.com> Regards, Hans > --- > drivers/media/platform/Kconfig

Re: [Intel-gfx] [PATCH v6 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.

On 24/05/18 11:57, Neil Armstrong wrote: > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > > Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> > Tested-by: Enric Balletbo i Serra <enric.balle...@collabora

Re: [Intel-gfx] [PATCH v6 5/6] mfd: cros_ec_dev: Add CEC sub-device registration

abora.com> For whatever it is worth: Acked-by: Hans Verkuil <hans.verk...@cisco.com> Regards, Hans > --- > drivers/mfd/cros_ec_dev.c | 16 > 1 file changed, 16 insertions(+) > > diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c >

Re: [Intel-gfx] [PATCH v5 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.

On 24/05/18 10:54, Neil Armstrong wrote: > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > > Signed-off-by: Neil Armstrong > Tested-by: Enric Balletbo i Serra > --- >

Re: [Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device > when the CEC feature bit is present. > > Signed-off-by: Neil Armstrong <narmstr...@baylibre.com> For what it is worth (not an MFD expert): Acked-by: Hans

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/18 10:28, Neil Armstrong wrote: > + int ret; > + > + cros_ec_cec = devm_kzalloc(>dev, sizeof(*cros_ec_cec), > +GFP_KERNEL); > + if (!cros_ec_cec) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, cros_ec_cec); >

Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support

On 08/06/18 10:17, Neil Armstrong wrote: > Hi Hans, > > On 08/06/2018 09:53, Hans Verkuil wrote: >> On 06/01/2018 10:19 AM, Neil Armstrong wrote: >>> Hi All, >>> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >&

Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support

On 06/01/2018 10:19 AM, Neil Armstrong wrote: > Hi All, > > The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > through it's Embedded Controller, to enable the Linux CEC Core to communicate > with it and get the CEC Physical Address from the correct HDMI Connector, the >

Re: [Intel-gfx] [PATCH v7 0/6] Add ChromeOS EC CEC Support

On 11/06/18 10:56, Neil Armstrong wrote: > Hi Lee, > > On 11/06/2018 08:03, Lee Jones wrote: >> On Fri, 08 Jun 2018, Hans Verkuil wrote: >>> On 08/06/18 10:17, Neil Armstrong wrote: >>>> On 08/06/2018 09:53, Hans Verkuil wrote: >>>>> On 06/01

Re: [Intel-gfx] [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size

igned-off-by: Neil Armstrong > Tested-by: Enric Balletbo i Serra Acked-by: Hans Verkuil Regards, Hans > --- > drivers/platform/chrome/cros_ec_proto.c | 40 > + > include/linux/mfd/cros_ec.h | 2 +- > include/

Re: [Intel-gfx] [PULL] drm/i915: Add HDCP support to i915

Hi Sean, On 13/02/18 21:18, Sean Paul wrote: > > Hi Dave, > Here's the pull request for HDCP. Hopefully no surprises since it's been > baking > in drm-tip for a while now. > > topic/hdcp-2018-02-13: > Add HDCP support to i915 drm driver. > > Cheers, Sean > > > The following changes since

Re: [Intel-gfx] [PULL] drm/i915: Add HDCP support to i915

On 14/02/18 14:44, Sean Paul wrote: > On Wed, Feb 14, 2018 at 3:33 AM, Hans Verkuil <hverk...@xs4all.nl> wrote: >> Hi Sean, >> >> On 13/02/18 21:18, Sean Paul wrote: >>> >>> Hi Dave, >>> Here's the pull request for HDCP. Hopefully no surprises

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)

On 16/07/18 15:10, Ville Syrjälä wrote: > On Sat, Jul 14, 2018 at 02:50:28PM +0200, Hans Verkuil wrote: >> On 11/07/18 17:24, Ville Syrjälä wrote: >>> On Wed, Jul 11, 2018 at 04:09:03PM +0200, Hans Verkuil wrote: >>>> Hi Ville, >>>> >>>> On 11

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)

On 11/07/18 17:24, Ville Syrjälä wrote: > On Wed, Jul 11, 2018 at 04:09:03PM +0200, Hans Verkuil wrote: >> Hi Ville, >> >> On 11/07/18 15:41, Patchwork wrote: >>> == Series Details == >>> >>> Series: drm/i915: add DisplayPort CEC-Tun

[Intel-gfx] [PATCHv10 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

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

[Intel-gfx] [PATCHv9 2/3] drm-kms-helpers.rst: document the DP CEC helpers

From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms

[Intel-gfx] [PATCHv9 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on the current media master branch (https://git.linuxtv.org/media_tree.git/log/) but it applies fine on top of the current mainline tree. The v9 is identical to v8

[Intel-gfx] [PATCHv9 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil Implement support for this DisplayPort feature. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu

[Intel-gfx] [PATCHv9 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

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

[Intel-gfx] [PATCHv10 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil Implement support for this DisplayPort feature. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu

[Intel-gfx] [PATCHv10 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on top of drm-intel-next. The v10 is identical to v9, except it is rebased to drm-intel-next (v9 didn't apply cleanly) and two alignment warnings have been fixed

[Intel-gfx] [PATCHv10 2/3] drm-kms-helpers.rst: document the DP CEC helpers

From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil Reviewed-by: Ville Syrjälä --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms

Re: [Intel-gfx] [PATCH v8 0/6] Add ChromeOS EC CEC Support

On 12/07/18 14:42, Neil Armstrong wrote: > Hi Lee, > > On 12/07/2018 14:26, Lee Jones wrote: >> On Wed, 04 Jul 2018, Neil Armstrong wrote: >> >>> Hi All, >>> >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support >>> through it's Embedded Controller, to enable the Linux CEC

Re: [Intel-gfx] Linux 4.16 Kernel Boot Crash

On 05/04/18 11:57, Mauro Carvalho Chehab wrote: > Em Wed, 4 Apr 2018 16:26:22 +0300 > Jaak Ristioja escreveu: > >> Hello, all! >> >> I experience the same issue with a Lenovo ThinkPad T440p (LENOVO >> 20AN006VMS/20AN006VMS, BIOS GLET90WW (2.44 ) 09/13/2017). I tried to >>

Re: [Intel-gfx] [PATCH v2 2/2] i915: content-type property for HDMI connector

On 04/18/18 18:51, StanLis wrote: > From: Stanislav Lisovskiy > > Added encoding of drm content_type property from > drm_connector_state within AVI infoframe in order to properly handle > external HDMI TV content-type setting. > > Signed-off-by: Stanislav

Re: [Intel-gfx] [PATCH v2 1/2] drm: content-type property for HDMI connector

On 04/18/18 18:51, StanLis wrote: > From: Stanislav Lisovskiy > > Added content_type property to > drm_connector_state in order to properly handle > external HDMI TV content-type setting. > > Signed-off-by: Stanislav Lisovskiy > ---

Re: [Intel-gfx] [PATCH v2 2/2] i915: content-type property for HDMI connector

On 04/18/18 14:01, Lisovskiy, Stanislav wrote: > Hi, > > Please see my reply inline: > > From: dri-devel [dri-devel-boun...@lists.freedesktop.org] on behalf of Hans > Verkuil [hverk...@xs4all.nl] > Sent: Wednesday, April 18, 2018 2:

Re: [Intel-gfx] [PATCH v5 1/2] drm: content-type property for HDMI connector

); > > int drm_mode_connector_set_path_property(struct drm_connector *connector, > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h > index 33b3a96d66d0..fb45839179dd 100644 > --- a/include/drm/drm_mode_config.h > +++ b/include/drm/drm_mode_config.h &g

Re: [Intel-gfx] [PATCH v5 2/2] i915: content-type property for HDMI connector

description to commit messages. > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovs...@intel.com> Acked-by: Hans Verkuil <hans.verk...@cisco.com> Regards, Hans > --- > drivers/gpu/drm/i915/intel_atomic.c | 2 ++ > drivers/gpu/drm/i915/intel_hdm

Re: [Intel-gfx] [v2 1/2] drm: Add colorspace property

-gfx@lists.freedesktop.org; Syrjala, Ville ; Lankhorst, Maarten ; Hans Verkuil Subject: Re: [Intel-gfx] [v2 1/2] drm: Add colorspace property On Fri, Nov 02, 2018 at 10:19:10AM +0100, Maarten Lankhorst wrote: Op 31-10-18 om 13:05 schreef Uma Shankar: This patch adds a colorspace property enabling

Re: [Intel-gfx] [PATCH v3 04/18] video/hdmi: Constify infoframe passed to the pack functions

t want to change all the >> drivers. >> >> v2: Deal with exynos churn >> Actually export the new funcs >> v3: Fix various documentation fails (Hans) > > Hans, any more concerns about this patch? Acked-by: Hans Verkuil Regards, Hans > >&

Re: [Intel-gfx] [PATCH 03/18] video/hdmi: Constify infoframe passed to the log functions

On 09/20/18 20:51, Ville Syrjala wrote: > From: Ville Syrjälä > > The log functions don't modify the passed in infoframe so make it const. > > Cc: Thierry Reding > Cc: Hans Verkuil Acked-by: Hans Verkuil Thanks, Hans > Cc: linux-me...@vger.kernel.org &

Re: [Intel-gfx] [PATCH 02/18] video/hdmi: Pass buffer size to infoframe unpack functions

ierry Reding > Cc: Hans Verkuil Acked-by: Hans Verkuil Thanks, Hans > Cc: linux-me...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/media/i2c/adv7511.c | 2 +- > drivers/media/i2c/adv7604.c | 2 +- > drivers/media/i2c/adv7842.c | 2 +- >

Re: [Intel-gfx] [PATCH 04/18] video/hdmi: Constify infoframe passed to the pack functions

> Actually export the new funcs > > Cc: Thierry Reding > Cc: Hans Verkuil > Cc: linux-me...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > drivers/video/hdmi.c | 425 > +++ > include/linux/hdmi.h | 19 ++

Re: [Intel-gfx] [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types

Hans > > Cc: Thierry Reding > Cc: Hans Verkuil > Cc: linux-me...@vger.kernel.org > Signed-off-by: Ville Syrjälä > --- > include/linux/hdmi.h | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/include/linux/hdmi.h b/include/lin

Re: [Intel-gfx] [PATCH 06/18] video/hdmi: Handle the MPEG Source infoframe

implementation of this infoframe is not recommended due to unresolved issues. I don't think I've ever seen it either. It obviously doesn't hurt to have this code, but I prefer to wait until there are devices that actively set/use this infoframe. Regards, Hans > > Cc: Thierry Reding >

Re: [Intel-gfx] [PATCH 01/18] video/hdmi: Constify 'buffer' to the unpack functions

On 09/20/18 20:51, Ville Syrjala wrote: > From: Ville Syrjälä > > The unpack functions just read from the passed in buffer, > so make it const. > > Cc: Thierry Reding > Cc: Hans Verkuil Acked-by: Hans Verkuil Thanks! Hans > Cc: linux-me...@vger.kernel.or

Re: [Intel-gfx] [PATCH 07/18] video/hdmi: Handle the NTSC VBI infoframe

om the spec, and totally untested. Do we have any driver that uses this? I would prefer to wait until someone actually need this. Regards, Hans > > Cc: Thierry Reding > Cc: Hans Verkuil > Cc: linux-me...@vger.kernel.org > Signed-off-by: Ville Syrjä

Re: [Intel-gfx] [PATCH 05/18] video/hdmi: Add an enum for HDMI packet types

On 09/21/18 16:01, Ville Syrjälä wrote: > On Fri, Sep 21, 2018 at 10:41:46AM +0200, Hans Verkuil wrote: >> On 09/20/18 20:51, Ville Syrjala wrote: >>> From: Ville Syrjälä >>> >>> We'll be wanting to send more than just infoframes over HDMI. So add an >>&

Re: [Intel-gfx] [PATCH 1/2] drm: Do not call drm_dp_cec_set_edid() while registering DP connectors

more than 3sec in a machine with 4 DP ports disconnected. Cc: Hans Verkuil Acked-by: Hans Verkuil Thanks, this makes sense. Hans Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/drm_dp_cec.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm

Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

On 11/30/18 16:16, Ville Syrjälä wrote: > On Fri, Nov 30, 2018 at 03:48:00PM +0100, Hans Verkuil wrote: >> On 11/30/18 15:29, Ville Syrjälä wrote: >>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: >>>> Hi Ville, >>>> >>>> As Ch

Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

On 12/03/2018 12:23 PM, Andrzej Hajda wrote: > On 30.11.2018 15:48, Hans Verkuil wrote: >> On 11/30/18 15:29, Ville Syrjälä wrote: >>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: >>>> Hi Ville, >>>> >>>> As Christoph can

Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

orted non RGB >>>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects >>>> the value ranges within the selected color encoding. The properties >>>> are stored to drm_plane object to allow different set of supported >>>> encodin

Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

;>>>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects >>>>> the value ranges within the selected color encoding. The properties >>>>> are stored to drm_plane object to allow different set of supported >>>>&

Re: [Intel-gfx] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x79/0x80

Hi Jani, On 2/25/19 2:40 PM, Jani Nikula wrote: On Fri, 22 Feb 2019, Randy Dunlap wrote: This is 5.0-rc7 on an old Toshiba Portege laptop. No hdmi or other external video. Linux dragon.dunlab 5.0.0-rc7mod #3 SMP PREEMPT Wed Feb 20 00:05:17 PST 2019 x86_64 x86_64 x86_64 GNU/Linux on

Re: [Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API

Hi all, The patches in this series can be applied independently from each other. If you maintain one of these drivers and you want to merge it for v5.4 yourself, then please do so and let me know. If you prefer I commit it to drm-misc, then please review and (hopefully) Ack the patch. I would

Re: [Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API

On 8/19/19 1:28 PM, Dariusz Marcinkiewicz wrote: > On Mon, Aug 19, 2019 at 11:38 AM Hans Verkuil > wrote: >> >> Hi all, >> > Hi Hans. >> The patches in this series can be applied independently from each other. >> >> If you maintain one of th

Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.

ng drm connector. > > Signed-off-by: Dariusz Marcinkiewicz > Signed-off-by: Hans Verkuil > Tested-by: Hans Verkuil > --- > .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- > drivers/gpu/drm/drm_dp_cec.c | 25 --- > drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH v7 2/9] drm/i915/intel_hdmi: use cec_notifier_conn_(un)register

nector, and fill in > the cec_connector_info. > > Signed-off-by: Dariusz Marcinkiewicz > Signed-off-by: Hans Verkuil > Tested-by: Hans Verkuil > --- > drivers/gpu/drm/i915/display/intel_hdmi.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > &g

Re: [Intel-gfx] [PATCH v7 0/9] drm: cec: convert DRM drivers to the new notifier API

On 8/19/19 4:48 PM, Neil Armstrong wrote: > Hi Dariusz, Hans, > > I can apply the dw-hdmi patches if necessary. I'd appreciate it if you can do that. Thanks, Hans > > Neil > > On 19/08/2019 11:38, Hans Verkuil wrote: >> Hi all, >> >> Th

Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.

On 8/22/19 10:08 AM, Hans Verkuil wrote: > Alex, Ville/Rodrigo, Ben, > > Can you (hopefully) Ack this patch so that I can merge it? Ping! Regards, Hans > > Thank you! > > Hans > > On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote: >> Pass the

Re: [Intel-gfx] [PATCH v7 2/9] drm/i915/intel_hdmi: use cec_notifier_conn_(un)register

On 8/22/19 10:03 AM, Hans Verkuil wrote: > Ville or Rodrigo, > > Can one of you either merge this patch or Ack it so that I can merge this? Ping! Regards, Hans > > Thank you! > > Regards, > > Hans > > On 8/14/19 12:45 PM, Dariusz Ma

Re: [Intel-gfx] [PATCH v3 10/41] media/ivtv: convert put_page() to put_user_page*()

version, as described in commit fc1d8e7cca2d > ("mm: introduce put_user_page*(), placeholder versions"). > > Cc: Andy Walls > Cc: Mauro Carvalho Chehab > Cc: linux-me...@vger.kernel.org > Signed-off-by: John Hubbard Acked-by: Hans Verkuil Regards, Hans

Re: [Intel-gfx] [PATCH v3 11/41] media/v4l2-core/mm: convert put_page() to put_user_page*()

version, as described in commit fc1d8e7cca2d > ("mm: introduce put_user_page*(), placeholder versions"). > > Cc: Mauro Carvalho Chehab > Cc: Kees Cook > Cc: Hans Verkuil > Cc: Sakari Ailus > Cc: Jan Kara > Cc: Robin Murphy > Cc: Souptick Joarder > Cc:

Re: [Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support

On 11/18/19 11:35 AM, Daniel Vetter wrote: > No in-tree users left. > > Signed-off-by: Daniel Vetter Acked-by: Hans Verkuil Thanks! Hans > Cc: Pawel Osciak > Cc: Marek Szyprowski > Cc: Kyungmin Park > Cc: Tomasz Figa > Cc: linux-me...@vger.kernel.or

Re: [Intel-gfx] [PATCH v3 10/12] media: constify fb ops across all drivers

On 12/3/19 5:38 PM, Jani Nikula wrote: > Now that the fbops member of struct fb_info is const, we can start > making the ops const as well. > > Remove the redundant fbops assignments while at it. > > v2: > - actually add const in vivid > - fix typo (Christophe de Dinechi

Re: [Intel-gfx] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support

On 01/09/2020 08:22, Sam McNally wrote: > From: Hans Verkuil > > Signed-off-by: Hans Verkuil > [sa...@chromium.org: > - rebased > - removed polling-related changes > - moved the calls to drm_dp_cec_(un)set_edid() into the next patch > ] > Signed-off-by: Sam McNal

Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect

Hi Hans, On 17/02/2021 13:24, Hans de Goede wrote: > > > Hi Hans, > > Fedora has a (opt-in) system to automatically collect backtraces from software > crashing on users systems. > > This includes collecting kernel backtraces (including once triggered by > WARN macros) while looking a the top

Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect

On 17/02/2021 16:11, Sean Young wrote: > Hi, > > On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote: >> On 2/17/21 3:32 PM, Sean Young wrote: >>> On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote: >>>> Hi Hans, >>>&g

  1   2   >