[Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper

Lucas De Marchi lucas.demarchi at intel.com
Tue Sep 20 17:56:01 UTC 2022


On Tue, Sep 20, 2022 at 02:04:33PM -0300, Gustavo Sousa wrote:
>Hi, Jani.
>
>On Tue, Sep 20, 2022 at 10:19:53AM +0300, Jani Nikula wrote:
>> On Mon, 19 Sep 2022, Gustavo Sousa <gustavo.sousa at intel.com> wrote:
>> > Make the code more readable, which will be more apparent as new
>> > platforms with different hotplug inversion needs are added.
>> >
>> > Signed-off-by: Gustavo Sousa <gustavo.sousa at intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/i915_irq.c | 25 ++++++++++++++++---------
>> >  1 file changed, 16 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>> > index de06f293e173..c53d21ae197f 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct drm_i915_private *dev_priv)
>> >  	spin_unlock_irq(&dev_priv->irq_lock);
>> >  }
>> >
>> > +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
>> > +{
>> > +	u32 invert_bits;
>> > +
>> > +	if (HAS_PCH_DG1(dev_priv))
>> > +		invert_bits = INVERT_DDIA_HPD |
>> > +			      INVERT_DDIB_HPD |
>> > +			      INVERT_DDIC_HPD |
>> > +			      INVERT_DDID_HPD;
>>
>> Nitpick, the indentation will be off compared to automated indentation.
>
>What do you mean by automated indentation?
>
>>
>> > +	else
>> > +		return;
>> > +
>> > +	intel_uncore_rmw(&dev_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
>> > +}
>> > +
>> >  static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
>> >  			       enum hpd_pin pin)
>> >  {
>> > @@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct drm_i915_private *i915,
>> >
>> >  static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
>> >  {
>> > -	u32 val;
>> > -
>> > -	val = intel_uncore_read(&dev_priv->uncore, SOUTH_CHICKEN1);
>> > -	val |= (INVERT_DDIA_HPD |
>> > -		INVERT_DDIB_HPD |
>> > -		INVERT_DDIC_HPD |
>> > -		INVERT_DDID_HPD);
>> > -	intel_uncore_write(&dev_priv->uncore, SOUTH_CHICKEN1, val);
>> > -
>> > +	setup_hotplug_inversion(dev_priv);
>>
>> Since you're already in a platform specific function here, seems a bit
>> odd to call a new generic function that needs to have another if ladder
>> platform check. What are we gaining here? The end result is
>> de-duplicating just one line of intel_uncore_rmw(). I'm not convinced.
>
>It is true that the proposed refactor repeats a platform check, but the proposed
>refactor has its benefits. As more platforms with hotplug inversion needs are
>added (e.g. MTL), we will have a common place for the logic of hotplug
>inversion. That arguably makes the code more readable and makes future refactors
>easier when we need split a function that has become too complex due to platform
>checks.
>
>To make that last point clearer, I am quoting Lucas' (copied here as well)
>comment (which was what convinced me) from a discussion regarding the advantage
>of using such a helper:
>
>    that is what helpers are for, so you don't have to open code it in every
>    platform-fork of the function that needs it. See how the various
>    "Sequences to initialize display" are done in the driver... When we are
>    extending it to a future platform, if the change is small enough we just
>    add e few if/else in the same function. But it doesn't take too long for
>    those functions to become unreadable if there are several branches the
>    code path may take.  So then we "fork" the function for a new platform,
>    but reuse the helpers doing the individual steps.

the missing information here is that there are changes in the pipeline
for platforms that have different bits to be inverted, or none at
all, with a different register to program. Adding the if/else in this
function seems unrelated churn.

Another possibility would be to just let the caller handle the if/else
decision, passing the bits (and possibly register) to invert. The noise
in xxx_hpd_irq_setup() function may be avoid by

#define INVERT_DII_HPD		(INVERT_DDIA_HPD | INVERT_DDIB_HPD | INVERT_DDIC_HPD | INVERT_DDID_HPD)
#define XXX_INVERT_DII_HPD	(...)

Third possibility since the function is already very small is to just go
ahead and use another _setup() for the next platforms.

Lucas De Marchi


More information about the Intel-gfx mailing list