Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Manasi Navare]

On Thu, Sep 29, 2016 at 04:17:06PM -0700, Manasi Navare wrote:
> On Thu, Sep 29, 2016 at 09:05:01AM -0700, Manasi Navare wrote:
> > On Thu, Sep 29, 2016 at 06:48:43PM +0300, Jani Nikula wrote:
> > > On Thu, 29 Sep 2016, Ville Syrjälä  wrote:
> > > > On Thu, Sep 29, 2016 at 12:44:19PM +0100, Chris Wilson wrote:
> > > >> On Thu, Sep 29, 2016 at 02:26:16PM +0300, Jani Nikula wrote:
> > > >> > On Thu, 29 Sep 2016, Manasi Navare  wrote:
> > > >> > > On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> > > >> > >> On Tue, 27 Sep 2016, Manasi Navare  
> > > >> > >> wrote:
> > > >> > >> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> > > >> > >> >> On Fri, 16 Sep 2016, Manasi Navare  
> > > >> > >> >> wrote:
> > > >> > >> >> > According to the DisplayPort Spec, in case of Clock Recovery 
> > > >> > >> >> > failure
> > > >> > >> >> > the link training sequence should fall back to the lower 
> > > >> > >> >> > link rate
> > > >> > >> >> > followed by lower lane count until CR succeeds.
> > > >> > >> >> > On CR success, the sequence proceeds with Channel EQ.
> > > >> > >> >> > In case of Channel EQ failures, it should fallback to
> > > >> > >> >> > lower link rate and lane count and start the CR phase again.
> > > >> > >> >> 
> > > >> > >> >> This change makes the link training start at the max lane 
> > > >> > >> >> count and max
> > > >> > >> >> link rate. This is not ideal, as it wastes the link. And it is 
> > > >> > >> >> not a
> > > >> > >> >> spec requirement. "The Link Policy Maker of the upstream 
> > > >> > >> >> device may
> > > >> > >> >> choose any link count and link rate as long as they do not 
> > > >> > >> >> exceed the
> > > >> > >> >> capabilities of the DP receiver."
> > > >> > >> >> 
> > > >> > >> >> Our current code starts at the minimum required bandwidth for 
> > > >> > >> >> the mode,
> > > >> > >> >> therefore we can't fall back to lower link rate and lane count 
> > > >> > >> >> without
> > > >> > >> >> reducing the mode.
> > > >> > >> >> 
> > > >> > >> >> AFAICT this patch here makes it possible for the link 
> > > >> > >> >> bandwidth to drop
> > > >> > >> >> below what is required for the mode. This is unacceptable.
> > > >> > >> >> 
> > > >> > >> >> BR,
> > > >> > >> >> Jani.
> > > >> > >> >> 
> > > >> > >> >>
> > > >> > >> >
> > > >> > >> > Thanks Jani for your review comments.
> > > >> > >> > Yes in this change we start at the max link rate and lane 
> > > >> > >> > count. This
> > > >> > >> > change was made according to the design document discussions we 
> > > >> > >> > had
> > > >> > >> > before strating this DP Redesign project. The main reason for 
> > > >> > >> > starting
> > > >> > >> > at the maxlink rate and max lane count was for ensuring proper
> > > >> > >> > behavior of DP MST. In case of DP MST, we want to train the 
> > > >> > >> > link at
> > > >> > >> > the maximum supported link rate/lane count based on an early/ 
> > > >> > >> > upfront
> > > >> > >> > link training result so that we dont fail when we try to 
> > > >> > >> > connect a
> > > >> > >> > higher resolution monitor as a second monitor. This a trade off
> > > >> > >> > between wsting the link or higher power vs. needing to retrain 
> > > >> > >> > for
> > > >> > >> > every monitor that requests a higher BW in case of DP MST.
> > > >> > >> 
> > > >> > >> We already train at max bandwidth for DP MST, which seems to be 
> > > >> > >> the
> > > >> > >> sensible thing to do.
> > > >> > >> 
> > > >> > >> > Actually this is also the reason for enabling upfront link 
> > > >> > >> > training in
> > > >> > >> > the following patch where we train the link much ahead in the 
> > > >> > >> > modeset
> > > >> > >> > sequence to understand the link rate and lane count values at 
> > > >> > >> > which
> > > >> > >> > the link can be successfully trained and then the link training
> > > >> > >> > through modeset will always start at the upfront values (maximum
> > > >> > >> > supported values of lane count and link rate based on upfront 
> > > >> > >> > link
> > > >> > >> > training).
> > > >> > >> 
> > > >> > >> I don't see a need to do this for DP SST.
> > > >> > >> 
> > > >> > >> > As per the CTS, all the test 4.3.1.4 requires that you fall 
> > > >> > >> > back to
> > > >> > >> > the lower link rate after trying to train at the maximum link 
> > > >> > >> > rate
> > > >> > >> > advertised through the DPCD registers.
> > > >> > >> 
> > > >> > >> That test does not require the source DUT to default to maximum 
> > > >> > >> lane
> > > >> > >> count or link rate of the sink. The source may freely choose the 
> > > >> > >> lane
> > > >> > >> count and link rate as long as they don't exceed sink 
> > > >> > >> capabilities.
> > > >> > >> 
> > > >> > >> For the purposes of the test, the test setup can request specific
> > > >> > >> parameters to be used, but that does not mean using 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Manasi Navare]

On Thu, Sep 29, 2016 at 09:05:01AM -0700, Manasi Navare wrote:
> On Thu, Sep 29, 2016 at 06:48:43PM +0300, Jani Nikula wrote:
> > On Thu, 29 Sep 2016, Ville Syrjälä  wrote:
> > > On Thu, Sep 29, 2016 at 12:44:19PM +0100, Chris Wilson wrote:
> > >> On Thu, Sep 29, 2016 at 02:26:16PM +0300, Jani Nikula wrote:
> > >> > On Thu, 29 Sep 2016, Manasi Navare  wrote:
> > >> > > On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> > >> > >> On Tue, 27 Sep 2016, Manasi Navare  
> > >> > >> wrote:
> > >> > >> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> > >> > >> >> On Fri, 16 Sep 2016, Manasi Navare  
> > >> > >> >> wrote:
> > >> > >> >> > According to the DisplayPort Spec, in case of Clock Recovery 
> > >> > >> >> > failure
> > >> > >> >> > the link training sequence should fall back to the lower link 
> > >> > >> >> > rate
> > >> > >> >> > followed by lower lane count until CR succeeds.
> > >> > >> >> > On CR success, the sequence proceeds with Channel EQ.
> > >> > >> >> > In case of Channel EQ failures, it should fallback to
> > >> > >> >> > lower link rate and lane count and start the CR phase again.
> > >> > >> >> 
> > >> > >> >> This change makes the link training start at the max lane count 
> > >> > >> >> and max
> > >> > >> >> link rate. This is not ideal, as it wastes the link. And it is 
> > >> > >> >> not a
> > >> > >> >> spec requirement. "The Link Policy Maker of the upstream device 
> > >> > >> >> may
> > >> > >> >> choose any link count and link rate as long as they do not 
> > >> > >> >> exceed the
> > >> > >> >> capabilities of the DP receiver."
> > >> > >> >> 
> > >> > >> >> Our current code starts at the minimum required bandwidth for 
> > >> > >> >> the mode,
> > >> > >> >> therefore we can't fall back to lower link rate and lane count 
> > >> > >> >> without
> > >> > >> >> reducing the mode.
> > >> > >> >> 
> > >> > >> >> AFAICT this patch here makes it possible for the link bandwidth 
> > >> > >> >> to drop
> > >> > >> >> below what is required for the mode. This is unacceptable.
> > >> > >> >> 
> > >> > >> >> BR,
> > >> > >> >> Jani.
> > >> > >> >> 
> > >> > >> >>
> > >> > >> >
> > >> > >> > Thanks Jani for your review comments.
> > >> > >> > Yes in this change we start at the max link rate and lane count. 
> > >> > >> > This
> > >> > >> > change was made according to the design document discussions we 
> > >> > >> > had
> > >> > >> > before strating this DP Redesign project. The main reason for 
> > >> > >> > starting
> > >> > >> > at the maxlink rate and max lane count was for ensuring proper
> > >> > >> > behavior of DP MST. In case of DP MST, we want to train the link 
> > >> > >> > at
> > >> > >> > the maximum supported link rate/lane count based on an early/ 
> > >> > >> > upfront
> > >> > >> > link training result so that we dont fail when we try to connect a
> > >> > >> > higher resolution monitor as a second monitor. This a trade off
> > >> > >> > between wsting the link or higher power vs. needing to retrain for
> > >> > >> > every monitor that requests a higher BW in case of DP MST.
> > >> > >> 
> > >> > >> We already train at max bandwidth for DP MST, which seems to be the
> > >> > >> sensible thing to do.
> > >> > >> 
> > >> > >> > Actually this is also the reason for enabling upfront link 
> > >> > >> > training in
> > >> > >> > the following patch where we train the link much ahead in the 
> > >> > >> > modeset
> > >> > >> > sequence to understand the link rate and lane count values at 
> > >> > >> > which
> > >> > >> > the link can be successfully trained and then the link training
> > >> > >> > through modeset will always start at the upfront values (maximum
> > >> > >> > supported values of lane count and link rate based on upfront link
> > >> > >> > training).
> > >> > >> 
> > >> > >> I don't see a need to do this for DP SST.
> > >> > >> 
> > >> > >> > As per the CTS, all the test 4.3.1.4 requires that you fall back 
> > >> > >> > to
> > >> > >> > the lower link rate after trying to train at the maximum link rate
> > >> > >> > advertised through the DPCD registers.
> > >> > >> 
> > >> > >> That test does not require the source DUT to default to maximum lane
> > >> > >> count or link rate of the sink. The source may freely choose the 
> > >> > >> lane
> > >> > >> count and link rate as long as they don't exceed sink capabilities.
> > >> > >> 
> > >> > >> For the purposes of the test, the test setup can request specific
> > >> > >> parameters to be used, but that does not mean using maximum by
> > >> > >> *default*.
> > >> > >> 
> > >> > >> We currently lack the feature to reduce lane count and link rate. 
> > >> > >> The
> > >> > >> key to understand here is that starting at max and reducing down to 
> > >> > >> the
> > >> > >> sufficient parameters for the mode (which is where we start now) 
> > >> > >> offers
> > >> > >> no real 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Manasi Navare]

On Thu, Sep 29, 2016 at 06:48:43PM +0300, Jani Nikula wrote:
> On Thu, 29 Sep 2016, Ville Syrjälä  wrote:
> > On Thu, Sep 29, 2016 at 12:44:19PM +0100, Chris Wilson wrote:
> >> On Thu, Sep 29, 2016 at 02:26:16PM +0300, Jani Nikula wrote:
> >> > On Thu, 29 Sep 2016, Manasi Navare  wrote:
> >> > > On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> >> > >> On Tue, 27 Sep 2016, Manasi Navare  wrote:
> >> > >> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> >> > >> >> On Fri, 16 Sep 2016, Manasi Navare  
> >> > >> >> wrote:
> >> > >> >> > According to the DisplayPort Spec, in case of Clock Recovery 
> >> > >> >> > failure
> >> > >> >> > the link training sequence should fall back to the lower link 
> >> > >> >> > rate
> >> > >> >> > followed by lower lane count until CR succeeds.
> >> > >> >> > On CR success, the sequence proceeds with Channel EQ.
> >> > >> >> > In case of Channel EQ failures, it should fallback to
> >> > >> >> > lower link rate and lane count and start the CR phase again.
> >> > >> >> 
> >> > >> >> This change makes the link training start at the max lane count 
> >> > >> >> and max
> >> > >> >> link rate. This is not ideal, as it wastes the link. And it is not 
> >> > >> >> a
> >> > >> >> spec requirement. "The Link Policy Maker of the upstream device may
> >> > >> >> choose any link count and link rate as long as they do not exceed 
> >> > >> >> the
> >> > >> >> capabilities of the DP receiver."
> >> > >> >> 
> >> > >> >> Our current code starts at the minimum required bandwidth for the 
> >> > >> >> mode,
> >> > >> >> therefore we can't fall back to lower link rate and lane count 
> >> > >> >> without
> >> > >> >> reducing the mode.
> >> > >> >> 
> >> > >> >> AFAICT this patch here makes it possible for the link bandwidth to 
> >> > >> >> drop
> >> > >> >> below what is required for the mode. This is unacceptable.
> >> > >> >> 
> >> > >> >> BR,
> >> > >> >> Jani.
> >> > >> >> 
> >> > >> >>
> >> > >> >
> >> > >> > Thanks Jani for your review comments.
> >> > >> > Yes in this change we start at the max link rate and lane count. 
> >> > >> > This
> >> > >> > change was made according to the design document discussions we had
> >> > >> > before strating this DP Redesign project. The main reason for 
> >> > >> > starting
> >> > >> > at the maxlink rate and max lane count was for ensuring proper
> >> > >> > behavior of DP MST. In case of DP MST, we want to train the link at
> >> > >> > the maximum supported link rate/lane count based on an early/ 
> >> > >> > upfront
> >> > >> > link training result so that we dont fail when we try to connect a
> >> > >> > higher resolution monitor as a second monitor. This a trade off
> >> > >> > between wsting the link or higher power vs. needing to retrain for
> >> > >> > every monitor that requests a higher BW in case of DP MST.
> >> > >> 
> >> > >> We already train at max bandwidth for DP MST, which seems to be the
> >> > >> sensible thing to do.
> >> > >> 
> >> > >> > Actually this is also the reason for enabling upfront link training 
> >> > >> > in
> >> > >> > the following patch where we train the link much ahead in the 
> >> > >> > modeset
> >> > >> > sequence to understand the link rate and lane count values at which
> >> > >> > the link can be successfully trained and then the link training
> >> > >> > through modeset will always start at the upfront values (maximum
> >> > >> > supported values of lane count and link rate based on upfront link
> >> > >> > training).
> >> > >> 
> >> > >> I don't see a need to do this for DP SST.
> >> > >> 
> >> > >> > As per the CTS, all the test 4.3.1.4 requires that you fall back to
> >> > >> > the lower link rate after trying to train at the maximum link rate
> >> > >> > advertised through the DPCD registers.
> >> > >> 
> >> > >> That test does not require the source DUT to default to maximum lane
> >> > >> count or link rate of the sink. The source may freely choose the lane
> >> > >> count and link rate as long as they don't exceed sink capabilities.
> >> > >> 
> >> > >> For the purposes of the test, the test setup can request specific
> >> > >> parameters to be used, but that does not mean using maximum by
> >> > >> *default*.
> >> > >> 
> >> > >> We currently lack the feature to reduce lane count and link rate. The
> >> > >> key to understand here is that starting at max and reducing down to 
> >> > >> the
> >> > >> sufficient parameters for the mode (which is where we start now) 
> >> > >> offers
> >> > >> no real benefit for any use case. What we're lacking is a feature to
> >> > >> reduce the link parameters *below* what's required by the mode the
> >> > >> userspace wants. This can only be achieved through cooperation with
> >> > >> userspace.
> >> > >> 
> >> > >
> >> > > We can train at the optimal link rate required for the requested mode 
> >> > > as
> >> > > done 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Jani Nikula]

On Thu, 29 Sep 2016, Ville Syrjälä  wrote:
> On Thu, Sep 29, 2016 at 12:44:19PM +0100, Chris Wilson wrote:
>> On Thu, Sep 29, 2016 at 02:26:16PM +0300, Jani Nikula wrote:
>> > On Thu, 29 Sep 2016, Manasi Navare  wrote:
>> > > On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
>> > >> On Tue, 27 Sep 2016, Manasi Navare  wrote:
>> > >> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
>> > >> >> On Fri, 16 Sep 2016, Manasi Navare  wrote:
>> > >> >> > According to the DisplayPort Spec, in case of Clock Recovery 
>> > >> >> > failure
>> > >> >> > the link training sequence should fall back to the lower link rate
>> > >> >> > followed by lower lane count until CR succeeds.
>> > >> >> > On CR success, the sequence proceeds with Channel EQ.
>> > >> >> > In case of Channel EQ failures, it should fallback to
>> > >> >> > lower link rate and lane count and start the CR phase again.
>> > >> >> 
>> > >> >> This change makes the link training start at the max lane count and 
>> > >> >> max
>> > >> >> link rate. This is not ideal, as it wastes the link. And it is not a
>> > >> >> spec requirement. "The Link Policy Maker of the upstream device may
>> > >> >> choose any link count and link rate as long as they do not exceed the
>> > >> >> capabilities of the DP receiver."
>> > >> >> 
>> > >> >> Our current code starts at the minimum required bandwidth for the 
>> > >> >> mode,
>> > >> >> therefore we can't fall back to lower link rate and lane count 
>> > >> >> without
>> > >> >> reducing the mode.
>> > >> >> 
>> > >> >> AFAICT this patch here makes it possible for the link bandwidth to 
>> > >> >> drop
>> > >> >> below what is required for the mode. This is unacceptable.
>> > >> >> 
>> > >> >> BR,
>> > >> >> Jani.
>> > >> >> 
>> > >> >>
>> > >> >
>> > >> > Thanks Jani for your review comments.
>> > >> > Yes in this change we start at the max link rate and lane count. This
>> > >> > change was made according to the design document discussions we had
>> > >> > before strating this DP Redesign project. The main reason for starting
>> > >> > at the maxlink rate and max lane count was for ensuring proper
>> > >> > behavior of DP MST. In case of DP MST, we want to train the link at
>> > >> > the maximum supported link rate/lane count based on an early/ upfront
>> > >> > link training result so that we dont fail when we try to connect a
>> > >> > higher resolution monitor as a second monitor. This a trade off
>> > >> > between wsting the link or higher power vs. needing to retrain for
>> > >> > every monitor that requests a higher BW in case of DP MST.
>> > >> 
>> > >> We already train at max bandwidth for DP MST, which seems to be the
>> > >> sensible thing to do.
>> > >> 
>> > >> > Actually this is also the reason for enabling upfront link training in
>> > >> > the following patch where we train the link much ahead in the modeset
>> > >> > sequence to understand the link rate and lane count values at which
>> > >> > the link can be successfully trained and then the link training
>> > >> > through modeset will always start at the upfront values (maximum
>> > >> > supported values of lane count and link rate based on upfront link
>> > >> > training).
>> > >> 
>> > >> I don't see a need to do this for DP SST.
>> > >> 
>> > >> > As per the CTS, all the test 4.3.1.4 requires that you fall back to
>> > >> > the lower link rate after trying to train at the maximum link rate
>> > >> > advertised through the DPCD registers.
>> > >> 
>> > >> That test does not require the source DUT to default to maximum lane
>> > >> count or link rate of the sink. The source may freely choose the lane
>> > >> count and link rate as long as they don't exceed sink capabilities.
>> > >> 
>> > >> For the purposes of the test, the test setup can request specific
>> > >> parameters to be used, but that does not mean using maximum by
>> > >> *default*.
>> > >> 
>> > >> We currently lack the feature to reduce lane count and link rate. The
>> > >> key to understand here is that starting at max and reducing down to the
>> > >> sufficient parameters for the mode (which is where we start now) offers
>> > >> no real benefit for any use case. What we're lacking is a feature to
>> > >> reduce the link parameters *below* what's required by the mode the
>> > >> userspace wants. This can only be achieved through cooperation with
>> > >> userspace.
>> > >> 
>> > >
>> > > We can train at the optimal link rate required for the requested mode as
>> > > done in the existing implementation and retrain whenever the link 
>> > > training
>> > > test request is sent. 
>> > > For the test 4.3.1.4 in CTS, it does force a failure in CR and expects 
>> > > the
>> > > driver to fall back to even lower link rate. We do not implement this in 
>> > > the
>> > > current driver and so this test fails. Could you elaborate on how this 
>> > > can
>> > > be 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Ville Syrjälä]

On Thu, Sep 29, 2016 at 12:44:19PM +0100, Chris Wilson wrote:
> On Thu, Sep 29, 2016 at 02:26:16PM +0300, Jani Nikula wrote:
> > On Thu, 29 Sep 2016, Manasi Navare  wrote:
> > > On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> > >> On Tue, 27 Sep 2016, Manasi Navare  wrote:
> > >> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> > >> >> On Fri, 16 Sep 2016, Manasi Navare  wrote:
> > >> >> > According to the DisplayPort Spec, in case of Clock Recovery failure
> > >> >> > the link training sequence should fall back to the lower link rate
> > >> >> > followed by lower lane count until CR succeeds.
> > >> >> > On CR success, the sequence proceeds with Channel EQ.
> > >> >> > In case of Channel EQ failures, it should fallback to
> > >> >> > lower link rate and lane count and start the CR phase again.
> > >> >> 
> > >> >> This change makes the link training start at the max lane count and 
> > >> >> max
> > >> >> link rate. This is not ideal, as it wastes the link. And it is not a
> > >> >> spec requirement. "The Link Policy Maker of the upstream device may
> > >> >> choose any link count and link rate as long as they do not exceed the
> > >> >> capabilities of the DP receiver."
> > >> >> 
> > >> >> Our current code starts at the minimum required bandwidth for the 
> > >> >> mode,
> > >> >> therefore we can't fall back to lower link rate and lane count without
> > >> >> reducing the mode.
> > >> >> 
> > >> >> AFAICT this patch here makes it possible for the link bandwidth to 
> > >> >> drop
> > >> >> below what is required for the mode. This is unacceptable.
> > >> >> 
> > >> >> BR,
> > >> >> Jani.
> > >> >> 
> > >> >>
> > >> >
> > >> > Thanks Jani for your review comments.
> > >> > Yes in this change we start at the max link rate and lane count. This
> > >> > change was made according to the design document discussions we had
> > >> > before strating this DP Redesign project. The main reason for starting
> > >> > at the maxlink rate and max lane count was for ensuring proper
> > >> > behavior of DP MST. In case of DP MST, we want to train the link at
> > >> > the maximum supported link rate/lane count based on an early/ upfront
> > >> > link training result so that we dont fail when we try to connect a
> > >> > higher resolution monitor as a second monitor. This a trade off
> > >> > between wsting the link or higher power vs. needing to retrain for
> > >> > every monitor that requests a higher BW in case of DP MST.
> > >> 
> > >> We already train at max bandwidth for DP MST, which seems to be the
> > >> sensible thing to do.
> > >> 
> > >> > Actually this is also the reason for enabling upfront link training in
> > >> > the following patch where we train the link much ahead in the modeset
> > >> > sequence to understand the link rate and lane count values at which
> > >> > the link can be successfully trained and then the link training
> > >> > through modeset will always start at the upfront values (maximum
> > >> > supported values of lane count and link rate based on upfront link
> > >> > training).
> > >> 
> > >> I don't see a need to do this for DP SST.
> > >> 
> > >> > As per the CTS, all the test 4.3.1.4 requires that you fall back to
> > >> > the lower link rate after trying to train at the maximum link rate
> > >> > advertised through the DPCD registers.
> > >> 
> > >> That test does not require the source DUT to default to maximum lane
> > >> count or link rate of the sink. The source may freely choose the lane
> > >> count and link rate as long as they don't exceed sink capabilities.
> > >> 
> > >> For the purposes of the test, the test setup can request specific
> > >> parameters to be used, but that does not mean using maximum by
> > >> *default*.
> > >> 
> > >> We currently lack the feature to reduce lane count and link rate. The
> > >> key to understand here is that starting at max and reducing down to the
> > >> sufficient parameters for the mode (which is where we start now) offers
> > >> no real benefit for any use case. What we're lacking is a feature to
> > >> reduce the link parameters *below* what's required by the mode the
> > >> userspace wants. This can only be achieved through cooperation with
> > >> userspace.
> > >> 
> > >
> > > We can train at the optimal link rate required for the requested mode as
> > > done in the existing implementation and retrain whenever the link training
> > > test request is sent. 
> > > For the test 4.3.1.4 in CTS, it does force a failure in CR and expects the
> > > driver to fall back to even lower link rate. We do not implement this in 
> > > the
> > > current driver and so this test fails. Could you elaborate on how this can
> > > be achieved with the the cooperation with userspace?
> > > Should we send a uevent to the userspace asking to retry at a lower 
> > > resolution
> > > after retraining at the lower link rate?
> > > This is pertty 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Chris Wilson]

On Thu, Sep 29, 2016 at 02:26:16PM +0300, Jani Nikula wrote:
> On Thu, 29 Sep 2016, Manasi Navare  wrote:
> > On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> >> On Tue, 27 Sep 2016, Manasi Navare  wrote:
> >> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> >> >> On Fri, 16 Sep 2016, Manasi Navare  wrote:
> >> >> > According to the DisplayPort Spec, in case of Clock Recovery failure
> >> >> > the link training sequence should fall back to the lower link rate
> >> >> > followed by lower lane count until CR succeeds.
> >> >> > On CR success, the sequence proceeds with Channel EQ.
> >> >> > In case of Channel EQ failures, it should fallback to
> >> >> > lower link rate and lane count and start the CR phase again.
> >> >> 
> >> >> This change makes the link training start at the max lane count and max
> >> >> link rate. This is not ideal, as it wastes the link. And it is not a
> >> >> spec requirement. "The Link Policy Maker of the upstream device may
> >> >> choose any link count and link rate as long as they do not exceed the
> >> >> capabilities of the DP receiver."
> >> >> 
> >> >> Our current code starts at the minimum required bandwidth for the mode,
> >> >> therefore we can't fall back to lower link rate and lane count without
> >> >> reducing the mode.
> >> >> 
> >> >> AFAICT this patch here makes it possible for the link bandwidth to drop
> >> >> below what is required for the mode. This is unacceptable.
> >> >> 
> >> >> BR,
> >> >> Jani.
> >> >> 
> >> >>
> >> >
> >> > Thanks Jani for your review comments.
> >> > Yes in this change we start at the max link rate and lane count. This
> >> > change was made according to the design document discussions we had
> >> > before strating this DP Redesign project. The main reason for starting
> >> > at the maxlink rate and max lane count was for ensuring proper
> >> > behavior of DP MST. In case of DP MST, we want to train the link at
> >> > the maximum supported link rate/lane count based on an early/ upfront
> >> > link training result so that we dont fail when we try to connect a
> >> > higher resolution monitor as a second monitor. This a trade off
> >> > between wsting the link or higher power vs. needing to retrain for
> >> > every monitor that requests a higher BW in case of DP MST.
> >> 
> >> We already train at max bandwidth for DP MST, which seems to be the
> >> sensible thing to do.
> >> 
> >> > Actually this is also the reason for enabling upfront link training in
> >> > the following patch where we train the link much ahead in the modeset
> >> > sequence to understand the link rate and lane count values at which
> >> > the link can be successfully trained and then the link training
> >> > through modeset will always start at the upfront values (maximum
> >> > supported values of lane count and link rate based on upfront link
> >> > training).
> >> 
> >> I don't see a need to do this for DP SST.
> >> 
> >> > As per the CTS, all the test 4.3.1.4 requires that you fall back to
> >> > the lower link rate after trying to train at the maximum link rate
> >> > advertised through the DPCD registers.
> >> 
> >> That test does not require the source DUT to default to maximum lane
> >> count or link rate of the sink. The source may freely choose the lane
> >> count and link rate as long as they don't exceed sink capabilities.
> >> 
> >> For the purposes of the test, the test setup can request specific
> >> parameters to be used, but that does not mean using maximum by
> >> *default*.
> >> 
> >> We currently lack the feature to reduce lane count and link rate. The
> >> key to understand here is that starting at max and reducing down to the
> >> sufficient parameters for the mode (which is where we start now) offers
> >> no real benefit for any use case. What we're lacking is a feature to
> >> reduce the link parameters *below* what's required by the mode the
> >> userspace wants. This can only be achieved through cooperation with
> >> userspace.
> >> 
> >
> > We can train at the optimal link rate required for the requested mode as
> > done in the existing implementation and retrain whenever the link training
> > test request is sent. 
> > For the test 4.3.1.4 in CTS, it does force a failure in CR and expects the
> > driver to fall back to even lower link rate. We do not implement this in the
> > current driver and so this test fails. Could you elaborate on how this can
> > be achieved with the the cooperation with userspace?
> > Should we send a uevent to the userspace asking to retry at a lower 
> > resolution
> > after retraining at the lower link rate?
> > This is pertty much the place where majority of the compliance tests are 
> > failing.
> > How can we pass compliance with regards to this feature?
> 
> So here's an idea Ville and I came up with. It's not completely thought
> out yet, probably has some wrinkles still, but then there are 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Jani Nikula]

On Thu, 29 Sep 2016, Manasi Navare  wrote:
> On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
>> On Tue, 27 Sep 2016, Manasi Navare  wrote:
>> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
>> >> On Fri, 16 Sep 2016, Manasi Navare  wrote:
>> >> > According to the DisplayPort Spec, in case of Clock Recovery failure
>> >> > the link training sequence should fall back to the lower link rate
>> >> > followed by lower lane count until CR succeeds.
>> >> > On CR success, the sequence proceeds with Channel EQ.
>> >> > In case of Channel EQ failures, it should fallback to
>> >> > lower link rate and lane count and start the CR phase again.
>> >> 
>> >> This change makes the link training start at the max lane count and max
>> >> link rate. This is not ideal, as it wastes the link. And it is not a
>> >> spec requirement. "The Link Policy Maker of the upstream device may
>> >> choose any link count and link rate as long as they do not exceed the
>> >> capabilities of the DP receiver."
>> >> 
>> >> Our current code starts at the minimum required bandwidth for the mode,
>> >> therefore we can't fall back to lower link rate and lane count without
>> >> reducing the mode.
>> >> 
>> >> AFAICT this patch here makes it possible for the link bandwidth to drop
>> >> below what is required for the mode. This is unacceptable.
>> >> 
>> >> BR,
>> >> Jani.
>> >> 
>> >>
>> >
>> > Thanks Jani for your review comments.
>> > Yes in this change we start at the max link rate and lane count. This
>> > change was made according to the design document discussions we had
>> > before strating this DP Redesign project. The main reason for starting
>> > at the maxlink rate and max lane count was for ensuring proper
>> > behavior of DP MST. In case of DP MST, we want to train the link at
>> > the maximum supported link rate/lane count based on an early/ upfront
>> > link training result so that we dont fail when we try to connect a
>> > higher resolution monitor as a second monitor. This a trade off
>> > between wsting the link or higher power vs. needing to retrain for
>> > every monitor that requests a higher BW in case of DP MST.
>> 
>> We already train at max bandwidth for DP MST, which seems to be the
>> sensible thing to do.
>> 
>> > Actually this is also the reason for enabling upfront link training in
>> > the following patch where we train the link much ahead in the modeset
>> > sequence to understand the link rate and lane count values at which
>> > the link can be successfully trained and then the link training
>> > through modeset will always start at the upfront values (maximum
>> > supported values of lane count and link rate based on upfront link
>> > training).
>> 
>> I don't see a need to do this for DP SST.
>> 
>> > As per the CTS, all the test 4.3.1.4 requires that you fall back to
>> > the lower link rate after trying to train at the maximum link rate
>> > advertised through the DPCD registers.
>> 
>> That test does not require the source DUT to default to maximum lane
>> count or link rate of the sink. The source may freely choose the lane
>> count and link rate as long as they don't exceed sink capabilities.
>> 
>> For the purposes of the test, the test setup can request specific
>> parameters to be used, but that does not mean using maximum by
>> *default*.
>> 
>> We currently lack the feature to reduce lane count and link rate. The
>> key to understand here is that starting at max and reducing down to the
>> sufficient parameters for the mode (which is where we start now) offers
>> no real benefit for any use case. What we're lacking is a feature to
>> reduce the link parameters *below* what's required by the mode the
>> userspace wants. This can only be achieved through cooperation with
>> userspace.
>> 
>
> We can train at the optimal link rate required for the requested mode as
> done in the existing implementation and retrain whenever the link training
> test request is sent. 
> For the test 4.3.1.4 in CTS, it does force a failure in CR and expects the
> driver to fall back to even lower link rate. We do not implement this in the
> current driver and so this test fails. Could you elaborate on how this can
> be achieved with the the cooperation with userspace?
> Should we send a uevent to the userspace asking to retry at a lower resolution
> after retraining at the lower link rate?
> This is pertty much the place where majority of the compliance tests are 
> failing.
> How can we pass compliance with regards to this feature?

So here's an idea Ville and I came up with. It's not completely thought
out yet, probably has some wrinkles still, but then there are wrinkles
with the upfront link training too (I'll get back to those separately).

If link training fails during modeset (either for real or because it's a
test sink that wants to test failures), we 1) store the link parameters
as failing, 2) send a uevent 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Manasi Navare]

On Tue, Sep 27, 2016 at 08:07:01PM +0300, Jani Nikula wrote:
> On Tue, 27 Sep 2016, Manasi Navare  wrote:
> > On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> >> On Fri, 16 Sep 2016, Manasi Navare  wrote:
> >> > According to the DisplayPort Spec, in case of Clock Recovery failure
> >> > the link training sequence should fall back to the lower link rate
> >> > followed by lower lane count until CR succeeds.
> >> > On CR success, the sequence proceeds with Channel EQ.
> >> > In case of Channel EQ failures, it should fallback to
> >> > lower link rate and lane count and start the CR phase again.
> >> 
> >> This change makes the link training start at the max lane count and max
> >> link rate. This is not ideal, as it wastes the link. And it is not a
> >> spec requirement. "The Link Policy Maker of the upstream device may
> >> choose any link count and link rate as long as they do not exceed the
> >> capabilities of the DP receiver."
> >> 
> >> Our current code starts at the minimum required bandwidth for the mode,
> >> therefore we can't fall back to lower link rate and lane count without
> >> reducing the mode.
> >> 
> >> AFAICT this patch here makes it possible for the link bandwidth to drop
> >> below what is required for the mode. This is unacceptable.
> >> 
> >> BR,
> >> Jani.
> >> 
> >>
> >
> > Thanks Jani for your review comments.
> > Yes in this change we start at the max link rate and lane count. This
> > change was made according to the design document discussions we had
> > before strating this DP Redesign project. The main reason for starting
> > at the maxlink rate and max lane count was for ensuring proper
> > behavior of DP MST. In case of DP MST, we want to train the link at
> > the maximum supported link rate/lane count based on an early/ upfront
> > link training result so that we dont fail when we try to connect a
> > higher resolution monitor as a second monitor. This a trade off
> > between wsting the link or higher power vs. needing to retrain for
> > every monitor that requests a higher BW in case of DP MST.
> 
> We already train at max bandwidth for DP MST, which seems to be the
> sensible thing to do.
> 
> > Actually this is also the reason for enabling upfront link training in
> > the following patch where we train the link much ahead in the modeset
> > sequence to understand the link rate and lane count values at which
> > the link can be successfully trained and then the link training
> > through modeset will always start at the upfront values (maximum
> > supported values of lane count and link rate based on upfront link
> > training).
> 
> I don't see a need to do this for DP SST.
> 
> > As per the CTS, all the test 4.3.1.4 requires that you fall back to
> > the lower link rate after trying to train at the maximum link rate
> > advertised through the DPCD registers.
> 
> That test does not require the source DUT to default to maximum lane
> count or link rate of the sink. The source may freely choose the lane
> count and link rate as long as they don't exceed sink capabilities.
> 
> For the purposes of the test, the test setup can request specific
> parameters to be used, but that does not mean using maximum by
> *default*.
> 
> We currently lack the feature to reduce lane count and link rate. The
> key to understand here is that starting at max and reducing down to the
> sufficient parameters for the mode (which is where we start now) offers
> no real benefit for any use case. What we're lacking is a feature to
> reduce the link parameters *below* what's required by the mode the
> userspace wants. This can only be achieved through cooperation with
> userspace.
> 

We can train at the optimal link rate required for the requested mode as
done in the existing implementation and retrain whenever the link training
test request is sent. 
For the test 4.3.1.4 in CTS, it does force a failure in CR and expects the
driver to fall back to even lower link rate. We do not implement this in the
current driver and so this test fails. Could you elaborate on how this can
be achieved with the the cooperation with userspace?
Should we send a uevent to the userspace asking to retry at a lower resolution
after retraining at the lower link rate?
This is pertty much the place where majority of the compliance tests are 
failing.
How can we pass compliance with regards to this feature?

Regards
Manasi 
> > This will not drop the link BW to a number below what is required for
> > the mode because the requested modes are pruned or validated in
> > intel_dp_mode_valid based on the upfront link training results in the
> > following patch. And these values are used here as the starting values
> > of link rate and lane count.
> 
> Each patch must be a worthwhile change on its own. By my reading of this
> patch, we can go under the required bandwidth. You can't justify that by
> saying the follow-up patch fixes it.
> 
> > I almost feel that 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Jani Nikula]

On Tue, 27 Sep 2016, Manasi Navare  wrote:
> On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
>> On Fri, 16 Sep 2016, Manasi Navare  wrote:
>> > According to the DisplayPort Spec, in case of Clock Recovery failure
>> > the link training sequence should fall back to the lower link rate
>> > followed by lower lane count until CR succeeds.
>> > On CR success, the sequence proceeds with Channel EQ.
>> > In case of Channel EQ failures, it should fallback to
>> > lower link rate and lane count and start the CR phase again.
>> 
>> This change makes the link training start at the max lane count and max
>> link rate. This is not ideal, as it wastes the link. And it is not a
>> spec requirement. "The Link Policy Maker of the upstream device may
>> choose any link count and link rate as long as they do not exceed the
>> capabilities of the DP receiver."
>> 
>> Our current code starts at the minimum required bandwidth for the mode,
>> therefore we can't fall back to lower link rate and lane count without
>> reducing the mode.
>> 
>> AFAICT this patch here makes it possible for the link bandwidth to drop
>> below what is required for the mode. This is unacceptable.
>> 
>> BR,
>> Jani.
>> 
>>
>
> Thanks Jani for your review comments.
> Yes in this change we start at the max link rate and lane count. This
> change was made according to the design document discussions we had
> before strating this DP Redesign project. The main reason for starting
> at the maxlink rate and max lane count was for ensuring proper
> behavior of DP MST. In case of DP MST, we want to train the link at
> the maximum supported link rate/lane count based on an early/ upfront
> link training result so that we dont fail when we try to connect a
> higher resolution monitor as a second monitor. This a trade off
> between wsting the link or higher power vs. needing to retrain for
> every monitor that requests a higher BW in case of DP MST.

We already train at max bandwidth for DP MST, which seems to be the
sensible thing to do.

> Actually this is also the reason for enabling upfront link training in
> the following patch where we train the link much ahead in the modeset
> sequence to understand the link rate and lane count values at which
> the link can be successfully trained and then the link training
> through modeset will always start at the upfront values (maximum
> supported values of lane count and link rate based on upfront link
> training).

I don't see a need to do this for DP SST.

> As per the CTS, all the test 4.3.1.4 requires that you fall back to
> the lower link rate after trying to train at the maximum link rate
> advertised through the DPCD registers.

That test does not require the source DUT to default to maximum lane
count or link rate of the sink. The source may freely choose the lane
count and link rate as long as they don't exceed sink capabilities.

For the purposes of the test, the test setup can request specific
parameters to be used, but that does not mean using maximum by
*default*.

We currently lack the feature to reduce lane count and link rate. The
key to understand here is that starting at max and reducing down to the
sufficient parameters for the mode (which is where we start now) offers
no real benefit for any use case. What we're lacking is a feature to
reduce the link parameters *below* what's required by the mode the
userspace wants. This can only be achieved through cooperation with
userspace.

> This will not drop the link BW to a number below what is required for
> the mode because the requested modes are pruned or validated in
> intel_dp_mode_valid based on the upfront link training results in the
> following patch. And these values are used here as the starting values
> of link rate and lane count.

Each patch must be a worthwhile change on its own. By my reading of this
patch, we can go under the required bandwidth. You can't justify that by
saying the follow-up patch fixes it.

> I almost feel that the upfront link training patch and this patch should be 
> combined so that insead of starting from the max link rate and lane count it
> is clear that we are starting from the upfront values.

I am still reading and gathering more feedback on the upfront link
training patch. I will get back to you. But the impression I'm currently
getting is that we can't do this. The upfront link training patch was
originally written for USB type C. But if DP compliance has priority,
the order of business should be getting compliance without upfront link
training. I am also still not convinced upfront link training is
required for compliance.

To be continued...

BR,
Jani.



>
> Regards,
> Manasi 
>> >
>> > v7:
>> > * Address readability concerns (Mika Kahola)
>> > v6:
>> > * Do not split quoted string across line (Mika Kahola)
>> > v5:
>> > * Reset the link rate index to the max link rate index
>> > before lowering the lane count (Jani Nikula)
>> > * Use 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Manasi Navare]

On Mon, Sep 26, 2016 at 04:39:34PM +0300, Jani Nikula wrote:
> On Fri, 16 Sep 2016, Manasi Navare  wrote:
> > According to the DisplayPort Spec, in case of Clock Recovery failure
> > the link training sequence should fall back to the lower link rate
> > followed by lower lane count until CR succeeds.
> > On CR success, the sequence proceeds with Channel EQ.
> > In case of Channel EQ failures, it should fallback to
> > lower link rate and lane count and start the CR phase again.
> 
> This change makes the link training start at the max lane count and max
> link rate. This is not ideal, as it wastes the link. And it is not a
> spec requirement. "The Link Policy Maker of the upstream device may
> choose any link count and link rate as long as they do not exceed the
> capabilities of the DP receiver."
> 
> Our current code starts at the minimum required bandwidth for the mode,
> therefore we can't fall back to lower link rate and lane count without
> reducing the mode.
> 
> AFAICT this patch here makes it possible for the link bandwidth to drop
> below what is required for the mode. This is unacceptable.
> 
> BR,
> Jani.
> 
>

Thanks Jani for your review comments.
Yes in this change we start at the max link rate and lane count. This change was
made according to the design document discussions we had before strating this 
DP 
Redesign project. The main reason for starting at the maxlink rate and max lane
count was for ensuring proper behavior of DP MST. In case of DP MST, we want to
train the link at the maximum supported link rate/lane count based on an early/
upfront link training result so that we dont fail when we try to connect a
higher resolution monitor as a second monitor. This a trade off between wsting 
the link or higher power vs. needing to retrain for every monitor that requests
a higher BW in case of DP MST.
 
Actually this is also the reason for enabling upfront link training in the 
following patch where we train the link much ahead in the modeset sequence 
to understand the link rate and lane count values at which the link can be 
successfully trained and then the link training through modeset will always 
start
at the upfront values (maximum supported values of lane count and link rate 
based
on upfront link training).

As per the CTS, all the test 4.3.1.4 requires that you fall back to the lower 
link
rate after trying to train at the maximum link rate advertised through the DPCD 
registers.

This will not drop the link BW to a number below what is required for the mode 
because the requested modes are pruned or validated in intel_dp_mode_valid
based on the upfront link training results in the following patch. And these 
values are used here as the starting values of link rate and lane count.

I almost feel that the upfront link training patch and this patch should be 
combined so that insead of starting from the max link rate and lane count it
is clear that we are starting from the upfront values.

Regards,
Manasi 
> >
> > v7:
> > * Address readability concerns (Mika Kahola)
> > v6:
> > * Do not split quoted string across line (Mika Kahola)
> > v5:
> > * Reset the link rate index to the max link rate index
> > before lowering the lane count (Jani Nikula)
> > * Use the paradigm for loop in intel_dp_link_rate_index
> > v4:
> > * Fixed the link rate fallback loop (Manasi Navare)
> > v3:
> > * Fixed some rebase issues (Mika Kahola)
> > v2:
> > * Add a helper function to return index of requested link rate
> > into common_rates array
> > * Changed the link rate fallback loop to make use
> > of common_rates array (Mika Kahola)
> > * Changed INTEL_INFO to INTEL_GEN (David Weinehall)
> >
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 113 
> > +++---
> >  drivers/gpu/drm/i915/intel_dp.c   |  15 
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |  13 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |   6 +-
> >  4 files changed, 133 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 8065a5f..093038c 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1637,19 +1637,18 @@ void intel_ddi_clk_select(struct intel_encoder 
> > *encoder,
> > }
> >  }
> >  
> > -static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> > +static void intel_ddi_pre_enable_edp(struct intel_encoder *encoder,
> > int link_rate, uint32_t lane_count,
> > -   struct intel_shared_dpll *pll,
> > -   bool link_mst)
> > +   struct intel_shared_dpll *pll)
> >  {
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = 

Re: [Intel-gfx] [PATCH v7 1/6] drm/i915: Fallback to lower link rate and lane count during link training

[Jani Nikula]

On Fri, 16 Sep 2016, Manasi Navare  wrote:
> According to the DisplayPort Spec, in case of Clock Recovery failure
> the link training sequence should fall back to the lower link rate
> followed by lower lane count until CR succeeds.
> On CR success, the sequence proceeds with Channel EQ.
> In case of Channel EQ failures, it should fallback to
> lower link rate and lane count and start the CR phase again.

This change makes the link training start at the max lane count and max
link rate. This is not ideal, as it wastes the link. And it is not a
spec requirement. "The Link Policy Maker of the upstream device may
choose any link count and link rate as long as they do not exceed the
capabilities of the DP receiver."

Our current code starts at the minimum required bandwidth for the mode,
therefore we can't fall back to lower link rate and lane count without
reducing the mode.

AFAICT this patch here makes it possible for the link bandwidth to drop
below what is required for the mode. This is unacceptable.

BR,
Jani.


>
> v7:
> * Address readability concerns (Mika Kahola)
> v6:
> * Do not split quoted string across line (Mika Kahola)
> v5:
> * Reset the link rate index to the max link rate index
> before lowering the lane count (Jani Nikula)
> * Use the paradigm for loop in intel_dp_link_rate_index
> v4:
> * Fixed the link rate fallback loop (Manasi Navare)
> v3:
> * Fixed some rebase issues (Mika Kahola)
> v2:
> * Add a helper function to return index of requested link rate
> into common_rates array
> * Changed the link rate fallback loop to make use
> of common_rates array (Mika Kahola)
> * Changed INTEL_INFO to INTEL_GEN (David Weinehall)
>
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 113 
> +++---
>  drivers/gpu/drm/i915/intel_dp.c   |  15 
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  13 ++-
>  drivers/gpu/drm/i915/intel_drv.h  |   6 +-
>  4 files changed, 133 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8065a5f..093038c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1637,19 +1637,18 @@ void intel_ddi_clk_select(struct intel_encoder 
> *encoder,
>   }
>  }
>  
> -static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> +static void intel_ddi_pre_enable_edp(struct intel_encoder *encoder,
>   int link_rate, uint32_t lane_count,
> - struct intel_shared_dpll *pll,
> - bool link_mst)
> + struct intel_shared_dpll *pll)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
>  
>   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> -  link_mst);
> - if (encoder->type == INTEL_OUTPUT_EDP)
> - intel_edp_panel_on(intel_dp);
> +  false);
> +
> + intel_edp_panel_on(intel_dp);
>  
>   intel_ddi_clk_select(encoder, pll);
>   intel_prepare_dp_ddi_buffers(encoder);
> @@ -1660,6 +1659,28 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_dp_stop_link_train(intel_dp);
>  }
>  
> +static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> + int link_rate, uint32_t lane_count,
> + struct intel_shared_dpll *pll,
> + bool link_mst)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_shared_dpll_config tmp_pll_config;
> +
> + /* Disable the PLL and obtain the PLL for Link Training
> +  * that starts with highest link rate and lane count.
> +  */
> + tmp_pll_config = pll->config;
> + pll->funcs.disable(dev_priv, pll);
> + pll->config.crtc_mask = 0;
> +
> + /* If Link Training fails, send a uevent to generate a hotplug */
> + if (!intel_ddi_link_train(intel_dp, link_rate, lane_count, link_mst))
> + drm_kms_helper_hotplug_event(encoder->base.dev);
> + pll->config = tmp_pll_config;
> +}
> +
>  static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> bool has_hdmi_sink,
> struct drm_display_mode *adjusted_mode,
> @@ -1693,20 +1714,26 @@ static void intel_ddi_pre_enable(struct intel_encoder 
> *intel_encoder,
>   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>   int type = intel_encoder->type;
>  
> - if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> + if