All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Lisovskiy\, Stanislav" <stanislav.lisovskiy@intel.com>,
	"intel-gfx\@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v1] drm/i915: Call intel_edp_init_connector only for eDP.
Date: Tue, 11 Feb 2020 15:55:45 +0200	[thread overview]
Message-ID: <87r1z1z0ri.fsf@intel.com> (raw)
In-Reply-To: <713d424e3ab55716b9f475ee0453dc3e4848e226.camel@intel.com>

On Tue, 11 Feb 2020, "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com> wrote:
> On Tue, 2020-02-11 at 15:03 +0200, Jani Nikula wrote:
>> On Tue, 11 Feb 2020, Stanislav Lisovskiy <
>> stanislav.lisovskiy@intel.com> wrote:
>> > I guess it would still be nice to make the code less confusing
>> > and do not call eDP specific function, for non-eDP connectors
>> > just to immediately return true(success) value as a hack.
>> > 
>> > So simply extracted that check out from this function,
>> > that we simply don't call it for non-eDP connectors. Bingo.
>> 
>> Fair enough, I guess...
>> 
>> Though I could be persuaded to take a patch for the reverse, because
>> generally we prefer localized knowledge in the callee than in a
>> potentially irrelevant place in the caller.
>> 
>> Consider the intel_dp_mst_encoder_init() call in the context of this
>> patch. We call it, and the function itself decides whether MST init
>> is
>> relevant or not. But I presume you wouldn't suggest pulling in all
>> the
>> conditions from there one level higher?
>> 
>> Would your opinion on intel_edp_init_connector() be different if the
>> conditions were more than just the single intel_dp_is_edp()? Or if we
>> moved all of eDP support to a separate file?
>
> Well, to me at least intel_edp_init_connector means that we are going
> to init an eDP connector, which already assumes that, we already should
> know that this is an eDP connector :) 
> Otherwise it should have somewhat different name, not saying that this
> is the best philosophy, but generally I would prefer the functions to
> be solely responsible for a single thing so that that init function is
> supposed to do only init, but not also some detection/checking or any 
> other side effects.
>
> So that there is a clear visibility what we are doing, if it's an init
> then we really do only init or if we supposed to detect something
> first, let it be a separate thing..
>
> Also this uses a return value in confusing way, i.e returning "Success"
> status for non-eDP from intel_edp_init_connector seems kind of
> confusing.

Again, how is this different from intel_dp_mst_encoder_init()?

With the *exactly* same rationale you'd end up with this:

        if (HAS_DP_MST(i915) && !intel_dp_is_edp(intel_dp)) &&
            !(INTEL_GEN(i915) < 12 && port == PORT_A) &&
            !(INTEL_GEN(i915) <	11 && port == PORT_E))
                intel_dp_mst_encoder_init(intel_dig_port,
                                          intel_connector->base.base.id);

Surely the information is better localized in a SPOT in the MST code?


BR,
Jani.

>
> Stan
>
>> 
>> BR,
>> Jani.
>> 
>> 
>> > 
>> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_dp.c | 13 ++++++-------
>> >  1 file changed, 6 insertions(+), 7 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > index f4dede6253f8..9bd36197a43d 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > @@ -7370,9 +7370,6 @@ static bool intel_edp_init_connector(struct
>> > intel_dp *intel_dp,
>> >  	intel_wakeref_t wakeref;
>> >  	struct edid *edid;
>> >  
>> > -	if (!intel_dp_is_edp(intel_dp))
>> > -		return true;
>> > -
>> >  	INIT_DELAYED_WORK(&intel_dp->panel_vdd_work,
>> > edp_panel_vdd_work);
>> >  
>> >  	/*
>> > @@ -7590,10 +7587,12 @@ intel_dp_init_connector(struct
>> > intel_digital_port *intel_dig_port,
>> >  	intel_dp_mst_encoder_init(intel_dig_port,
>> >  				  intel_connector->base.base.id);
>> >  
>> > -	if (!intel_edp_init_connector(intel_dp, intel_connector)) {
>> > -		intel_dp_aux_fini(intel_dp);
>> > -		intel_dp_mst_encoder_cleanup(intel_dig_port);
>> > -		goto fail;
>> > +	if (intel_dp_is_edp(intel_dp)) {
>> > +		if (!intel_edp_init_connector(intel_dp,
>> > intel_connector)) {
>> > +			intel_dp_aux_fini(intel_dp);
>> > +			intel_dp_mst_encoder_cleanup(intel_dig_port);
>> > +			goto fail;
>> > +		}
>> >  	}
>> >  
>> >  	intel_dp_add_properties(intel_dp, connector);
>> 
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-02-11 13:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 11:40 [Intel-gfx] [PATCH v1] drm/i915: Call intel_edp_init_connector only for eDP Stanislav Lisovskiy
2020-02-11 12:16 ` Imre Deak
2020-02-11 13:03 ` Jani Nikula
2020-02-11 13:33   ` Lisovskiy, Stanislav
2020-02-11 13:55     ` Jani Nikula [this message]
2020-02-11 14:03       ` Lisovskiy, Stanislav
2020-02-11 14:12         ` Jani Nikula
2020-02-11 14:27           ` Lisovskiy, Stanislav
2020-02-11 14:21       ` Imre Deak
2020-02-13 15:11 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork

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=87r1z1z0ri.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stanislav.lisovskiy@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.