All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms
Date: Wed, 13 Sep 2017 13:37:20 +0300	[thread overview]
Message-ID: <20170913103720.GE4914@intel.com> (raw)
In-Reply-To: <438d631f-0854-5928-9361-51e6dc1d1385@linux.intel.com>

On Wed, Sep 13, 2017 at 09:32:40AM +0200, Maarten Lankhorst wrote:
> Op 12-09-17 om 22:11 schreef Pandiyan, Dhinakaran:
> >
> >
> > On Tue, 2017-09-12 at 19:08 +0000, Pandiyan, Dhinakaran wrote:
> >> On Tue, 2017-09-12 at 19:17 +0300, Ville Syrjälä wrote:
> >>> On Tue, Sep 12, 2017 at 07:11:32PM +0300, Ville Syrjälä wrote:
> >>>> On Tue, Sep 05, 2017 at 06:26:34PM -0700, Dhinakaran Pandiyan wrote:
> >>>>> Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message trasactions to
> >>>>> set power states for downstream sinks. Apart from giving us the ability
> >>>>> to set power state for individual sinks, this fixes the below test for
> >>>>> me
> >>>>>
> >>>>> $ xrandr --display :0 --output DP-2-2-8 --off
> >>>>> $ xrandr --display :0 --output DP-2-2-1 --off
> >>>>> $ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
> >>>>> $ xrandr --display :0 --output DP-2-2-1 --auto
> >>>>>
> >>>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>>> Cc: Lyude <lyude@redhat.com>
> >>>>> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> >>>>> ---
> >>>>>  drivers/gpu/drm/i915/intel_ddi.c    | 6 ++++--
> >>>>>  drivers/gpu/drm/i915/intel_dp_mst.c | 8 ++++----
> >>>>>  2 files changed, 8 insertions(+), 6 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> >>>>> index 1da3bb2cc4b4..8aebacc0aa31 100644
> >>>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >>>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >>>>> @@ -2161,7 +2161,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> >>>>>  		intel_prepare_dp_ddi_buffers(encoder);
> >>>>>  
> >>>>>  	intel_ddi_init_dp_buf_reg(encoder);
> >>>>> -	intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> >>>>> +	if (!link_mst)
> >>>>> +		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> >>>>>  	intel_dp_start_link_train(intel_dp);
> >>>>>  	if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> >>>>>  		intel_dp_stop_link_train(intel_dp);
> >>>>> @@ -2240,7 +2241,8 @@ static void intel_ddi_post_disable(struct intel_encoder *intel_encoder,
> >>>>>  	if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> >>>>>  		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> >>>>>  
> >>>>> -		intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >>>>> +		if (old_crtc_state && old_conn_state)
> >>>>> +			intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >>>> I would make that
> >>>> !intel_crtc_has_type(DP_MST)
> >>>>
> > old_crtc_state, which intel_crtc_has_type() needs, is NULL for MST and
> > the reason Maarten provided in his commit is
> >
> > " We also shouldn't pass crtc_state, because in that case the
> >   disabling sequence may potentially be different depending on
> >   which crtc is disabled last. Nice way to introduce bugs.
> > "
> > I am not 100% sure I understand the concern. But since that change was
> > intentional I guess we can use the NULL values, like I've done, to
> > identify the mst sinks. I am open to ideas.
> I think checking for NULL crtc_state is enough, in case we ever decide to pass the real connector state.
> For clarity, I would add something like bool is_dsp_mst = !crtc_state; /* When enabling the link for MST, this connector is never bound to a crtc */.

The NULL state is rather ugly IMO. With a comment I might be able to
stomach it. However, after another look I see that we already pass the
crtc state to ddi_pre_enable() from the MST code, so even just from a
symmetry POV it would make sense to pass it to ddi_post_disable as well.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-09-13 10:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-06  1:26 [PATCH 1/2] drm/dp/mst: Sideband message transaction to power up/down nodes Dhinakaran Pandiyan
2017-09-06  1:26 ` [PATCH 2/2] drm/i915/mst: Use MST sideband message transaction for dpms Dhinakaran Pandiyan
2017-09-07  5:51   ` Stefan Assmann
2017-09-12 16:11   ` Ville Syrjälä
2017-09-12 16:17     ` Ville Syrjälä
2017-09-12 19:08       ` Pandiyan, Dhinakaran
2017-09-12 20:11         ` Pandiyan, Dhinakaran
2017-09-13  7:32           ` Maarten Lankhorst
2017-09-13 10:37             ` Ville Syrjälä [this message]
2017-09-13 10:46               ` [Intel-gfx] " Maarten Lankhorst
2017-09-13 11:48                 ` Ville Syrjälä
2017-09-13 11:55                   ` Maarten Lankhorst
2017-09-13 13:52                     ` Ville Syrjälä
2017-09-06  1:46 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/dp/mst: Sideband message transaction to power up/down nodes Patchwork
2017-09-06 15:40 ` [PATCH 1/2] " Lyude Paul
2017-09-06 16:36   ` Pandiyan, Dhinakaran
2017-09-07  0:14   ` [PATCH v2] " Dhinakaran Pandiyan
2017-09-07 18:04     ` Lyude Paul
2017-09-07 18:54       ` [Intel-gfx] " Pandiyan, Dhinakaran
2017-09-11 13:33     ` Ville Syrjälä
2017-09-11 19:10       ` Pandiyan, Dhinakaran
2017-09-07  0:35 ` ✗ Fi.CI.BAT: failure for series starting with [v2] drm/dp/mst: Sideband message transaction to power up/down nodes (rev2) Patchwork
2017-09-07  5:49 ` [PATCH 1/2] drm/dp/mst: Sideband message transaction to power up/down nodes Stefan Assmann

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=20170913103720.GE4914@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@linux.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.