Re: [PATCH] drm: actually remove the newline for CRC source name.

[Harry Wentland]

Thanks for the quick follow-up to Sam.

Drop the word "actually" from the patch subject line.

It's generally helpful to generate a 2nd version of the patch with '-v
2', and to leave a description what v2 changed.

Also CC anyone who previously commented.

On 2019-06-05 2:35 p.m., Dingchen Zhang wrote:
> 'n-1' is the index to replace the newline character of CRC source name.
> 

Add here:
v2: Update patch subject (Sam)

> Cc: Leo Li 
> Cc: Harry Wentland
> Signed-off-by: Dingchen Zhang 
> ---
>  drivers/gpu/drm/drm_debugfs_crc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 585169f0dcc5..e20adef9d623 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const 
> char __user *ubuf,
>   if (IS_ERR(source))
>   return PTR_ERR(source);
>  
> - if (source[len] == '\n')
> - source[len] = '\0';
> + if (source[len-1] == '\n')
> + source[len-1] = '\0';
>  

As Sam mentioned, you'll want this to be

+   if (source[len - 1] == '\n')
+   source[len - 1] = '\0';

I forgot to mention this to you before, but please run
./scripts/checkpatch.pl on your patches before sending them and fix up
any errors or warnings.

Harry

>   ret = crtc->funcs->verify_crc_source(crtc, source, _cnt);
>   if (ret)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm/amd/display: Add HDR output metadata support for amdgpu

[Harry Wentland]

On 2019-05-28 3:08 p.m., Nicholas Kazlauskas wrote:
> This patch series enables HDR output metadata support in amdgpu using the
> DRM HDR interface merged in drm-misc-next. Enabled for DCE and DCN ASICs
> over DP and HDMI.
> 
> It's limited to static HDR metadata support for now since that's all the
> DRM interface supports. It requires a modeset for entering and exiting HDR
> but the metadata can be changed without one.
> 
> Cc: Harry Wentland 
> 

Series is
Reviewed-by: Harry Wentland 

Harry

> Nicholas Kazlauskas (2):
>   drm/amd/display: Expose HDR output metadata for supported connectors
>   drm/amd/display: Only force modesets when toggling HDR
> 
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 155 +-
>  1 file changed, 151 insertions(+), 4 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait

[Harry Wentland]

arm32's udelay only allows values up to 2000 microseconds. msleep
does the trick for us here as there is no problem if this isn't
microsecond accurate and takes a tad longer.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 4c31930f1cdf..f5d02f89b3f9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -548,7 +548,7 @@ static void read_edp_current_link_settings_on_detect(struct 
dc_link *link)
break;
}
 
-   udelay(8000);
+   msleep(8);
}
 
ASSERT(status == DC_OK);
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: Set crc->opened = false before setting crc source to NULL.

[Harry Wentland]

On 2019-06-05 1:06 p.m., Dingchen Zhang wrote:
> to terminate the while-loop in drm_dp_aux_crc_work when drm_dp_start/stop_crc
> are called in the hook to set crc source.
> 
> Cc:Leo Li , Harry , Nick 
> 
> Signed-off-by: Dingchen Zhang 

I wonder how this isn't creating problems for Rockchip with the Analogix
bridge.

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_debugfs_crc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index e20adef9d623..0e8bcc130383 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -249,6 +249,13 @@ static int crtc_crc_release(struct inode *inode, struct 
> file *filep)
>   struct drm_crtc *crtc = filep->f_inode->i_private;
>   struct drm_crtc_crc *crc = >crc;
>  
> + /* terminate the infinite while loop if 'drm_dp_aux_crc_work' running */
> + if (crc->opened) {
> + spin_lock_irq(>lock);
> + crc->opened = false;
> + spin_unlock_irq(>lock);
> + }
> +
>   crtc->funcs->set_crc_source(crtc, NULL);
>  
>   spin_lock_irq(>lock);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 Xorg Election Results

[Harry Wentland]

Total membership 84; total votes 65; which makes for a 77.4% voter 
turnout. Here are the results:

Board Members:
   Name   1   2   3   4   5   6  Score
   Daniel Vetter 27  10  14   6   2   6   296
   Samuel Iglesias Gonsálvez 11  10  13  15  10   6   239
   Lyude Paul10  12  13  12  12   6   238
   Manasi Navare  8  13   7  16  18   3   228
   Trevor Woerner 4  14  10  10   8  19   199
   Arkadiusz Hiler5   6   8   6  15  25   165

So that means our new board members are:

   Daniel Vetter
   Samuel Iglesias Gonsálvez
   Lyude Paul
   Manasi Navare

Please welcome our new members to the board!

In the interest of transparency I should mention that one person 
accidentally signed up twice and voted twice. Luckily this doesn't 
change the results of the election since there is more than a 6-point 
gap between 4th and 5th place. We'll take this as a reminder to have a 
better look at membership sign-ups.

It should also be noted that even though our election process as 
outlined at https://www.x.org/wiki/BoardOfDirectors/Elections/ allows 
denying candidates any points our website didn't take this into account 
and forced voters to rank every candidate. Due to the lack of 
controversy about the candidates we don't expect this to have had any 
impact on the final results.

Thanks,
Harry Wentland,
On behalf of the Xorg Elections Committee   
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Fix 32-bit divide error in wait_for_alt_mode

[Harry Wentland]

On 2019-08-20 7:57 p.m., Nathan Chancellor wrote:
> When building arm32 allyesconfig:
> 
> ld.lld: error: undefined symbol: __aeabi_uldivmod
>>>> referenced by dc_link.c
>>>> gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive 
>>>> drivers/built-in.a
>>>> referenced by dc_link.c
>>>> gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive 
>>>> drivers/built-in.a
> 
> time_taken_in_ns is of type unsigned long long so we need to use div_u64
> to avoid this error.
> 
> Fixes: b5b1f4554904 ("drm/amd/display: Enable type C hotplug")
> Reported-by: Randy Dunlap 
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index f2d78d7b089e..8634923b 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -721,7 +721,7 @@ bool wait_for_alt_mode(struct dc_link *link)
>   time_taken_in_ns = dm_get_elapse_time_in_ns(
>   link->ctx, finish_timestamp, enter_timestamp);
>   DC_LOG_WARNING("Alt mode entered finished after %llu 
> ms\n",
> -time_taken_in_ns / 100);
> +div_u64(time_taken_in_ns, 100));
>   return true;
>   }
>  
> @@ -730,7 +730,7 @@ bool wait_for_alt_mode(struct dc_link *link)
>   time_taken_in_ns = dm_get_elapse_time_in_ns(link->ctx, finish_timestamp,
>   enter_timestamp);
>   DC_LOG_WARNING("Alt mode has timed out after %llu ms\n",
> - time_taken_in_ns / 100);
> + div_u64(time_taken_in_ns, 100));
>   return false;
>  }
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 5/6] drm/dp_mst: Add new quirk for Synaptics MST hubs

[Harry Wentland]

On 2019-08-26 2:05 p.m., David Francis wrote:
> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
> support virtual DPCD registers, but do support DSC.
> The DSC caps can be read from the physical aux,
> like in SST DSC. These hubs have many different
> DEVICE_IDs.  Add a new quirk to detect this case.
> 
> Cc: Lyude Paul 
> Cc: Jani Nikula 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 2 ++
>  include/drm/drm_dp_helper.h | 7 +++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2cc21eff4cf3..fc39323e7d52 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1270,6 +1270,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
>   { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false, 
> BIT(DP_DPCD_QUIRK_NO_PSR) },
>   /* CH7511 seems to leave SINK_COUNT zeroed */
>   { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'), 
> false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
> + /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
> + { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true, 
> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },

This seems to be generic OUI for Synaptics [1]. Could this cause us to
cast the net too wide?

Even if we check that it's DP_DPCD_REV >= 1.4 there's a good chance
Synaptics is fixing this in the future and won't require the quirk.

[1] https://aruljohn.com/mac/vendor/Synaptics

Harry

>  };
>  
>  #undef OUI
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8364502f92cf..a1331b08705f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1434,6 +1434,13 @@ enum drm_dp_quirk {
>* The driver should ignore SINK_COUNT during detection.
>*/
>   DP_DPCD_QUIRK_NO_SINK_COUNT,
> + /**
> +  * @DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD:
> +  *
> +  * The device supports MST DSC despite not supporting Virtual DPCD.
> +  * The DSC caps can be read from the physical aux instead.
> +  */
> + DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
>  };
>  
>  /**
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 5/6] drm/dp_mst: Add new quirk for Synaptics MST hubs

[Harry Wentland]

On 2019-08-26 3:14 p.m., Francis, David wrote:
> On 2019-08-26 2:05 p.m., David Francis wrote:
>>> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
>>> support virtual DPCD registers, but do support DSC.
>>> The DSC caps can be read from the physical aux,
>>> like in SST DSC. These hubs have many different
>>> DEVICE_IDs.  Add a new quirk to detect this case.
>>>
>>> Cc: Lyude Paul 
>>> Cc: Jani Nikula 
>>> Signed-off-by: David Francis 
>>> ---
>>>  drivers/gpu/drm/drm_dp_helper.c | 2 ++
>>>  include/drm/drm_dp_helper.h | 7 +++
>>>  2 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>>> b/drivers/gpu/drm/drm_dp_helper.c
>>> index 2cc21eff4cf3..fc39323e7d52 100644
>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>> @@ -1270,6 +1270,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
>>>{ OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false, 
>>> BIT(DP_DPCD_QUIRK_NO_PSR) },
>>>/* CH7511 seems to leave SINK_COUNT zeroed */
>>>{ OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'), 
>>> false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
>>> + /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
>>> + { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true, 
>>> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
>>
>> This seems to be generic OUI for Synaptics [1]. Could this cause us to
>> cast the net too wide?
>>
>> Even if we check that it's DP_DPCD_REV >= 1.4 there's a good chance
>> Synaptics is fixing this in the future and won't require the quirk.
>>
>> [1] https://aruljohn.com/mac/vendor/Synaptics
>>
>>
>> Harry
> 
> It's not pretty, but
> - Currently the net of "all Synaptics devices with rev>DP1.4" catches every 
> device we care about and none we don't
> - If a future Synaptics device supports virtual DPCD properly, we will check 
> for that first and never resort to the workaround (see patch 6/6)
> - We don't know any of the properties of any hypothetical future Synaptics 
> hardware, so we can't create cases for them now
> 

That's fair enough. Thanks for the explanation.

Reviewed-by: Harry Wentland 

Harry

> Also, received offline review from AMD MST DSC (Non-Linux) expert Wenjing 
> Liu, giving me permission  o mark this patch
> Reviewed-by: Wenjing Liu 
> 
>>
>>>  };
>>>
>>>  #undef OUI
>>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>>> index 8364502f92cf..a1331b08705f 100644
>>> --- a/include/drm/drm_dp_helper.h
>>> +++ b/include/drm/drm_dp_helper.h
>>> @@ -1434,6 +1434,13 @@ enum drm_dp_quirk {
>>> * The driver should ignore SINK_COUNT during detection.
>>> */
>>>DP_DPCD_QUIRK_NO_SINK_COUNT,
>>> + /**
>>> +  * @DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD:
>>> +  *
>>> +  * The device supports MST DSC despite not supporting Virtual DPCD.
>>> +  * The DSC caps can be read from the physical aux instead.
>>> +  */
>>> + DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
>>>  };
>>>
>>>  /**
> 
> 
> From: Wentland, Harry 
> Sent: August 26, 2019 3:05 PM
> To: Francis, David; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v8 5/6] drm/dp_mst: Add new quirk for Synaptics MST hubs
> 
> On 2019-08-26 2:05 p.m., David Francis wrote:
>> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
>> support virtual DPCD registers, but do support DSC.
>> The DSC caps can be read from the physical aux,
>> like in SST DSC. These hubs have many different
>> DEVICE_IDs.  Add a new quirk to detect this case.
>>
>> Cc: Lyude Paul 
>> Cc: Jani Nikula 
>> Signed-off-by: David Francis 
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c | 2 ++
>>  include/drm/drm_dp_helper.h | 7 +++
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 2cc21eff4cf3..fc39323e7d52 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -1270,6 +1270,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
>>   { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false, 
>> BIT(DP_DPCD_QUIRK_NO_PSR) },
>>   /* CH7511 seems to leave SINK_COUNT zeroed */
>>   { OUI(0x00, 0x00, 0x00),

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

[Harry Wentland]

On 2019-08-26 2:05 p.m., David Francis wrote:
> With DSC, bpp can be fractional in multiples of 1/16.
> 
> Change drm_dp_calc_pbn_mode to reflect this, adding a new
> parameter bool dsc. When this parameter is true, treat the
> bpp parameter as having units not of bits per pixel, 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-...@lists.freedesktop.org
> Reviewed-by: Manasi Navare 
> Reviewed-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> Signed-off-by: David Francis 
> ---
>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c|  2 +-
>  drivers/gpu/drm/drm_dp_mst_topology.c| 16 
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_dp_mst.c   |  2 +-
>  include/drm/drm_dp_mst_helper.h  |  3 +--
>  6 files changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index a0ed0154a9f0..abafb5221b44 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -235,7 +235,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
>  
>   /* TODO need to know link rate */
>  
> - pbn = drm_dp_calc_pbn_mode(clock, bpp);
> + pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
>  
>   slots = drm_dp_find_vcpi_slots(mst_mgr, pbn);
>   ret = drm_dp_mst_allocate_vcpi(mst_mgr, mst_port, pbn, slots);
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 82add736e17d..3e7b7553cf4d 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3534,10 +3534,11 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
>   * drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
>   * @clock: dot clock for the mode
>   * @bpp: bpp for the mode.
> + * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
>   *
>   * This uses the formula in the spec to calculate the PBN value for a mode.
>   */
> -int drm_dp_calc_pbn_mode(int clock, int bpp)
> +int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
>  {
>   u64 kbps;
>   s64 peak_kbps;
> @@ -3555,11 +3556,18 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
>* peak_kbps *= (1006/1000)
>* peak_kbps *= (64/54)
>* peak_kbps *= 8convert to bytes
> +  *
> +  * If the bpp is in units of 1/16, further divide by 16. Put this
> +  * factor in the numerator rather than the denominator to avoid
> +  * integer overflow
>*/
>  
>   numerator = 64 * 1006;
>   denominator = 54 * 8 * 1000 * 1000;
>  
> + if (dsc)
> + numerator /= 16;
> +
>   kbps *= numerator;
>   peak_kbps = drm_fixp_from_fraction(kbps, denominator);
>  
> @@ -3570,19 +3578,19 @@ EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
>  static int test_calc_pbn_mode(void)
>  {
>   int ret;
> - ret = drm_dp_calc_pbn_mode(154000, 30);
> + ret = drm_dp_calc_pbn_mode(154000, 30, false);
>   if (ret != 689) {
>   DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
> expected PBN %d, actual PBN %d.\n",
>   154000, 30, 689, ret);
>   return -EINVAL;
>   }
> - ret = drm_dp_calc_pbn_mode(234000, 30);
> + ret = drm_dp_calc_pbn_mode(234000, 30, false);
>   if (ret != 1047) {
>   DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
> expected PBN %d, actual PBN %d.\n",
>   234000, 30, 1047, ret);
>   return -EINVAL;
>   }
> - ret = drm_dp_calc_pbn_mode(297000, 24);
> + ret = drm_dp_calc_pbn_mode(297000, 24, false);
>   if (ret != 1063) {
>   DRM_ERROR("PBN calculation test failed - clock %d, bpp %d, 
> expected PBN %d, actual PBN %d.\n",
>   297000, 24, 1063, ret);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2c5ac3dd647f..4f17f61f4453 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -61,7 +61,7 @@ static int intel_dp_mst_compute_link_config(struct 
> intel_encoder *encoder,
>   crtc_state->pipe_bpp = bpp;
>  
>   crtc_s

Re: [PATCH v8 2/6] drm/dp_mst: Parse FEC capability on MST ports

[Harry Wentland]

On 2019-08-26 2:05 p.m., David Francis wrote:
> As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
> if FEC can be supported up to that point in the MST network.
> 
> The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
> bottom-most bit (refer to section 2.11.9.4 of DP standard,
> v1.4)
> 
> That value is needed for FEC and DSC support
> 
> Store it on drm_dp_mst_port
> 
> Signed-off-by: David Francis 
> Reviewed-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
>  include/drm/drm_dp_mst_helper.h   | 3 +++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 3e7b7553cf4d..9f3604355705 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -553,6 +553,7 @@ static bool 
> drm_dp_sideband_parse_enum_path_resources_ack(struct drm_dp_sideband
>  {
>   int idx = 1;
>   repmsg->u.path_resources.port_number = (raw->msg[idx] >> 4) & 0xf;
> + repmsg->u.path_resources.fec_capable = raw->msg[idx] & 0x1;
>   idx++;
>   if (idx > raw->curlen)
>   goto fail_len;
> @@ -2183,6 +2184,7 @@ static int drm_dp_send_enum_path_resources(struct 
> drm_dp_mst_topology_mgr *mgr,
>   DRM_DEBUG_KMS("enum path resources %d: %d %d\n", 
> txmsg->reply.u.path_resources.port_number, 
> txmsg->reply.u.path_resources.full_payload_bw_number,
>  
> txmsg->reply.u.path_resources.avail_payload_bw_number);
>   port->available_pbn = 
> txmsg->reply.u.path_resources.avail_payload_bw_number;
> + port->fec_capable = 
> txmsg->reply.u.path_resources.fec_capable;
>   }
>   }
>  
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 9116b2c95239..f113ae04fa88 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -108,6 +108,8 @@ struct drm_dp_mst_port {
>* audio-capable.
>*/
>   bool has_audio;
> +
> + bool fec_capable;
>  };
>  
>  /**
> @@ -312,6 +314,7 @@ struct drm_dp_port_number_req {
>  
>  struct drm_dp_enum_path_resources_ack_reply {
>   u8 port_number;
> + bool fec_capable;
>   u16 full_payload_bw_number;
>   u16 avail_payload_bw_number;
>  };
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/5] MST DSC support in drm-mst

[Harry Wentland]

On 2019-08-26 3:50 p.m., Dave Airlie wrote:
> On Sat, 24 Aug 2019 at 06:24, Francis, David  wrote:
>>
>> Adding DSC functionality to drm_dp_mst_atomic_check() is a good idea.
>> However, until amdgpu switches over to that system, I wouldn't be able
>> to test those changes. Making that switch is on our TODO list, and it would
>> fix a number of problems with our current MST implementation, but
>> it's going to be a major rewrite.
>>
>> MST DSC hardware is already on the market. It would be expedient to
>> merge the patches we need for Navi support sooner and update
>> drm_dp_mst_atomic_check when we're able to test it.
> 
> Is there any commitment to rewriting it, a timeline or anything?
> 
> The problem with this situation is there is always new hardware coming
> onto the market, and there is always pressure to support all the
> features of that new hardware, and the pressure always comes like this
> and being expedient. However I've found that a lot of the time the
> required refactor or work is never done, because the time is being
> allocated now to the next GPU that is coming on the market, and nobody
> ever cares enough to clean up their technical debt.
> 
> How come the needs for MST DSC support wasn't identified earlier,
> blocked on refactoring of the code to use common code, and then that
> task made a higher priority?
> 

drm_dp_mst_atomic_check was introduced by Lyude back in January with
https://patchwork.freedesktop.org/patch/276405/ as part of
https://patchwork.freedesktop.org/series/54031/

At the time Lyude updated i915 and nouveau to use these helpers. amdgpu
wasn't updated.

> I'm sorta inclined to say no we shouldn't be merging any driver
> specific code here, because this is the only point we can push
> pressure on to refactor the MST implementation, which I guess
> otherwise we'll just keep avoiding until Lyude ends up doing it for
> you.
> 

That's fair. I agree that the refactor should be done and I understand
where you're coming from. Since David is heading back to school in less
than a week I was inclined to see if we can push back a little so he can
get his change in. Other than that I don't mind holding off on the merge
unless the refactor is done.

Adding Mikita who'll pick up DSC stuff from David and will iterate on
these patches if necessary and look at the MST refactor.

Thanks for keeping us honest.

Harry

> Dave.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 3/6] drm/dp_mst: Add MST support to DP DPCD R/W functions

[Harry Wentland]

On 2019-08-26 2:05 p.m., David Francis wrote:
> Instead of having drm_dp_dpcd_read/write and
> drm_dp_mst_dpcd_read/write as entry points into the
> aux code, have drm_dp_dpcd_read/write handle both.
> 
> This means that DRM drivers can make MST DPCD read/writes.
> 
> v2: Fix spacing
> v3: Dump dpcd access on MST read/writes
> 
> Reviewed-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dp_aux_dev.c | 12 ++--
>  drivers/gpu/drm/drm_dp_helper.c  | 30 --
>  2 files changed, 22 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c 
> b/drivers/gpu/drm/drm_dp_aux_dev.c
> index 0cfb386754c3..418cad4f649a 100644
> --- a/drivers/gpu/drm/drm_dp_aux_dev.c
> +++ b/drivers/gpu/drm/drm_dp_aux_dev.c
> @@ -163,11 +163,7 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb, 
> struct iov_iter *to)
>   break;
>   }
>  
> - if (aux_dev->aux->is_remote)
> - res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
> -todo);
> - else
> - res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
> + res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
>  
>   if (res <= 0)
>   break;
> @@ -215,11 +211,7 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb, 
> struct iov_iter *from)
>   break;
>   }
>  
> - if (aux_dev->aux->is_remote)
> - res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
> - todo);
> - else
> - res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
> + res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf, todo);
>  
>   if (res <= 0)
>   break;
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index ffc68d305afe..2cc21eff4cf3 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -30,6 +30,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -251,7 +252,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
> request,
>  
>  /**
>   * drm_dp_dpcd_read() - read a series of bytes from the DPCD
> - * @aux: DisplayPort AUX channel
> + * @aux: DisplayPort AUX channel (SST or MST)
>   * @offset: address of the (first) register to read
>   * @buffer: buffer to store the register values
>   * @size: number of bytes in @buffer
> @@ -280,13 +281,18 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, 
> unsigned int offset,
>* We just have to do it before any DPCD access and hope that the
>* monitor doesn't power down exactly after the throw away read.
>*/
> - ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer,
> -  1);
> - if (ret != 1)
> - goto out;
> + if (!aux->is_remote) {
> + ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV,
> +  buffer, 1);
> + if (ret != 1)
> + goto out;
> + }
>  
> - ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
> -  size);
> + if (aux->is_remote)
> + ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
> + else
> + ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset,
> +  buffer, size);
>  
>  out:
>   drm_dp_dump_access(aux, DP_AUX_NATIVE_READ, offset, buffer, ret);
> @@ -296,7 +302,7 @@ EXPORT_SYMBOL(drm_dp_dpcd_read);
>  
>  /**
>   * drm_dp_dpcd_write() - write a series of bytes to the DPCD
> - * @aux: DisplayPort AUX channel
> + * @aux: DisplayPort AUX channel (SST or MST)
>   * @offset: address of the (first) register to write
>   * @buffer: buffer containing the values to write
>   * @size: number of bytes in @buffer
> @@ -313,8 +319,12 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, 
> unsigned int offset,
>  {
>   int ret;
>  
> - ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
> -  size);
> + if (aux->is_remote)
> + ret = drm_dp_mst_dpcd_write(aux, offset, buffer, size);
> + else
> + ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset,
> +  buffer, size);
> +
>   drm_dp_dump_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer, ret);
>   return ret;
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 4/6] drm/dp_mst: Fill branch->num_ports

[Harry Wentland]

On 2019-08-26 2:05 p.m., David Francis wrote:
> This field on drm_dp_mst_branch was never filled
> 
> It is initialized to zero when the port is kzallocced.
> When a port is added to the list, increment num_ports,
> and when a port is removed from the list, decrement num_ports.
> 
> v2: remember to decrement on port removal
> v3: don't explicitly init to 0
> 
> Signed-off-by: David Francis 
> Reviewed-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 9f3604355705..502923c24450 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1669,6 +1669,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
> *mstb,
>   mutex_lock(>mgr->lock);
>   drm_dp_mst_topology_get_port(port);
>   list_add(>next, >ports);
> + mstb->num_ports++;
>   mutex_unlock(>mgr->lock);
>   }
>  
> @@ -1703,6 +1704,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
> *mstb,
>   /* remove it from the port list */
>   mutex_lock(>mgr->lock);
>   list_del(>next);
> + mstb->num_ports--;
>   mutex_unlock(>mgr->lock);
>   /* drop port list reference */
>   drm_dp_mst_topology_put_port(port);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 6/6] drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux

[Harry Wentland]

On 2019-08-26 2:05 p.m., David Francis wrote:
> Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
> register might have to be written on the leaf port's DPCD,
> its parent's DPCD, or the MST manager's DPCD. This function
> finds the correct aux for the job.
> 
> As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
> is a DP feature new in DP v1.4, which exposes certain DPCD
> registers on virtual ports.
> 
> v2: Remember to unlock mutex on all paths
> 
> Cc: Lyude Paul 
> Cc: Jani Nikula 
> Signed-off-by: David Francis 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 152 ++
>  include/drm/drm_dp_mst_helper.h   |   2 +
>  2 files changed, 154 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 502923c24450..1fee92bd51f7 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4150,3 +4150,155 @@ static void drm_dp_mst_unregister_i2c_bus(struct 
> drm_dp_aux *aux)
>  {
>   i2c_del_adapter(>ddc);
>  }
> +
> +/**
> + * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer Device
> + * @port: The port to check
> + *
> + * A single physical MST hub object can be represented in the topology
> + * by multiple branches, with virtual ports between those branches.
> + *
> + * As of DP1.4, An MST hub with internal (virtual) ports must expose
> + * certain DPCD registers over those ports. See sections 2.6.1.1.1
> + * and 2.6.1.1.2 of Display Port specification v1.4 for details.
> + *

I've briefly perused these sections and they seem quite vague. What we
have here is probably a reasonable implementation, though.

Might be worthwhile to mention that the spec is not very clear on this
and that this is the best interpretation we have.

> + * May acquire mgr->lock
> + *
> + * Returns:
> + * true if the port is a virtual DP peer device, false otherwise
> + */
> +static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *downstream_port;
> +
> + if (!port)
> + return false;
> +

Can we early return with false if dpcd_rev < DP_DPCD_REV_14 rather than
check this in each if statement below?

> + /* Virtual DP Sink (Internal Display Panel) */
> + if (port->port_num >= 8 && port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-HDMI Protocol Converter */
> + if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
> + !port->mcs &&
> + port->ldps &&
> + port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-DP */
> + mutex_lock(>mgr->lock);
> + if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
> + port->mstb &&
> + port->dpcd_rev >= DP_DPCD_REV_14 &&
> + port->mstb->num_ports == 2) {

Is 'num_ports == 2' required? Maybe I don't follow this bit...

> + list_for_each_entry(downstream_port, >mstb->ports, next) {
> + if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK &&
> + !downstream_port->input) {
> + mutex_unlock(>mgr->lock);
> + return true;
> + }
> + }
> + }
> + mutex_unlock(>mgr->lock);
> +
> + return false;
> +}
> +
> +/**
> + * drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
> + * @port: The port to check. A leaf of the MST tree with an attached display.
> + *
> + * Depending on the situation, DSC may be enabled via the endpoint aux,
> + * the immediately upstream aux, or the connector's physical aux.
> + *
> + * This is both the correct aux to read DSC_CAPABILITY and the
> + * correct aux to write DSC_ENABLED.
> + *
> + * This operation can be expensive (up to four aux reads), so
> + * the caller should cache the return.
> + *
> + * Returns:
> + * NULL if DSC cannot be enabled on this port, otherwise the aux device
> + */
> +struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *immediate_upstream_port;
> + struct drm_dp_mst_port *fec_port;
> + struct drm_dp_desc *desc = NULL;
> +

Might be good to early return if !port to avoid proceeding through the
entire function if this is called without a port.

> + if (port && port->parent)
> + immediate_upstream_port = port->parent->port_parent;
> + else
> + immediate_upstream_port = NULL;
> +
> + fec_port = immediate_upstream_port;
> + while (fec_port) {
> + /*
> +  * Each physical link (i.e. not a virtual port) between the
> +  * output and the primary device must support FEC
> +  */
> + if (!drm_dp_mst_is_virtual_dpcd(fec_port) &&
> + !fec_port->fec_capable)
> +  

Re: [PATCH 2/3] drm/amd/display: remove unused function setFieldWithMask

[Harry Wentland]

On 2019-08-27 3:09 a.m., YueHaibing wrote:
> After commit a9f54ce3c603 ("drm/amd/display: Refactoring VTEM"),
> there is no caller in tree.
> 
> Reported-by: Hulk Robot  Signed-off-by: YueHaibing 
> 

Reviewed-by: Harry Wentland 

Harry

> ---
>  .../drm/amd/display/modules/info_packet/info_packet.c | 19 
> ---
>  1 file changed, 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c 
> b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> index 5f4b98d..d885d64 100644
> --- a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> +++ b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c
> @@ -114,25 +114,6 @@ enum ColorimetryYCCDP {
>   ColorimetryYCC_DP_ITU2020YCbCr  = 7,
>  };
>  
> -void setFieldWithMask(unsigned char *dest, unsigned int mask, unsigned int 
> value)
> -{
> - unsigned int shift = 0;
> -
> - if (!mask || !dest)
> - return;
> -
> - while (!((mask >> shift) & 1))
> - shift++;
> -
> - //reset
> - *dest = *dest & ~mask;
> - //set
> - //dont let value span past mask
> - value = value & (mask >> shift);
> - //insert value
> - *dest = *dest | (value << shift);
> -}
> -
>  void mod_build_vsc_infopacket(const struct dc_stream_state *stream,
>   struct dc_info_packet *info_packet)
>  {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index cb7cfa9b34f2..e872a415b409 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -5144,11 +5144,12 @@ static int amdgpu_dm_connector_init(struct 
> amdgpu_display_manager *dm,
>  
>   connector_type = to_drm_connector_type(link->connector_signal);
>  
> - res = drm_connector_init(
> + res = drm_connector_init_with_ddc(
>   dm->ddev,
>   >base,
>   _dm_connector_funcs,
> - connector_type);
> + connector_type,
> + >base);
>  
>   if (res) {
>   DRM_ERROR("connector_init failed\n");
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V3] drm: Add LTTPR defines for DP 1.4a

[Harry Wentland]

On 2019-08-28 3:52 p.m., Siqueira, Rodrigo wrote:
> DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
> which is required to add support for systems with Thunderbolt or other
> repeater devices.
> 
> Changes since V2:
> - Drop the kernel-doc comment
> - Reorder LTTPR according to register offset
> Changes since V1:
> - Adjusts registers names to be aligned with spec and the rest of the
>   file
> - Update spec comment from 1.4 to 1.4a
> 
> Cc: Abdoulaye Berthe 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Siqueira 
> Signed-off-by: Abdoulaye Berthe 

Reviewed-by: Harry Wentland 

Harry

> ---
>  include/drm/drm_dp_helper.h | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8364502f92cf..67f9121d781d 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -989,6 +989,31 @@
>  #define HDCP_2_2_DP_RXSTATUS_REAUTH_REQ(x)   ((x) & BIT(3))
>  #define HDCP_2_2_DP_RXSTATUS_LINK_FAILED(x)  ((x) & BIT(4))
>  
> +/* Link Training (LT)-tunable Physical Repeaters - DP 1.4a */
> +#define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 0xf
> +#define DP_MAX_LINK_RATE_PHY_REPEATER   0xf0001
> +#define DP_PHY_REPEATER_CNT 0xf0002
> +#define DP_PHY_REPEATER_MODE0xf0003
> +#define DP_MAX_LANE_COUNT_PHY_REPEATER  0xf0004
> +#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT   0xf0005
> +#define DP_TRAINING_PATTERN_SET_PHY_REPEATER1   0xf0010
> +#define DP_TRAINING_LANE0_SET_PHY_REPEATER1 0xf0011
> +#define DP_TRAINING_LANE1_SET_PHY_REPEATER1 0xf0012
> +#define DP_TRAINING_LANE2_SET_PHY_REPEATER1 0xf0013
> +#define DP_TRAINING_LANE3_SET_PHY_REPEATER1 0xf0014
> +#define DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1   0xf0020
> +#define DP_TRANSMITTER_CAPABILITY_PHY_REPEATER1 0xf0021
> +#define DP_LANE0_1_STATUS_PHY_REPEATER1 0xf0030
> +#define DP_LANE2_3_STATUS_PHY_REPEATER1 0xf0031
> +#define DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1  0xf0032
> +#define DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER1 0xf0033
> +#define DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER1 0xf0034
> +#define DP_SYMBOL_ERROR_COUNT_LANE0_PHY_REPEATER1   0xf0035
> +#define DP_SYMBOL_ERROR_COUNT_LANE1_PHY_REPEATER1   0xf0037
> +#define DP_SYMBOL_ERROR_COUNT_LANE2_PHY_REPEATER1   0xf0039
> +#define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER1   0xf003b
> +#define DP_FEC_STATUS_PHY_REPEATER1 0xf0290
> +
>  /* DP 1.2 Sideband message defines */
>  /* peer device type - DP 1.2a Table 2-92 */
>  #define DP_PEER_DEVICE_NONE  0x0
> 



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_connector: add additional aspect ratio values

[Harry Wentland]

On 2019-08-22 5:50 p.m., Wayne Lin wrote:
> For HDMI2.0 CTS item - HF1-35, it verifies if the source generates
> video timing "64:27" video format correctly.
> 
> eg: (vic-76) 1920x1080p@60Hz,24bpp
> 
> This patch add on "64:27" and "256:135" to drm_aspect_ratio_enum_list.
> Thereafter, one can specify the aspect ratio to "64:27" or "256:135"
> after creating aspect ratio property.>
> Change-Id: Ifc9df54e8e8f78e70960fcd737a3a57e49c81152
> Signed-off-by: Wayne Lin 

Drop the Change-Id.

With that fixed this patch is

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_connector.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 3a0cacb71235..c0629a01d08e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -772,6 +772,8 @@ static const struct drm_prop_enum_list 
> drm_aspect_ratio_enum_list[] = {
>   { DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
>   { DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
>   { DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
> + { DRM_MODE_PICTURE_ASPECT_64_27, "64:27" },
> + { DRM_MODE_PICTURE_ASPECT_256_135, "256:135" },
>  };
>  
>  static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2] drm: Add LTTPR defines for DP 1.4a

[Harry Wentland]

+Cc Manasi, FYI

On 2019-08-26 11:29 a.m., Siqueira, Rodrigo wrote:
> DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
> which is required to add support for systems with Thunderbolt or other
> repeater devices.
> 
> Changes since V1:
> - Adjusts registers names to be aligned with spec and the rest of the
>   file
> - Update spec comment from 1.4 to 1.4a
> 
> Cc: Abdoulaye Berthe 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Signed-off-by: Rodrigo Siqueira 
> Signed-off-by: Abdoulaye Berthe 

Reviewed-by: Harry Wentland 

Harry

> ---
>  include/drm/drm_dp_helper.h | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8364502f92cf..e8beb4e7e5da 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -134,6 +134,31 @@
>  #define DP_SUPPORTED_LINK_RATES  0x010 /* eDP 1.4 */
>  # define DP_MAX_SUPPORTED_RATES   8  /* 16-bit 
> little-endian */
>  
> +/** Link Training (LT)-tunable Physical Repeaters - DP 1.4a **/
> +#define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 0xf
> +#define DP_MAX_LINK_RATE_PHY_REPEATER   0xf0001
> +#define DP_PHY_REPEATER_CNT 0xf0002
> +#define DP_PHY_REPEATER_MODE0xf0003
> +#define DP_MAX_LANE_COUNT_PHY_REPEATER  0xf0004
> +#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT   0xf0005
> +#define DP_TRAINING_PATTERN_SET_PHY_REPEATER1   0xf0010
> +#define DP_TRAINING_LANE0_SET_PHY_REPEATER1 0xf0011
> +#define DP_TRAINING_LANE1_SET_PHY_REPEATER1 0xf0012
> +#define DP_TRAINING_LANE2_SET_PHY_REPEATER1 0xf0013
> +#define DP_TRAINING_LANE3_SET_PHY_REPEATER1 0xf0014
> +#define DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1   0xf0020
> +#define DP_TRANSMITTER_CAPABILITY_PHY_REPEATER1 0xf0021
> +#define DP_LANE0_1_STATUS_PHY_REPEATER1 0xf0030
> +#define DP_LANE2_3_STATUS_PHY_REPEATER1 0xf0031
> +#define DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1  0xf0032
> +#define DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER1 0xf0033
> +#define DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER1 0xf0034
> +#define DP_SYMBOL_ERROR_COUNT_LANE0_PHY_REPEATER1   0xf0035
> +#define DP_SYMBOL_ERROR_COUNT_LANE1_PHY_REPEATER1   0xf0037
> +#define DP_SYMBOL_ERROR_COUNT_LANE2_PHY_REPEATER1   0xf0039
> +#define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER1   0xf003b
> +#define DP_FEC_STATUS_PHY_REPEATER1 0xf0290
> +
>  /* Multiple stream transport */
>  #define DP_FAUX_CAP  0x020   /* 1.2 */
>  # define DP_FAUX_CAP_1   (1 << 0)
> 



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] drm/amdgpu/display: fix build error without CONFIG_DRM_AMD_DC_DSC_SUPPORT

[Harry Wentland]

On 2019-08-26 4:57 a.m., YueHaibing wrote:
> If CONFIG_DRM_AMD_DC_DSC_SUPPORT is not set, build fails:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: In function 
> dcn20_hw_sequencer_construct:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:2099:28:
>  error: dcn20_dsc_pg_control undeclared (first use in this function); did you 
> mean dcn20_dpp_pg_control?
>   dc->hwss.dsc_pg_control = dcn20_dsc_pg_control;
> ^~~~
> dcn20_dpp_pg_control
> 
> Use CONFIG_DRM_AMD_DC_DSC_SUPPORT to guard this.
> 
> Reported-by: Hulk Robot 
> Fixes: 8a31820b1218 ("drm/amd/display: Make init_hw and init_pipes generic 
> for seamless boot")
> Signed-off-by: YueHaibing 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c 
> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
> index e146d1d..54d67f6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
> @@ -2092,7 +2092,11 @@ void dcn20_hw_sequencer_construct(struct dc *dc)
>   dc->hwss.enable_power_gating_plane = dcn20_enable_power_gating_plane;
>   dc->hwss.dpp_pg_control = dcn20_dpp_pg_control;
>   dc->hwss.hubp_pg_control = dcn20_hubp_pg_control;
> +#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
>   dc->hwss.dsc_pg_control = dcn20_dsc_pg_control;
> +#else
> + dc->hwss.dsc_pg_control = NULL;
> +#endif
>   dc->hwss.disable_vga = dcn20_disable_vga;
>  
>   if (IS_FPGA_MAXIMUS_DC(dc->ctx->dce_environment)) {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][drm-next] drm/amd/display: fix a potential null pointer dereference

[Harry Wentland]

On 2019-08-16 6:10 p.m., Colin King wrote:
> From: Colin Ian King 
> 
> Currently the pointer init_data is dereferenced on the assignment
> of fw_info before init_data is sanity checked to see if it is null.
> Fix te potential null pointer dereference on init_data by only
> performing dereference after it is null checked.
> 
> Addresses-Coverity: ("Dereference before null check")
> Fixes: 9adc8050bf3c ("drm/amd/display: make firmware info only load once 
> during dc_bios create")
> Signed-off-by: Colin Ian King 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> index bee81bf288be..926954c804a6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> @@ -1235,7 +1235,7 @@ static bool calc_pll_max_vco_construct(
>   struct calc_pll_clock_source_init_data *init_data)
>  {
>   uint32_t i;
> - struct dc_firmware_info *fw_info = _data->bp->fw_info;
> + struct dc_firmware_info *fw_info;
>   if (calc_pll_cs == NULL ||
>   init_data == NULL ||
>   init_data->bp == NULL)
> @@ -1244,6 +1244,7 @@ static bool calc_pll_max_vco_construct(
>   if (init_data->bp->fw_info_valid)
>   return false;
>  
> + fw_info = _data->bp->fw_info;
>   calc_pll_cs->ctx = init_data->ctx;
>   calc_pll_cs->ref_freq_khz = fw_info->pll_info.crystal_frequency;
>   calc_pll_cs->min_vco_khz =
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add LTTPR defines for DP 1.4

[Harry Wentland]

On 2019-08-22 6:46 p.m., Siqueira, Rodrigo wrote:
> DP 1.4 specification defines Link Training Tunable PHY Repeater (LTTPR)
> which is required to add support for systems with Thunderbolt or other
> repeater devices.
> 
> Cc: Abdoulaye Berthe 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Signed-off-by: Rodrigo Siqueira 
> Signed-off-by: Abdoulaye Berthe 
> ---
>  include/drm/drm_dp_helper.h | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8364502f92cf..8336d960da7f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -134,6 +134,32 @@
>  #define DP_SUPPORTED_LINK_RATES  0x010 /* eDP 1.4 */
>  # define DP_MAX_SUPPORTED_RATES   8  /* 16-bit 
> little-endian */
>  
> +/** Link Training (LT)-tunable Physical Repeaters - DP 1.4 **/
> +#define DP_LTTPR_REV  0xf
> +#define DP_LTTPR_MAX_LINK_RATE0xf0001
> +#define DP_LTTPR_REPEATER_CNT 0xf0002
> +#define DP_LTTPR_REPEATER_MODE0xf0003
> +#define DP_LTTPR_MAX_LANE_CNT 0xf0004
> +#define DP_LTTPR_EXTENDED_WAIT_TIMEOUT0xf0005
> +#define DP_LTTPR_TRAINING_PATTERN_SET_REPEATER1   0xf0010
> +#define DP_LTTPR_TRAINING_LANE0_SET_REPEATER1 0xf0011
> +#define DP_LTTPR_TRAINING_LANE1_SET_REPEATER1 0xf0012
> +#define DP_LTTPR_TRAINING_LANE2_SET_REPEATER1 0xf0013
> +#define DP_LTTPR_TRAINING_LANE3_SET_REPEATER1 0xf0014

Can we align the register naming with the spec and to align with the
rest of this file?

The seem to take the form of DP_

E.g. call this one DP_TRAINING_LANE3_SET_PHY_REPEATER1

Same for all other registers.

Keeping the naming consistent makes it easier to search.

> +#define DP_LTTPR_TRAINING_AUX_RD_INTERVAL_REPEATER1   0xf0020
> +#define DP_LTTPR_TRANSMITTER_CAPABILITY_REPEATER1 0xf0021
> +#define DP_LTTPR_LANE0_1_STATUS_REPEATER1 0xf0030
> +#define DP_LTTPR_LANE2_3_STATUS_REPEATER1 0xf0031
> +#define DP_LTTPR_LANE_ALIGN_STATUS_UPDATED_REPEATER1  0xf0032
> +#define DP_LTTPR_ADJUST_REQUEST_LANE0_1_REPEATER1 0xf0033
> +#define DP_LTTPR_ADJUST_REQUEST_LANE2_3_REPEATER1 0xf0034
> +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE0_REPEATER1   0xf0035
> +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE1_REPEATER1   0xf0037
> +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE2_REPEATER1   0xf0039
> +#define DP_LTTPR_SYMBOL_ERROR_COUNT_LANE3_REPEATER1   0xf003b
> +#define DP_REPEATER_CONFIGURATION_AND_STATUS_OFFSET   0x50

With a cursory search I can't seem to find this in the spec. Where is
this coming from?

Harry

> +#define DP_LTTPR_FEC_STATUS_REPEATER1 0xf0290> +
>  /* Multiple stream transport */
>  #define DP_FAUX_CAP  0x020   /* 1.2 */
>  # define DP_FAUX_CAP_1   (1 << 0)
> 



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for Sep 4 (amd/display/)

[Harry Wentland]

On 2019-09-04 4:58 p.m., Randy Dunlap wrote:
> On 9/4/19 6:34 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> News: this will be the last linux-next I will release until Sept 30.
>>
>> Changes since 20190903:
>>
> 
> on x86_64:
> 
> In file included from 
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/display_rq_dlg_calc_20v2.c:77:0:
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/../dml_inline_defs.h: 
> In function ‘dml_min’:
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/../dml_inline_defs.h:34:1:
>  error: SSE register return with SSE disabled
> 

Is that fixed by Stephen's fixup here?

https://lists.freedesktop.org/archives/dri-devel/2019-September/234292.html

Thanks,
Harry

> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V4] drm: Add LTTPR defines for DP 1.4a

[Harry Wentland]

On 2019-09-05 1:29 p.m., Ville Syrjälä wrote:
> On Wed, Sep 04, 2019 at 07:02:18PM +, Siqueira, Rodrigo wrote:
>> DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR)
> 
> A bunch of this stuff was already in DP 1.3 so the statement here
> (and in the comment) is a bit misleading.
> 
> "LTTPR" is not a name that appears anywhere in the spec AFAICS, so
> calling it that is a bit confusing.
> 
>> which is required to add support for systems with Thunderbolt or other
>> repeater devices.
> 
> "required" seems a bit strong. IIRC by default these things should be in
> transparent mode so the DPTX can remain blissfully unaware of their
> presence.
> 

That's the idea but in reality things usually don't work out like this.
I remember a couple years back debugging Thunderbolt and having it
modify DPCD register reads on me and messing up link training with
certain receivers.

Either way, we've found that in order to receive a reliable
implementation we need to make use of the LTTPR functionality.

>>
>> Changes since V3:
>> - Replace spaces by tabs
>> Changes since V2:
>> - Drop the kernel-doc comment
>> - Reorder LTTPR according to register offset
>> Changes since V1:
>> - Adjusts registers names to be aligned with spec and the rest of the
>>   file
>> - Update spec comment from 1.4 to 1.4a
>>
>> Cc: Abdoulaye Berthe 
>> Cc: Harry Wentland 
>> Cc: Leo Li 
>> Cc: Jani Nikula 
>> Cc: Manasi Navare 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Rodrigo Siqueira 
>> Signed-off-by: Abdoulaye Berthe 
>> Reviewed-by: Harry Wentland 
>> ---
>>  include/drm/drm_dp_helper.h | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 8364502f92cf..5abed96a1cb1 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -966,6 +966,31 @@
>>  #define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET  0x69494
>>  #define DP_HDCP_2_2_REG_DBG_OFFSET  0x69518
>>  
>> +/* Link Training (LT)-tunable Physical Repeaters - DP 1.4a */
> 
> s/Physical/PHY/ to match the spec.
> 
>> +#define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 0xf
>> +#define DP_MAX_LINK_RATE_PHY_REPEATER   0xf0001
>> +#define DP_PHY_REPEATER_CNT 0xf0002
>> +#define DP_PHY_REPEATER_MODE0xf0003
>> +#define DP_MAX_LANE_COUNT_PHY_REPEATER  0xf0004
>> +#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT   0xf0005
> 
> The last two are DP 1.4a it seems.
> 
> 0xf0004 was called Repeater_FEC_CAPABILITY in 1.4. But the spec doesn't
> say anything about the DPCD revision so I have no idea how you're
> supposed to decide which definition to use.
> 
> DP 1.4a seems to have added FEC_CAPABILITY_PHY_REPEATER1 at 0xf0294.
> To replace the 1.4 Repeater_FEC_CAPABILITY I suppose.
> 

This part confused me when I saw it in 1.4 and 1.4a. It's probably
safest to go with the 1.4a definition.

>> +#define DP_TRAINING_PATTERN_SET_PHY_REPEATER1   0xf0010
>> +#define DP_TRAINING_LANE0_SET_PHY_REPEATER1 0xf0011
>> +#define DP_TRAINING_LANE1_SET_PHY_REPEATER1 0xf0012
>> +#define DP_TRAINING_LANE2_SET_PHY_REPEATER1 0xf0013
>> +#define DP_TRAINING_LANE3_SET_PHY_REPEATER1 0xf0014
>> +#define DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1   0xf0020
>> +#define DP_TRANSMITTER_CAPABILITY_PHY_REPEATER1 0xf0021
> 
> Above two are DP 1.4a.
> 
>> +#define DP_LANE0_1_STATUS_PHY_REPEATER1 0xf0030
>> +#define DP_LANE2_3_STATUS_PHY_REPEATER1 0xf0031
>> +#define DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1  0xf0032
>> +#define DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER1 0xf0033
>> +#define DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER1 0xf0034
>> +#define DP_SYMBOL_ERROR_COUNT_LANE0_PHY_REPEATER1   0xf0035
>> +#define DP_SYMBOL_ERROR_COUNT_LANE1_PHY_REPEATER1   0xf0037
>> +#define DP_SYMBOL_ERROR_COUNT_LANE2_PHY_REPEATER1   0xf0039
>> +#define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER1   0xf003b
>> +#define DP_FEC_STATUS_PHY_REPEATER1 0xf0290
> 
> This seems to have appared in DP 1.4.
> 
> You skipped quite a few registers here. I guess those were deemed not
> important?
> 

They won't be used by us at the moment.

Harry

>> +
>>  /* DP HDCP message start offsets in DPCD address space */
>>  #define DP_HDCP_2_2_AKE_INIT_OFFSET DP_HDCP_2_2_REG_RTX_OFFSET
>>  #define DP_HDCP_2_2_AKE_SEND_CERT_OFFSETDP_HDCP_2_2_REG_CERT_RX_OFFSET
>> -- 
>> 2.23.0
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Move static keyword to the front of declaration

[Harry Wentland]

On 2019-09-05 2:33 p.m., Krzysztof Wilczynski wrote:
> Move the static keyword to the front of declaration of DC_BUILD_ID,
> and resolve the following compiler warning that can be seen when
> building with warnings enabled (W=1):
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1: warning:
>   ‘static’ is not at beginning of declaration [-Wold-style-declaration]
> 
> Signed-off-by: Krzysztof Wilczynski 

Reviewed-by: Harry Wentland 

Harry

> ---
> Related: https://lore.kernel.org/r/20190827233017.gk9...@google.com
> 
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 87ca5a290d12..a5a89bc0e1d1 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -72,7 +72,7 @@
>  #define DC_LOGGER \
>   dc->ctx->logger
>  
> -const static char DC_BUILD_ID[] = "production-build";
> +static const char DC_BUILD_ID[] = "production-build";
>  
>  /**
>   * DOC: Overview
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm/amd: be quiet when no SAD block is found

[Harry Wentland]

On 2019-09-04 5:12 a.m., Jean Delvare wrote:
> It is fine for displays without audio functionality to not provide
> any SAD block in their EDID. Do not log an error in that case,
> just return quietly.
> 
> This fixes half of bug fdo#107825:
> https://bugs.freedesktop.org/show_bug.cgi?id=107825
> 
> Signed-off-by: Jean Delvare 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Harry Wentland 
> Cc: Leo Li 

Reviewed-by: Harry Wentland 

Harry

> ---
> No change since v1.
> 
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|4 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|4 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |4 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |4 ++--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c |7 +++
>  5 files changed, 11 insertions(+), 12 deletions(-)
> 
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 2019-07-08 
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  2019-08-30 
> 14:28:46.081682223 +0200
> @@ -1345,10 +1345,10 @@ static void dce_v10_0_audio_write_sad_re
>   }
>  
>   sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
>   DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
>   return;
> - }
>   BUG_ON(!sads);
>  
>   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 2019-07-08 
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  2019-08-30 
> 14:29:27.276205310 +0200
> @@ -1371,10 +1371,10 @@ static void dce_v11_0_audio_write_sad_re
>   }
>  
>   sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
>   DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
>   return;
> - }
>   BUG_ON(!sads);
>  
>   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  2019-07-08 
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   2019-08-30 
> 17:58:53.613953458 +0200
> @@ -1248,10 +1248,10 @@ static void dce_v6_0_audio_write_sad_reg
>   }
>  
>   sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
>   DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
>   return;
> - }
>  
>   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
>   u32 tmp = 0;
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  2019-07-08 
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   2019-08-30 
> 14:29:01.948883708 +0200
> @@ -1298,10 +1298,10 @@ static void dce_v8_0_audio_write_sad_reg
>   }
>  
>   sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
>   DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
>   return;
> - }
>   BUG_ON(!sads);
>  
>   for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> --- linux-5.2.orig/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  
> 2019-07-08 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c   
> 2019-08-30 14:31:03.086421910 +0200
> @@ -98,11 +98,10 @@ enum dc_edid_status dm_helpers_parse_edi
>   (struct edid *) edid->raw_edid);
>  
>   sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> - if (sad_count <= 0) {
> - DRM_INFO("SADs count is: %d, don't need to read it\n",
> - sad_count);
> + if (sad_count < 0)
> + DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
>   return result;
> - }
>  
>   edid_caps->audio_mode_count = sad_count < DC_MAX_AUDIO_DESC_COUNT ? 
> sad_count : DC_MAX_AUDIO_DESC_COUNT;
>   for (i = 0; i < edid_caps->audio_mode_count; ++i) {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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 the HDCP 2.3 spec [1] a device compliant with
HDCP 2.0 and higher must be capable of storing and updating the SRM in
non-volatile memory. Section 5.2 describes how this SRM needs to be
updated when a new version is served alongside protected content.

Isn't /lib/firmware intended for static firmware making updates to the
folder problematic for anyone but the system's package maintainer? I've
heard /lib might even be treated as read-only in certain environments.
This would mean it'd be impossible to support HDCP 2.x on those systems.

Wouldn't it be easier to provide a sysfs entry for SRM that allows
userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM
from the HDCP implementation for non-volatile storage and (b) to pass
the SRM to the HDCP implementation for revocation checking?

[1]
https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf

Thanks,
Harry

> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
> implements the HDCP authentication)
> 
> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> 
> v2:
>   moved the uAPI to request_firmware_direct() [Daniel]
> v3:
>   kdoc added. [Daniel]
>   srm_header unified and bit field definitions are removed. [Daniel]
>   locking improved. [Daniel]
>   vrl length violation is fixed. [Daniel]
> v4:
>   s/__swab16/be16_to_cpu [Daniel]
>   be24_to_cpu is done through a global func [Daniel]
>   Unused variables are removed. [Daniel]
>   unchecked return values are dropped from static funcs [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Acked-by: Satyeshwar Singh 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>  drivers/gpu/drm/drm_internal.h|   4 +
>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>  include/drm/drm_hdcp.h|  24 ++
>  6 files changed, 370 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 14102ae035dc..0fe726a6ee67 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -181,6 +181,12 @@ Panel Helper Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> :export:
> 
> +HDCP Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> +   :export:
> +
>  Display Port Helper Functions Reference
>  ===
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 72f5036d9bfa..dd02e9dec810 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -17,7 +17,7 @@ drm-y   :=drm_auth.o drm_cache.o \
> drm_plane.o drm_color_mgmt.o drm_print.o \
> drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> -   drm_atomic_uapi.o
> +   drm_atomic_uapi.o drm_hdcp.o
> 
>  drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o 
> drm_dma.o drm_scatter.o drm_lock.o
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> new file mode 100644
> index ..5e5409505c31
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -0,0 +1,333 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * Authors:
> + * Ramalingam C 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct hdcp_srm {
> +   u32 revoked_ksv_cnt;
> +   u8 *revoked_ksv_list;
> +
> +   /* Mutex to protect above struct member */
> +   struct mutex mutex;
> +} *srm_data;
> +
> +static inline void drm_hdcp_print_ksv(const u8 *ksv)
> +{
> +   DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
> + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
> +}
> +
> +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
> +{
> +   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> +
> +   while (parsed_bytes < vrls_length) {
> +   vrl_ksv_cnt = *buf;
> +   ksv_count += vrl_ksv_cnt;
> +
> +   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> +   buf += vrl_sz;
> +   parsed_bytes 

Re: HDCP Content Type Interface

[Harry Wentland]

On 2019-09-12 3:47 a.m., Ramalingam C wrote:
> On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote:
>> Hi all,
>>
>> This is regarding the recent hdcp content type patch that was merged into 
>> drm-misc. 
>> (https://patchwork.freedesktop.org/patch/320958/?series=57233=11)
>>
>> There are displays on the market that advertise HDCP 2.2 support and will 
>> pass authentication and encryption but will then show a corrupted/blue/black 
>> screen (the driver cannot detect this). These displays work with HDCP 1.4 
>> without any issues. Due to the large number of HDCP-supporting devices on 
>> the market we might not be able to catch them with a blacklist.
>>
>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same 
>> thing. Meaning that this interface doesn't allow us to force the hdcp 
>> version. Due to the problems mentioned above we might want to expose the 
>> ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) 
>> in case they experience problems.
>>
>> What are your thoughts? and what would be a good way to deal with it?
> Hi,
> 
> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel
> supposed to exercise the highest version of HDCP supported on panel and
> platform.
> 
> As we implement the HDCP spec support, if a device is non-compliant with
> HDCP spec after completing the HDCP authentication, I dont think we need
> to worry about it.
> 

Tell that to our (or your) customers.

In this case an enduser might plug in a bad monitor or TV and be unable
to play protected content.

What if we add a new enum value to the content_type property that says
"DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"?

Harry

> In case if you want to track and implement a quirk for it, like not to
> project the HDCP2.2 capability, you can use the receiver id of that panel
> to track it.
> 
> Thanks,
> -Ram
>>
>>
>> Thanks,
>>
>> Bhawan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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 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 the HDCP 2.3 spec [1] a device compliant with
>> HDCP 2.0 and higher must be capable of storing and updating the SRM in
>> non-volatile memory. Section 5.2 describes how this SRM needs to be
>> updated when a new version is served alongside protected content.
>>
>> Isn't /lib/firmware intended for static firmware making updates to the
>> folder problematic for anyone but the system's package maintainer? I've
>> heard /lib might even be treated as read-only in certain environments.
>> This would mean it'd be impossible to support HDCP 2.x on those systems.
>>
>> Wouldn't it be easier to provide a sysfs entry for SRM that allows
>> userspace (e.g. system startup/shutdown scripts) to (a) retrieve the SRM
>> from the HDCP implementation for non-volatile storage and (b) to pass
>> the SRM to the HDCP implementation for revocation checking?
> 
> This uAPI is decided considering below points:
> 
> userspace will handle the non-volatile storage of the SRM table and it's 
> upgrade
> with latest versions received from content providers etc.
> 
> Prior to any HDCP auth request userspace will write the latest SRM into
> the /lib/firmware.
> 
> And regarding the interface, binary sysfs based implementation [1] was 
> opposed by Greg KH.
> And after the discussion on different alternate i/fs [2] request
> firmware is choosen.
> 
> [1]. https://patchwork.freedesktop.org/patch/296442/?series=57232=5uAPI
> [2]. https://patchwork.freedesktop.org/patch/296439/?series=57232=5
> 
> I hope this addresses the questions above.
> 

Interesting discussion. Thanks for sharing.

It sounds like Greg's main concern was with the fact that DRM parses the
binary.

In our case we'll need to pass the blob to FW without touching it. A
device sysfs sounds like a better use-case for that.

On the other hand certain people are interested to have a non-FW
approach to content protection for which your approach seems to work best.

I still don't know how this solution can get HDCP 2.x certified. I was
under the impression HDCP 2.x required a protected execution environment
with stricter requirements than x86 kernel space can provide.

Harry

> -Ram
> 
> 
>>
>> [1]
>> https://www.digital-cp.com/sites/default/files/HDCP%20on%20HDMI%20Specification%20Rev2_3.pdf
>>
>> Thanks,
>> Harry
>>
>>> SRM table is parsed and stored at drm_hdcp.c, with functions exported
>>> for the services for revocation check from drivers (which
>>> implements the HDCP authentication)
>>>
>>> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
>>>
>>> v2:
>>>   moved the uAPI to request_firmware_direct() [Daniel]
>>> v3:
>>>   kdoc added. [Daniel]
>>>   srm_header unified and bit field definitions are removed. [Daniel]
>>>   locking improved. [Daniel]
>>>   vrl length violation is fixed. [Daniel]
>>> v4:
>>>   s/__swab16/be16_to_cpu [Daniel]
>>>   be24_to_cpu is done through a global func [Daniel]
>>>   Unused variables are removed. [Daniel]
>>>   unchecked return values are dropped from static funcs [Daniel]
>>>
>>> Signed-off-by: Ramalingam C 
>>> Acked-by: Satyeshwar Singh 
>>> Reviewed-by: Daniel Vetter 
>>> ---
>>>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>>>  drivers/gpu/drm/Makefile  |   2 +-
>>>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>>>  drivers/gpu/drm/drm_internal.h|   4 +
>>>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>>>  include/drm/drm_hdcp.h|  24 ++
>>>  6 files changed, 370 insertions(+), 1 deletion(-)
>>>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
>>>
>>> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
>>> b/Documentation/gpu/drm-kms-helpers.rst
>>> index 14102ae035dc..0fe726a6ee67 100644
>>> --- a/Documentation/gpu/drm-kms-helpers.rst
>>> +++ b/Documentation/gpu/drm-kms-helpers.rst
>>> @@ -181,6 +181,12 @@ Panel Helper Reference
>>>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
>>> :export:
>&g

Re: HDCP Content Type Interface

[Harry Wentland]

On 2019-09-12 10:49 a.m., Ramalingam C wrote:
> On 2019-09-12 at 14:23:05 +0000, Harry Wentland wrote:
>> On 2019-09-12 3:47 a.m., Ramalingam C wrote:
>>> On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote:
>>>> Hi all,
>>>>
>>>> This is regarding the recent hdcp content type patch that was merged into 
>>>> drm-misc. 
>>>> (https://patchwork.freedesktop.org/patch/320958/?series=57233=11)
>>>>
>>>> There are displays on the market that advertise HDCP 2.2 support and will 
>>>> pass authentication and encryption but will then show a 
>>>> corrupted/blue/black screen (the driver cannot detect this). These 
>>>> displays work with HDCP 1.4 without any issues. Due to the large number of 
>>>> HDCP-supporting devices on the market we might not be able to catch them 
>>>> with a blacklist.
>>>>
>>>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same 
>>>> thing. Meaning that this interface doesn't allow us to force the hdcp 
>>>> version. Due to the problems mentioned above we might want to expose the 
>>>> ability for a user to force an HDCP downgrade to a certain level (e.g. 
>>>> 1.4) in case they experience problems.
>>>>
>>>> What are your thoughts? and what would be a good way to deal with it?
>>> Hi,
>>>
>>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel
>>> supposed to exercise the highest version of HDCP supported on panel and
>>> platform.
>>>
>>> As we implement the HDCP spec support, if a device is non-compliant with
>>> HDCP spec after completing the HDCP authentication, I dont think we need
>>> to worry about it.
>>>
>>
>> Tell that to our (or your) customers.
>>
>> In this case an enduser might plug in a bad monitor or TV and be unable
>> to play protected content.
>>
>> What if we add a new enum value to the content_type property that says
>> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"?
> "content type" is for defining the stream type. Adding an entry into it
> sounds like polluting it.
> 

For sure

> Separate uAPI for forcing a HDCP version might be need. Or wondering on
> using the sysfs of connector for this dirty job!?
> 

Did a bit more digging...

On other OS we got a monitor quirk for a few displays and also something
similar to a module parameter to force disable HDCP 2.x support.

It looks like there aren't too many quirky receivers so that might be an
acceptable solution. I'm still thinking a connector property might be
useful to force a certain HDCP version but maybe I'm overthinking it.

Harry

> -Ram
>>
>> Harry
>>
>>> In case if you want to track and implement a quirk for it, like not to
>>> project the HDCP2.2 capability, you can use the receiver id of that panel
>>> to track it.
>>>
>>> Thanks,
>>> -Ram
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Bhawan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HDCP Content Type Interface

[Harry Wentland]

On 2019-09-12 10:57 a.m., Jani Nikula wrote:
> On Thu, 12 Sep 2019, Harry Wentland  wrote:
>> On 2019-09-12 3:47 a.m., Ramalingam C wrote:
>>> On 2019-09-09 at 15:54:50 +, Lakha, Bhawanpreet wrote:
>>>> Hi all,
>>>>
>>>> This is regarding the recent hdcp content type patch that was merged into 
>>>> drm-misc. 
>>>> (https://patchwork.freedesktop.org/patch/320958/?series=57233=11)
>>>>
>>>> There are displays on the market that advertise HDCP 2.2 support and will 
>>>> pass authentication and encryption but will then show a 
>>>> corrupted/blue/black screen (the driver cannot detect this). These 
>>>> displays work with HDCP 1.4 without any issues. Due to the large number of 
>>>> HDCP-supporting devices on the market we might not be able to catch them 
>>>> with a blacklist.
>>>>
>>>> From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same 
>>>> thing. Meaning that this interface doesn't allow us to force the hdcp 
>>>> version. Due to the problems mentioned above we might want to expose the 
>>>> ability for a user to force an HDCP downgrade to a certain level (e.g. 
>>>> 1.4) in case they experience problems.
>>>>
>>>> What are your thoughts? and what would be a good way to deal with it?
>>> Hi,
>>>
>>> As you mentioned, uAPI is designed to be HDCP version agnostic. Kernel
>>> supposed to exercise the highest version of HDCP supported on panel and
>>> platform.
>>>
>>> As we implement the HDCP spec support, if a device is non-compliant with
>>> HDCP spec after completing the HDCP authentication, I dont think we need
>>> to worry about it.
>>>
>>
>> Tell that to our (or your) customers.
> 
> Agreed, let's rather not.
> 
>> In this case an enduser might plug in a bad monitor or TV and be unable
>> to play protected content.
>>
>> What if we add a new enum value to the content_type property that says
>> "DRM_MODE_HDCP_CONTENT_TYPE_FORCE_14"?
> 
> In general, I think if the fix is to teach the user to jump through
> hoops in case the output is not working, it is really not a fix.
> 
> Would, say, a set top box or a Blu-ray player have a setting to force
> HDCP 1.4, and a troubleshooting item in the manual to select that if the
> display does not work? Or would OS X have that?
> 

Not sure. AFAIU on other OS we're currently dealing with this through
monitor quirks. We can probably pull the same quirks to DRM.

> If broken HDCP 2.2 sink support is a widespread problem (is it?), what
> do other HDCP sources do? If it's a Linux issue, what are we doing wrong
> or different?

Not a Linux issue and not overly widespread. Looks like a handful of
receivers are problematic.

Harry

> 
> 
> BR,
> Jani.
> 
> 
> 
>>
>> Harry
>>
>>> In case if you want to track and implement a quirk for it, like not to
>>> project the HDCP2.2 capability, you can use the receiver id of that panel
>>> to track it.
>>>
>>> Thanks,
>>> -Ram
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Bhawan
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: include: fix W=1 warnings in struct drm_dsc_config

[Harry Wentland]

+Manasi, Gaurav

On 2019-09-09 9:52 a.m., Benjamin Gaignard wrote:
> Change scale_increment_interval and nfl_bpg_offset fields to
> u32 to avoid W=1 warnings because we are testing them against
> 65535.
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>   include/drm/drm_dsc.h | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> index 887954cbfc60..e495024e901c 100644
> --- a/include/drm/drm_dsc.h
> +++ b/include/drm/drm_dsc.h
> @@ -207,11 +207,13 @@ struct drm_dsc_config {
>* Number of group times between incrementing the scale factor value
>* used at the beginning of a slice.
>*/
> - u16 scale_increment_interval;
> + u32 scale_increment_interval;

The DSC spec defines both as u16. I think the check in drm_dsc.c is 
useless and should be dropped.

Harry

> +
>   /**
>* @nfl_bpg_offset: Non first line BPG offset to be used
>*/
> - u16 nfl_bpg_offset;
> +
> + u32 nfl_bpg_offset;
>   /**
>* @slice_bpg_offset: BPG offset used to enforce slice bit
>*/
> 

Re: [PATCH] drm: fix warnings in DSC

[Harry Wentland]

On 2019-09-11 4:47 a.m., Benjamin Gaignard wrote:
> Remove always false comparisons due to limited range of nfl_bpg_offset
> and scale_increment_interval fields.
> Warnings detected when compiling with W=1.
> 
> Signed-off-by: Benjamin Gaignard 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dsc.c | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 77f4e5ae4197..27e5c6036658 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -336,12 +336,6 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
> *vdsc_cfg)
>   else
>   vdsc_cfg->nfl_bpg_offset = 0;
>  
> - /* 2^16 - 1 */
> - if (vdsc_cfg->nfl_bpg_offset > 65535) {
> - DRM_DEBUG_KMS("NflBpgOffset is too large for this slice 
> height\n");
> - return -ERANGE;
> - }
> -
>   /* Number of groups used to code the entire slice */
>   groups_total = groups_per_line * vdsc_cfg->slice_height;
>  
> @@ -371,11 +365,6 @@ int drm_dsc_compute_rc_parameters(struct drm_dsc_config 
> *vdsc_cfg)
>   vdsc_cfg->scale_increment_interval = 0;
>   }
>  
> - if (vdsc_cfg->scale_increment_interval > 65535) {
> - DRM_DEBUG_KMS("ScaleIncrementInterval is large for slice 
> height\n");
> - return -ERANGE;
> - }
> -
>   /*
>* DSC spec mentions that bits_per_pixel specifies the target
>* bits/pixel (bpp) rate that is used by the encoder,
> 

[PATCH] drm/amd/display: Add number of slices per line to DSC parameter validation

[Harry Wentland]

From: Nikola Cornij 

[why]
Number of slices per line was mistakenly left out

Cc: Hariprasad Kelam 
Signed-off-by: Nikola Cornij 
Signed-off-by: Harry Wentland 
Reviewed-by: Harry Wentland 
---

Thanks, Hariprasad, for your patch. The second condition should actually check
for num_slices_h.

Harry

 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index e870caa8d4fa..adb69c038efb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -302,7 +302,7 @@ static bool dsc_prepare_config(struct 
display_stream_compressor *dsc, const stru
dsc_cfg->dc_dsc_cfg.linebuf_depth == 0)));
ASSERT(96 <= dsc_cfg->dc_dsc_cfg.bits_per_pixel && 
dsc_cfg->dc_dsc_cfg.bits_per_pixel <= 0x3ff); // 6.0 <= bits_per_pixel <= 
63.9375
 
-   if (!dsc_cfg->dc_dsc_cfg.num_slices_v || 
!dsc_cfg->dc_dsc_cfg.num_slices_v ||
+   if (!dsc_cfg->dc_dsc_cfg.num_slices_v || 
!dsc_cfg->dc_dsc_cfg.num_slices_h ||
!(dsc_cfg->dc_dsc_cfg.version_minor == 1 || 
dsc_cfg->dc_dsc_cfg.version_minor == 2) ||
!dsc_cfg->pic_width || !dsc_cfg->pic_height ||
!((dsc_cfg->dc_dsc_cfg.version_minor == 1 && // v1.1 line 
buffer depth range:
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: hide an unused variable

[Harry Wentland]

On 2019-09-18 3:53 p.m., Arnd Bergmann wrote:
> Without CONFIG_DEBUG_FS, we get a warning for an unused
> variable:
> 
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6020:33: error: 
> unused variable 'source' [-Werror,-Wunused-variable]
> 
> Hide the variable in an #ifdef like its only users.
> 
> Fixes: 14b2584636c6 ("drm/amd/display: add functionality to grab DPRX CRC 
> entries.")
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e1b09bb432bd..74252f57bafb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6017,7 +6017,9 @@ static void amdgpu_dm_enable_crtc_interrupts(struct 
> drm_device *dev,
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   int i;
> +#ifdef CONFIG_DEBUG_FS
>   enum amdgpu_dm_pipe_crc_source source;
> +#endif
>  
>   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm/amdgpu/dm/mst: Don't create MST topology managers for eDP ports

[Harry Wentland]

On 2019-09-26 6:51 p.m., Lyude Paul wrote:
> Signed-off-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 5ec14efd4d8c..185bf0e2bda2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -417,6 +417,10 @@ void amdgpu_dm_initialize_dp_connector(struct 
> amdgpu_display_manager *dm,
>   drm_dp_aux_register(>dm_dp_aux.aux);
>   drm_dp_cec_register_connector(>dm_dp_aux.aux,
> >base);
> +
> + if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
> + return;
> +
>   aconnector->mst_mgr.cbs = _mst_cbs;
>   drm_dp_mst_topology_mgr_init(
>   >mst_mgr,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/6] drm/amdgpu/dm/mst: Use ->atomic_best_encoder

[Harry Wentland]

On 2019-09-26 6:51 p.m., Lyude Paul wrote:
> We are supposed to be atomic after all. We'll need this in a moment for
> the next commit.
> 
> Signed-off-by: Lyude Paul 

Reviewed-by: Harry Wentland 

Harry

> ---
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index a398ddd1f306..d9113ce0be09 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -243,17 +243,17 @@ static int dm_dp_mst_get_modes(struct drm_connector 
> *connector)
>   return ret;
>  }
>  
> -static struct drm_encoder *dm_mst_best_encoder(struct drm_connector 
> *connector)
> +static struct drm_encoder *
> +dm_mst_atomic_best_encoder(struct drm_connector *connector,
> +struct drm_connector_state *connector_state)
>  {
> - struct amdgpu_dm_connector *amdgpu_dm_connector = 
> to_amdgpu_dm_connector(connector);
> -
> - return _dm_connector->mst_encoder->base;
> + return _amdgpu_dm_connector(connector)->mst_encoder->base;
>  }
>  
>  static const struct drm_connector_helper_funcs 
> dm_dp_mst_connector_helper_funcs = {
>   .get_modes = dm_dp_mst_get_modes,
>   .mode_valid = amdgpu_dm_connector_mode_valid,
> - .best_encoder = dm_mst_best_encoder,
> + .atomic_best_encoder = dm_mst_atomic_best_encoder,
>  };
>  
>  static void amdgpu_dm_encoder_destroy(struct drm_encoder *encoder)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Harry Wentland]

On 2019-11-04 5:53 a.m., Daniel Vetter wrote:
> On Wed, Oct 9, 2019 at 10:58 PM Daniel Vetter  wrote:
>> On Wed, Oct 9, 2019 at 10:46 PM Lakha, Bhawanpreet
>>  wrote:
>>>
>>> I misunderstood and was talking about the ksv validation specifically
>>> (usage of drm_hdcp_check_ksvs_revoked()).
>>
>> Hm for that specifically I think you want to do both, i.e. both
>> consult your psp, but also check for revoked ksvs with the core
>> helper. At least on some platforms only the core helper might have the
>> updated revoke list.
>>

I think it's an either/or. Either we use an HDCP implementation that's
fully running in x86 kernel space (still not sure how that's compliant)
or we fully rely on our PSP FW to do what it's designed to do. I don't
think it makes sense to mix and match here.

>>> For the defines I will create patches to use drm_hdcp where it is usable.
>>
>> Thanks a lot. Ime once we have shared definitions it's much easier to
>> also share some helpers, where it makes sense.
>>
>> Aside I think the hdcp code could also use a bit of demidlayering. At
>> least I'm not understanding why you add a 2nd abstraction layer for
>> i2c/dpcd, dm_helper already has that. That seems like one abstraction
>> layer too much.
> 
> I haven't seen anything fly by or in the latest pull request ... you
> folks still working on this or more put on the "maybe, probably never"
> pile?
> 

Following up with Bhawan.

Harry

> -Daniel
> 
> 
>> -Daniel
>>
>>>
>>>
>>> Bhawan
>>>
>>> On 2019-10-09 2:43 p.m., Daniel Vetter wrote:
 On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
  wrote:
> Hi,
>
> The reason we don't use drm_hdcp is because our policy is to do hdcp
> verification using PSP/HW (onboard secure processor).
 i915 also uses hw to auth, we still use the parts from drm_hdcp ...
 Did you actually look at what's in there? It's essentially just shared
 defines and data structures from the standard, plus a few minimal
 helpers to en/decode some bits. Just from a quick read the entire
 patch very much looks like midlayer everywhere design that we
 discussed back when DC landed ...
 -Daniel

> Bhawan
>
> On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
>> On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
>>> Hi,
>>>
>>> Static analysis with Coverity has detected a potential issue with
>>> function validate_bksv in
>>> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
>>> commit:
>>>
>>> commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
>>> Author: Bhawanpreet Lakha 
>>> Date:   Tue Aug 6 17:52:01 2019 -0400
>>>
>>>   drm/amd/display: Add HDCP module
>> I think the real question here is ... why is this not using drm_hdcp?
>> -Daniel
>>
>>> The analysis is as follows:
>>>
>>>28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp 
>>> *hdcp)
>>>29 {
>>>
>>> CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
>>>
>>> 1. overrun-local:
>>> Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
>>> (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
>>>
>>>30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
>>>31uint8_t count = 0;
>>>32
>>>33while (n) {
>>>34count++;
>>>35n &= (n - 1);
>>>36}
>>>
>>> hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
>>> drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
>>>
>>> struct mod_hdcp_message_hdcp1 {
>>>   uint8_t an[8];
>>>   uint8_t aksv[5];
>>>   uint8_t ainfo;
>>>   uint8_t bksv[5];
>>>   uint16_tr0p;
>>>   uint8_t bcaps;
>>>   uint16_tbstatus;
>>>   uint8_t ksvlist[635];
>>>   uint16_tksvlist_size;
>>>   uint8_t vp[20];
>>>
>>>   uint16_tbinfo_dp;
>>> };
>>>
>>> variable n is going to contain the contains of r0p and bcaps. I'm not
>>> sure if that is intentional. If not, then the count is going to be
>>> incorrect if these are non-zero.
>>>
>>> Colin
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


>>
>>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 
> 
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm: Add support for DP 1.4 Compliance edid corruption test 4.2.2.6

[Harry Wentland]

On 2019-11-01 3:38 p.m., Jerry (Fangzhi) Zuo wrote:
> DP 1.4 edid corruption test requires source DUT to write calculated
> CRC, not the corrupted CRC from reference sink.
> 
> Return the calculated CRC back, and initiate the required sequence.
> 
> -v2: Have separate routine for returning real CRC
> 
> Signed-off-by: Jerry (Fangzhi) Zuo 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 36 
>  drivers/gpu/drm/drm_edid.c  | 14 ++
>  include/drm/drm_connector.h |  7 +++
>  include/drm/drm_dp_helper.h |  3 +++
>  4 files changed, 60 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index ffc68d305afe..75dbd30c62a7 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -336,6 +336,42 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +/**
> +  * drm_dp_send_bad_edid_checksum() - send back real edid checksum value
> +  * @aux: DisplayPort AUX channel
> +  * @bad_edid_checksum: real edid checksum for the last block
> +  *
> +  * Returns true on success
> +  */
> +bool drm_dp_send_bad_edid_checksum(struct drm_dp_aux *aux,
> +u8 bad_edid_checksum)
> +{
> +u8 link_edid_read = 0, auto_test_req = 0;
> +u8 test_resp = 0;
> +
> +drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 
> 1);
> +auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
> +
> +drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1);
> +link_edid_read &= DP_TEST_LINK_EDID_READ;
> +
> +if (!auto_test_req || !link_edid_read) {
> +DRM_DEBUG_KMS("Source DUT does not support 
> TEST_EDID_READ\n");
> +return false;
> +}
> +
> +drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 
> 1);
> +
> +/* send back checksum for the last edid extension block data */
> +drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM, _edid_checksum, 1);
> +
> +test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
> +drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1);
> +
> +return true;
> +}
> +EXPORT_SYMBOL(drm_dp_send_bad_edid_checksum);
> +
>  /**
>   * drm_dp_link_probe() - probe a DisplayPort link for capabilities
>   * @aux: DisplayPort AUX channel
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 82a4ceed3fcf..0598314e3f46 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1354,6 +1354,17 @@ static int drm_edid_block_checksum(const u8 *raw_edid)
>   return csum;
>  }
>  
> +static int drm_edid_block_real_checksum(const u8 *raw_edid)
> +{
> + int i;
> + u8 csum = 0;
> +
> + for (i = 0; i < EDID_LENGTH - 1; i++)
> + csum += raw_edid[i];
> +
> + return (0x100 - csum);
> +}
> +
>  static bool drm_edid_is_zero(const u8 *in_edid, int length)
>  {
>   if (memchr_inv(in_edid, 0, length))
> @@ -1572,6 +1583,9 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>  prefix, DUMP_PREFIX_NONE, 16, 1,
>  block, EDID_LENGTH, false);
>   }
> +
> + /* Calculate real checksum for the last edid extension block data */
> + connector->bad_edid_checksum = drm_edid_block_real_checksum(edid + 
> edid[0x7e] * EDID_LENGTH);
>  }
>  
>  /* Get override or firmware EDID */
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 681cb590f952..8442461542b9 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1345,6 +1345,13 @@ struct drm_connector {
>* rev1.1 4.2.2.6
>*/
>   bool edid_corrupt;
> + /**
> + * @bad_edid_checksum: real edid checksum value for corrupted edid 
> block.
> + * Required in Displayport 1.4 compliance testing
> + * rev1.1 4.2.2.6
> + */
> +uint8_t bad_edid_checksum;


This variable name confused me a bit. Maybe name this
"computed_edid_checksum" to clarify that this is the EDID checksum that
we've computed for the EDID, i.e. the correct one.

> +
>  
>   /** @debugfs_entry: debugfs directory for this connector */
>   struct dentry *debugfs_entry;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 5a795075d5da..2a7e54bebb18 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1383,6 +1383,9 @@ static inline ssize_t drm_dp_dpcd_writeb(struct 
> drm_dp_aux *aux,
>  int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>u8 status[DP_LINK_STATUS_SIZE]);
>  
> +bool drm_dp_send_bad_edid_checksum(struct drm_dp_aux *aux,

Same as before, might be good to name this
drm_dp_send_computed_edid_checksum or something similar.

Harry

> + u8 bad_edid_checksum);
> +
>  /*
>   * DisplayPort 

Re: [PATCH] drm/amd/display: remove redundant null pointer check before kfree

[Harry Wentland]

On 2019-10-29 9:57 p.m., zhong jiang wrote:
> kfree has taken null pointer into account. hence it is safe to remove
> the unnecessary check.
> 
> Signed-off-by: zhong jiang 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c 
> b/drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c
> index cf6ef38..6f730b5 100644
> --- a/drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c
> +++ b/drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c
> @@ -174,9 +174,7 @@ static bool hdmi_14_process_transaction(
>   link->ctx,
>   link,
>   _command);
> -
> - if (buff)
> - kfree(buff);
> + kfree(buff);
>  
>   return result;
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] drm/amd/display: remove some set but not used variables

[Harry Wentland]

On 2019-11-14 7:36 a.m., zhengbin wrote:
> zhengbin (4):
>   drm/amd/display: remove set but not used variable 'old_plane_crtc'
>   drm/amd/display: remove set but not used variable 'bp' in
> bios_parser2.c
>   drm/amd/display: remove set but not used variable 'bp' in
> bios_parser.c
>   drm/amd/display: remove set but not used variable 'min_content'
> 

These would be fine as a single patch as well but I don't have a strong
preference either way.

Patches are:
Reviewed-by: Harry Wentland 

Harry

>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 3 +--
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser.c   | 2 --
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c  | 2 --
>  drivers/gpu/drm/amd/display/modules/color/color_gamma.c | 2 --
>  4 files changed, 1 insertion(+), 8 deletions(-)
> 
> --
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

On 2019-11-14 3:44 p.m., Chris Wilson wrote:
> An old display with no audio may not have an EDID with a CEA block, or
> it may simply be too old to support audio. This is not a driver error,
> so don't flag it as such.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112140
> 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_helpers.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 11e5784aa62a..04808dbecab3 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -97,8 +97,6 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
>   (struct edid *) edid->raw_edid);
>  
>   sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> - if (sad_count < 0)
> - DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
>   if (sad_count <= 0)
>   return result;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] drm/amd/display: Fix old-style declaration

[Harry Wentland]

On 2019-11-11 7:28 a.m., YueHaibing wrote:
> Fix a build warning:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
>  warning: 'static' is not at beginning of declaration 
> [-Wold-style-declaration]
> 
> Signed-off-by: YueHaibing 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 1fdba13..0d8c663 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -69,7 +69,7 @@
>  #define DC_LOGGER \
>   dc->ctx->logger
>  
> -const static char DC_BUILD_ID[] = "production-build";
> +static const char DC_BUILD_ID[] = "production-build";
>  
>  /**
>   * DOC: Overview
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] drm/amd/display: Fix old-style declaration

[Harry Wentland]

On 2019-11-12 2:51 a.m., Yuehaibing wrote:
> On 2019/11/12 10:39, Joe Perches wrote:
>> On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
>>> Fix a build warning:
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
>>>  warning: 'static' is not at beginning of declaration 
>>> [-Wold-style-declaration]
>> []
>>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
>>> b/drivers/gpu/drm/amd/display/dc/core/dc.c
>> []
>>> @@ -69,7 +69,7 @@
>>>  #define DC_LOGGER \
>>> dc->ctx->logger
>>>  
>>> -const static char DC_BUILD_ID[] = "production-build";
>>> +static const char DC_BUILD_ID[] = "production-build";
>>
>> DC_BUILD_ID is used exactly once.
>> Maybe just use it directly and remove DC_BUILD_ID instead?
> 
> commit be61df574256ae8c0dbd45ac148ca7260a0483c0
> Author: Jun Lei 
> Date:   Thu Sep 13 09:32:26 2018 -0400
> 
> drm/amd/display: Add DC build_id to determine build type
> 
> [why]
> Sometimes there are indications that the incorrect driver is being
> loaded in automated tests. This change adds the ability for builds to
> be tagged with a string, and picked up by the test infrastructure.
> 
> [how]
> dc.c will allocate const for build id, which is init-ed with default
> value, indicating production build. For test builds, build server will
> find/replace this value. The test machine will then verify this value.
> 
> It seems DC_BUILD_ID is used by the build server, so maybe we should keep it.

Thanks, Haibing. Yes, we'll want to keep it for build purposes.

Harry

> 
>>
>> ---
>>  drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
>> b/drivers/gpu/drm/amd/display/dc/core/dc.c
>> index 1fdba13..803dc14 100644
>> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
>> @@ -69,8 +69,6 @@
>>  #define DC_LOGGER \
>>  dc->ctx->logger
>>  
>> -const static char DC_BUILD_ID[] = "production-build";
>> -
>>  /**
>>   * DOC: Overview
>>   *
>> @@ -815,7 +813,7 @@ struct dc *dc_create(const struct dc_init_data 
>> *init_params)
>>  if (dc->res_pool->dmcu != NULL)
>>  dc->versions.dmcu_version = dc->res_pool->dmcu->dmcu_version;
>>  
>> -dc->build_id = DC_BUILD_ID;
>> +dc->build_id = "production-build";
>>  
>>  DC_LOG_DC("Display Core initialized\n");
>>  
>>
>>
>>
>> .
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Harry Wentland]

On 2019-11-05 9:23 a.m., Daniel Vetter wrote:
> On Tue, Nov 5, 2019 at 3:17 PM Harry Wentland  wrote:
>>
>>
>>
>> On 2019-11-05 8:14 a.m., Daniel Vetter wrote:
>>> On Tue, Nov 5, 2019 at 1:52 PM Alex Deucher  wrote:
>>>>
>>>> On Mon, Nov 4, 2019 at 12:24 PM Daniel Vetter  wrote:
>>>>>
>>>>> On Mon, Nov 04, 2019 at 12:05:40PM -0500, Alex Deucher wrote:
>>>>>> On Mon, Nov 4, 2019 at 11:55 AM Daniel Vetter  wrote:
>>>>>>>
>>>>>>> On Mon, Nov 04, 2019 at 03:23:09PM +, Harry Wentland wrote:
>>>>>>>> On 2019-11-04 5:53 a.m., Daniel Vetter wrote:
>>>>>>>>> On Wed, Oct 9, 2019 at 10:58 PM Daniel Vetter  wrote:
>>>>>>>>>> On Wed, Oct 9, 2019 at 10:46 PM Lakha, Bhawanpreet
>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>> I misunderstood and was talking about the ksv validation 
>>>>>>>>>>> specifically
>>>>>>>>>>> (usage of drm_hdcp_check_ksvs_revoked()).
>>>>>>>>>>
>>>>>>>>>> Hm for that specifically I think you want to do both, i.e. both
>>>>>>>>>> consult your psp, but also check for revoked ksvs with the core
>>>>>>>>>> helper. At least on some platforms only the core helper might have 
>>>>>>>>>> the
>>>>>>>>>> updated revoke list.
>>>>>>>>>>
>>>>>>>>
>>>>>>>> I think it's an either/or. Either we use an HDCP implementation that's
>>>>>>>> fully running in x86 kernel space (still not sure how that's compliant)
>>>>>>>> or we fully rely on our PSP FW to do what it's designed to do. I don't
>>>>>>>> think it makes sense to mix and match here.
>>>>>>>
>>>>>>> Then you need to somehow tie the revoke list that's in the psp to the
>>>>>>> revoke list update logic we have. That's what we've done for hdcp2 
>>>>>>> (which
>>>>>>> is similarly to yours implemented in hw). The point is that on linux we
>>>>>>> now have a standard way to get these revoke lists updated/handled.
>>>>>>>
>>>>>>> I guess it wasn't clear how exactly I think you're supposed to combine
>>>>>>> them?
>>>>>>
>>>>>> There's no driver sw required at all for our implementation and as far
>>>>>> as I know, HDCP 2.x requires that all of the key revoke handling be
>>>>>> handled in a secure processor rather than than on the host processor,
>>>>>> so I'm not sure how we make use if it.  All the driver sw is
>>>>>> responsible for doing is saving/restoring the potentially updated srm
>>>>>> at suspend/resume/etc.
>>>>>
>>>>> Uh, you don't have a permanent store on the chip? I thought another
>>>>> requirement is that you can't downgrade.
>>>>
>>>> Right.  That's why the driver has to save and restore the srm when the
>>>> GPU is powered down.  I guess that part can be done by the host
>>>> processor as long as the srm is signed properly.
>>>>
>>>>>
>>>>> And for hw solutions all you do with the updated revoke cert is stuff it
>>>>> into the hw, it's purely for updating it. And those updates need to come
>>>>> from somewhere else (usually in the media you play), the kernel can't
>>>>> fetch them over the internet itself. I thought we already had the function
>>>>> to give you the srm directly so you can stuff it into the hw, but looks
>>>>> like that part isn't there (yet).
>>>>
>>>> IIRC, the revoke stuff gets gleaned from the stream by the secure
>>>> processor somehow when you play back secure content.  I'm not entirely
>>>> clear on the details, but from the design, the driver doesn't have to
>>>> do anything in our case other than saving and restoring the srm from
>>>> the secure processor.
>>>
>>> Hm, is that implemented in open userspace somewhere? tbh I don't know
>>> whether the srm is in the bitstream or somewhere else in the file
>>> (they're all containers with lots of stuff), but the current upstream
>>&g

Re: drm/amd/display: Add HDCP module - static analysis bug report

[Harry Wentland]

On 2019-11-05 8:14 a.m., Daniel Vetter wrote:
> On Tue, Nov 5, 2019 at 1:52 PM Alex Deucher  wrote:
>>
>> On Mon, Nov 4, 2019 at 12:24 PM Daniel Vetter  wrote:
>>>
>>> On Mon, Nov 04, 2019 at 12:05:40PM -0500, Alex Deucher wrote:
>>>> On Mon, Nov 4, 2019 at 11:55 AM Daniel Vetter  wrote:
>>>>>
>>>>> On Mon, Nov 04, 2019 at 03:23:09PM +, Harry Wentland wrote:
>>>>>> On 2019-11-04 5:53 a.m., Daniel Vetter wrote:
>>>>>>> On Wed, Oct 9, 2019 at 10:58 PM Daniel Vetter  wrote:
>>>>>>>> On Wed, Oct 9, 2019 at 10:46 PM Lakha, Bhawanpreet
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> I misunderstood and was talking about the ksv validation specifically
>>>>>>>>> (usage of drm_hdcp_check_ksvs_revoked()).
>>>>>>>>
>>>>>>>> Hm for that specifically I think you want to do both, i.e. both
>>>>>>>> consult your psp, but also check for revoked ksvs with the core
>>>>>>>> helper. At least on some platforms only the core helper might have the
>>>>>>>> updated revoke list.
>>>>>>>>
>>>>>>
>>>>>> I think it's an either/or. Either we use an HDCP implementation that's
>>>>>> fully running in x86 kernel space (still not sure how that's compliant)
>>>>>> or we fully rely on our PSP FW to do what it's designed to do. I don't
>>>>>> think it makes sense to mix and match here.
>>>>>
>>>>> Then you need to somehow tie the revoke list that's in the psp to the
>>>>> revoke list update logic we have. That's what we've done for hdcp2 (which
>>>>> is similarly to yours implemented in hw). The point is that on linux we
>>>>> now have a standard way to get these revoke lists updated/handled.
>>>>>
>>>>> I guess it wasn't clear how exactly I think you're supposed to combine
>>>>> them?
>>>>
>>>> There's no driver sw required at all for our implementation and as far
>>>> as I know, HDCP 2.x requires that all of the key revoke handling be
>>>> handled in a secure processor rather than than on the host processor,
>>>> so I'm not sure how we make use if it.  All the driver sw is
>>>> responsible for doing is saving/restoring the potentially updated srm
>>>> at suspend/resume/etc.
>>>
>>> Uh, you don't have a permanent store on the chip? I thought another
>>> requirement is that you can't downgrade.
>>
>> Right.  That's why the driver has to save and restore the srm when the
>> GPU is powered down.  I guess that part can be done by the host
>> processor as long as the srm is signed properly.
>>
>>>
>>> And for hw solutions all you do with the updated revoke cert is stuff it
>>> into the hw, it's purely for updating it. And those updates need to come
>>> from somewhere else (usually in the media you play), the kernel can't
>>> fetch them over the internet itself. I thought we already had the function
>>> to give you the srm directly so you can stuff it into the hw, but looks
>>> like that part isn't there (yet).
>>
>> IIRC, the revoke stuff gets gleaned from the stream by the secure
>> processor somehow when you play back secure content.  I'm not entirely
>> clear on the details, but from the design, the driver doesn't have to
>> do anything in our case other than saving and restoring the srm from
>> the secure processor.
> 
> Hm, is that implemented in open userspace somewhere? tbh I don't know
> whether the srm is in the bitstream or somewhere else in the file
> (they're all containers with lots of stuff), but the current upstream
> hdcp stuff is done under the assumption that userspace still does the
> decrypting (so only the lowest content protection level supported
> right now). Hence the explicit step to update the kernel on the latest
> srm, which the kernel can then use to either check for revokes or hand
> to the hardware.
> -Daniel
> 

Not sure I follow your questions about whether this is implemented in
open userspace.

The SRM is provided to PSP (our secure processor) through other
interfaces. I'm currently not sure whether that's directly from the
bitstream or another interface from the secure userspace that's handling
content protection (e.g. OEMCrypto or similar).

The key for HDCP SRM handling is that PSP doesn't have a permanent store
on the chip and needs us to handle the save a

Re: [PATCH v8 12/17] drm/dp_mst: Add branch bandwidth validation to MST atomic check

[Harry Wentland]

On 2019-12-03 9:35 a.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski 
> 
> Adding PBN attribute to drm_dp_vcpi_allocation structure to
> keep track of how much bandwidth each Port requires.
> Adding drm_dp_mst_atomic_check_bw_limit to verify that
> state's bandwidth needs doesn't exceed available bandwidth.
> The funtion is called in drm_dp_mst_atomic_check after
> drm_dp_mst_atomic_check_topology_state to fully verify that
> the proposed topology is supported.
> 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Lyude Paul 
> Signed-off-by: Mikita Lipski 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 67 ++-
>  include/drm/drm_dp_mst_helper.h   |  1 +
>  2 files changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 5e549f48ffb8..76bcbb4cd8b4 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4052,7 +4052,7 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>  {
>   struct drm_dp_mst_topology_state *topology_state;
>   struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
> - int prev_slots, req_slots;
> + int prev_slots, prev_bw, req_slots, ret;
>  

'ret' is unused here.

Harry

>   topology_state = drm_atomic_get_mst_topology_state(state, mgr);
>   if (IS_ERR(topology_state))
> @@ -4063,6 +4063,7 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   if (pos->port == port) {
>   vcpi = pos;
>   prev_slots = vcpi->vcpi;
> + prev_bw = vcpi->pbn;
>  
>   /*
>* This should never happen, unless the driver tries
> @@ -4078,8 +4079,10 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   break;
>   }
>   }
> - if (!vcpi)
> + if (!vcpi) {
>   prev_slots = 0;
> + prev_bw = 0;
> + }
>  
>   if (pbn_div <= 0)
>   pbn_div = mgr->pbn_div;
> @@ -4089,6 +4092,9 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] [MST PORT:%p] VCPI %d -> %d\n",
>port->connector->base.id, port->connector->name,
>port, prev_slots, req_slots);
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] [MST PORT:%p] PBN %d -> %d\n",
> +  port->connector->base.id, port->connector->name,
> +  port, prev_bw, pbn);
>  
>   /* Add the new allocation to the state */
>   if (!vcpi) {
> @@ -4101,6 +4107,7 @@ int drm_dp_atomic_find_vcpi_slots(struct 
> drm_atomic_state *state,
>   list_add(>next, _state->vcpis);
>   }
>   vcpi->vcpi = req_slots;
> + vcpi->pbn = pbn;
>  
>   return req_slots;
>  }
> @@ -4703,6 +4710,59 @@ static void drm_dp_mst_destroy_state(struct 
> drm_private_obj *obj,
>   kfree(mst_state);
>  }
>  
> +static bool drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port 
> *port,
> +  struct drm_dp_mst_branch 
> *branch)
> +{
> + while (port->parent) {
> + if (port->parent == branch)
> + return true;
> +
> + if (port->parent->port_parent)
> + port = port->parent->port_parent;
> + else
> + break;
> + }
> + return false;
> +}
> +
> +static inline
> +int drm_dp_mst_atomic_check_bw_limit(struct drm_dp_mst_branch *branch,
> +  struct drm_dp_mst_topology_state 
> *mst_state)
> +{
> + struct drm_dp_mst_port *port;
> + struct drm_dp_vcpi_allocation *vcpi;
> + int pbn_limit = 0, pbn_used = 0;
> +
> + list_for_each_entry(port, >ports, next) {
> + if (port->mstb) {
> + if (drm_dp_mst_atomic_check_bw_limit(port->mstb, 
> mst_state))
> + return -EINVAL;
> + }
> + if (port->available_pbn > 0)
> + pbn_limit = port->available_pbn;
> + }
> + DRM_DEBUG_ATOMIC("[MST BRANCH:%p] branch has %d PBN available\n",
> +  branch,
> +  pbn_limit);
> +
> + list_for_each_entry(vcpi, _state->vcpis, next) {
> + if (!vcpi->pb

Re: [PATCH v8 04/17] drm/dp_mst: Fill branch->num_ports

[Harry Wentland]

On 2019-12-03 9:35 a.m., mikita.lip...@amd.com wrote:
> From: David Francis 
> 
> This field on drm_dp_mst_branch was never filled
> 
> It is initialized to zero when the port is kzallocced.
> When a port is added to the list, increment num_ports,
> and when a port is removed from the list, decrement num_ports.
> 
> v2: remember to decrement on port removal
> v3: don't explicitly init to 0
> 
> Reviewed-by: Lyude Paul 
> Reviewed-by: Harry Wentland 
> Signed-off-by: David Francis 
> Signed-off-by: Mikita Lipski 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 06aae9b52e8a..d74b767d0fe1 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2129,6 +2129,7 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch 
> *mstb,
>   build_mst_prop_path(mstb, port->port_num, proppath, sizeof(proppath));
>   port->connector = mgr->cbs->add_connector(mgr, port, proppath);
>   if (!port->connector) {
> + mstb->num_ports--;
>   ret = -ENOMEM;
>   goto error;
>   }
> @@ -2256,6 +2257,7 @@ drm_dp_mst_handle_link_address_port(struct 
> drm_dp_mst_branch *mstb,
>   mutex_lock(>lock);
>   drm_dp_mst_topology_get_port(port);
>   list_add(>next, >ports);
> + mstb->num_ports++;
>   mutex_unlock(>lock);
>   }
>  

Did you drop the num_ports-- when we do list_del() by accident?

See https://patchwork.freedesktop.org/patch/325600/

Harry

> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: add dp helper to initialize remote aux channel.

[Harry Wentland]

On 2019-12-05 11:55 a.m., David (Dingchen) Zhang wrote:
> [why]
> We need to minimally initialize the remote aux channel, e.g. the
> crc work struct of remote aux to dump the sink's DPRX CRCs in MST
> setup.
> 
> [how]
> Add helper that only initializes the crc work struct of the remote
> aux, hooke crc work queue to 'drm_dp_aux_crc_work'. Then call this
> helper in DP MST port initialization.
> 
> 
> Cc: Leo Li 
> Cc: Harry Wentland 
> Signed-off-by: David (Dingchen) Zhang 
> ---
>  drivers/gpu/drm/drm_dp_helper.c   | 13 +
>  drivers/gpu/drm/drm_dp_mst_topology.c |  3 +++
>  include/drm/drm_dp_helper.h   |  1 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index fc39323e7d52..37312593dd0a 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1091,6 +1091,19 @@ static void drm_dp_aux_crc_work(struct work_struct 
> *work)
>   }
>  }
>  
> +/**
> + * drm_dp_remote_aux_init() - minimally initialise a remote aux channel
> + * @aux: DisplayPort AUX channel
> + *
> + * Used for remote aux channel in general. Merely initialize the crc work
> + * struct.
> + */
> +void drm_dp_remote_aux_init(struct drm_dp_aux *aux)
> +{
> + INIT_WORK(>crc_work, drm_dp_aux_crc_work);
> +}
> +EXPORT_SYMBOL(drm_dp_remote_aux_init);
> +
>  /**
>   * drm_dp_aux_init() - minimally initialise an aux channel
>   * @aux: DisplayPort AUX channel
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index d5df02315e14..4308316fe211 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1642,6 +1642,9 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
> *mstb,

This function is gone in amd-staging-drm-next.

Please send a v2 of this patch based on amd-staging-drm-next of agd5f's
repo from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next

Harry

>   port->aux.dev = dev->dev;
>   port->aux.is_remote = true;
>  
> + /* initialize the MST downstream port's AUX crc work queue */
> + drm_dp_remote_aux_init(>aux);
> +
>   /*
>* Make sure the memory allocation for our parent branch stays
>* around until our own memory allocation is released
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 61ef351c5fca..da0a69f10e38 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1403,6 +1403,7 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char 
> id[6]);
>  void drm_dp_downstream_debug(struct seq_file *m, const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>const u8 port_cap[4], struct drm_dp_aux *aux);
>  
> +void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
>  void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: add dp helper to initialize remote aux channel.

[Harry Wentland]

On 2019-12-06 10:30 a.m., Harry Wentland wrote:
> On 2019-12-05 11:55 a.m., David (Dingchen) Zhang wrote:
>> [why]
>> We need to minimally initialize the remote aux channel, e.g. the
>> crc work struct of remote aux to dump the sink's DPRX CRCs in MST
>> setup.
>>
>> [how]
>> Add helper that only initializes the crc work struct of the remote
>> aux, hooke crc work queue to 'drm_dp_aux_crc_work'. Then call this
>> helper in DP MST port initialization.
>>
>>
>> Cc: Leo Li 
>> Cc: Harry Wentland 
>> Signed-off-by: David (Dingchen) Zhang 
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c   | 13 +
>>  drivers/gpu/drm/drm_dp_mst_topology.c |  3 +++
>>  include/drm/drm_dp_helper.h   |  1 +
>>  3 files changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index fc39323e7d52..37312593dd0a 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -1091,6 +1091,19 @@ static void drm_dp_aux_crc_work(struct work_struct 
>> *work)
>>  }
>>  }
>>  
>> +/**
>> + * drm_dp_remote_aux_init() - minimally initialise a remote aux channel
>> + * @aux: DisplayPort AUX channel
>> + *
>> + * Used for remote aux channel in general. Merely initialize the crc work
>> + * struct.
>> + */
>> +void drm_dp_remote_aux_init(struct drm_dp_aux *aux)
>> +{
>> +INIT_WORK(>crc_work, drm_dp_aux_crc_work);
>> +}
>> +EXPORT_SYMBOL(drm_dp_remote_aux_init);
>> +
>>  /**
>>   * drm_dp_aux_init() - minimally initialise an aux channel
>>   * @aux: DisplayPort AUX channel
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index d5df02315e14..4308316fe211 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1642,6 +1642,9 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
>> *mstb,
> 
> This function is gone in amd-staging-drm-next.
> 
> Please send a v2 of this patch based on amd-staging-drm-next of agd5f's
> repo from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next
> 

My bad. This should be the drm-misc-next branch on

https://cgit.freedesktop.org/drm/drm-misc

Harry

> Harry
> 
>>  port->aux.dev = dev->dev;
>>  port->aux.is_remote = true;
>>  
>> +/* initialize the MST downstream port's AUX crc work queue */
>> +drm_dp_remote_aux_init(>aux);
>> +
>>  /*
>>   * Make sure the memory allocation for our parent branch stays
>>   * around until our own memory allocation is released
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 61ef351c5fca..da0a69f10e38 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -1403,6 +1403,7 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char 
>> id[6]);
>>  void drm_dp_downstream_debug(struct seq_file *m, const u8 
>> dpcd[DP_RECEIVER_CAP_SIZE],
>>   const u8 port_cap[4], struct drm_dp_aux *aux);
>>  
>> +void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
>>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>>  int drm_dp_aux_register(struct drm_dp_aux *aux);
>>  void drm_dp_aux_unregister(struct drm_dp_aux *aux);
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Remove unneeded semicolon

[Harry Wentland]

On 2019-12-14 4:12 a.m., zhengbin wrote:
> Fixes coccicheck warning:
> 
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c:412:90-91: Unneeded 
> semicolon
> 
> Reported-by: Hulk Robot 
> Signed-off-by: zhengbin 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c 
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> index de51ef1..a1b7e76 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
> @@ -409,7 +409,7 @@ void build_watermark_ranges(struct clk_bw_params 
> *bw_params, struct pp_smu_wm_ra
>   continue;
> 
>   ranges->reader_wm_sets[num_valid_sets].wm_inst = 
> bw_params->wm_table.entries[i].wm_inst;
> - ranges->reader_wm_sets[num_valid_sets].wm_type = 
> bw_params->wm_table.entries[i].wm_type;;
> + ranges->reader_wm_sets[num_valid_sets].wm_type = 
> bw_params->wm_table.entries[i].wm_type;
>   /* We will not select WM based on dcfclk, so leave it as 
> unconstrained */
>   ranges->reader_wm_sets[num_valid_sets].min_drain_clk_mhz = 
> PP_SMU_WM_SET_RANGE_CLK_UNCONSTRAINED_MIN;
>   ranges->reader_wm_sets[num_valid_sets].max_drain_clk_mhz = 
> PP_SMU_WM_SET_RANGE_CLK_UNCONSTRAINED_MAX;
> --
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: add dp helper to initialize remote aux channel.

[Harry Wentland]

On 2019-12-06 5:56 p.m., David (Dingchen) Zhang wrote:
> [why]
> We need to minimally initialize the remote aux channel, e.g. the
> crc work struct of remote aux to dump the sink's DPRX CRCs in MST
> setup.
> 
> [how]
> Add helper that only initializes the crc work struct of the remote
> aux, hooke crc work queue to 'drm_dp_aux_crc_work'. Then call this
> helper in DP MST port initialization.
> This, plus David Francis' patch [1], fix the issue of MST remote
> aux DPCD CRCs read.
> 
> [1] https://patchwork.kernel.org/patch/11217941/
> 
> Cc: Leo Li 
> Cc: Harry Wentland 
> Signed-off-by: David (Dingchen) Zhang 

Patch is
Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_dp_helper.c   | 13 +
>  drivers/gpu/drm/drm_dp_mst_topology.c |  3 +++
>  include/drm/drm_dp_helper.h   |  1 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2c7870aef469..cc4845d0fcb8 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -968,6 +968,19 @@ static void drm_dp_aux_crc_work(struct work_struct *work)
>   }
>  }
>  
> +/**
> + * drm_dp_remote_aux_init() - minimally initialise a remote aux channel
> + * @aux: DisplayPort AUX channel
> + *
> + * Used for remote aux channel in general. Merely initialize the crc work
> + * struct.
> + */
> +void drm_dp_remote_aux_init(struct drm_dp_aux *aux)
> +{
> + INIT_WORK(>crc_work, drm_dp_aux_crc_work);
> +}
> +EXPORT_SYMBOL(drm_dp_remote_aux_init);
> +
>  /**
>   * drm_dp_aux_init() - minimally initialise an aux channel
>   * @aux: DisplayPort AUX channel
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 87fc44895d83..edafa182264a 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1945,6 +1945,9 @@ drm_dp_mst_handle_link_address_port(struct 
> drm_dp_mst_branch *mstb,
>   port->aux.dev = dev->dev;
>   port->aux.is_remote = true;
>  
> + /* initialize the MST downstream port's AUX crc work queue */
> + drm_dp_remote_aux_init(>aux);
> +
>   /*
>* Make sure the memory allocation for our parent branch stays
>* around until our own memory allocation is released
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8f8f3632e697..b2e6923d5929 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1465,6 +1465,7 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char 
> id[6]);
>  void drm_dp_downstream_debug(struct seq_file *m, const u8 
> dpcd[DP_RECEIVER_CAP_SIZE],
>const u8 port_cap[4], struct drm_dp_aux *aux);
>  
> +void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
>  void drm_dp_aux_init(struct drm_dp_aux *aux);
>  int drm_dp_aux_register(struct drm_dp_aux *aux);
>  void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add LT-tunable PHY repeater mode operations

[Harry Wentland]

On 2019-10-15 9:40 a.m., Siqueira, Rodrigo wrote:
> LT-tunable PHY Repeaters can operate in two different modes: transparent
> (default) and non-transparent. The value 0x55 specifies the transparent
> mode, and 0xaa represents the non-transparent; this commit adds these
> two values as definitions.
> 
> Cc: Abdoulaye Berthe 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Abdoulaye Berthe 
> Signed-off-by: Rodrigo Siqueira 

Reviewed-by: Harry Wentland 

Harry

> ---
>  include/drm/drm_dp_helper.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index bf62b43aaf2b..cfadeeef8492 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1034,6 +1034,10 @@
>  #define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER10xf003b /* 1.3 */
>  #define DP_FEC_STATUS_PHY_REPEATER1  0xf0290 /* 1.4 */
>  
> +/* Repeater modes */
> +#define DP_PHY_REPEATER_MODE_TRANSPARENT 0x55/* 1.3 */
> +#define DP_PHY_REPEATER_MODE_NON_TRANSPARENT 0xaa/* 1.3 */
> +
>  /* DP HDCP message start offsets in DPCD address space */
>  #define DP_HDCP_2_2_AKE_INIT_OFFSET  DP_HDCP_2_2_REG_RTX_OFFSET
>  #define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET DP_HDCP_2_2_REG_CERT_RX_OFFSET
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] drm: Fix DSC throughput mode 0 mask definition

[Harry Wentland]

On 2019-10-21 11:03 a.m., Siqueira, Rodrigo wrote:
> Commit d7cd0e05 introduced a change at DP_DSC_THROUGHPUT_MODE_0_170
> which is not aligned with the spec. This commit replace 15 << 4 by
> 15 << 0 for DP_DSC_THROUGHPUT_MODE_0_170 in order to make it follow the
> specification.
> 
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: Nikola Cornij 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Fixes: d7cd0e053b1 (drm/amd/display: Add 170Mpix/sec DSC throughput support)
> Signed-off-by: Rodrigo Siqueira 

Reviewed-by: Harry Wentland 

Harry

> ---
>  include/drm/drm_dp_helper.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index cfadeeef8492..52024049c59e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -306,7 +306,7 @@
>  # define DP_DSC_THROUGHPUT_MODE_0_900   (12 << 0)
>  # define DP_DSC_THROUGHPUT_MODE_0_950   (13 << 0)
>  # define DP_DSC_THROUGHPUT_MODE_0_1000  (14 << 0)
> -# define DP_DSC_THROUGHPUT_MODE_0_170   (15 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_0_170   (15 << 0) /* 1.4a */
>  # define DP_DSC_THROUGHPUT_MODE_1_MASK  (0xf << 4)
>  # define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
>  # define DP_DSC_THROUGHPUT_MODE_1_UPSUPPORTED 0
> 



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

On 2019-10-23 8:00 p.m., Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> 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: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Clinton A Taylor 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_edid.c  | 49 +
>  include/drm/drm_connector.h | 25 +++
>  include/drm/drm_edid.h  |  2 ++
>  3 files changed, 76 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 474ac04d5600..97dd1200773e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4707,6 +4707,52 @@ static void drm_parse_cea_ext(struct drm_connector 
> *connector,
>   }
>  }
>  
> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> +   const struct edid *edid)
> +{
> + struct drm_display_info *info = >display_info;
> + const struct detailed_timing *timing;
> + const struct detailed_non_pixel *data;
> + const struct detailed_data_monitor_range *range;
> + int i;
> +
> + /*
> +  * Restrict Adaptive Sync only for dp and edp
> +  */
> + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
> +
> + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + timing  = >detailed_timings[i];
> + data= >data.other_data;
> + range   = >data.range;
> + /*
> +  * Check if monitor has continuous frequency mode
> +  */
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + continue;
> + /*
> +  * Check for flag range limits only. If flag == 1 then
> +  * no additional timing information provided.
> +  * Default GTF, GTF Secondary curve and CVT are not
> +  * supported
> +  */
> + if (range->flags != 1)
> + continue;
> +
> + info->adaptive_sync.min_vfreq = range->min_vfreq;
> + info->adaptive_sync.max_vfreq = range->max_vfreq;
> + info->adaptive_sync.pixel_clock_mhz =
> + range->pixel_clock_mhz * 10;
> + break;
> + }
> +}
> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
> +
>  /* A connector has no EDID information, so we've got no EDID to compute 
> quirks from. Reset
>   * all of the values which would have been set from EDID
>   */
> @@ -4728,6 +4774,7 @@ drm_reset_display_info(struct drm_connector *connector)
>   memset(>hdmi, 0, sizeof(info->hdmi));
>  
>   info->non_desktop = 0;
> + memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
>  }
>  
>  u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
> *edid)
> @@ -4743,6 +4790,8 @@ u32 drm_add_display_info(struct drm_connector 
> *connector, const struct edid *edi
>  
>   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>  
> + drm_get_adaptive_sync_limits(connector, edid);
> +
>   DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>  
>   if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 5f8c3389d46f..a27a84270d8d 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,26 @@ enum drm_panel_orientation {
>   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
>  };
>  
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
> + * _display_info
> + *
> + * This struct is used to store a Panel's Adaptive Sync capabilities
> + * as parsed from EDID's detailed monitor range descriptor block.
> + *
> + * @min_vfreq: This is the min supported refresh rate in Hz from
> + * EDID's detailed monitor range.
> + * @max_vfreq: This is the max supported refresh rate in Hz from
> + * EDID's detailed m

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

[Harry Wentland]

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.
>>
>> This option will be particularly useful in the scenarios where
>> Integer mode scaling is possible, and a UI client wants to pick
>> filters like Nearest-neighbor applied for non-blurry outputs.
>>
>> There was a RFC patch series published, to discus the request to enable
>> Integer mode scaling by some of the gaming communities, which can be
>> found here:
>> https://patchwork.freedesktop.org/series/66175/
>>
>> Signed-off-by: Shashank Sharma 
>> ---
>>  drivers/gpu/drm/drm_atomic_uapi.c |  4 
>>  include/drm/drm_crtc.h| 26 ++
>>  include/drm/drm_mode_config.h |  6 ++
>>  3 files changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 0d466d3b0809..883329453a86 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
>> *crtc,
>>  return ret;
>>  } else if (property == config->prop_vrr_enabled) {
>>  state->vrr_enabled = val;
>> +} else if (property == config->scaling_filter_property) {
>> +state->scaling_filter = val;
>>  } else if (property == config->degamma_lut_property) {
>>  ret = drm_atomic_replace_property_blob_from_id(dev,
>>  >degamma_lut,
>> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>>  *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>>  else if (property == config->prop_out_fence_ptr)
>>  *val = 0;
>> +else if (property == config->scaling_filter_property)
>> +*val = state->scaling_filter;
>>  else if (crtc->funcs->atomic_get_property)
>>  return crtc->funcs->atomic_get_property(crtc, state, property, 
>> val);
>>  else
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 5e9b15a0e8c5..94c5509474a8 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -58,6 +58,25 @@ struct device_node;
>>  struct dma_fence;
>>  struct edid;
>>  
>> +enum drm_scaling_filters {
>> +DRM_SCALING_FILTER_DEFAULT,
>> +DRM_SCALING_FILTER_MEDIUM,
>> +DRM_SCALING_FILTER_BILINEAR,
>> +DRM_SCALING_FILTER_NN,
> 
> Please use real words.
> 
>> +DRM_SCALING_FILTER_NN_IS_ONLY,
> 
> Not a big fan of this. I'd just add the explicit nearest filter
> and leave the decision whether to use it to userspace.
> 
>> +DRM_SCALING_FILTER_EDGE_ENHANCE,
>> +DRM_SCALING_FILTER_INVALID,
> 
> That invalid enum value seems entirely pointless.
> 
> This set of filters is pretty arbitrary. It doesn't even cover all
> Intel hw. I would probably just leave it at "default+linear+nearest"
> initially. Exposing more vague hw specific choices needs more though,
> and I'd prefer not to spend those brain cells until a real use case
> emerges.
> 

FWIW, AMD HW allows us to specify a number of horizontal and vertical
taps for scaling. Number of taps are limited by our linebuffer size. The
default is 4 in each dimension but you could have 2 v_taps and 4 h_taps
if your're running a large horizontal resolution on some ASICs.

I'm not sure it makes sense to define filters here that aren't used. It
sounds like default and nearest neighbour would suffice for now in order
to support integer scaling.

Harry

>> +};
>> +
>> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
>> +{ DRM_SCALING_FILTER_DEFAULT, "Default" },
>> +{ DRM_SCALING_FILTER_MEDIUM, "Medium" },
>> +{ DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
>> +{ DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
>> +{ DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
>> +{ DRM_SCALING_FILTER_INVALID, "Invalid" },
>> +};
>> +
>>  static inline int64_t U642I64(uint64_t val)
>>  {
>>  return (int64_t)*((int64_t *));
>> @@ -283,6 +302,13 @@ struct drm_crtc_state {
>>   */
>>  u32 target_vblank;
>>  
>> +/**
>> + * @scaling_filter:
>> + *
>> + * Scaling filter mode to be applied
>> + */
>> +u32 scaling_filter;
> 
> We have an enum so should use it. The documentation should probably
> point out that this applies to full crtc scaling only, not plane
> scaling.
> 
>> +
>>  /**
>>   * @async_flip:
>>   *
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 3bcbe30339f0..efd6fd55770f 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -914,6 +914,12 @@ struct drm_mode_config {
>>   */
>>  struct drm_property *modifiers_property;
>>  
>> +/**

Re: [PATCH] dc.c:use kzalloc without test

[Harry Wentland]

On 2019-10-23 4:32 a.m., zhongshiqi wrote:
> dc.c:583:null check is needed after using kzalloc function
> 
> Signed-off-by: zhongshiqi 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 5d1aded..4b8819c 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -580,6 +580,10 @@ static bool construct(struct dc *dc,
>  #ifdef CONFIG_DRM_AMD_DC_DCN2_0
>   // Allocate memory for the vm_helper
>   dc->vm_helper = kzalloc(sizeof(struct vm_helper), GFP_KERNEL);
> + if (!dc->vm_helper) {
> + dm_error("%s: failed to create dc->vm_helper\n", __func__);
> + goto fail;
> + }
>  
>  #endif
>   memcpy(>bb_overrides, _params->bb_overrides, 
> sizeof(dc->bb_overrides));
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/amdgpu: correct length misspelling

[Harry Wentland]

On 2019-10-19 3:34 a.m., Wambui Karuga wrote:
> Correct the "_LENTH" mispelling in the AMDGPU_MAX_TIMEOUT_PARAM_LENGTH
> constant.
> 
> Signed-off-by: Wambui Karuga 

This patch would be better sent in a patch set with the "make undeclared
variables static" patch. You can do that by providing a range to "git
format-patch". I usually call git format-patch with the -o parameter to
put all my patches in a directory. Then I can send it with "git
send-email *" in that directory.

Reviewed-by: Harry Wentland 

This won't apply cleanly without "make undeclared variables static".
Please see my comments on that patch and send a v2 for this one.

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index c5b3c0c9193b..aaab37833659 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -86,7 +86,7 @@
>  #define KMS_DRIVER_MINOR 34
>  #define KMS_DRIVER_PATCHLEVEL0
>  
> -#define AMDGPU_MAX_TIMEOUT_PARAM_LENTH   256
> +#define AMDGPU_MAX_TIMEOUT_PARAM_LENGTH  256
>  
>  int amdgpu_vram_limit = 0;
>  int amdgpu_vis_vram_limit = 0;
> @@ -100,7 +100,7 @@ int amdgpu_disp_priority = 0;
>  int amdgpu_hw_i2c = 0;
>  int amdgpu_pcie_gen2 = -1;
>  int amdgpu_msi = -1;
> -static char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENTH];
> +static char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENGTH];
>  int amdgpu_dpm = -1;
>  int amdgpu_fw_load_type = -1;
>  int amdgpu_aspm = -1;
> @@ -1327,9 +1327,9 @@ int amdgpu_device_get_job_timeout_settings(struct 
> amdgpu_device *adev)
>   adev->sdma_timeout = adev->video_timeout = adev->gfx_timeout;
>   adev->compute_timeout = MAX_SCHEDULE_TIMEOUT;
>  
> - if (strnlen(input, AMDGPU_MAX_TIMEOUT_PARAM_LENTH)) {
> + if (strnlen(input, AMDGPU_MAX_TIMEOUT_PARAM_LENGTH)) {
>   while ((timeout_setting = strsep(, ",")) &&
> - strnlen(timeout_setting, 
> AMDGPU_MAX_TIMEOUT_PARAM_LENTH)) {
> + strnlen(timeout_setting, 
> AMDGPU_MAX_TIMEOUT_PARAM_LENGTH)) {
>   ret = kstrtol(timeout_setting, 0, );
>   if (ret)
>   return ret;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: remove assignment for return value

[Harry Wentland]

On 2019-10-19 3:32 a.m., Wambui Karuga wrote:
> Remove unnecessary assignment for return value and have the
> function return the required value directly.
> Issue found by coccinelle:
> @@
> local idexpression ret;
> expression e;
> @@
> 
> -ret =
> +return
>  e;
> -return ret;
> 
> Signed-off-by: Wambui Karuga 

Thanks for your patch.

Reviewed-by: Harry Wentland 

Harry


> ---
>  drivers/gpu/drm/radeon/cik.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 62eab82a64f9..daff9a2af3be 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -221,9 +221,7 @@ int ci_get_temp(struct radeon_device *rdev)
>   else
>   actual_temp = temp & 0x1ff;
>  
> - actual_temp = actual_temp * 1000;
> -
> - return actual_temp;
> + return actual_temp * 1000;
>  }
>  
>  /* get temperature in millidegrees */
> @@ -239,9 +237,7 @@ int kv_get_temp(struct radeon_device *rdev)
>   else
>   actual_temp = 0;
>  
> - actual_temp = actual_temp * 1000;
> -
> - return actual_temp;
> + return actual_temp * 1000;
>  }
>  
>  /*
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/amdgpu: make undeclared variables static

[Harry Wentland]

On 2019-10-19 3:24 a.m., Wambui Karuga wrote:
> Make the `amdgpu_lockup_timeout` and `amdgpu_exp_hw_support` variables
> static to remove the following sparse warnings:
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:103:19: warning: symbol 
> 'amdgpu_lockup_timeout' was not declared. Should it be static?

This should be declared in amdgpu.h. amdgpu is maintained on the
amd-staging-drm-next branch from
https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next. Can
you check there?

> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:117:18: warning: symbol 
> 'amdgpu_exp_hw_support' was not declared. Should it be static?
> 
> Signed-off-by: Wambui Karuga 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 3fae1007143e..c5b3c0c9193b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -100,7 +100,7 @@ int amdgpu_disp_priority = 0;
>  int amdgpu_hw_i2c = 0;
>  int amdgpu_pcie_gen2 = -1;
>  int amdgpu_msi = -1;
> -char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENTH];
> +static char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENTH];
>  int amdgpu_dpm = -1;
>  int amdgpu_fw_load_type = -1;
>  int amdgpu_aspm = -1;
> @@ -114,7 +114,7 @@ int amdgpu_vm_block_size = -1;
>  int amdgpu_vm_fault_stop = 0;
>  int amdgpu_vm_debug = 0;
>  int amdgpu_vm_update_mode = -1;
> -int amdgpu_exp_hw_support = 0;
> +static int amdgpu_exp_hw_support;

This is indeed only used in this file but for consistency's sake it's
probably better to also declare it in amdgpu.h rather than make it
static here.

Harry

>  int amdgpu_dc = -1;
>  int amdgpu_sched_jobs = 32;
>  int amdgpu_sched_hw_submission = 2;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm: Add support for DP 1.4 Compliance edid corruption test 4.2.2.6

[Harry Wentland]

On 2019-11-25 4:36 p.m., Zuo, Jerry wrote:
> Please kindly give a review on my latest revision. Thanks a lot.
> 

Both patches are
Reviewed-by: Harry Wentland 

Harry

> Regards,
> Jerry
> 
> -Original Message-
> From: Jerry (Fangzhi) Zuo  
> Sent: November 5, 2019 11:38 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: ly...@redhat.com; manasi.d.nav...@intel.com; Wentland, Harry 
> ; Zuo, Jerry 
> Subject: [PATCH v4] drm: Add support for DP 1.4 Compliance edid corruption 
> test 4.2.2.6
> 
> DP 1.4 edid corruption test requires source DUT to write calculated CRC, not 
> the corrupted CRC from reference sink.
> 
> Return the calculated CRC back, and initiate the required sequence.
> 
> -v2: Have separate routine for returning real CRC
> 
> -v3: Rewrite checksum computation routine to avoid duplicated code.
>  Rename to avoid confusion
> 
> -v4: Fix a minor typo.
> 
> Signed-off-by: Jerry (Fangzhi) Zuo 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 36 
>  drivers/gpu/drm/drm_edid.c  | 18 +++---
>  include/drm/drm_connector.h |  7 +++
>  include/drm/drm_dp_helper.h |  3 +++
>  4 files changed, 61 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> b/drivers/gpu/drm/drm_dp_helper.c index ffc68d305afe..22a0e966ea9f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -336,6 +336,42 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux, 
>  }  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +/**
> +  * drm_dp_send_real_edid_checksum() - send back real edid checksum 
> +value
> +  * @aux: DisplayPort AUX channel
> +  * @real_edid_checksum: real edid checksum for the last block
> +  *
> +  * Returns true on success
> +  */
> +bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
> +u8 real_edid_checksum) {
> +u8 link_edid_read = 0, auto_test_req = 0;
> +u8 test_resp = 0;
> +
> +drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 
> 1);
> +auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
> +
> +drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1);
> +link_edid_read &= DP_TEST_LINK_EDID_READ;
> +
> +if (!auto_test_req || !link_edid_read) {
> +DRM_DEBUG_KMS("Source DUT does not support 
> TEST_EDID_READ\n");
> +return false;
> +}
> +
> +drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, 
> + _test_req, 1);
> +
> +/* send back checksum for the last edid extension block data */
> +drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM, 
> + _edid_checksum, 1);
> +
> +test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
> +drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1);
> +
> +return true;
> +}
> +EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
> +
>  /**
>   * drm_dp_link_probe() - probe a DisplayPort link for capabilities
>   * @aux: DisplayPort AUX channel
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 
> 82a4ceed3fcf..ff64e5f1feb6 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1348,10 +1348,19 @@ static int drm_edid_block_checksum(const u8 
> *raw_edid)  {
>   int i;
>   u8 csum = 0;
> - for (i = 0; i < EDID_LENGTH; i++)
> +
> + for (i = 0; i < EDID_LENGTH - 1; i++)
>   csum += raw_edid[i];
>  
> - return csum;
> + return (0x100 - csum);
> +}
> +
> +static bool drm_edid_block_checksum_diff(const u8 *raw_edid, u8 
> +real_checksum) {
> + if (raw_edid[EDID_LENGTH - 1] != real_checksum)
> + return true;
> + else
> + return false;
>  }
>  
>  static bool drm_edid_is_zero(const u8 *in_edid, int length) @@ -1409,7 
> +1418,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid,
>   }
>  
>   csum = drm_edid_block_checksum(raw_edid);
> - if (csum) {
> + if (drm_edid_block_checksum_diff(raw_edid, csum)) {
>   if (edid_corrupt)
>   *edid_corrupt = true;
>  
> @@ -1572,6 +1581,9 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>  prefix, DUMP_PREFIX_NONE, 16, 1,
>  block, EDID_LENGTH, false);
>   }
> +
> + /* Calculate real checksum for the last edid extension block data */
> + connector->real_edid_checksum = drm_edid_block_checksum(edid + 
> +edid[0x7e] * EDID_LENGTH);
>  

Re: [PATCH][next] drm/amd/display: fix double assignment to msg_id field

[Harry Wentland]

On 2019-11-20 12:22 p.m., Colin King wrote:
> From: Colin Ian King 
> 
> The msg_id field is being assigned twice. Fix this by replacing the second
> assignment with an assignment to msg_size.
> 
> Addresses-Coverity: ("Unused value")
> Fixes: 11a00965d261 ("drm/amd/display: Add PSP block to verify HDCP2.2 steps")
> Signed-off-by: Colin Ian King 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c 
> b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c
> index 2dd5feec8e6c..6791c5844e43 100644
> --- a/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c
> +++ b/drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c
> @@ -42,7 +42,7 @@ static void hdcp2_message_init(struct mod_hdcp *hdcp,
>   in->process.msg2_desc.msg_id = TA_HDCP_HDCP2_MSG_ID__NULL_MESSAGE;
>   in->process.msg2_desc.msg_size = 0;
>   in->process.msg3_desc.msg_id = TA_HDCP_HDCP2_MSG_ID__NULL_MESSAGE;
> - in->process.msg3_desc.msg_id = 0;
> + in->process.msg3_desc.msg_size = 0;
>  }
>  enum mod_hdcp_status mod_hdcp_remove_display_topology(struct mod_hdcp *hdcp)
>  {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Use NULL for pointer assignment in copy_stream_update_to_stream

[Harry Wentland]

On 2019-11-23 2:36 p.m., Nathan Chancellor wrote:
> Clang warns:
> 
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1965:26: warning:
> expression which evaluates to zero treated as a null pointer constant of
> type 'struct dc_dsc_config *' [-Wnon-literal-null-conversion]
> update->dsc_config = false;
>  ^
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1971:25: warning:
> expression which evaluates to zero treated as a null pointer constant of
> type 'struct dc_dsc_config *' [-Wnon-literal-null-conversion]
> update->dsc_config = false;
>  ^
> 2 warnings generated.
> 
> Fixes: f6fe4053b91f ("drm/amd/display: Use a temporary copy of the current 
> state when updating DSC config")
> Link: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FClangBuiltLinux%2Flinux%2Fissues%2F777data=02%7C01%7Charry.wentland%40amd.com%7Ceb5e55813307456cf7d608d7704c79c4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C1%7C637101346080296409sdata=6HK3wWYMoILbiBisjoHkFwopV%2BuJYUh8wCDhMSvRQQ8%3Dreserved=0
> Signed-off-by: Nathan Chancellor 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index c7db4f4810c6..2645d20e8c4c 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1962,13 +1962,13 @@ static void copy_stream_update_to_stream(struct dc 
> *dc,
>   if (!dc->res_pool->funcs->validate_bandwidth(dc, 
> dsc_validate_context, true)) {
>   stream->timing.dsc_cfg = old_dsc_cfg;
>   stream->timing.flags.DSC = old_dsc_enabled;
> - update->dsc_config = false;
> + update->dsc_config = NULL;
>   }
>  
>   dc_release_state(dsc_validate_context);
>   } else {
>   DC_ERROR("Failed to allocate new validate context for 
> DSC change\n");
> - update->dsc_config = false;
> + update->dsc_config = NULL;
>   }
>   }
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add modes from CTA-861-G

[Harry Wentland]

+Bhawan who has been looking at this from our side.

Harry

On 2019-11-23 12:50 a.m., Thomas Anderson wrote:
> The new modes are needed for exotic displays such as 8K. Verified that
> modes like 8K60 and 4K120 are properly obtained from a Samsung Q900R.
> 
> Signed-off-by: Thomas Anderson 
> ---
>  drivers/gpu/drm/drm_edid.c  | 388 +++-
>  include/drm/drm_connector.h |  16 +-
>  2 files changed, 391 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6b0177112e18..ff5c928516fb 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1278,6 +1278,374 @@ static const struct drm_display_mode edid_cea_modes[] 
> = {
>  4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 108 - 1280x720@48Hz 16:9 */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
> +2280, 2500, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 109 - 1280x720@48Hz 64:27 */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
> +2280, 2500, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 110 - 1680x720@48Hz 64:27 */
> + { DRM_MODE("1680x720", DRM_MODE_TYPE_DRIVER, 99000, 1680, 2490,
> +2530, 2750, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 111 - 1920x1080@48Hz 16:9 */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 112 - 1920x1080@48Hz 64:27 */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 113 - 2560x1080@48Hz 64:27 */
> + { DRM_MODE("2560x1080", DRM_MODE_TYPE_DRIVER, 198000, 2560, 3558,
> +3602, 3750, 0, 1080, 1084, 1089, 1100, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 114 - 3840x2160@48Hz 16:9 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 594000, 3840, 5116,
> +5204, 5500, 0, 2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 115 - 4096x2160@48Hz 256:135 */
> + { DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 594000, 4096, 5116,
> +5204, 5500, 0, 2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48,
> +   .picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135, },
> + /* 116 - 3840x2160@48Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 594000, 3840, 5116,
> +5204, 5500, 0, 2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 117 - 3840x2160@100Hz 16:9 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4896,
> +4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 118 - 3840x2160@120Hz 16:9 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4016,
> +4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 119 - 3840x2160@100Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4896,
> +4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 120 - 3840x2160@120Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4016,
> +4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> +

Re: [PATCH 0/4] drm/amd/display: Remove unneeded semicolon

[Harry Wentland]

Series is
Reviewed-by: Harry Wentland 

Harry

On 2019-11-27 9:31 p.m., zhengbin wrote:
> zhengbin (4):
>   drm/amd/display: Remove unneeded semicolon in bios_parser.c
>   drm/amd/display: Remove unneeded semicolon in bios_parser2.c
>   drm/amd/display: Remove unneeded semicolon in hdcp.c
>   drm/amd/display: Remove unneeded semicolon in display_rq_dlg_calc_21.c
> 
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser.c | 2 +-
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c| 2 +-
>  drivers/gpu/drm/amd/display/dc/dml/dcn21/display_rq_dlg_calc_21.c | 4 ++--
>  drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c   | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> --
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: prevent memory leak

[Harry Wentland]

On 2019-09-25 12:23 a.m., Navid Emamdoost wrote:
> In dcn*_create_resource_pool the allocated memory should be released if
> construct pool fails.
> 
> Signed-off-by: Navid Emamdoost 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 1 +
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 1 +
>  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 1 +
>  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 1 +
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c   | 1 +
>  5 files changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> index afc61055eca1..1787b9bf800a 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c
> @@ -1091,6 +1091,7 @@ struct resource_pool *dce100_create_resource_pool(
>   if (construct(num_virtual_links, dc, pool))
>   return >base;
>  
> + kfree(pool);
>   BREAK_TO_DEBUGGER();
>   return NULL;
>  }
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> index c66fe170e1e8..318e9c2e2ca8 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> @@ -1462,6 +1462,7 @@ struct resource_pool *dce110_create_resource_pool(
>   if (construct(num_virtual_links, dc, pool, asic_id))
>   return >base;
>  
> + kfree(pool);
>   BREAK_TO_DEBUGGER();
>   return NULL;
>  }
> diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> index 3ac4c7e73050..3199d493d13b 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> @@ -1338,6 +1338,7 @@ struct resource_pool *dce112_create_resource_pool(
>   if (construct(num_virtual_links, dc, pool))
>   return >base;
>  
> + kfree(pool);
>   BREAK_TO_DEBUGGER();
>   return NULL;
>  }
> diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> index 7d08154e9662..bb497f43f6eb 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> @@ -1203,6 +1203,7 @@ struct resource_pool *dce120_create_resource_pool(
>   if (construct(num_virtual_links, dc, pool))
>   return >base;
>  
> + kfree(pool);
>   BREAK_TO_DEBUGGER();
>   return NULL;
>  }
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> index 5a89e462e7cc..59305e411a66 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c
> @@ -1570,6 +1570,7 @@ struct resource_pool *dcn10_create_resource_pool(
>   if (construct(init_data->num_virtual_links, dc, pool))
>   return >base;
>  
> + kfree(pool);
>   BREAK_TO_DEBUGGER();
>   return NULL;
>  }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] drm/amd/display: remove set but not used variable 'core_freesync'

[Harry Wentland]

On 2019-10-06 6:57 a.m., YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> rivers/gpu/drm/amd/amdgpu/../display/modules/freesync/freesync.c:
>  In function mod_freesync_get_settings:
> drivers/gpu/drm/amd/amdgpu/../display/modules/freesync/freesync.c:984:24:
>  warning: variable core_freesync set but not used [-Wunused-but-set-variable]
> 
> It is not used since commit 98e6436d3af5 ("drm/amd/display: Refactor FreeSync 
> module")
> 
> Reported-by: Hulk Robot 
> Signed-off-by: YueHaibing 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
> b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> index 9ce56a8..237dda7 100644
> --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> @@ -981,13 +981,9 @@ void mod_freesync_get_settings(struct mod_freesync 
> *mod_freesync,
>   unsigned int *inserted_frames,
>   unsigned int *inserted_duration_in_us)
>  {
> - struct core_freesync *core_freesync = NULL;
> -
>   if (mod_freesync == NULL)
>   return;
>  
> - core_freesync = MOD_FREESYNC_TO_CORE(mod_freesync);
> -
>   if (vrr->supported) {
>   *v_total_min = vrr->adjust.v_total_min;
>   *v_total_max = vrr->adjust.v_total_max;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Fix typo in some comments

[Harry Wentland]

On 2019-10-05 7:32 a.m., Christophe JAILLET wrote:
> p and g are switched in 'amdpgu_dm'
> 
> Signed-off-by: Christophe JAILLET 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 92932d521d7f..b9c2e1a930ab 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1043,7 +1043,7 @@ static void s3_handle_mst(struct drm_device *dev, bool 
> suspend)
>  
>  /**
>   * dm_hw_init() - Initialize DC device
> - * @handle: The base driver device containing the amdpgu_dm device.
> + * @handle: The base driver device containing the amdgpu_dm device.
>   *
>   * Initialize the  amdgpu_display_manager device. This involves 
> calling
>   * the initializers of each DM component, then populating the struct with 
> them.
> @@ -1073,7 +1073,7 @@ static int dm_hw_init(void *handle)
>  
>  /**
>   * dm_hw_fini() - Teardown DC device
> - * @handle: The base driver device containing the amdpgu_dm device.
> + * @handle: The base driver device containing the amdgpu_dm device.
>   *
>   * Teardown components within  amdgpu_display_manager that require
>   * cleanup. This involves cleaning up the DRM device, DC, and any modules 
> that
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] drm/amd/display: some fixes for gcc warning

[Harry Wentland]

Series is
Reviewed-by: Harry Wentland 

Harry

On 2019-10-04 10:44 p.m., zhengbin wrote:
> zhengbin (5):
>   drm/amd/display: Make function wait_for_alt_mode static
>   drm/amd/display: Remove set but not used variable 'source_bpp'
>   drm/amd/display: Remove set but not used variables
> 'h_ratio_chroma','v_ratio_chroma'
>   drm/amd/display: Remove set but not used variable 'pixel_width'
>   drm/amd/display: Remove set but not used variables 'pp_smu','old_pipe'
> 
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c   |  2 +-
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c | 12 
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c|  7 ---
>  drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dwb_scl.c|  4 
>  drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c|  3 ---
>  5 files changed, 1 insertion(+), 27 deletions(-)
> 
> --
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/display: make various arrays static, makes object smaller

[Harry Wentland]

On 2019-10-07 5:58 p.m., Colin King wrote:
> From: Colin Ian King 
> 
> Don't populate the arrays on the stack but instead make them
> static. Makes the object code smaller by 158 bytes.
> 
> Before:
>text  data bss dec hex filename
>   32468  2072   0   3454086ec display/dc/bios/bios_parser.o
>   22198  1088   0   232865af6 display/dc/bios/bios_parser2.o
>   22278  1076   0   233545b3a display/dc/dce/dce_mem_input.o
> 
> 81180
> After:
>text  data bss dec hex filename
>   32341  2136   0   3447786ad display/dc/bios/bios_parser.o
>   22070  1184   0   232545ad6 display/dc/bios/bios_parser2.o
>   22119  1172   0   232915afb display/dc/dce/dce_mem_input.o
> 
> (gcc version 9.2.1, amd64)
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser.c  | 2 +-
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 +-
>  drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> index 221e0f56389f..65ab225cf542 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> @@ -2745,7 +2745,7 @@ static enum bp_result bios_get_board_layout_info(
>   struct bios_parser *bp;
>   enum bp_result record_result;
>  
> - const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
> + static const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {

Won't this break the multi-GPU case where you'll have multiple driver
instances with different layout?

Harry

>   GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID1,
>   GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID2,
>   0, 0
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index dff65c0fe82f..809c4a89b899 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -1832,7 +1832,7 @@ static enum bp_result bios_get_board_layout_info(
>   struct bios_parser *bp;
>   enum bp_result record_result;
>  
> - const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
> + static const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
>   GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID1,
>   GENERICOBJECT_BRACKET_LAYOUT_ENUM_ID2,
>   0, 0
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> index 8aa937f496c4..ed0031d5e021 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c
> @@ -395,7 +395,7 @@ static void program_size_and_rotation(
>  {
>   const struct rect *in_rect = _size->surface_size;
>   struct rect hw_rect = plane_size->surface_size;
> - const uint32_t rotation_angles[ROTATION_ANGLE_COUNT] = {
> + static const uint32_t rotation_angles[ROTATION_ANGLE_COUNT] = {
>   [ROTATION_ANGLE_0] = 0,
>   [ROTATION_ANGLE_90] = 1,
>   [ROTATION_ANGLE_180] = 2,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/display: make various arrays static, makes object smaller

[Harry Wentland]

On 2019-10-08 10:00 a.m., Joe Perches wrote:
> On Tue, 2019-10-08 at 13:56 +0000, Harry Wentland wrote:
> []
>>> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
>>> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
>> []
>>> @@ -2745,7 +2745,7 @@ static enum bp_result bios_get_board_layout_info(
>>> struct bios_parser *bp;
>>> enum bp_result record_result;
>>>  
>>> -   const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
>>> +   static const unsigned int slot_index_to_vbios_id[MAX_BOARD_SLOTS] = {
>>
>> Won't this break the multi-GPU case where you'll have multiple driver
>> instances with different layout?
> 
> As the array is read-only, how could that happen?
> 

You're right.

Patch is
Reviewed-by: Harry Wentland 

Harry

> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] drm/amd/display/dc/dce: remove some not used variables

[Harry Wentland]

Thanks for the patches.

I think for all of them we should just drop the REG_READ calls
completely. They look like leftovers from when we had a different
register update scheme that would read the register, then update or get
the field value. Now we just use the REG_ macros that will combine the
read with the GET or UPDATE operations.

Harry

On 2019-10-09 2:25 a.m., zhengbin wrote:
> zhengbin (3):
>   drm/amd/display: Remove set but not used variables
> 'bl_pwm_cntl','pwm_period_cntl'
>   drm/amd/display: Remove set but not used variable 'value0'
>   drm/amd/display: Remove set but not used variables 'regval','speakers'
> 
>  drivers/gpu/drm/amd/display/dc/dce/dce_abm.c| 8 
>  drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c   | 3 +--
>  drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 5 +
>  3 files changed, 6 insertions(+), 10 deletions(-)
> 
> --
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH next] drm/amd/display: make non-global functions static

[Harry Wentland]

On 2019-12-19 6:55 a.m., Chen Zhou wrote:
> Fix sparse warning:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:964:5:
>   warning: symbol 'shift_border_left_to_dst' was not declared. Should it 
> be static?
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:975:6:
>   warning: symbol 'restore_border_left_from_dst' was not declared. Should 
> it be static?
> 
> Fixes: 89d07b662f5e (drm/amd/display: fix 270 degree rotation for mixed-SLS 
> mode)
> Reported-by: Hulk Robot 
> Signed-off-by: Chen Zhou 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> index 64a0e08f..5843c16 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
> @@ -961,7 +961,7 @@ static void calculate_inits_and_adj_vp(struct pipe_ctx 
> *pipe_ctx)
>   * We also need to make sure pipe_ctx->plane_res.scl_data.h_active uses the
>   * original h_border_left value in its calculation.
>   */
> -int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
> +static int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
>  {
>   int store_h_border_left = pipe_ctx->stream->timing.h_border_left;
>  
> @@ -972,7 +972,7 @@ int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
>   return store_h_border_left;
>  }
>  
> -void restore_border_left_from_dst(struct pipe_ctx *pipe_ctx,
> +static void restore_border_left_from_dst(struct pipe_ctx *pipe_ctx,
>int store_h_border_left)
>  {
>   pipe_ctx->stream->dst.x -= store_h_border_left;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

On 2019-12-18 10:13 a.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.
> 

Please roll this into your patch that renames the definition. 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/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 42aa889fd0f5..1a6109be2fce 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct 
> dc_link *link)
>   /* get phy test pattern and pattern parameters from DP receiver */
>   core_link_read_dpcd(
>   link,
> - DP_TEST_PHY_PATTERN,
> + DP_PHY_TEST_PATTERN,
>   _test_pattern.raw,
>   sizeof(dpcd_test_pattern));
>   core_link_read_dpcd(
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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]:
>>> Changed the macro name of the dpcd address used for getting requested
>>> test-pattern.
>>>
>> Please roll this into your patch that renames the definition. All
>> patches should compile on their own.
> 
> 
> Thanks Harry for review, wanted to follow similar commit-description
> format followed in amd-driver compare to i915 and created a separate
> patch. Maybe is it good idea to change the patch sequence and make it as
> first patch.
> 

Thanks for looking to follow the commit style from the rest of the amd
driver but in this case we need to combine them or you'll be left with
one patch in the sequence that won't build on its own.

Harry

> Regards,
> Animesh
> 
>>
>> 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/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> index 42aa889fd0f5..1a6109be2fce 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
>>> @@ -2491,7 +2491,7 @@ static void
>>> dp_test_send_phy_test_pattern(struct dc_link *link)
>>>   /* get phy test pattern and pattern parameters from DP receiver */
>>>   core_link_read_dpcd(
>>>   link,
>>> -    DP_TEST_PHY_PATTERN,
>>> +    DP_PHY_TEST_PATTERN,
>>>   _test_pattern.raw,
>>>   sizeof(dpcd_test_pattern));
>>>   core_link_read_dpcd(
>>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH next] drm/amd/display: make some symbols static

[Harry Wentland]

On 2019-12-20 1:55 a.m., Chen Zhou wrote:
> Make some structs and functions static to fix build warnings, parts of
> warnings are as follows:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_resource.c:744:21:
>   warning: symbol 'dce110_clock_source_create' was not declared. Should 
> it be static?
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_resource.c:768:6:
>   warning: symbol 'dce110_clock_source_destroy' was not declared. Should 
> it be static?
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Chen Zhou 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> index bf14e9a..87227db 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> @@ -741,7 +741,7 @@ struct dce_i2c_hw *dce110_i2c_hw_create(
>  
>   return dce_i2c_hw;
>  }
> -struct clock_source *dce110_clock_source_create(
> +static struct clock_source *dce110_clock_source_create(
>   struct dc_context *ctx,
>   struct dc_bios *bios,
>   enum clock_source_id id,
> @@ -765,7 +765,7 @@ struct clock_source *dce110_clock_source_create(
>   return NULL;
>  }
>  
> -void dce110_clock_source_destroy(struct clock_source **clk_src)
> +static void dce110_clock_source_destroy(struct clock_source **clk_src)
>  {
>   struct dce110_clk_src *dce110_clk_src;
>  
> @@ -1007,7 +1007,7 @@ static bool dce110_validate_bandwidth(
>   return result;
>  }
>  
> -enum dc_status dce110_validate_plane(const struct dc_plane_state 
> *plane_state,
> +static enum dc_status dce110_validate_plane(const struct dc_plane_state 
> *plane_state,
>struct dc_caps *caps)
>  {
>   if (((plane_state->dst_rect.width * 2) < plane_state->src_rect.width) ||
> @@ -1062,7 +1062,7 @@ static bool dce110_validate_surface_sets(
>   return true;
>  }
>  
> -enum dc_status dce110_validate_global(
> +static enum dc_status dce110_validate_global(
>   struct dc *dc,
>   struct dc_state *context)
>  {
> @@ -1305,7 +1305,7 @@ static void bw_calcs_data_update_from_pplib(struct dc 
> *dc)
>   1000);
>  }
>  
> -const struct resource_caps *dce110_resource_cap(
> +static const struct resource_caps *dce110_resource_cap(
>   struct hw_asic_id *asic_id)
>  {
>   if (ASIC_REV_IS_STONEY(asic_id->hw_internal_rev))
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)

[Harry Wentland]

On 2020-02-07 4:17 p.m., Alex Deucher wrote:
> Split into init and register functions to avoid a segfault
> in some configs when the load/unload callbacks are removed.
> 

Looks like MST is completely broken with this change with a NULL pointer
dereference in drm_dp_aux_register.

> v2:
> - add back accidently dropped has_aux setting
> - set dev in late_register
> 
> v3:
> - fix dp cec ordering
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c   | 16 
>  drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 10 ++
>  .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c  |  7 ++-
>  3 files changed, 24 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index ec1501e3a63a..f355d9a752d2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -1461,6 +1461,20 @@ static enum drm_mode_status 
> amdgpu_connector_dp_mode_valid(struct drm_connector
>   return MODE_OK;
>  }
>  
> +static int
> +amdgpu_connector_late_register(struct drm_connector *connector)
> +{
> + struct amdgpu_connector *amdgpu_connector = 
> to_amdgpu_connector(connector);
> + int r = 0;
> +
> + if (amdgpu_connector->ddc_bus->has_aux) {
> + amdgpu_connector->ddc_bus->aux.dev = 
> amdgpu_connector->base.kdev;
> + r = drm_dp_aux_register(_connector->ddc_bus->aux);
> + }
> +
> + return r;
> +}
> +
>  static const struct drm_connector_helper_funcs 
> amdgpu_connector_dp_helper_funcs = {
>   .get_modes = amdgpu_connector_dp_get_modes,
>   .mode_valid = amdgpu_connector_dp_mode_valid,
> @@ -1475,6 +1489,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_dp_funcs = {
>   .early_unregister = amdgpu_connector_unregister,
>   .destroy = amdgpu_connector_destroy,
>   .force = amdgpu_connector_dvi_force,
> + .late_register = amdgpu_connector_late_register,
>  };
>  
>  static const struct drm_connector_funcs amdgpu_connector_edp_funcs = {
> @@ -1485,6 +1500,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_edp_funcs = {
>   .early_unregister = amdgpu_connector_unregister,
>   .destroy = amdgpu_connector_destroy,
>   .force = amdgpu_connector_dvi_force,
> + .late_register = amdgpu_connector_late_register,
>  };
>  
>  void
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> index ea702a64f807..9b74cfdba7b8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> @@ -186,16 +186,10 @@ amdgpu_atombios_dp_aux_transfer(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *m
>  
>  void amdgpu_atombios_dp_aux_init(struct amdgpu_connector *amdgpu_connector)
>  {
> - int ret;
> -
>   amdgpu_connector->ddc_bus->rec.hpd = amdgpu_connector->hpd.hpd;
> - amdgpu_connector->ddc_bus->aux.dev = amdgpu_connector->base.kdev;
>   amdgpu_connector->ddc_bus->aux.transfer = 
> amdgpu_atombios_dp_aux_transfer;
> - ret = drm_dp_aux_register(_connector->ddc_bus->aux);
> - if (!ret)
> - amdgpu_connector->ddc_bus->has_aux = true;
> -
> - WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n", ret);
> + drm_dp_aux_init(_connector->ddc_bus->aux);
> + amdgpu_connector->ddc_bus->has_aux = true;
>  }
>  
>  /* general DP utility functions */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 3959c942c88b..d5b9e72f2649 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -155,6 +155,11 @@ amdgpu_dm_mst_connector_late_register(struct 
> drm_connector *connector)
>   struct amdgpu_dm_connector *amdgpu_dm_connector =
>   to_amdgpu_dm_connector(connector);
>   struct drm_dp_mst_port *port = amdgpu_dm_connector->port;
> + int r;
> +
> + r = drm_dp_aux_register(_dm_connector->dm_dp_aux.aux);

This calls drm_dp_aux_register_devnode which is also called later in
drm_dp_mst_connector_late_register. Wonder if that's a problem.

Harry

> + if (r)
> + return r;
>  
>  #if defined(CONFIG_DEBUG_FS)
>   connector_debugfs_init(amdgpu_dm_connector);
> @@ -484,7 +489,7 @@ void amdgpu_dm_initialize_dp_connector(struct 
> amdgpu_display_manager *dm,
>   aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
>   aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
>  
> - drm_dp_aux_register(>dm_dp_aux.aux);
> + drm_dp_aux_init(>dm_dp_aux.aux);
>   drm_dp_cec_register_connector(>dm_dp_aux.aux,
> >base);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH] drm/amdgpu: Stop using the DRIVER debugging flag for vblank debugging messages

[Harry Wentland]

On 2020-01-23 8:07 p.m., Lyude Paul wrote:
> These are some very loud debug statements that get printed on every
> vblank when driver level debug printing is enabled in DRM, and doesn't
> really tell us anything that isn't related to vblanks. So let's move
> this over to the proper debug flag to be a little less spammy with our
> debug output.
> 
> Signed-off-by: Lyude Paul 

Thanks. Great change.

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 9402374d2466..3675e1c32707 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -407,8 +407,9 @@ static void dm_vupdate_high_irq(void *interrupt_params)
>   if (acrtc) {
>   acrtc_state = to_dm_crtc_state(acrtc->base.state);
>  
> - DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> -  amdgpu_dm_vrr_active(acrtc_state));
> + DRM_DEBUG_VBL("crtc:%d, vupdate-vrr:%d\n",
> +   acrtc->crtc_id,
> +   amdgpu_dm_vrr_active(acrtc_state));
>  
>   /* Core vblank handling is done here after end of front-porch in
>* vrr mode, as vblank timestamping will give valid results
> @@ -458,8 +459,9 @@ static void dm_crtc_high_irq(void *interrupt_params)
>   if (acrtc) {
>   acrtc_state = to_dm_crtc_state(acrtc->base.state);
>  
> - DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> -  amdgpu_dm_vrr_active(acrtc_state));
> + DRM_DEBUG_VBL("crtc:%d, vupdate-vrr:%d\n",
> +   acrtc->crtc_id,
> +   amdgpu_dm_vrr_active(acrtc_state));
>  
>   /* Core vblank handling at start of front-porch is only possible
>* in non-vrr mode, as only there vblank timestamping will give
> @@ -522,8 +524,8 @@ static void dm_dcn_crtc_high_irq(void *interrupt_params)
>  
>   acrtc_state = to_dm_crtc_state(acrtc->base.state);
>  
> - DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> - amdgpu_dm_vrr_active(acrtc_state));
> + DRM_DEBUG_VBL("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> +   amdgpu_dm_vrr_active(acrtc_state));
>  
>   amdgpu_dm_crtc_handle_crc_irq(>base);
>   drm_crtc_handle_vblank(>base);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/dm/mst: Ignore payload update failures on disable

[Harry Wentland]

00246 ORIG_RAX: 0010
> RAX: ffda RBX: 7ffd045f90a0 RCX: 7fab2121f87b
> RDX: 7ffd045f90a0 RSI: c06864a2 RDI: 000b
> RBP: 7ffd045f90a0 R08:  R09: 55dbd2985d10
> R10: 55dbd2196280 R11: 0246 R12: c06864a2
> R13: 000b R14: 0000 R15: 55dbd2196280
> ---[ end trace 6ea888c24d2059cd ]---
> 
> Note as well, I have only been able to reproduce this on setups with 2
> MST displays.
> 
> Signed-off-by: Lyude Paul 
> Cc: sta...@vger.kernel.org

LGTM but would like Mikita or Wayne to have a look as well.
Acked-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index 069b7a6f5597..252fa60c6775 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -216,6 +216,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
>   drm_dp_mst_reset_vcpi_slots(mst_mgr, mst_port);
>   }
>  
> + /* If disabling, it's OK for this to fail */
>   ret = drm_dp_update_payload_part1(mst_mgr);
>  
>   /* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
> @@ -225,7 +226,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
>  
>   get_payload_table(aconnector, proposed_table);
>  
> - if (ret)
> + if (ret && !enable)
>   return false;
>  
>   return true;
> @@ -299,9 +300,9 @@ bool dm_helpers_dp_mst_send_payload_allocation(
>   if (!mst_mgr->mst_state)
>   return false;
>  
> + /* If disabling, it's OK for this to fail */
>   ret = drm_dp_update_payload_part2(mst_mgr);
> -
> - if (ret)
> + if (enable && ret)
>   return false;
>  
>   if (!enable)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

On 2020-01-31 3:24 p.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 not accurate; actually, we need to return
> the actual CRC value when corruption is detected.
> This commit changes this issue by returning the calculated CRC,
> and initiate the required sequence.
> 
> Change since v5
> - Obtain real CRC value before dumping bad edid
> 
> Change since v4
> - Fix for CI.CHECKPATCH
> 
> Change since v3
> - Fix a minor typo.
> 
> Change since v2
> - Rewrite checksum computation routine to avoid duplicated code.
> - Rename to avoid confusion.
> 
> Change since v1
> - Have separate routine 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 |  6 ++
>  include/drm/drm_dp_helper.h |  3 +++
>  4 files changed, 63 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f629fc5494a4..18b285fa1a42 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -351,6 +351,41 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +/**
> + * drm_dp_send_real_edid_checksum() - send back real edid checksum value
> + * @aux: DisplayPort AUX channel
> + * @real_edid_checksum: real edid checksum for the last block
> + *
> + * Returns true on success
> + */
> +bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
> +u8 real_edid_checksum)
> +{
> + u8 link_edid_read = 0, auto_test_req = 0, test_resp = 0;
> +
> + drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 1);
> + auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
> +
> + drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1);
> + link_edid_read &= DP_TEST_LINK_EDID_READ;
> +
> + if (!auto_test_req || !link_edid_read) {
> + DRM_DEBUG_KMS("Source DUT does not support TEST_EDID_READ\n");
> + return false;
> + }
> +
> + drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 1);
> +
> + /* send back checksum for the last edid extension block data */
> + drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM, _edid_checksum, 1);
> +
> + test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
> + drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1);
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
> +
>  /**
>   * drm_dp_downstream_max_clock() - extract branch device max
>   * pixel rate for legacy VGA
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..f064e75fb4c5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1590,11 +1590,22 @@ static int validate_displayid(u8 *displayid, int 
> length, int idx);
>  static int drm_edid_block_checksum(const u8 *raw_edid)
>  {
>   int i;
> - u8 csum = 0;
> - for (i = 0; i < EDID_LENGTH; i++)
> + u8 csum = 0, crc = 0;
> +
> + for (i = 0; i < EDID_LENGTH - 1; i++)
>   csum += raw_edid[i];
>  
> - return csum;
> + crc = 0x100 - csum;
> +
> + return crc;
> +}
> +
> +static bool drm_edid_block_checksum_diff(const u8 *raw_edid, u8 
> real_checksum)
> +{
> + if (raw_edid[EDID_LENGTH - 1] != real_checksum)
> + return true;
> + else
> + return false;
>  }
>  
>  static bool drm_edid_is_zero(const u8 *in_edid, int length)
> @@ -1652,7 +1663,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid,
>   }
>  
>   csum = drm_edid_block_checksum(raw_edid);
> - if (csum) {
> + if (drm_edid_block_checksum_diff(raw_edid, csum)) {
>   if (edid_corrupt)
>   *edid_corrupt = true;
>  
> @@ -1793,6 +1804,10 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>  u8 *edid, int num_blocks)
>  {
>   int i;
> + u8 num_of_ext = edid[0x7e];
> +
> + /* Calculate real checksum for the last edid extension block data */
> + connector->real_edid_checksum = drm_edid_block_checksum(edid + 
> num_of_

Re: [PATCH 6/6] drm/amd/display: REFERENCE for srm interface patches

[Harry Wentland]

Thanks for providing more documentation and this reference.

The patch set (1-5) is
Reviewed-by: Harry Wentland 

Harry

On 2020-01-22 4:05 p.m., Bhawanpreet Lakha wrote:
> This is just a reference for the patches. not to be merged
> 
> Signed-off-by: Bhawanpreet Lakha 
> ---
>  REFERENCE | 49 +
>  1 file changed, 49 insertions(+)
>  create mode 100644 REFERENCE
> 
> diff --git a/REFERENCE b/REFERENCE
> new file mode 100644
> index ..2e53f9cc82ff
> --- /dev/null
> +++ b/REFERENCE
> @@ -0,0 +1,49 @@
> +SRM interface Reference Usermode scripts for ubuntu. 
> +These are just reference sciprts to facilitate the SRM interface for amdgpu.
> +
> ++-+
> +| Main script, this is called on boot/shutdown/suspend/resume , it calls the 
> sysfs to get/set the SRM |
> +| FILE: /home/amdgpu_hdcp_srm_script.sh  
>  |
> ++-+
> +#!/bin/bash
> +
> +SRMFILE="/home/SRM"
> +sudo cat "$SRMFILE" > /sys/class/drm/card0/device/hdcp_srm
> +sudo cat /sys/class/drm/card0/device/hdcp_srm > "$SRMFILE"
> +
> +
> +
> +
> +
> ++-+
> +| .service file, This is placed into /etc/systemd/system/ so it runs the 
> main script on boot/shutdown |
> +| FILE: /etc/systemd/system/amdgpu_hdc_srm_boot_shutdown.service 
>  |
> ++-+
> +[Unit]
> +Description=HDCP SRM boot and shutdown save/load
> +
> +[Service]
> +Type=simple
> +ExecStart=/home/amdgpu_hdcp_srm_script.sh
> +ExecStop=/home/amdgpu_hdcp_srm_script.sh
> +
> +[Install]
> +WantedBy=multi-user.target
> +
> +
> +
> ++-+
> +| To run the script on boot/start run
>   |
> ++-+
> +sudo systemctl start amdgpu_hdc_srm_boot_shutdown
> +sudo systemctl enable amdgpu_hdc_srm_boot_shutdown
> +
> +
> +
> ++-+
> +| To symlnk the files (adding to these directory will run the script on 
> suspend/resume|
> ++-+
> +sudo ln -s $SCRIPTFILE /lib/systemd/system-sleep/amdgpu_hdcp_srm
> +sudo ln -s $SCRIPTFILE /usr/lib/pm-utils/sleep.d/95amdgpu_hdcp_srm
> +
> +
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/14] amdgpu: remove load and unload callbacks

[Harry Wentland]

Patches 10-12 are
Reviewed-by: Harry Wentland 

Harry

On 2020-02-04 10:48 p.m., Alex Deucher wrote:
> These are deprecated and the drm will soon start warning when drivers still
> use them.  It was a long and twisty road, but seems to work.
> 
> Alex Deucher (14):
>   drm/amdgpu: rename amdgpu_debugfs_preempt_cleanup
>   drm/amdgpu/ttm: move debugfs init into core amdgpu debugfs
>   drm/amdgpu/pm: move debugfs init into core amdgpu debugfs
>   drm/amdgpu/sa: move debugfs init into core amdgpu debugfs
>   drm/amdgpu/fence: move debugfs init into core amdgpu debugfs
>   drm/amdgpu/gem: move debugfs init into core amdgpu debugfs
>   drm/amdgpu/regs: move debugfs init into core amdgpu debugfs
>   drm/amdgpu/firmware: move debugfs init into core amdgpu debugfs
>   drm/amdgpu: don't call drm_connector_register for non-MST ports
>   drm/amdgpu/display: move debugfs init into core amdgpu debugfs
>   drm/amd/display: move dpcd debugfs members setup
>   drm/amdgpu/display: add a late register connector callback
>   drm/amdgpu/ring: move debugfs init into core amdgpu debugfs
>   drm/amdgpu: drop legacy drm load and unload callbacks
> 
>  .../gpu/drm/amd/amdgpu/amdgpu_connectors.c|  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c   | 67 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 17 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 13 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |  3 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c|  7 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c|  9 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.h|  2 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c  | 15 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h  |  4 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 14 +---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |  3 +
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |  1 -
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |  3 +
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 -
>  18 files changed, 112 insertions(+), 78 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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 not accurate; actually, we need to return
> the actual CRC value when corruption is detected.
> This commit changes this issue by returning the calculated CRC,
> and initiate the required sequence.
> 
> Change since v6
> - Add return check
> 
> Change since v5
> - Obtain real CRC value before dumping bad edid
> 
> Change since v4
> - Fix for CI.CHECKPATCH
> 
> Change since v3
> - Fix a minor typo.
> 
> Change since v2
> - Rewrite checksum computation routine to avoid duplicated code.
> - Rename to avoid confusion.
> 
> Change since v1
> - Have separate routine for returning real CRC.
> 
> Signed-off-by: Jerry (Fangzhi) Zuo 

Please make sure to add the Reviewed-bys you've received on previous
versions. I've already reviewed v5 and an earlier one. Please add my
Reviewed-by.

Harry

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 51 +
>  drivers/gpu/drm/drm_edid.c  | 23 ---
>  include/drm/drm_connector.h |  6 
>  include/drm/drm_dp_helper.h |  3 ++
>  4 files changed, 79 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f629fc5494a4..1efd609df402 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -351,6 +351,57 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
> +/**
> + * drm_dp_send_real_edid_checksum() - send back real edid checksum value
> + * @aux: DisplayPort AUX channel
> + * @real_edid_checksum: real edid checksum for the last block
> + *
> + * Returns:
> + * True on success
> + */
> +bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
> + u8 real_edid_checksum)
> +{
> + u8 link_edid_read = 0, auto_test_req = 0, test_resp = 0;
> +
> + if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 
> 1) < 1) {
> + DRM_ERROR("DPCD failed read at register 0x%x\n", 
> DP_DEVICE_SERVICE_IRQ_VECTOR);
> + return false;
> + }
> + auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
> +
> + if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1) < 1) {
> + DRM_ERROR("DPCD failed read at register 0x%x\n", 
> DP_TEST_REQUEST);
> + return false;
> + }
> + link_edid_read &= DP_TEST_LINK_EDID_READ;
> +
> + if (!auto_test_req || !link_edid_read) {
> + DRM_DEBUG_KMS("Source DUT does not support TEST_EDID_READ\n");
> + return false;
> + }
> +
> + if (drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, 
> _test_req, 1) < 1) {
> + DRM_ERROR("DPCD failed write at register 0x%x\n", 
> DP_DEVICE_SERVICE_IRQ_VECTOR);
> + return false;
> + }
> +
> + /* send back checksum for the last edid extension block data */
> + if (drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM, _edid_checksum, 
> 1) < 1) {
> + DRM_ERROR("DPCD failed write at register 0x%x\n", 
> DP_TEST_EDID_CHECKSUM);
> + return false;
> + }
> +
> + test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
> + if (drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1) < 1) {
> + DRM_ERROR("DPCD failed write at register 0x%x\n", 
> DP_TEST_RESPONSE);
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
> +
>  /**
>   * drm_dp_downstream_max_clock() - extract branch device max
>   * pixel rate for legacy VGA
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..f064e75fb4c5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1590,11 +1590,22 @@ static int validate_displayid(u8 *displayid, int 
> length, int idx);
>  static int drm_edid_block_checksum(const u8 *raw_edid)
>  {
>   int i;
> - u8 csum = 0;
> - for (i = 0; i < EDID_LENGTH; i++)
> + u8 csum = 0, crc = 0;
> +
> + for (i = 0; i < EDID_LENGTH - 1; i++)
>   csum += raw_edid[i];
>  
> - return csum;
> + crc = 0x100 - csum;
> +
> + return crc;
> +}
> +
> +static bool drm_edid_block_checksum_diff(const u8 *raw_edid, u8 
> real_checksum)
> +{
> + if (raw_edid[EDID_LENGTH - 1] != real_checksum)
> + return true;
> + else
> + return false;
>  }
>  
>  static bool drm_edid_is_zero(const u8 *in_edid, int length)
> @@ -1652,7 +1663,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid,
>   }
>  
>   csum = drm_edid_block_checksum(raw_edid);
> - if (csum) {
> + if (drm_edid_block_checksum_diff(raw_edid, csum)) {

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

[Harry Wentland]

On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> If the current eDP link settings, as read from hw, provide a higher
> bandwidth than the verified_link_cap ones (= reported_link_cap), then
> override verified_link_cap with current settings.
> 
> These initial current eDP link settings have been set up by
> firmware during boot, so they should work on the eDP panel.
> Therefore use them if the firmware thinks they are good and
> they provide higher link bandwidth, e.g., to enable higher
> resolutions / color depths.
> 

This only works when taking over from UEFI, so on boot or resume from
hibernate. This wouldn't work on a normal suspend/resume.

Can you check if setting link->dc->config.optimize_edp_link_rate (see
first if statement in detect_edp_sink_caps) fixes this? I imagine we
need to read the reported settings from DP_SUPPORTED_LINK_RATES and fail
to do so.

Thanks,
Harry

> This fixes a problem found on the MacBookPro 2017 Retina panel:
> 
> The panel reports 10 bpc color depth in its EDID, and the
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
> but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
> as possible, so verified_link_cap is only good for 2.7 Gbps
> and 8 bpc, not providing the full color depth of the panel.
> 
> Signed-off-by: Mario Kleiner 
> Cc: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21 +++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index 5ea4a1675259..f3acdb8fead5 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct dc_link *link,
>   case SIGNAL_TYPE_EDP: {
>   detect_edp_sink_caps(link);
>   read_current_link_settings_on_detect(link);
> +
> + /* If cur_link_settings provides higher bandwidth than
> +  * verified_link_cap, then use cur_link_settings as new
> +  * verified_link_cap, as it obviously works according to
> +  * firmware boot setup.
> +  *
> +  * This has been observed on the Apple MacBookPro 2017
> +  * Retina panel, which boots with a link setting higher
> +  * than what dpcd[DP_MAX_LINK_RATE] claims as possible.
> +  * Overriding allows to run the panel at 10 bpc / 30 
> bit.
> +  */
> + if (dc_link_bandwidth_kbps(link, 
> >cur_link_settings) >
> + dc_link_bandwidth_kbps(link, 
> >verified_link_cap)) {
> + DC_LOG_DETECTION_DP_CAPS(
> + "eDP current link setting bw %d kbps > 
> verified_link_cap %d kbps. Override.",
> + dc_link_bandwidth_kbps(link, 
> >cur_link_settings),
> + dc_link_bandwidth_kbps(link, 
> >verified_link_cap));
> +
> + link->verified_link_cap = 
> link->cur_link_settings;
> + }
> +
>   sink_caps.transaction_type = 
> DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
>   sink_caps.signal = SIGNAL_TYPE_EDP;
>   break;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/amd/display: Reorder detect_edp_sink_caps before link settings read.

[Harry Wentland]

On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> read_current_link_settings_on_detect() on eDP 1.4+ may use the
> edp_supported_link_rates table which is set up by
> detect_edp_sink_caps(), so that function needs to be called first.
> 
> Signed-off-by: Mario Kleiner 
> Cc: Martin Leung 

Reviewed-by: Harry Wentland 

This also fixes our assumption that retrieve_link_cap is the first DPCD
reads we perform during detection.

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index cef8c1ba9797..5ea4a1675259 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -817,8 +817,8 @@ static bool dc_link_detect_helper(struct dc_link *link,
>   }
>  
>   case SIGNAL_TYPE_EDP: {
> - read_current_link_settings_on_detect(link);
>   detect_edp_sink_caps(link);
> + read_current_link_settings_on_detect(link);
>   sink_caps.transaction_type = 
> DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
>   sink_caps.signal = SIGNAL_TYPE_EDP;
>   break;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/display: Use u64 divide macro for round up division

[Harry Wentland]

On 2020-01-13 8:20 a.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski 
> 
> [why]
> Fix compilation warnings on i386 architecture:
> undefined reference to `__udivdi3'
> [how]
> Switch DIV_ROUND_UP to DIV64_U64_ROUND_UP
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Mikita Lipski 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 52fb207393ef..96b391e4b3e7 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -534,7 +534,7 @@ static int kbps_to_peak_pbn(int kbps)
>  
>   peak_kbps *= 1006;
>   peak_kbps = div_u64(peak_kbps, 1000);
> - return (int) DIV_ROUND_UP(peak_kbps * 64, (54 * 8 * 1000));
> + return (int) DIV64_U64_ROUND_UP(peak_kbps * 64, (54 * 8 * 1000));
>  }
>  
>  static void set_dsc_configs_from_fairness_vars(struct 
> dsc_mst_fairness_params *params,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

Fixing Nick's email.

On 2020-01-10 5:43 p.m., Manasi Navare wrote:
> On Thu, Jan 09, 2020 at 05:24:30PM +0200, Jani Nikula wrote:
>> On Tue, 07 Jan 2020, Manasi Navare  wrote:
>>> Adaptive Sync is a VESA feature so add a DRM core helper to parse
>>> the EDID's detailed descritors to obtain the adaptive sync monitor range.
>>> Store this info as part fo drm_display_info so it can be used
>>> across all drivers.
>>> 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
>>>
>>> v2:
>>> * Change vmin and vmax to use u8 (Ville)
>>> * Dont store pixel clock since that is just a max dotclock
>>> and not related to VRR mode (Manasi)
>>>
>>> Cc: Ville Syrjälä 
>>> Cc: Harry Wentland 
>>> Cc: Clinton A Taylor 
>>> Cc: Nicholas Kazlauskas 
>>> Signed-off-by: Manasi Navare 
>>> ---
>>>  drivers/gpu/drm/drm_edid.c  | 51 +
>>>  include/drm/drm_connector.h | 22 
>>>  include/drm/drm_edid.h  |  2 ++
>>>  3 files changed, 75 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 99769d6c9f84..52781a0e708b 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector 
>>> *connector,
>>> }
>>>  }
>>>  
>>> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
>>> + const struct edid *edid)
>>> +{
>>> +   struct drm_display_info *info = >display_info;
>>> +   const struct detailed_timing *timing;
>>> +   const struct detailed_non_pixel *data;
>>> +   const struct detailed_data_monitor_range *range;
>>> +   int i;
>>> +
>>> +   /*
>>> +* Restrict Adaptive Sync only for dp and edp
>>> +*/
>>> +   if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
>>> +   connector->connector_type != DRM_MODE_CONNECTOR_eDP)
>>> +   return;
>>> +
>>> +   if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
>>> +   return;
>>> +
>>> +   for (i = 0; i < 4; i++) {
>>> +   timing  = >detailed_timings[i];
>>> +   data= >data.other_data;
>>> +   range   = >data.range;
>>> +   /*
>>> +* Check if monitor has continuous frequency mode
>>> +*/
>>> +   if (data->type != EDID_DETAIL_MONITOR_RANGE)
>>> +   continue;
>>> +   /*
>>> +* Check for flag range limits only. If flag == 1 then
>>> +* no additional timing information provided.
>>> +* Default GTF, GTF Secondary curve and CVT are not
>>> +* supported
>>> +*/
>>> +   if (range->flags != 1)
>>> +   continue;
>>> +
>>> +   info->adaptive_sync.min_vfreq = range->min_vfreq;
>>> +   info->adaptive_sync.max_vfreq = range->max_vfreq;
>>> +
>>> +   DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d 
>>> Hz\n",
>>> + info->adaptive_sync.min_vfreq,
>>> + info->adaptive_sync.max_vfreq);
>>> +   break;
>>> +   }
>>> +}
>>> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
>>
>> Why the export? Rather, why is this not static?
>>
> 
> I could make it static but since the way AMDGPU code is written right now they
> would be calling this function explicitly to populate the vmin and vmax in 
> their local
> structs but I can make it static and with some minor refactoring they should 
> be able to
> use thsi infor directly from drm_display_info
> 

Calling this through drm_add_edid_modes should be sufficient for us.
We'll just need to move amdgpu_dm_update_freesync_caps to our get_modes
function.

Dropping the export here seems to be the right thing to do.

Harry

> Manasi
>  
>> BR,
>> Jani.
>>
>>> +
>>>  /* A connector has no EDID information, so we've got no EDID to compute 
>>> quirks from. Reset
>>>   * all of the values which would have

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

[Harry Wentland]

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 Deucher
> mailto:alexdeuc...@gmail.com>> wrote:
> >>
> >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >>  > wrote:
> >> >
> As Harry mentioned in the other thread, won't this only work if the
> display was brought up by the vbios?  In the suspend/resume case,
> won't we just fall back to 2.7Gbps?
>
> Alex
>
>
> Adding Harry to cc...
>
> The code is only executed for eDP. On the Intel side, it seems that
> intel_edp_init_dpcd() gets only called during driver load /
> modesetting init, so not on resume.
>
> On the AMD DC side, dc_link_detect_helper() has this early no-op
> return at the beginning:
>
> if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
>   link->connector_signal == SIGNAL_TYPE_EDP) &&
>   link->local_sink)
>   return true;
>
> So i guess if link->local_sink doesn't get NULL'ed during a
> suspend/resume cycle, then we never reach the setup code that would
> overwrite with non vbios settings?
>
> Sounds reasonable to me, given that eDP panels are usually fixed
> internal panels, nothing that gets hot(un-)plugged?
>
> I can't test, because suspend/resume with the Polaris gpu on the MBP
> 2017 is totally broken atm., just as vgaswitcheroo can't do its job.
> Looks like powering down the gpu works, but powering up doesn't. And
> also modesetting at vgaswitcheroo switch time is no-go, because the
> DDC/AUX lines apparently can't be switched on that Apple gmux, and
> handover of that data seems to be not implemented in current
> vgaswitcheroo. At the moment switching between AMD only or Intel+AMD
> Prime setup is quite a pita...
>

I haven't followed the entire discussion on the i915 thread but for the
amdgpu dc patch I would prefer a DPCD quirk to override the reported
link settings with the correct link rate.

Harry

> -mario
>
>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Allow current eDP link settings to override verified ones.

[Harry Wentland]

On 2020-01-09 4:13 p.m., Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 7:44 PM Harry Wentland  <mailto:hwent...@amd.com>> wrote:
> 
> On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> > If the current eDP link settings, as read from hw, provide a higher
> > bandwidth than the verified_link_cap ones (= reported_link_cap), then
> > override verified_link_cap with current settings.
> >
> > These initial current eDP link settings have been set up by
> > firmware during boot, so they should work on the eDP panel.
> > Therefore use them if the firmware thinks they are good and
> > they provide higher link bandwidth, e.g., to enable higher
> > resolutions / color depths.
> >
>  
> 
> 
> Hi Harry, happy new year!
> 

Frohes Neues. :)

> This only works when taking over from UEFI, so on boot or resume from
> hibernate. This wouldn't work on a normal suspend/resume.
> 
> 
> See the other thread i just cc'ed you on. Depends if
> dc_link_detect_helper() gets skipped/early returns or not on EDP. Some
> if statement suggests it might get skipped on EDP + resume?
>  

You've likely looked at the code more closely while debugging this than
I have recently. It looks like we indeed skip detection if we've
previously detected the eDP sink.

> 
> Can you check if setting link->dc->config.optimize_edp_link_rate (see
> first if statement in detect_edp_sink_caps) fixes this? I imagine we
> need to read the reported settings from DP_SUPPORTED_LINK_RATES and fail
> to do so.
> 
> 
> Tried that already (see other mail), replacing the whole if statement
> with a if (true) to force reading DP_SUPPORTED_LINK_RATES. The whole
> table reads back as all-zero, and versions are DP 1.1, eDP 1.3, not 1.4+
> as what seems to be required. The use the classic link bw stuff, but
> with a non-standard link bandwidth multiplier of 0xc, and a reported
> DP_MAX_LINK_RATE of 0xa, contradicting the 0xc setting that the firmware
> sets at bootup.
> 
> Seems to be a very Apple thing...

Indeed. I think it was a funky panel that was "ahead of its time" and
ahead of the spec.

I would prefer a DPCD quirk for this panel that updates the reported DP
caps, rather than picking the "current" ones from the FW lightup.

Harry

> -mario
>  
> 
> 
> Thanks,
> Harry
> 
> > This fixes a problem found on the MacBookPro 2017 Retina panel:
> >
> > The panel reports 10 bpc color depth in its EDID, and the
> > firmware chooses link settings at boot which support enough
> > bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2),
> > but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps
> > as possible, so verified_link_cap is only good for 2.7 Gbps
> > and 8 bpc, not providing the full color depth of the panel.
> >
> > Signed-off-by: Mario Kleiner  <mailto:mario.kleiner...@gmail.com>>
> > Cc: Alex Deucher  <mailto:alexander.deuc...@amd.com>>
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 21
> +++
> >  1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > index 5ea4a1675259..f3acdb8fead5 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -819,6 +819,27 @@ static bool dc_link_detect_helper(struct
> dc_link *link,
> >               case SIGNAL_TYPE_EDP: {
> >                       detect_edp_sink_caps(link);
> >                       read_current_link_settings_on_detect(link);
> > +
> > +                     /* If cur_link_settings provides higher
> bandwidth than
> > +                      * verified_link_cap, then use
> cur_link_settings as new
> > +                      * verified_link_cap, as it obviously works
> according to
> > +                      * firmware boot setup.
> > +                      *
> > +                      * This has been observed on the Apple
> MacBookPro 2017
> > +                      * Retina panel, which boots with a link
> setting higher
> > +                      * than what dpcd[DP_MAX_LINK_RATE] claims
> as possible.
> > +                      * Overriding allows to run the panel at 10
> bpc / 30 bit.
> > +                      */
> > +                     if (dc_link_bandwidth_kbps(l

Re: [PATCH v2] drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded

[Harry Wentland]

On 2019-12-02 4:47 p.m., Thomas Anderson wrote:
> For high-res (8K) or HFR (4K120) displays, using uncompressed pixel
> formats like YCbCr444 would exceed the bandwidth of HDMI 2.0, so the
> "interesting" modes would be disabled, leaving only low-res or low
> framerate modes.
> 
> This change lowers the pixel encoding to 4:2:2 or 4:2:0 if the max TMDS
> clock is exceeded. Verified that 8K30 and 4K120 are now available and
> working with a Samsung Q900R over an HDMI 2.0b link from a Radeon 5700.
> 
> Signed-off-by: Thomas Anderson 

Apologies for the late response.

Thanks for getting high-res modes working on HDMI.

This change is
Reviewed-by: Harry Wentland 

Harry

> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 ++-
>  1 file changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 7aac9568d3be..803e59d97411 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3356,27 +3356,21 @@ get_output_color_space(const struct dc_crtc_timing 
> *dc_crtc_timing)
>   return color_space;
>  }
>  
> -static void reduce_mode_colour_depth(struct dc_crtc_timing *timing_out)
> -{
> - if (timing_out->display_color_depth <= COLOR_DEPTH_888)
> - return;
> -
> - timing_out->display_color_depth--;
> -}
> -
> -static void adjust_colour_depth_from_display_info(struct dc_crtc_timing 
> *timing_out,
> - const struct drm_display_info 
> *info)
> +static bool adjust_colour_depth_from_display_info(
> + struct dc_crtc_timing *timing_out,
> + const struct drm_display_info *info)
>  {
> + enum dc_color_depth depth = timing_out->display_color_depth;
>   int normalized_clk;
> - if (timing_out->display_color_depth <= COLOR_DEPTH_888)
> - return;
>   do {
>   normalized_clk = timing_out->pix_clk_100hz / 10;
>   /* YCbCr 4:2:0 requires additional adjustment of 1/2 */
>   if (timing_out->pixel_encoding == PIXEL_ENCODING_YCBCR420)
>   normalized_clk /= 2;
>   /* Adjusting pix clock following on HDMI spec based on colour 
> depth */
> - switch (timing_out->display_color_depth) {
> + switch (depth) {
> + case COLOR_DEPTH_888:
> + break;
>   case COLOR_DEPTH_101010:
>   normalized_clk = (normalized_clk * 30) / 24;
>   break;
> @@ -3387,14 +3381,15 @@ static void 
> adjust_colour_depth_from_display_info(struct dc_crtc_timing *timing_
>   normalized_clk = (normalized_clk * 48) / 24;
>   break;
>   default:
> - return;
> + /* The above depths are the only ones valid for HDMI. */
> + return false;
>   }
> - if (normalized_clk <= info->max_tmds_clock)
> - return;
> - reduce_mode_colour_depth(timing_out);
> -
> - } while (timing_out->display_color_depth > COLOR_DEPTH_888);
> -
> + if (normalized_clk <= info->max_tmds_clock) {
> + timing_out->display_color_depth = depth;
> + return true;
> + }
> + } while (--depth > COLOR_DEPTH_666);
> + return false;
>  }
>  
>  static void fill_stream_properties_from_drm_display_mode(
> @@ -3474,8 +3469,14 @@ static void 
> fill_stream_properties_from_drm_display_mode(
>  
>   stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
>   stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
> - if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
> - adjust_colour_depth_from_display_info(timing_out, info);
> + if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) {
> + if (!adjust_colour_depth_from_display_info(timing_out, info) &&
> + drm_mode_is_420_also(info, mode_in) &&
> + timing_out->pixel_encoding != PIXEL_ENCODING_YCBCR420) {
> + timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
> + adjust_colour_depth_from_display_info(timing_out, info);
> + }
> + }
>  }
>  
>  static void fill_audio_info(struct audio_info *audio_info,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm: Set crc->opened to false before setting crc source to NULL.

[Harry Wentland]

On 2019-07-26 1:37 p.m., David (Dingchen) Zhang wrote:
> From: Dingchen Zhang 
> 
> to terminate the while-loop in drm_dp_aux_crc_work when
> drm_dp_start/stop_crc are called in the hook to set crc source.
> 
> v3: set crc->opened to false without checking (Nick)
> v2: Move spin_lock around entire crc->opened use (Daniel)
> 
> Cc: Daniel Vetter 
> Cc: Harry Wentland 
> Cc: Nick Kazlauskas 
> Signed-off-by: Dingchen Zhang 

Looks like we dropped the ball on this and the other CRC patch. I'll
merge them now.

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_debugfs_crc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index dac267e840af..d2d2389d8892 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -249,6 +249,11 @@ static int crtc_crc_release(struct inode *inode, struct 
> file *filep)
>   struct drm_crtc *crtc = filep->f_inode->i_private;
>   struct drm_crtc_crc *crc = >crc;
>  
> + /* terminate the infinite while loop if 'drm_dp_aux_crc_work' running */
> + spin_lock_irq(>lock);
> + crc->opened = false;
> + spin_unlock_irq(>lock);
> +
>   crtc->funcs->set_crc_source(crtc, NULL);
>  
>   spin_lock_irq(>lock);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

[Harry Wentland]

On 2020-01-03 12:50 a.m., Wayne Lin wrote:
> [Why]
> According to DP spec, it should shift left 4 digits for NO_STOP_BIT
> in REMOTE_I2C_READ message. Not 5 digits.
> 
> In current code, NO_STOP_BIT is always set to zero which means I2C
> master is always generating a I2C stop at the end of each I2C write
> transaction while handling REMOTE_I2C_READ sideband message. This issue
> might have the generated I2C signal not meeting the requirement. Take
> random read in I2C for instance, I2C master should generate a repeat
> start to start to read data after writing the read address. This issue
> will cause the I2C master to generate a stop-start rather than a
> re-start which is not expected in I2C random read.
> 

Thanks for elaborating on the potential consequences of this bug.

Harry

> [How]
> Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
> drm_dp_encode_sideband_req().
> 
> Changes since v1:(https://patchwork.kernel.org/patch/11312667/)
> * Add more descriptions in commit and cc to stable
> 
> Fixes: ad7f8a1f9ce (drm/helper: add Displayport multi-stream helper (v0.6))
> Reviewed-by: Harry Wentland 
> Signed-off-by: Wayne Lin 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 1cf5f8b8bbb8..9d24c98bece1 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct 
> drm_dp_sideband_msg_req_body *req,
>   memcpy([idx], 
> req->u.i2c_read.transactions[i].bytes, 
> req->u.i2c_read.transactions[i].num_bytes);
>   idx += req->u.i2c_read.transactions[i].num_bytes;
>  
> - buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit 
> & 0x1) << 5;
> + buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit 
> & 0x1) << 4;
>   buf[idx] |= 
> (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
>   idx++;
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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 
> Signed-off-by: Animesh Manna 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
>  include/drm/drm_dp_helper.h  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 42aa889fd0f5..1a6109be2fce 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct 
> dc_link *link)
>   /* get phy test pattern and pattern parameters from DP receiver */
>   core_link_read_dpcd(
>   link,
> - DP_TEST_PHY_PATTERN,
> + DP_PHY_TEST_PATTERN,
>   _test_pattern.raw,
>   sizeof(dpcd_test_pattern));
>   core_link_read_dpcd(
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8f8f3632e697..d6e560870fb1 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -699,7 +699,7 @@
>  # define DP_TEST_CRC_SUPPORTED   (1 << 5)
>  # define DP_TEST_COUNT_MASK  0xf
>  
> -#define DP_TEST_PHY_PATTERN 0x248
> +#define DP_PHY_TEST_PATTERN 0x248
>  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
>  #define  DP_TEST_80BIT_CUSTOM_PATTERN_15_8   0x251
>  #define  DP_TEST_80BIT_CUSTOM_PATTERN_23_16  0x252
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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 review feedback from Manasi on RFC version,
> - added dp revision as function argument in set_phy_pattern api.
> - used int for link_rate and u8 for lane_count to align with existing code.
> 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 93 +
>  include/drm/drm_dp_helper.h | 31 +++
>  2 files changed, 124 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2c7870aef469..91c80973aa83 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1371,3 +1371,96 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8 
> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
>   return num_bpc;
>  }
>  EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
> +
> +/**
> + * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data)
> +{
> + int err;
> + u8 rate, lanes;
> +
> + err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
> + if (err < 0)
> + return err;
> + data->link_rate = drm_dp_bw_code_to_link_rate(rate);
> +
> + err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
> + if (err < 0)
> + return err;
> + data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
> +
> + if (lanes & DP_ENHANCED_FRAME_CAP)
> + data->enahanced_frame_cap = true;
> +
> + err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, >phy_pattern);
> + if (err < 0)
> + return err;
> +
> + switch (data->phy_pattern) {
> + case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
> + err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
> +>custom80, 10);

Using sizeof(data->custom80) might be safer.

> + if (err < 0)
> + return err;
> +
> + break;
> + case DP_PHY_TEST_PATTERN_CP2520:
> + err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
> +>hbr2_reset, 2);

Same here, using sizeof(data->hbr2_reset).

> + if (err < 0)
> + return err;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
> +
> +/**
> + * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data, u8 dp_rev)
> +{
> + int err, i;
> + u8 link_config[2];
> + u8 test_pattern;
> +
> + link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
> + link_config[1] = data->num_lanes;
> + if (data->enahanced_frame_cap)
> + link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> + err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
> + if (err < 0)
> + return err;
> +
> + test_pattern = data->phy_pattern;
> + if (dp_rev < 0x12) {
> + test_pattern = (test_pattern << 2) &
> +DP_LINK_QUAL_PATTERN_11_MASK;
> + err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
> +  test_pattern);
> + if (err < 0)
> + return err;
> + } else {
> + for (i = 0; i < data->num_lanes; i++) {
> + err = drm_dp_dpcd_writeb(aux,
> +  DP_LINK_QUAL_LANE0_SET + i,
> +  test_pattern);
> + if (err < 0)
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index d6e560870fb1..42a364748308 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -700,6 +700,15 @@
>  # define DP_TEST_COUNT_MASK  0xf
>  
>  #define DP_PHY_TEST_PATTERN 0x248
> +# define DP_PHY_TEST_PATTERN_SEL_MASK   0x7
> +# define DP_PHY_TEST_PATTERN_NONE   0x0
> +# define DP_PHY_TEST_PATTERN_D10_2  0x1
> +# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
> +# define DP_PHY_TEST_PATTERN_PRBS7 

Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

[Harry Wentland]

On 2019-12-30 11:00 p.m., Lin, Wayne wrote:
> [AMD Official Use Only - Internal Distribution Only]
> 

Make sure to select the correct AIP designation for public emails. See
my email on that from yesterday. :)

>> 
>> From: Wentland, Harry 
>> Sent: Monday, December 30, 2019 23:26
>> To: Lin, Wayne; dri-devel@lists.freedesktop.org; 
>> amd-...@lists.freedesktop.org
>> Cc: ly...@redhat.com; Zuo, Jerry; Kazlauskas, Nicholas; Wentland, Harry
>> Subject: Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
>>
>> On 2019-12-30 2:05 a.m., Wayne Lin wrote:
>>> [Why]
>>> According to DP spec, it should shift left 4 digits for NO_STOP_BIT
>>> in REMOTE_I2C_READ message. Not 5 digits.
>>>
>>> [How]
>>> Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
>>> drm_dp_encode_sideband_req().
>>>
>>> Signed-off-by: Wayne Lin 
>>
>> Good catch. Looks like this has been there since the beginning of MST in
>> the kernel. How did you find this? Did this cause bad EDID reads or some
>> other problem? If so the commit message should probably mention it.
>>
>> Harry
> Thanks for your time.
> 
> I found this while I was trying to debug MST issues by using AUX monitor.
> So far, I don't observe problems that relate to this under my test cases and 
> environment.
> However, this bit might affect the I2C signal generated by I2C master, I will 
> mention more
> in the commit message.
> 

Thanks. Was just curious if you saw any real issues. Good find
nevertheless and good patch.

You can add my
Reviewed-by: Harry Wentland 

Harry

> Thanks.
>>
>>> ---
>>>  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
>>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>>> index 1d1bfa49ca2b..0557e225ff67 100644
>>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>>> @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct 
>>> drm_dp_sideband_msg_req_body *req,
>>>   memcpy([idx], 
>>> req->u.i2c_read.transactions[i].bytes, 
>>> req->u.i2c_read.transactions[i].num_bytes);
>>>   idx += req->u.i2c_read.transactions[i].num_bytes;
>>>
>>> - buf[idx] = 
>>> (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5;
>>> + buf[idx] = 
>>> (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
>>>   buf[idx] |= 
>>> (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
>>>   idx++;
>>>   }
>>>
> --
> Wayne Lin
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Fix error returned by program_hpd_filter

[Harry Wentland]

On 2019-11-17 12:22 p.m., Aditya Pakki wrote:
> program_hpd_filter() currently fails to check for the errors
> returned in construct(). This patch returns error in
> case of failure.
> 
> Signed-off-by: Aditya Pakki 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index ca20b150afcc..bbb648a50c41 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -1379,9 +1379,8 @@ static bool construct(
>* If GPIO isn't programmed correctly HPD might not rise or drain
>* fast enough, leading to bounces.
>*/
> - program_hpd_filter(link);
> + return program_hpd_filter(link);

We don't want program_hpd_filter to become a fatal error, which this
would do.

Though it would be good to print a warning if program_hpd_filter fails
as it's unexpected and might lead to bugs with some displays. In many
cases failing to program the HPD filter won't lead to adverse behavior.

Harry

>  
> - return true;
>  device_tag_fail:
>   link->link_enc->funcs->destroy(>link_enc);
>  link_enc_create_fail:
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Harry Wentland]

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. 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 review feedback from Manasi on RFC version,
>>> - added dp revision as function argument in set_phy_pattern api.
>>> - used int for link_rate and u8 for lane_count to align with
>>> existing code.
>>>
>>> Signed-off-by: Animesh Manna 
>>> ---
>>>   drivers/gpu/drm/drm_dp_helper.c | 93
>>> +
>>>   include/drm/drm_dp_helper.h | 31 +++
>>>   2 files changed, 124 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>>> b/drivers/gpu/drm/drm_dp_helper.c
>>> index 2c7870aef469..91c80973aa83 100644
>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>> @@ -1371,3 +1371,96 @@ int
>>> drm_dp_dsc_sink_supported_input_bpcs(const u8
>>> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
>>>   return num_bpc;
>>>   }
>>>   EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
>>> +
>>> +/**
>>> + * drm_dp_get_phy_test_pattern() - get the requested pattern from
>>> the sink.
>>> + * @aux: DisplayPort AUX channel
>>> + * @data: DP phy compliance test parameters.
>>> + *
>>> + * Returns 0 on success or a negative error code on failure.
>>> + */
>>> +int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
>>> +    struct drm_dp_phy_test_params *data)
>>> +{
>>> +    int err;
>>> +    u8 rate, lanes;
>>> +
>>> +    err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
>>> +    if (err < 0)
>>> +    return err;
>>> +    data->link_rate = drm_dp_bw_code_to_link_rate(rate);
>>> +
>>> +    err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
>>> +    if (err < 0)
>>> +    return err;
>>> +    data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
>>> +
>>> +    if (lanes & DP_ENHANCED_FRAME_CAP)
>>> +    data->enahanced_frame_cap = true;
>>> +
>>> +    err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN,
>>> >phy_pattern);
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    switch (data->phy_pattern) {
>>> +    case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
>>> +    err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
>>> +   >custom80, 10);
>> Using sizeof(data->custom80) might be safer.
>>
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    break;
>>> +    case DP_PHY_TEST_PATTERN_CP2520:
>>> +    err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
>>> +   >hbr2_reset, 2);
>> Same here, using sizeof(data->hbr2_reset).
>>
>>> +    if (err < 0)
>>> +    return err;
>>> +    }
>>> +
>>> +    return 0;
>>> +}
>>> +EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
>>> +
>>> +/**
>>> + * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
>>> + * @aux: DisplayPort AUX channel
>>> + * @data: DP phy compliance test parameters.
>>> + *
>>> + * Returns 0 on success or a negative error code on failure.
>>> + */
>>> +int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
>>> +    struct drm_dp_phy_test_params *data, u8 dp_rev)
>>> +{
>>> +    int err, i;
>>> +    u8 link_config[2];
>>> +    u8 test_pattern;
>>> +
>>> +    link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
>>> +    link_config[1] = data->num_lanes;
>>> +    if (data->enahanced_frame_cap)
>>> +    link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
>>> +    err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
>>> +    if (err < 0)
>>> +    return err;
>>> +
>>> +    test_pattern = data->phy_pattern;
>>> +    if (dp_rev < 0x12) {
>>> +    test_pattern = (test_pattern << 2) &
>>> + 

Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

[Harry Wentland]

On 2019-12-30 2:05 a.m., Wayne Lin wrote:
> [Why]
> According to DP spec, it should shift left 4 digits for NO_STOP_BIT
> in REMOTE_I2C_READ message. Not 5 digits.
> 
> [How]
> Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
> drm_dp_encode_sideband_req().
> 
> Signed-off-by: Wayne Lin 

Good catch. Looks like this has been there since the beginning of MST in
the kernel. How did you find this? Did this cause bad EDID reads or some
other problem? If so the commit message should probably mention it.

Harry

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 1d1bfa49ca2b..0557e225ff67 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct 
> drm_dp_sideband_msg_req_body *req,
>   memcpy([idx], 
> req->u.i2c_read.transactions[i].bytes, 
> req->u.i2c_read.transactions[i].num_bytes);
>   idx += req->u.i2c_read.transactions[i].num_bytes;
>  
> - buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit 
> & 0x1) << 5;
> + buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit 
> & 0x1) << 4;
>   buf[idx] |= 
> (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
>   idx++;
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Variable Refresh Rate & flickering screens

[Harry Wentland]

On 2020-03-12 7:25 a.m., Simon Ser wrote:
> On Thursday, March 12, 2020 11:45 AM, Michel Dänzer  
> wrote:
> 
>> On 2020-03-11 9:09 p.m., Simon Ser wrote:
>>
>>> Hi all,
>>> I've been working on adding VRR support to Sway [1] (a Wayland
>>> compositor). The compositor just sets the VRR_ENABLED property.
>>> This works fine for some screens, but causes flcikering for other
>>> screens as expected [2]. Fixing the flickering is something we've
>>> talked about last XDC [3]. The flickering is caused by physical
>>> limitations of the screen: changing the refresh rate too quickly
>>> results in brightness issues.
>>> The approach taken by xf86-video-amdgpu is to only enable VRR if an app
>>> is fullscreen and not present in a special Mesa blacklist (e.g. Firefox
>>> is in the blacklist because it doesn't render at a fixed interval).
>>> For Wayland, I'd prefer to avoid having a blacklist. I'd like to be
>>> able to use VRR in the general case (not just for fullscreen apps).
>>> A way to fix the flickering would be to implement a slew rate and make
>>> it so refresh rate variations are capped by the slew rate.
>>
>> One potential issue I see with this is the cursor, which can feel
>> awkward if it only moves at 30 Hz. I wonder if a slew rate which can
>> reliably prevent flickering allows the framerate to ramp up quickly
>> enough for this not to be annoying.
> 
> Thanks for pointing this out, that's a valid concern.
> 
> My VRR monitor has a 40-60Hz VRR range. With the current Sway
> implementation and drm_monitor [1], I can check that moving my mouse on
> the monitor makes the refresh interval go from ~25ms to ~16.6ms (ie.
> 40Hz to 60Hz). Right now there's no slew rate, so it goes from min to
> max instantly. I don't notice any flickering and there's no lag.
> 
> Looking at the list of monitors [2] on Wikipedia, it doesn't seem like
> there's any monitor supporting less than 35Hz.
> 
> We'd need to perform experiments on more hardware, but flickering has
> been noticed by our users on higher-end monitors which support 144Hz.
> I think the slew rate would prevent going from 35Hz to 144Hz directly,
> but probably not from 40Hz to 60Hz. I think that would be acceptable.
> 
> If it's not, we can always tweak the minimum refresh rate.
> 
> tl;dr need to test on more hardware, but should probably be fine.

Not the main VRR expert and we're still discussing this internally but I
think it'll very much depend on the display whether you'll see flicker
in this case.

The other complication is that for gaming we don't want to use the
cursor as a VRR trigger and only look at page flips in order to allow
for smooth gameplay. For a desktop use-case that's probably not the
right policy.

Harry

> 
> [1]: https://github.com/emersion/drm_monitor
> [2]: https://en.wikipedia.org/wiki/FreeSync#List_of_supported_monitors
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: amd: display: fix kernel-doc struct warning

[Harry Wentland]

On 2020-04-19 9:50 p.m., Randy Dunlap wrote:
> Fix a kernel-doc warning of missing struct field desription:
> 
> ../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:331: warning: Function 
> parameter or member 'hdcp_workqueue' not described in 'amdgpu_display_manager'
> 
> Fixes: 52704fcaf74b ("drm/amd/display: Initialize HDCP work queue")
> Signed-off-by: Randy Dunlap 
> Cc: Bhawanpreet Lakha 
> Cc: Harry Wentland 
> Cc: Alex Deucher 
> Cc: Leo Li 
> Cc: amd-...@lists.freedesktop.org

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |1 +
>  1 file changed, 1 insertion(+)
> 
> --- lnx-57-rc2.orig/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ lnx-57-rc2/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -139,6 +139,7 @@ struct amdgpu_dm_backlight_caps {
>   * @backlight_link: Link on which to control backlight
>   * @backlight_caps: Capabilities of the backlight device
>   * @freesync_module: Module handling freesync calculations
> + * @hdcp_workqueue: workqueue for display manager interaction with HDCP 
> module
>   * @fw_dmcu: Reference to DMCU firmware
>   * @dmcu_fw_version: Version of the DMCU firmware
>   * @soc_bounding_box: SOC bounding box values provided by gpu_info FW
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel