Re: [Intel-gfx] [RFC 7/7] drm/i915/dp: Program vswing, pre-emphasis, test-pattern

From: Animesh Manna <animesh.manna@intel.com>
To: Manasi Navare <manasi.d.navare@intel.com>
Cc: jani.nikula@intel.com, nidhi1.gupta@intel.com,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC 7/7] drm/i915/dp: Program vswing, pre-emphasis, test-pattern
Date: Fri, 13 Dec 2019 22:54:20 +0530	[thread overview]
Message-ID: <de3a0a1b-345c-d3b0-3001-cea529addf0e@intel.com> (raw)
In-Reply-To: <20191211235019.GB19224@intel.com>

Hi Manasi/Jani,

Thanks for helping phy compliance design.

Added my understanding/doubts below.

On 12/12/2019 5:20 AM, Manasi Navare wrote:
> Hi Animesh/Jani,
>
> Is this the right way to force a full modeset by adding new dev_priv->dp_phy_comp?

In modeset path we disable active crtc first then initiate the modeset 
sequence which is causing trouble in updating phy compliance parameters 
in modeset path.
As per phy compliance spec test-scope can request to change the 
following parameters,
- Test pattern
- V-swing:
- Pre-emphasis:
- Link rate:
- Lane count:

For test-pattern/v-swing/pre-emphasis, active link may not need to cut. 
Tried the same in the following patch series where I am skipping 
atomic-check, atomic-commit and write these parameters in 
atomic-commit-tail without touching anything else. Can you please share 
your thought how to handle it properly. Maybe once we are clear about 
what we should do in atomic_check/atomic_commit/atomic_commit_tail we 
can move dp_phy_comp flag to some atomic-state object.
https://patchwork.freedesktop.org/series/70300/

For Link-rate/lane-count, we need to do link-training/modeset. As per my 
observation the request is coming as link-compliance request, still 
waiting feedback from compliance team to confirm. So not handled as part 
dp-phy-compliance implementation.
> Also its still not clear to me how this will work without actualling using the phy link rate
> and lane count stored in the phy test pattern params to compute the pipe config?
> Currently those only get used directly to set the link bw.

If link-compliance request is not used for link-rate/lane-count change 
then your point is valid. As mentioned above getting link-compliance 
request which is confusing and waiting confirmation from compliance team.

> This can work if the phy comp runs after link layer comp but on standalone phy comp testing
> this could be a problem.
>
> Also I dont see my comment addressed where I had asked to move the below to patch 3:
>>> +   /* Set test active flag here so userspace doesn't interrupt things */
>>> +   intel_dp->compliance.test_active = 1;
>>> +   dev_priv->dp_phy_comp = true;
>>> +

Thinking of creating a separate patch for sending uevent and setting 
test_active flag true for intel_dp_compliance tool.
The patch 3/7 will take the preparation part and acknowledge the test 
request. Hope it will be fine.

Regards,
Animesh

> Manasi
>
>
> On Sun, Nov 17, 2019 at 11:53:54PM -0800, Manasi Navare wrote:
>> On Fri, Nov 15, 2019 at 08:55:49PM +0530, Animesh Manna wrote:
>>> This patch process phy compliance request by programming requested
>>> vswing, pre-emphasis and test pattern.
>> Again here a slightly detailed description of where in the atomic modeset
>> do we process the PHY com request would be good.
>>
>> The design overall looks good now, few comments below:
>>
>>> Signed-off-by: Animesh Manna <animesh.manna@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/display/intel_ddi.c     | 14 ++++
>>>   drivers/gpu/drm/i915/display/intel_display.c |  5 ++
>>>   drivers/gpu/drm/i915/display/intel_dp.c      | 77 ++++++++++++++++++++
>>>   drivers/gpu/drm/i915/display/intel_dp.h      |  2 +
>>>   drivers/gpu/drm/i915/i915_drv.h              |  2 +
>>>   5 files changed, 100 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> index 8f817de34460..c12d4ebbd352 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> @@ -3700,8 +3700,17 @@ static void intel_ddi_pre_enable(struct intel_encoder *encoder,
>>>   {
>>>   	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>>>   	struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>> +	struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
>>>   	enum pipe pipe = crtc->pipe;
>>>   
>>> +	if (encoder->type == INTEL_OUTPUT_DP) {
>>> +		if (dig_port->dp.compliance.test_type ==
>>> +		    DP_TEST_LINK_PHY_TEST_PATTERN) {
>>> +			intel_dp_process_phy_request(&dig_port->dp);
>>> +			return;
>>> +		}
>>> +	}
>>> +
>>>   	/*
>>>   	 * When called from DP MST code:
>>>   	 * - conn_state will be NULL
>>> @@ -4147,6 +4156,11 @@ intel_ddi_pre_pll_enable(struct intel_encoder *encoder,
>>>   	enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
>>>   	bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
>>>   
>>> +	if (encoder->type == INTEL_OUTPUT_DP)
>>> +		if (dig_port->dp.compliance.test_type ==
>>> +		    DP_TEST_LINK_PHY_TEST_PATTERN)
>>> +			return;
>>> +
>>>   	if (is_tc_port)
>>>   		intel_tc_port_get_link(dig_port, crtc_state->lane_count);
>>>   
>>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
>>> index adf50c4b38ad..4ad11df55f07 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>>> @@ -545,6 +545,11 @@ icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, enum pipe pipe,
>>>   static bool
>>>   needs_modeset(const struct intel_crtc_state *state)
>>>   {
>>> +	struct drm_i915_private *dev_priv = to_i915(state->uapi.crtc->dev);
>>> +
>>> +	if (dev_priv->dp_phy_comp)
>>> +		return true;
>> Could you double check with Jani N if this is an acceptable solution to
>> foce a full modeset for a PHY compliance test?
>>
>>> +
>>>   	return drm_atomic_crtc_needs_modeset(&state->uapi);
>>>   }
>>>   
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>>> index df31278a1619..2c3d4b6c6036 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>> @@ -5010,14 +5010,91 @@ static inline void intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
>>>   	}
>>>   }
>>>   
>>> +static void
>>> +intel_dp_autotest_phy_ddi_disable(struct intel_dp *intel_dp)
>>> +{
>>> +	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>>> +	struct drm_device *dev = intel_dig_port->base.base.dev;
>>> +	struct drm_i915_private *dev_priv = to_i915(dev);
>>> +	enum port port = intel_dig_port->base.port;
>>> +	u32 ddi_buf_ctl_value, dp_tp_ctl_value, trans_ddi_func_ctl_value;
>>> +
>>> +	ddi_buf_ctl_value = I915_READ(DDI_BUF_CTL(port));
>>> +	dp_tp_ctl_value = I915_READ(TGL_DP_TP_CTL(port));
>>> +	trans_ddi_func_ctl_value = I915_READ(TRANS_DDI_FUNC_CTL(port));
>>> +
>>> +	ddi_buf_ctl_value        &= ~(DDI_BUF_CTL_ENABLE | DDI_PORT_WIDTH_MASK);
>>> +	dp_tp_ctl_value          &= ~DP_TP_CTL_ENABLE;
>>> +	trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
>>> +				      DDI_PORT_WIDTH_MASK);
>>> +
>>> +	I915_WRITE(DDI_BUF_CTL(port), ddi_buf_ctl_value);
>>> +	I915_WRITE(TGL_DP_TP_CTL(port), dp_tp_ctl_value);
>>> +	I915_WRITE(TRANS_DDI_FUNC_CTL(port), trans_ddi_func_ctl_value);
>>> +}
>>> +
>>> +static void
>>> +intel_dp_autotest_phy_ddi_enable(struct intel_dp *intel_dp, uint8_t lane_cnt)
>>> +{
>>> +	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>>> +	struct drm_device *dev = intel_dig_port->base.base.dev;
>>> +	struct drm_i915_private *dev_priv = to_i915(dev);
>>> +	enum port port = intel_dig_port->base.port;
>>> +	u32 ddi_buf_ctl_value, dp_tp_ctl_value, trans_ddi_func_ctl_value;
>>> +
>>> +	ddi_buf_ctl_value = I915_READ(DDI_BUF_CTL(port));
>>> +	dp_tp_ctl_value = I915_READ(TGL_DP_TP_CTL(port));
>>> +	trans_ddi_func_ctl_value = I915_READ(TRANS_DDI_FUNC_CTL(port));
>>> +
>>> +	ddi_buf_ctl_value        |= DDI_BUF_CTL_ENABLE |
>>> +				    DDI_PORT_WIDTH(lane_cnt);
>>> +	dp_tp_ctl_value          |= DP_TP_CTL_ENABLE;
>>> +	trans_ddi_func_ctl_value |= TRANS_DDI_FUNC_ENABLE |
>>> +				    DDI_PORT_WIDTH(lane_cnt);
>>> +
>>> +	I915_WRITE(TRANS_DDI_FUNC_CTL(port), trans_ddi_func_ctl_value);
>>> +	I915_WRITE(TGL_DP_TP_CTL(port), dp_tp_ctl_value);
>>> +	I915_WRITE(DDI_BUF_CTL(port), ddi_buf_ctl_value);
>>> +}
>>> +
>>> +void intel_dp_process_phy_request(struct intel_dp *intel_dp)
>>> +{
>>> +	struct drm_dp_phy_test_params *data =
>>> +		&intel_dp->compliance.test_data.phytest;
>>> +	u8 link_status[DP_LINK_STATUS_SIZE];
>>> +
>>> +	if (!intel_dp_get_link_status(intel_dp, link_status)) {
>>> +		DRM_DEBUG_KMS("failed to get link status\n");
>>> +		return;
>>> +	}
>>> +
>>> +	/* retrieve vswing & pre-emphasis setting */
>>> +	intel_get_adjust_train(intel_dp, link_status);
>>> +
>>> +	intel_dp_autotest_phy_ddi_disable(intel_dp);
>>> +
>>> +	intel_dp_set_signal_levels(intel_dp);
>>> +
>>> +	intel_dp_phy_pattern_update(intel_dp);
>>> +
>>> +	intel_dp_autotest_phy_ddi_enable(intel_dp, data->num_lanes);
>>> +
>>> +	drm_dp_set_phy_test_pattern(&intel_dp->aux, data);
>>> +}
>>> +
>>>   static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
>>>   {
>>>   	u8 test_result = DP_TEST_NAK;
>>> +	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>>>   
>>>   	test_result = intel_dp_prepare_phytest(intel_dp);
>>>   	if (test_result != DP_TEST_ACK)
>>>   		DRM_ERROR("Phy test preparation failed\n");
>>>   
>>> +	/* Set test active flag here so userspace doesn't interrupt things */
>>> +	intel_dp->compliance.test_active = 1;
>>> +	dev_priv->dp_phy_comp = true;
>>> +
>> This should be moved to the patch 3 I think where you handle  phy test request and
>> call prepare function. The same patch that handles test req can set the test active to 1.
>>
>>>   	return test_result;
>>>   }
>>>   
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
>>> index 0d0cb692f701..b1274ecffc7f 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.h
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
>>> @@ -120,6 +120,8 @@ void intel_dp_hdr_metadata_enable(struct intel_dp *intel_dp,
>>>   				  const struct intel_crtc_state *crtc_state,
>>>   				  const struct drm_connector_state *conn_state);
>>>   bool intel_digital_port_connected(struct intel_encoder *encoder);
>>> +void intel_dp_process_phy_request(struct intel_dp *intel_dp);
>>> +
>>>   
>>>   static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
>>>   {
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>>> index 1779f600fcfb..232e0dfb9d8e 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -1285,6 +1285,8 @@ struct drm_i915_private {
>>>   
>>>   	I915_SELFTEST_DECLARE(struct i915_selftest_stash selftest;)
>>>   
>>> +	bool dp_phy_comp;
>> Not sure if this is the best way to handle the full mdoeset, could you double
>> check with Jani?
>>
>> Other than that I think now the placement in pre_enable_dp is good.
>>
>> The only other concern I have is changing link rate and lane count only happens
>> in set_phy_patterns where we write the test link rate and lane count
>> directly to the link bw set. But the driver's compute config is still configuring
>> the pipe and plls based on the link rate and lane count that could be
>> different than the test link rate/count. This might work now since you said
>> the link layer test is already configuring it at test params but in general
>> shouldnt we be using the phy->link rate and lane count if in phy compliance
>> also in compute_config()?
>>
>> Jani, any thoughts here?
>>
>> Regards
>> Manasi
>>
>>> +
>>>   	/*
>>>   	 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>>>   	 * will be rejected. Instead look for a better place.
>>> -- 
>>> 2.22.0
>>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx