On 09/09/2024 09:53, Uros Bizjak wrote:
> Substitute the inclusion of header with
> to allow the removal of legacy inclusion
> of from .
>
> Signed-off-by: Uros Bizjak
Acked-by: Hans Verkuil
Regards,
Hans
> Cc: Hans Verkuil
> Cc: Mauro Carvalho C
On 05/04/2024 12:18, Wolfram Sang wrote:
> Hello Easwar,
>
> On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix driver
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
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 +++---
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
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
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 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
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 10/17/22 19:22, Dmitry Osipenko wrote:
> Prepare V4L2 memory allocators to the common dynamic dma-buf locking
> convention by starting to use the unlocked versions of dma-buf API
> functions.
>
> Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Thanks!
Hans
> A
On 10/17/22 19:22, Dmitry Osipenko wrote:
> Prepare Tegra video decoder driver to the common dynamic dma-buf
> locking convention by starting to use the unlocked versions of dma-buf
> API functions.
>
> Acked-by: Christian König
Acked-by: Hans Verkuil
Thanks!
Hans
Nice!
Acked-by: Hans Verkuil
Regards,
Hans
On 24/08/2022 12:22, Dmitry Osipenko wrote:
> All drivers that use dma-bufs have been moved to the updated locking
> specification and now dma-buf reservation is guaranteed to be locked
> by importers during the mapping operations.
_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 18/02/2021 09:52, Sean Young wrote:
> Hi,
>
> On Wed, Feb 17, 2021 at 05:29:46PM +0100, Hans Verkuil wrote:
>> On 17/02/2021 16:11, Sean Young wrote:
>>> On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
>>>> On 2/17/21 3:32 PM, Sean Young wro
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
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 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
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
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
>
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
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
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
r, 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
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,
>>
>&g
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
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
sion, 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: Da
sion, 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
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
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
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
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
-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
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,
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
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
>
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
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ä
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:
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
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
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 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.
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 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 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
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
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
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
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
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
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
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 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
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 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
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 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
>
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
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
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
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
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/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.
>
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 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
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:
> 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
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/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/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/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
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
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
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:
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 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 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 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
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 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 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 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-
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 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/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/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 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/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/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/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 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
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
1 - 100 of 117 matches
Mail list logo
