Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

Wayne Lin I haven't been deep in MST code in a while but this all looks pretty straightforward and good. Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- > drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +

Re: [PATCH v2 1/4] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check

On 2024-01-15 11:05, Andri Yngvason wrote: > From: Werner Sembach > > Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the > drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() && > force_yuv420_output case. > > Without further knowledge if YCbCr 4:2:0 is

Re: [PATCH v2 2/4] drm/uAPI: Add "force color format" drm property as setting for userspace

I'm a bit late to the game but I don't think this is merged yet. On 2024-01-15 11:05, Andri Yngvason wrote: > From: Werner Sembach > > Add a new general drm property "force color format" which can be used > by userspace to tell the graphics driver which color format to use. > > Possible

Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms

On 2024-02-13 01:48, Uma Shankar wrote: > This series intends to add support for Plane Color Management for > Intel platforms. This is based on the design which has been agreed > upon by the community. Series implementing the design for generic > DRM core has been sent out by Ha

Re: [RFC 0/5] Introduce drm sharpening property

Adding a couple of compositor devs as they might be interested in this. On 2024-02-14 06:24, Nemesa Garg wrote: > Many a times images are blurred or upscaled content is also not as > crisp as original rendered image. Traditional sharpening techniques often > apply a uniform level of

Re: [Intel-gfx] [PATCH v4 02/30] drm/dp_mst: Fix fractional DSC bpp handling

the passed in bpp value .4 binary > fixed point always, instead of having to pass in different > things based on whether DSC is enabled or not. > > v2: > - Fix DSC kunit test cases. > > Cc: Manasi Navare > Cc: Lyude Paul > Cc: Harry Wentland > Cc: David Franc

Re: [Intel-gfx] [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline

On 2023-08-29 12:03, Uma Shankar wrote: Add the documentation for the new proposed Plane Color Pipeline. Co-developed-by: Chaitanya Kumar Borah Signed-off-by: Chaitanya Kumar Borah Signed-off-by: Uma Shankar --- .../gpu/rfc/plane_color_pipeline.rst | 394 ++ 1

Re: [Intel-gfx] [RFC 00/33] Add Support for Plane Color Pipeline

scope for the current proposal. Acknowledgements and credits There are multiple contributors who have helped us to reach to this proposal. Special mention to Ville Syrjala, Pekka Paalanen, Simon Ser, Harry Wentland, Melissa Wen, Jonas, Sebastian Wick, Bhanu and Sha

Re: [Intel-gfx] [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property

be consulted for simple "cursor like" use cases. v2: Try to add some docs Cc: Simon Ser Cc: Jonas Ådahl Cc: Daniel Stone Cc: Pekka Paalanen Acked-by: Harry Wentland Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_mode_config.c | 7 + drivers/gpu/drm/drm_plane.c

Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property

rough look at the details of this implementation but like what it does, so this is Acked-by: Harry Wentland Harry --- drivers/gpu/drm/drm_mode_config.c | 7 +++ drivers/gpu/drm/drm_plane.c | 33 +++ include/drm/drm_mode_config.h | 5 + include/drm/d

Re: [Intel-gfx] [PATCHv2 1/2] drm: Add SDP Error Detection Configuration Register

On 1/19/23 06:47, Arun R Murthy wrote: > DP2.0 E11 defines a new register to facilitate SDP error detection by a > 128B/132B capable DPRX device. > > v2: Update the macro name to reflect the DP spec(Harry) > > Signed-off-by: Arun R Murthy Reviewed-by: Harry Wentland Harry

Re: [Intel-gfx] [PATCH 1/2] drm: Add SDP Error Detection Configuration Register

On 1/12/23 23:36, Arun R Murthy wrote: > DP2.0 E11 defines a new register to facilitate SDP error detection by a > 128B/132B capable DPRX device. > > Signed-off-by: Arun R Murthy > --- > include/drm/display/drm_dp.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git

Re: [Intel-gfx] [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

>>> driver only tries to add/remove a specific payload stream only. The newly >>> design idea conflicts with the implementation in amdgpu nowadays. >>> >>> [How] >>> Revert this patch first. After addressing all regression problems caused by >>>

Re: [Intel-gfx] [RFC 0/2] drm/connector: connector iterator with filtering

n one place leads to memory corruption and undefined behavior and is almost impossible to spot without KASAN. This series is Acked-by: Harry Wentland Harry > > BR, > Jani. > > > Cc: Arun R Murthy > Cc: Dave Airlie > Cc: Laurent Pinchart > Cc: Suraj Kandpal &g

Re: [Intel-gfx] [PATCH 03/15] drm/amd/display: stop using connector->override_edid

aconnector->base.name); > > aconnector->base.force = DRM_FORCE_OFF; > - aconnector->base.override_edid = false; I'm not even sure the DRM_FORCE_OFF business is right. Either way, I don't think amdgpu should be messing with override_edid, so this is Re

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

On 2022-05-02 10:29, Harry Wentland wrote: > > > On 2022-05-02 10:27, Modem, Bhanuprakash wrote: >> On Mon-02-05-2022 07:08 pm, Harry Wentland wrote: >>> >>> >>> On 2022-05-02 09:28, Modem, Bhanuprakash wrote: >>>

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

On 2022-05-02 10:27, Modem, Bhanuprakash wrote: > On Mon-02-05-2022 07:08 pm, Harry Wentland wrote: >> >> >> On 2022-05-02 09:28, Modem, Bhanuprakash wrote: >>> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote: >>>> >>>> >>>

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

gt;> drm >>> layer. >>> >>> This patch will also move "Current" bpc to the crtc debugfs from >>> connector >>> debugfs, since we are getting this info from crtc_state. >>> >>> Cc: Harry Wentland >>> Cc: Rodrigo Siqueira >

Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting

On 2022-02-18 07:12, Simon Ser wrote: > On Friday, February 18th, 2022 at 12:54, Hans de Goede > wrote: > >> On 2/18/22 12:39, Simon Ser wrote: >>> On Friday, February 18th, 2022 at 11:38, Hans de Goede >>> wrote: >>> What I'm reading in the above is that it is being considered to allow

Re: [Intel-gfx] [PATCH v3 1/3] drm: Rename lut check functions to lut channel checks

On 2021-10-29 09:43, Sean Paul wrote: > On Thu, Oct 28, 2021 at 11:03:54PM -0400, Mark Yacoub wrote: >> On Thu, Oct 28, 2021 at 8:42 PM Sean Paul wrote: >>> >>> On Tue, Oct 26, 2021 at 03:21:00PM -0400, Mark Yacoub wrote: From: Mark Yacoub [Why] This function and enum do

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

On 2021-10-27 04:00, Pekka Paalanen wrote: > On Tue, 26 Oct 2021 11:36:33 -0400 > Harry Wentland wrote: > >> On 2021-10-14 15:44, Shankar, Uma wrote: >>> > ... >> FWIW, AMD HW (depending on generation) can do these operations >> (in this order): >

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

On 2021-10-12 16:58, Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Tuesday, October 12, 2021 4:01 PM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >> harry.wentl...@amd.com;

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

On 2021-10-14 15:44, Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, October 13, 2021 2:01 PM >> To: Shankar, Uma >> Cc: harry.wentl...@amd.com; ville.syrj...@linux.intel.com; intel- >> g...@lists.freedesktop.org;

Re: [Intel-gfx] [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

Thanks, Uma, for the updated patches. I'm finally finding time to go through them. On 2021-10-15 03:42, Pekka Paalanen wrote: > On Thu, 14 Oct 2021 19:44:25 + > "Shankar, Uma" wrote: > >>> -Original Message- >>> From: Pekka Paalanen >>> Sent: Wednesday, October 13, 2021 2:01 PM >>>

Re: [Intel-gfx] [RFC v2 00/22] Add Support for Plane Color Lut and CSC features

color quality from source to panel taking >>> advantage of advanced color features in hardware. >>> >>> These patches add the property interfaces and enable helper functions. >>> This series adds Intel's XE_LPD hw specific plane gamma feature. We >>>

Re: [Intel-gfx] [PATCH 02/15] drm/amdgpu: use drm_* functions instead of duplicated code in amdgpu driver

d. Separating the functional bits from the straight refactor will help with bisection if this leads to a regression. All changes look reasonable to me, though. With this patch split into three patches in the sequence (b), (c), then (a) this is Reviewed-by: Harry Wentland Harry > Signed-off-by: Cl

Re: [Intel-gfx] [PATCH v3] drm/dp: Add Additional DP2 Headers

; > Etc.. > Fixed by https://patchwork.freedesktop.org/patch/456190/?series=95166=2 but looks like it's not in drm-misc-next. Siqueira, do you have bandwidth to pull that patch into drm-misc-next? Harry > Regards, > > Tvrtko > > > On 30/09/2021 22:21, Rodrigo

Re: [Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

already defined > > [AMD Official Use Only] > >> -Original Message- >> From: Harry Wentland >> Sent: September 28, 2021 1:08 PM >> To: Deucher, Alexander ; amd- >> g...@lists.freedesktop.org; Zuo, Jerry >> Cc: jani.nik...@intel.com; Li, Su

[Intel-gfx] [PATCH v3] drm/amd/display: Only define DP 2.0 symbols if not already defined

updates for any addition DP 2.0 definitions required by our driver. We also ensure drm_dp_helper.h is included before dc_dp_types.h. v3: Ensure drm_dp_helper.h is included before dc_dp_types.h v2: Add one missing endif Signed-off-by: Harry Wentland Reviewed-by: Fangzhi Zuo --- drivers/gpu/drm

[Intel-gfx] [PATCH v2] drm/amd/display: Only define DP 2.0 symbols if not already defined

and provide follow-up header updates for any addition DP 2.0 definitions required by our driver. Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 54 ++-- 1 file changed, 49 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc

Re: [Intel-gfx] [PATCH v3] drm/dp: Add Additional DP2 Headers

On 2021-09-27 15:23, Fangzhi Zuo wrote: > Include FEC, DSC, Link Training related headers. > > Change since v2 > - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT > > Signed-off-by: Fangzhi Zuo Reviewed-by: Harry Wentland Harry > --- > This patch is b

Re: [Intel-gfx] [PATCH] drm/dp: Add Additional DP2 Headers

On 2021-09-27 10:38, Fangzhi Zuo wrote: > Include FEC, DSC, Link Training related headers. > > Signed-off-by: Fangzhi Zuo Please send this to dri-devel and amd-gfx as well. > --- The section after the '---' is not part of the commit description. Please mention here that this patch is based on

[Intel-gfx] [PATCH] drm/amd/display: Only define DP 2.0 symbols if not already defined

updates for any addition DP 2.0 definitions required by our driver. Signed-off-by: Harry Wentland --- drivers/gpu/drm/amd/display/dc/dc_dp_types.h | 53 ++-- 1 file changed, 48 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dc_dp_types.h b/drivers/gpu/drm

Re: [Intel-gfx] [PATCH 00/14] drm/hdcp: Pull HDCP auth/exchange/check into

On 2021-09-13 3:26 p.m., Sean Paul wrote: > On Mon, Sep 13, 2021 at 2:05 PM Alex Deucher wrote: >> >> On Mon, Sep 13, 2021 at 1:57 PM Sean Paul wrote: >>> >>> From: Sean Paul >>> >>> Hello, >>> This patchset pulls the HDCP protocol auth/exchange/check logic out from >>> i915 into a HDCP

Re: [Intel-gfx] [PATCH 04/21] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes

On 2021-06-01 6:52 a.m., Uma Shankar wrote: > Define the structure with XE_LPD degamma lut ranges. HDR and SDR > planes have different capabilities, implemented respective > structure for the HDR planes. > > Signed-off-by: Uma Shankar > --- > drivers/gpu/drm/i915/display/intel_color.c | 52

Re: [Intel-gfx] [PATCH 0/9] Enhance pipe color support for multi segmented luts

On 2021-06-07 2:01 p.m., Shankar, Uma wrote: > > >> -Original Message----- >> From: Harry Wentland >> Sent: Saturday, June 5, 2021 12:21 AM >> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org; >> dri- >> de...@lists.freedesktop.org >> Cc

Re: [Intel-gfx] [PATCH 0/9] Enhance pipe color support for multi segmented luts

On 2021-06-01 6:41 a.m., Uma Shankar wrote: > Modern hardwares have multi segmented lut approach to prioritize > the darker regions of the spectrum. This series introduces a new > UAPI to define the lut ranges supported by the respective hardware. > > This also enables Pipe Color Management

Re: [Intel-gfx] [PATCH 02/21] drm: Add Plane Degamma Mode property

On 2021-06-01 6:51 a.m., Uma Shankar wrote: > Add Plane Degamma Mode as an enum property. Create a helper > function for all plane color management features. > > This is an enum property with values as blob_id's and exposes > the various gamma modes supported and the lut ranges. Getting > the

Re: [Intel-gfx] [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes

On 2021-06-02 4:26 p.m., Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, June 2, 2021 3:04 PM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, >> Bhanuprakash >> Subject: Re: [PATCH 01/21]

Re: [Intel-gfx] [PATCH 00/21] Add Support for Plane Color Lut and CSC features

On 2021-06-02 4:22 p.m., Shankar, Uma wrote: > > >> -Original Message- >> From: Pekka Paalanen >> Sent: Wednesday, June 2, 2021 2:59 PM >> To: Shankar, Uma >> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem, >> Bh

Re: [Intel-gfx] [PATCH 2/3] drm/connector: Add helper to compare HDR metadata

it into an helper that can be shared across those drivers. Signed-off-by: Maxime Ripard Patches 1 & 2 are Reviewed-by: Harry Wentland Harry --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +-- drivers/gpu

Re: [Intel-gfx] 2021 X.Org Foundation Election Candidates

is it less. NTL what is important is the application. I would like to see more training material and more X11 applications especially for remote access. But i was never involved in the xorg organisation. So i see myself more as an apprentice. We will see if i can help. Thanks, Harry Wentland, on behalf

[Intel-gfx] 2021 X.Org Foundation Election Candidates

pril anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ** Nominees ** ## Samuel Iglesias Gonsálvez __Current Affiliation:__ Igalia __Personal Statement:__ I have

[Intel-gfx] 2021 X.Org Foundation Membership renewal period extended to Mar 18

date QA: Mon 15th March Deadline of X.Org membership application or renewal: Thu 18th March Election Planned Start: Mon 22nd March anywhere on earth Election Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Th

[Intel-gfx] 2021 X.Org Foundation Membership renewal ENDS on THURSDAY Mar 11

tion Planned End: Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Intel-gfx mailing list Intel

[Intel-gfx] 2021 X.Org Board of Directions Nomination period ends next Sunday

Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Cheers, Harry Wentland, on behalf of the X.Org elections committee ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 2021 X.Org Board of Directors Elections Nomination period is NOW

Filion, Keith Packard, and Harry Wentland. They will continue to serve until their term ends in 2022. Current directors whose term expires in 2021 are Samuel Iglesias Gonsálvez, Manasi D Navare, Lyude Paul, and Daniel Vetter. A director is expected to participate in the fortnightly IRC meeting

[Intel-gfx] 2021 X.Org Foundation Membership renewal and election schedule

Sun 4th April anywhere on earth ** Election Committee ** * Eric Anholt * Mark Filion * Keith Packard * Harry Wentland Thanks, Harry Wentland, on behalf of the X.Org elections committee ___ Intel-gfx mailing list Intel-gfx@lists.freedes

Re: [Intel-gfx] [PATCH 2/8] drm/amdgpu: Use __drm_atomic_helper_crtc_reset

Alex Deucher > Cc: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Rodrigo Siqueira > Cc: Bhawanpreet Lakha > Cc: Roman Li > Cc: Mikita Lipski > Cc: Stylon Wang Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +--- &

Re: [Intel-gfx] [PATCH 2/3] drm: Create a drm_connector_helper_funcs hook for Adaptive Sync support

) hooks to also > query the adaptive sync support of the driver. > > Cc: Jani Nikula > Cc: Ville Syrjälä > Cc: Harry Wentland > Cc: Nicholas Kazlauskas > Signed-off-by: Manasi Navare Patches 1 and 2 are Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/drm_pro

Re: [Intel-gfx] [PATCH V6] drm: Add support for DP 1.4 Compliance edid corruption test

On 2020-02-05 10:22 a.m., Jerry (Fangzhi) Zuo wrote: > Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate > real CRC value of the last edid data block, and write it back. > Current edid CRC calculates routine adds the last CRC byte, > and check if non-zero. > > This behavior is

Re: [Intel-gfx] [PATCH V5] drm: Add support for DP 1.4 Compliance edid corruption test

for returning real CRC. > > Signed-off-by: Jerry (Fangzhi) Zuo Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/drm_dp_helper.c | 35 + > drivers/gpu/drm/drm_edid.c | 23 ++ > include/drm/drm_connector.h |

Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.

On 2020-01-09 4:04 p.m., Mario Kleiner wrote: > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher > wrote: > > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner > mailto:mario.kleiner...@gmail.com>> > wrote: > > > > On Thu, Jan 9, 2020 at 4:40 PM Alex

Re: [Intel-gfx] [PATCH v3 2/9] drm/dp: get/set phy compliance pattern

On 2019-12-30 11:05 a.m., Manna, Animesh wrote: > On 24-12-2019 01:23, Harry Wentland wrote: >> >> On 2019-12-23 12:03 p.m., Animesh Manna wrote: >>> During phy compliance auto test mode source need to read >>> requested test pattern from sink through DPCD.

Re: [Intel-gfx] [PATCH v3 2/9] drm/dp: get/set phy compliance pattern

On 2019-12-23 12:03 p.m., Animesh Manna wrote: > During phy compliance auto test mode source need to read > requested test pattern from sink through DPCD. After processing > the request source need to set the pattern. So set/get method > added in drm layer as it is DP protocol. > > v2: As per

Re: [Intel-gfx] [PATCH v3 1/9] drm/amd/display: Align macro name as per DP spec

On 2019-12-23 12:03 p.m., Animesh Manna wrote: > [Why]: > Aligh with DP spec wanted to follow same naming convention. > > [How]: > Changed the macro name of the dpcd address used for getting requested > test-pattern. > > Cc: Harry Wentland > Cc: Alex Deucher >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Add support for DP 1.4 Compliance edid corruption test (rev3)

On 2019-12-20 2:40 p.m., Zuo, Jerry wrote: > Hi All: > > I got CI check failures. Among those, hdmi-hpd-fast seems related, but I > am not sure why. Please take a brief review and help to determine if it is a > real false-positive again. > It looks like the hdmi-hpd-fast failures are

Re: [Intel-gfx] [PATCH v2 2/9] drm/amd/display: Fix compilation issue.

finition. All patches should compile on their own. Thanks, Harry > Cc: Harry Wentland > Cc: Alex Deucher > Signed-off-by: Animesh Manna > --- > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dri

Re: [Intel-gfx] [PATCH v2 2/9] drm/amd/display: Fix compilation issue.

On 2019-12-18 11:13 a.m., Manna, Animesh wrote: > > On 18-12-2019 21:12, Harry Wentland wrote: >> On 2019-12-18 10:13 a.m., Animesh Manna wrote: >>> [Why]: >>> Aligh with DP spec wanted to follow same naming convention. >>> >>> [How]: >

Re: [Intel-gfx] [PATCH] drm/amdgpu/dm: Do not throw an error for a display with no audio

40 > References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found") > Signed-off-by: Chris Wilson Reviewed-by: Harry Wentland Harry > Cc: Harry Wentland > Cc: Jean Delvare > Cc: Alex Deucher > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_h

Re: [Intel-gfx] [PATCH] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

> This part of the code is stripped out of amdgpu's function > amdgpu_dm_update_freesync_caps() to make it generic and be used > across all DRM drivers > Please CC Nick on these as well. Added him now. Would it be possible to add a patch to update amdgpu to call this function? Harry > Cc:

Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_content_protection: check i915 and generic debugfs name for HDCP caps

915_* if device is i915, otherwise check the generic name. > > Signed-off-by: Bhawanpreet Lakha Reviewed-by: Harry Wentland Harry > --- > tests/kms_content_protection.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/te

Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property

On 2019-10-22 8:20 a.m., Ville Syrjälä wrote: > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote: >> This patch adds a scaling filter mode porperty >> to allow: >> - A driver/HW to showcase it's scaling filter capabilities. >> - A userspace to pick a desired effect while scaling.

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

On 2019-09-12 2:54 a.m., Ramalingam C wrote: > On 2019-09-12 at 00:15:32 +0000, Harry Wentland wrote: >> Adding a couple AMD guys. >> >> I know this is already merged but I have a few questions after some >> internal discussions. >> >> On 2019-05-07 12:27

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

Adding a couple AMD guys. I know this is already merged but I have a few questions after some internal discussions. On 2019-05-07 12:27 p.m., Ramalingam C wrote: > On every hdcp revocation check request SRM is read from fw file > /lib/firmware/display_hdcp_srm.bin > According to section 5 of

Re: [Intel-gfx] [PATCH RESEND 03/14] drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory

On 2019-08-26 3:25 p.m., Andrzej Pietrasiewicz wrote: > Use the ddc pointer provided by the generic connector. > > Signed-off-by: Andrzej Pietrasiewicz Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++-- > 1 file changed,

Re: [Intel-gfx] [PATCH v8 1/6] drm/dp_mst: Add PBN calculation for DSC modes

xel, but > 1/16 of a bit per pixel > > v2: Don't add separate function for this > > Cc: amd-...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Reviewed-by: Manasi Navare > Reviewed-by: Lyude Paul Reviewed-by: Harry Wentla

Re: [Intel-gfx] [PATCH v2 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

function that DRM drivers can call in order to have CRTC enabling > commits fail automatically if the MST port driving the connector no > longer exists. We'll also be able to expand upon this later as well once > we add MST fallback retraining support. > > Changes since v1: >

Re: [Intel-gfx] [PATCH 6/6] drm/amdgpu/dm/mst: Use drm_dp_mst_connector_atomic_check()

only atomic DRM driver without the > ->best_encoder() bug is amdgpu. Congrats AMD! > > Signed-off-by: Lyude Paul Reviewed-by: Harry Wentland Harry > --- > .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 12 > 1 file changed, 12 insertions(+) > >

Re: [Intel-gfx] [PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

gt; Cc: sta...@vger.kernel.org This does seem like a saner way to handle the case when the MST connector is gone. As this doesn't currently seem to affect amdgpu directly and I therefore might miss something I'll leave the RB to someone else, but you have my Acked-by: Harry Wentland Harry > -

Re: [Intel-gfx] [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic

On 2018-09-13 12:31 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > Disable atomic on a per-device basis instead of for all devices. > Made possible by the new device.driver_features thing. > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David

Re: [Intel-gfx] [PATCH v2 08/23] drm/dsc: Define VESA Display Stream Compression Capabilities

gt; * Define DSC 1.2 parameters (Manasi) > * Use DSC_NUM_BUF_RANGES (Manasi) > * Call it drm_dsc_config (Manasi) > > Cc: dri-de...@lists.freedesktop.org > Cc: Jani Nikula > Cc: Ville Syrjala > Cc: Anusha Srivatsa > Cc: Harry Wentland > Signed-off-by: Manasi

Re: [Intel-gfx] [PATCH v2 10/23] drm/dsc: Add helpers for DSC picture parameter set infoframes

ence to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst > (Daniel Vetter) > > v2: > * Add EXPORT_SYMBOL for the drm functions (Manasi) > > Cc: dri-de...@lists.freedesktop.org > Cc: Jani Nikula > Cc: Ville Syrjala > Cc: Anusha Srivatsa > Cc: Harry Wen

Re: [Intel-gfx] [PATCH v2 07/23] drm/dsc: Define Display Stream Compression PPS infoframe

frame syntax elements are taken from DSC 1.2 specification > from VESA. > > Cc: Gaurav K Singh > Cc: dri-de...@lists.freedesktop.org > Cc: Jani Nikula > Cc: Ville Syrjala > Cc: Anusha Srivatsa > Cc: Harry Wentland > Signed-off-by: Manasi Navare Looks like this

Re: [Intel-gfx] [PATCH] drm: Pass crtc to .best_encoder()

On 2018-06-26 11:01 AM, Harry Wentland wrote: > On 2018-06-15 03:52 PM, Ville Syrjala wrote: >> From: Ville Syrjälä >> >> To pick the correct MST encoder i915 wants to know which crtc is going >> to be feeding us. To that end let's pass the crtc to the .best_encoder()

Re: [Intel-gfx] [PATCH] drm: Pass crtc to .best_encoder()

n the amdgpu/radeon drivers. None of > the other drivers have such internal uses. The other callers > (crtc_helper, atomic_helper, fb_helper) will pass in the proper crtc. > but no one besides i915 will currently look at it. > > Cc: Alex Deucher > Cc: "Christian

Re: [Intel-gfx] [PATCH 2/3] drm: Print bad user modes

On 2018-06-11 03:34 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > Print out the modeline when we reject a bad user mode. Avoids having to > guess why it was rejected. > > Signed-off-by: Ville Syrjälä Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/

Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Improve debug messages

On 2018-06-11 03:34 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > Print the id/name of the object we're dealing with. Makes it easier to > figure out what's going on. Also toss in a few extra debug prints that > might be useful. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 0/4] DRM helpers for Display Stream Compression PPS infoframes

.@lists.freedesktop.org > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: Ville Syrjala <ville.syrj...@linux.intel.com> > Cc: Anusha Srivatsa <anusha.sriva...@intel.com> With my comments for patch 2 and 3 addressed patches 1-3 are Reviewed-by: Harry Wentland <har

Re: [Intel-gfx] [PATCH v2 3/4] drm/dsc: Define VESA Display Stream Compression Capabilities

On 2018-05-14 10:05 PM, Manasi Navare wrote: > From: Gaurav K Singh > > This defines all the DSC parameters as per the VESA DSC spec > that will be required for DSC encoder/decoder > > v2: Define this struct in DRM (From Manasi) > * Changed the data types to u8/u16

Re: [Intel-gfx] [PATCH v2 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

On 2018-05-14 10:05 PM, Manasi Navare wrote: > This patch defines a new header file for all the DSC 1.2 structures > and creates a structure for PPS infoframe which will be used to send > picture parameter set secondary data packet for display stream compression. > All the PPS infoframe syntax

Re: [Intel-gfx] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

shbar.org> > Acked-by: Eric Anholt <e...@anholt.net> > Acked-by: Gustavo Padovan <gust...@padovan.org> > Acked-by: Petri Latvala <petri.latv...@intel.com> Acked-by: Harry Wentland <harry.wentl...@amd.com> Harry > Cc: Alex Deucher <alexander.deuc...@a

Re: [Intel-gfx] [PATCH 04/13] drm/amdgpu/dc: Stop updating plane->fb

Deucher <alexander.deuc...@amd.com> >> Cc: "Christian König" <christian.koe...@amd.com> >> Cc: "David (ChunMing) Zhou" <david1.z...@amd.com> >> Cc: Harry Wentland <harry.wentl...@amd.com> >> Cc: amd-...@lists.freedesktop.org >

Re: [Intel-gfx] [PATCH 16/23] drm/amdgpu/dc: Stop updating plane->fb

ristian.koe...@amd.com> > Cc: "David (ChunMing) Zhou" <david1.z...@amd.com> > Cc: Harry Wentland <harry.wentl...@amd.com> > Cc: amd-...@lists.freedesktop.org > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Reviewed-by: Harry Wentland <

Re: [Intel-gfx] [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers

On 2018-03-22 01:54 PM, Emil Velikov wrote: > Hi Ville, > > On 22 March 2018 at 15:22, Ville Syrjala > wrote: >> From: Ville Syrjälä >> >> I really just wanted to fix i915 to re-enable its planes afer load >> detection (a two line

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

On 2018-03-06 12:13 PM, Daniel Vetter wrote: > On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote: >> On 2018-03-06 07:18 AM, Ville Syrjälä wrote: >>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote: >>>> On Tue, Feb 27, 2018 at 02:57:0

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

_edid/update_edid_property > Yeah, it's because the dc_sink carries the EDID and is only created at this point for us. It's bugged me ever since we did this. Might be time to think of a solution to it now. Harry >> >> Otherwise I think this is a real good patch. >> >&

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On 2018-03-06 05:35 AM, Daniel Vetter wrote: > On Mon, Mar 05, 2018 at 05:44:16PM -0500, Harry Wentland wrote: >> On 2018-03-05 04:33 PM, Alex Deucher wrote: >>> On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä >>> <ville.syrj...@linux.intel.com> wrote: >>>

Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

On 2018-03-06 02:51 AM, Daniel Vetter wrote: > On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote: >> On 2018-02-22 04:42 PM, Ville Syrjala wrote: >>> From: Ville Syrjälä <ville.syrj...@linux.intel.com> >>> >>> The documentation for the ctm mat

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On 2018-03-05 04:33 PM, Alex Deucher wrote: > On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä > wrote: >> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: >>> Ville Syrjala writes: >>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

yrjälä <ville.syrj...@linux.intel.com> Good clarification. Our new CTM implementation (1) actually assumed two's complement but nobody's using it yet, so we'll patch it to convert. Reviewed-by: Harry Wentland <harry.wentl...@amd.com> (1) https://patchwork.freedesktop.org/patch/2

Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after drm_modeset_lock_all

acquire_done patches I've acked, but where's the fun in not trying :-) > This shouldn't really hurt anything, other than throw DEBUG warnings if DEBUG_MUTEXES is on. Acked-by: Harry Wentland <harry.wentl...@amd.com> Harry > Cheers, Daniel > >> --- >> drivers/gpu/drm/d

Re: [Intel-gfx] [PATCH v2 3/8] drm/atomic: Include color encoding/range in plane state dump

On 2018-02-19 03:28 PM, Ville Syrjala wrote: > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > Include color_enconding and color_range in the plane state dump. > > v2: Add kerneldoc (danvet) > > Cc: Harry Wentland <harry.wentl...@amd.com> > Cc:

Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

it reference HW vblank count. Explicitly typecasting this down > to u32 either fixes a potential problem or serves to add clarity in case > the typecasting was implicitly done. > > Cc: Keith Packard <kei...@keithp.com> > Cc: Alex Deucher <alexander.deuc...@amd.com> >

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

On 2018-02-01 05:30 AM, Maarten Lankhorst wrote: > Op 31-01-18 om 20:57 schreef Harry Wentland: >> On 2018-01-30 05:28 AM, Maarten Lankhorst wrote: >>> Op 29-01-18 om 16:41 schreef Leo Li: >>>> Updated IGT results seem sane: >>>> https://intel-gfx-ci.01.o

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

On 2018-01-30 05:28 AM, Maarten Lankhorst wrote: > Op 29-01-18 om 16:41 schreef Leo Li: >> Updated IGT results seem sane: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html >> >> Would someone be able to apply this patch? >> > Thanks for the reminder, pushed. > Thanks,

Re: [Intel-gfx] [PATCH v3] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

allocated via ida, we can simply limit the maximum > value the ida is allowed to hand out. The error handling is already > in place. > > v2: Return an error to the caller (Harry) > v3: Print a debug message so that we know what happened (Maarten) > > Cc: Harry Wentland <

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

On 2018-01-24 04:24 PM, Ville Syrjälä wrote: > On Wed, Jan 24, 2018 at 04:01:18PM -0500, Harry Wentland wrote: >> On 2018-01-24 01:37 PM, Ville Syrjala wrote: >>> From: Ville Syrjälä <ville.syrj...@linux.intel.com> >>> >>> We use 32bit bitmasks

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

On 2018-01-24 01:37 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > We use 32bit bitmasks to track planes/crtcs/encoders/connectors. > Naturally we can only do that if the index of those objects stays > below 32. Issue a warning whenever we exceed that limit,

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Add HBR3 support in existing DRM DP helpers

nux.intel.com> > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com> Both patches look right according to DP 1.4 spec. Series is Reviewed-by: Harry Wentland <harry.wentl...@amd.com> Harry > --- > drivers/gpu/drm/drm_dp_helper.c

  1   2   >