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
-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
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
>>>> encoding f
lect the supported 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
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
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
>> bisect v4.15..v4.16 but
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 Lisovskiy
> ---
> drivers/gpu/drm/i915
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
> ---
> Documentation/gpu/kms-properties.csv | 1 +
> drivers/gpu/
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:
rm_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
> @@ -726,6 +726,11 @@ struct drm_
to bind those together
>in same "content type" property.
>
> v4:
> * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
>
> v5:
> * Moved patch revision's description to
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
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
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
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
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
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
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
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
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 C
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
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
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.
gt; Cc: Thierry 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 |
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
al with exynos churn
> 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/l
plementation 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:
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ä
es.
Regards,
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/incl
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
>
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
lazy and didn'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,
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 by
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
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
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.
>
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 the
>
On 05/15/18 10:28, Neil Armstrong wrote:
> + int ret;
> +
> + cros_ec_cec = devm_kzalloc(&pdev->dev, sizeof(*cros_ec_cec),
> +GFP_KERNEL);
> + if (!cros_ec_cec)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, cros_ec_cec);
>
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 notifier
changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
Thanks!
Hans
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 12
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
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
For what it is worth (not an MFD expert):
Acked-by: Hans Verkuil
Thanks!
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.
>
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
> instea
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 ev
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
ed-off-by: Neil Armstrong
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/cec/cec-notifier.c | 11 ---
> include/media/cec-notifier.h | 27 ---
> 2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/d
or name.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platf
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
> ---
> include/linux/mfd/cros_ec_commands.h | 85
>
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
> Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
Thanks!
Hans
&
On 24/05/18 11:57, 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
> Reviewed-by: Enric Balletbo i Serra
For whatever it is worth:
Acked-by: Hans Ve
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/
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
> fol
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
>&
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
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 com
On 14/02/18 14:44, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 3:33 AM, Hans Verkuil wrote:
>> 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
; Cc: David Herrmann
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> CC: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
> Cc: Hans Verkuil
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 wo
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
>>>
>>> This patch set adds color manager implementation in drm/i915 layer.
>>> Color Manager i
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:31
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 Vett
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 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 07/14/15 12:16, Daniel Vetter wrote:
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 t
On 07/15/15 14:35, Hans Verkuil wrote:
> On 07/14/15 12:16, Daniel Vetter wrote:
>
>
>
>>>>> I would guess that a LUT supporting 16 bit color components would need a
>>>>> precision
>>>>> of 0.20 or so (assuming the resulting values a
From: Hans Verkuil
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 functions.
Then the DP CEC registers
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
Signed-off-by: Clint Taylor
Signed-off-by: Jani Nikula
Link:
ht
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
From: Hans Verkuil
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 messages even if no hotplug signal
From: Hans Verkuil
Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID.
Signed-off-by: Hans Verkuil
---
include/media/cec.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/media/cec.h b/include/media/cec.h
index 9989cdb58bd8..6123a5eec540 100644
--- a/include
From: Hans Verkuil
Document the new CEC_CAP_NEEDS_HPD capability.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
b/Documentation/media/uapi
From: Hans Verkuil
Implement support for this DisplayPort feature.
The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the
From: Hans Verkuil
This function simplifies the integration of CEC in DRM drivers.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 14 ++
include/media/cec.h | 9 +
2 files changed, 23 insertions(+)
diff --git a/drivers/media/cec/cec-adap.c b
model.
There are some more adapters that I can test next week, and I'll see if I can
also
test a bunch of (mini-)DP to HDMI adapters.
Regards,
Hans
>
> Thanks
>
> Mike
>
> On Thu, 25 May 2017 at 16:06 Hans Verkuil <mailto:hverk...@xs4all.nl>> wrote
On 05/26/2017 12:13 PM, Jani Nikula wrote:
> On Thu, 25 May 2017, Hans Verkuil wrote:
>> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>> return -EINVAL;
>> }
>>
>> +static bool
>> +intel_dp_check_cec_status(struct
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
>>
>> Implement support for this DisplayPort feature.
>>
>> The cec device is created whenever it detects an adapter that
>> ha
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
>>
>> This adds support for the DisplayPort CEC-Tunneling-over-AUX
>> feature that is part of the DisplayPort 1.3 standard.
>>
>
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
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
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
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
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
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
On 11/13/2017 06:04 PM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 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
> Cc: Hans Verkuil
> Cc: linux-
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 p
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:
> -
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 openSUSE
_drv.h | 6 +-
> drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
> drivers/gpu/drm/vkms/vkms_writeback.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 7 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.h | 6 +-
For these three:
> .../common/videobuf2/videobuf2-dma-contig.c | 8 +-
> .../media/common/videobuf2/videobuf2-dma-sg.c | 9 +-
> .../common/videobuf2/videobuf2-vmalloc.c | 11 +-
Acked-by: Hans Verkuil
Regards,
Hans
On 31/08/2023 12:51, Jani Nikula wrote:
> In the drm subsystem, the source physical address is, in most cases,
> available without having to parse the EDID again. Add notes about
> preferring to use the pre-parsed address instead.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.k
On 24/08/2023 15:46, Jani Nikula wrote:
> Avoid parsing the EDID again for source physical address. Also gets rids
> of a few remaining raw EDID usages.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Rega
ng is a bit specific now that
> there's no need to pass the EDID at all, so aim for attach/detach going
> forward.
>
> v2: Fix the embarrashing build failures
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verku
On 24/08/2023 15:46, Jani Nikula wrote:
> In the drm subsystem, the source physical address is, in most cases,
> available without having to parse the EDID again. Add notes about
> preferring to use the pre-parsed address instead.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.k
On 24/08/2023 15:46, Jani Nikula wrote:
> CEC needs the source physical address. Parsing it is trivial with the
> existing EDID CEA DB infrastructure.
>
> Default to CEC_PHYS_ADDR_INVALID (0x) instead of 0 to cater for
> easier CEC usage.
>
> Cc: Hans Ve
rging via
> drm-intel?
That's fine, it makes sense to do that.
If you need it, for this series:
Acked-by: Hans Verkuil
Regards,
Hans
>
> Thanks,
> Jani.
>
>
>>
>> drivers/gpu/drm/display/drm_dp_cec.c | 22 +++---
there's no need to pass the EDID at all, so aim for attach/detach going
> forward.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_cec.c | 22 +++---
> include/drm/display
d-by: Emil Velikov
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 ---
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 ---
> drivers/media/common/videobuf2/vide
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.org
>
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 1
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 - 100 of 116 matches
Mail list logo
