All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com>
To: Imre Deak <imre.deak@intel.com>, Jani Nikula <jani.nikula@intel.com>
Cc: <intel-gfx@lists.freedesktop.org>, <uma.shankar@intel.com>,
	<animesh.manna@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Remove check for low voltage sku for max dp source rate
Date: Thu, 7 Oct 2021 13:19:25 +0530	[thread overview]
Message-ID: <5e73ecc6-ea08-a6f0-d708-9ff0ea12c07c@intel.com> (raw)
In-Reply-To: <20211005153153.GA2847074@ideak-desk.fi.intel.com>


On 10/5/2021 9:01 PM, Imre Deak wrote:
> On Tue, Oct 05, 2021 at 01:34:21PM +0300, Jani Nikula wrote:
>> Cc: Imre, I think you were involved in adding the checks.
> About ADL-S the spec says:
>
> Bspec 53597:
> Combo Port Maximum Speed:
> OEM must use VBT to specify a maximum that is tolerated by the board design.
>
> Combo Port HBR3 support:
> May require retimer on motherboard. The OEM must use VBT to limit the link rate to HBR2 if HBR3 not supported by motherboard.
>
> Bspec/49201:
> Combo Port HBR3/6.48GHz support:
> Only supported on SKUs with higher I/O voltage
>
> I take the above meaning that only high voltage SKUs support HBR3 and
> on those SKUs the OEM must limit this to HBR2 if HBR3 would require a
> retimer on the board, but the board doesn't have this.
>
> If the above isn't correct and low voltage SKUs also in fact support
> HBR3 (with retimers if necessary) then this should imo clarified at
> Bspec/49201. The VBT limit could be used then if present, ignoring the
> low voltage SKU readout.

Thanks Imre for the inputs.

As you have mentioned note : rate >5.4 G supported only on High voltage 
I/O, is mentioned for platforms like ICL, JSL and Display 12 platforms.

I had again asked the HW team and VBT/GOP team whether we can safely 
rely on VBT for the max rate for these platforms, without worrying about 
the SKU's IO Voltage, and also requested them to update the Bspec page 
for the same.

In response the Bspec pages 49201, 20598 are now updated with the note 
"OEM must use VBT to specify a maximum that is tolerated by the board 
design" for the rates above 5.4G.

 From what I understand, we can depend upon the VBT's rate, and if there 
are some low voltage I/O SKUs that do not support HBR3 rate, it should 
be limited by the VBT.

Thanks & Regards,

Ankit

>> BR,
>> Jani.
>>
>> On Tue, 05 Oct 2021, "Nautiyal, Ankit K" <ankit.k.nautiyal@intel.com> wrote:
>>> On 10/5/2021 1:34 PM, Jani Nikula wrote:
>>>> On Tue, 05 Oct 2021, Ankit Nautiyal <ankit.k.nautiyal@intel.com> wrote:
>>>>> The low voltage sku check can be ignored as OEMs need to consider that
>>>>> when designing the board and then put any limits in VBT.
>>>> "can" or "must"?
>>>>
>>>> VBT has been notoriously buggy over the years, and we need to safeguard
>>>> against that. Are there any cases where having these checks are wrong?
>>> Hi Jani,
>>>
>>> Bspec page for Combo PHY PLL frequencies now says "OEM must use VBT to
>>> specify a maximum that is tolerated by the board design" for the rates
>>> above 5.4G.
>>>
>>> Earlier it was mentioned that rates > 5.4G were supported on SKUs with
>>> Higher I/O Voltage.
>>>
>>> There was an instance where on an ADL-S board, where VBT was showing as
>>> HBR3 supporting for a combo phy port,  but we were reading the IO
>>> voltage as 0.85V in is_low_voltage_sku()
>>>
>>> (Specifically, we were reading Register_PORT_COMP_DW3 bits 24-25 as 0)
>>> for a combo PHY port, and therefore we were limiting the BW to 5.4Gbps
>>>
>>> Due to this, 8k@60 mode was getting pruned on the board for that combo
>>> phy port. On removing the low_voltage_sku( ) the mode was able to be set
>>> properly.
>>>
>>> Incidentally, with Windows 8k@60 was also coming up on the same board on
>>> same port.
>>>
>>> So I had checked with HW team and GOP/VBT team if driver should consider
>>> the low voltage sku check.  As per their response we 'can' ignore the
>>> check and rely on the VBT, as OEM should limit the rate as per board
>>> design. The Bspec was also updated to reflect the same.
>>>
>>> So IMHO we need not limit the rate as per is_low_voltage_sku check, as
>>> this limiting of the rate through VBT is a must for the OEMs.
>>>
>>> I should perhaps change the wording of the commit message to convey the
>>> same.
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Ankit
>>>
>>>
>>>> BR,
>>>> Jani.
>>>>
>>>>> Same is now changed in Bspec (53720).
>>>>>
>>>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
>>>>> ---
>>>>>    drivers/gpu/drm/i915/display/intel_dp.c | 32 +++----------------------
>>>>>    1 file changed, 3 insertions(+), 29 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>>>>> index 74a657ae131a..75c364c3c88e 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>>>> @@ -297,23 +297,13 @@ static int dg2_max_source_rate(struct intel_dp *intel_dp)
>>>>>    	return intel_dp_is_edp(intel_dp) ? 810000 : 1350000;
>>>>>    }
>>>>>    
>>>>> -static bool is_low_voltage_sku(struct drm_i915_private *i915, enum phy phy)
>>>>> -{
>>>>> -	u32 voltage;
>>>>> -
>>>>> -	voltage = intel_de_read(i915, ICL_PORT_COMP_DW3(phy)) & VOLTAGE_INFO_MASK;
>>>>> -
>>>>> -	return voltage == VOLTAGE_INFO_0_85V;
>>>>> -}
>>>>> -
>>>>>    static int icl_max_source_rate(struct intel_dp *intel_dp)
>>>>>    {
>>>>>    	struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>>>>>    	struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>>>>>    	enum phy phy = intel_port_to_phy(dev_priv, dig_port->base.port);
>>>>>    
>>>>> -	if (intel_phy_is_combo(dev_priv, phy) &&
>>>>> -	    (is_low_voltage_sku(dev_priv, phy) || !intel_dp_is_edp(intel_dp)))
>>>>> +	if (intel_phy_is_combo(dev_priv, phy) && !intel_dp_is_edp(intel_dp))
>>>>>    		return 540000;
>>>>>    
>>>>>    	return 810000;
>>>>> @@ -321,23 +311,7 @@ static int icl_max_source_rate(struct intel_dp *intel_dp)
>>>>>    
>>>>>    static int ehl_max_source_rate(struct intel_dp *intel_dp)
>>>>>    {
>>>>> -	struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>>>>> -	struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>>>>> -	enum phy phy = intel_port_to_phy(dev_priv, dig_port->base.port);
>>>>> -
>>>>> -	if (intel_dp_is_edp(intel_dp) || is_low_voltage_sku(dev_priv, phy))
>>>>> -		return 540000;
>>>>> -
>>>>> -	return 810000;
>>>>> -}
>>>>> -
>>>>> -static int dg1_max_source_rate(struct intel_dp *intel_dp)
>>>>> -{
>>>>> -	struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>>>>> -	struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>>>>> -	enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
>>>>> -
>>>>> -	if (intel_phy_is_combo(i915, phy) && is_low_voltage_sku(i915, phy))
>>>>> +	if (intel_dp_is_edp(intel_dp))
>>>>>    		return 540000;
>>>>>    
>>>>>    	return 810000;
>>>>> @@ -380,7 +354,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>>>>>    			max_rate = dg2_max_source_rate(intel_dp);
>>>>>    		else if (IS_ALDERLAKE_P(dev_priv) || IS_ALDERLAKE_S(dev_priv) ||
>>>>>    			 IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
>>>>> -			max_rate = dg1_max_source_rate(intel_dp);
>>>>> +			max_rate = 810000;
>>>>>    		else if (IS_JSL_EHL(dev_priv))
>>>>>    			max_rate = ehl_max_source_rate(intel_dp);
>>>>>    		else
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2021-10-07  7:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05  7:15 [Intel-gfx] [PATCH] drm/i915/display: Remove check for low voltage sku for max dp source rate Ankit Nautiyal
2021-10-05  8:04 ` Jani Nikula
2021-10-05 10:20   ` Nautiyal, Ankit K
2021-10-05 10:34     ` Jani Nikula
2021-10-05 15:31       ` Imre Deak
2021-10-07  7:49         ` Nautiyal, Ankit K [this message]
2021-10-13 15:19           ` Imre Deak
2021-10-13 15:35             ` Jani Nikula
2021-10-14 11:51               ` Nautiyal, Ankit K
2021-10-14 11:32             ` Nautiyal, Ankit K
2021-10-14 12:52               ` Imre Deak
2021-10-05 11:10 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2021-10-05 15:10 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-10-19 12:24 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Remove check for low voltage sku for max dp source rate (rev3) Patchwork
2021-10-19 15:17 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2021-10-26  5:38 [Intel-gfx] [PATCH] drm/i915/display: Remove check for low voltage sku for max dp source rate Ankit Nautiyal
2021-10-26  7:53 ` Jani Nikula
2021-10-26 11:05   ` Nautiyal, Ankit K
2022-03-10 15:25 ` Imre Deak
2022-03-15  8:19   ` Nautiyal, Ankit K

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e73ecc6-ea08-a6f0-d708-9ff0ea12c07c@intel.com \
    --to=ankit.k.nautiyal@intel.com \
    --cc=animesh.manna@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=uma.shankar@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.