public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 07/12] drm/i915: Remove I915_READ8
Date: Fri, 07 Jun 2019 16:44:45 +0300	[thread overview]
Message-ID: <87ef45zf02.fsf@intel.com> (raw)
In-Reply-To: <a471eb99-349e-f7b7-0350-00307f54b614@linux.intel.com>

On Fri, 07 Jun 2019, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
> On 07/06/2019 14:11, Jani Nikula wrote:
>> On Fri, 07 Jun 2019, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> Only a few call sites remain which have been converted to uncore mmio
>>> accessors and so the macro can be removed.
>>>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> 
>> I have some reservations about this one and patch 11. Again, I'm fine
>> with nuking I915_READ8 and I915_READ_NOTRACE (in patch 11). I think
>> they're special cases and it's okay if they grow into a bit longer lines
>> or multiple lines.
>> 
>> The problem is converting regular I915_READ and I915_WRITE in display
>> code while at it.
>> 
>> I don't think en masse conversion of them to intel_uncore_read and
>> intel_uncore_write directly is going to happen in display code, because
>> there's too much code that gets turned too ugly with the increase in
>> function name length and the extra passed parameter. I think many of
>> those places are pretty ugly as it is already. That's my feeling anyway.
>> 
>> I understand your reasoning is to avoid the mixed use of intel_uncore_*
>
> Exactly.
>
>> and I915_*. But I fear using intel_uncore_read and intel_uncore_write
>> now is going to promote their use all over the place, and *that* will
>> lead to mixed use. Which is not optimal if the overall feeling is that
>> we need to come up with a shorter function/macro for display code reads
>> and writes.
>
> I am fine with the argument that you may desire something shorter for 
> display. But I don't think converting whole functions would create any 
> more future mixed use than converting functions partially.
>
> Btw have you seen the latest RFC from Daniele?

Yes, but haven't had the time to digest it.

> That would allow that you 
> only replace the assignemnts at the top of functions perhaps like from:
>
> 	struct intel_uncore *uncore = &dev_priv->uncore;
>
> to:
>
> 	struct intel_uncore *uncore = &dev_priv->display_uncore;
>
> But sure, if you desire shorter accessors then lets first have a 
> definitive decision of that.

If there were display accessors they might just take i915 as pointer:

#define FOO_READ(i915, reg) intel_uncore_read(&i915->display_uncore, reg)

Dunno.

>
>> I presume Ville has something to say about the gt vs. display stuff as
>> well; does the whole series make that harder? I hope not, because I do
>> like the rest of what's being done here.
>
> It doesn't make it harder. I can easily drop the bits you don't like if 
> that will be the final decision. In fact, I should probably do that 
> straight away if that would unblock the remaining two patches because 
> then I can proceed with other refactorings on top.

Hum, you know what, it's not *that* big of a deal. Ack on the whole
series, we can tidy up later on if needed.

I guess I'd like to get Ville's ack on the series too. Ville?


BR,
Jani.


>
> Regards,
>
> Tvrtko
>
>> 
>> 
>> BR,
>> Jani.
>> 
>> 
>> 
>>> ---
>>>   drivers/gpu/drm/i915/i915_drv.h  |  2 --
>>>   drivers/gpu/drm/i915/intel_crt.c | 41 ++++++++++++++++++--------------
>>>   drivers/gpu/drm/i915/intel_pm.c  |  6 ++---
>>>   3 files changed, 26 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>>> index b2763721b76d..13815795e197 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -2852,8 +2852,6 @@ extern void intel_display_print_error_state(struct drm_i915_error_state_buf *e,
>>>   #define __I915_REG_OP(op__, dev_priv__, ...) \
>>>   	intel_uncore_##op__(&(dev_priv__)->uncore, __VA_ARGS__)
>>>   
>>> -#define I915_READ8(reg__)	  __I915_REG_OP(read8, dev_priv, (reg__))
>>> -
>>>   #define I915_READ16(reg__)	   __I915_REG_OP(read16, dev_priv, (reg__))
>>>   #define I915_WRITE16(reg__, val__) __I915_REG_OP(write16, dev_priv, (reg__), (val__))
>>>   
>>> diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
>>> index bb56518576a1..3fcf2f84bcce 100644
>>> --- a/drivers/gpu/drm/i915/intel_crt.c
>>> +++ b/drivers/gpu/drm/i915/intel_crt.c
>>> @@ -643,6 +643,7 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
>>>   {
>>>   	struct drm_device *dev = crt->base.base.dev;
>>>   	struct drm_i915_private *dev_priv = to_i915(dev);
>>> +	struct intel_uncore *uncore = &dev_priv->uncore;
>>>   	u32 save_bclrpat;
>>>   	u32 save_vtotal;
>>>   	u32 vtotal, vactive;
>>> @@ -663,9 +664,9 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
>>>   	pipeconf_reg = PIPECONF(pipe);
>>>   	pipe_dsl_reg = PIPEDSL(pipe);
>>>   
>>> -	save_bclrpat = I915_READ(bclrpat_reg);
>>> -	save_vtotal = I915_READ(vtotal_reg);
>>> -	vblank = I915_READ(vblank_reg);
>>> +	save_bclrpat = intel_uncore_read(uncore, bclrpat_reg);
>>> +	save_vtotal = intel_uncore_read(uncore, vtotal_reg);
>>> +	vblank = intel_uncore_read(uncore, vblank_reg);
>>>   
>>>   	vtotal = ((save_vtotal >> 16) & 0xfff) + 1;
>>>   	vactive = (save_vtotal & 0x7ff) + 1;
>>> @@ -674,21 +675,23 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
>>>   	vblank_end = ((vblank >> 16) & 0xfff) + 1;
>>>   
>>>   	/* Set the border color to purple. */
>>> -	I915_WRITE(bclrpat_reg, 0x500050);
>>> +	intel_uncore_write(uncore, bclrpat_reg, 0x500050);
>>>   
>>>   	if (!IS_GEN(dev_priv, 2)) {
>>> -		u32 pipeconf = I915_READ(pipeconf_reg);
>>> -		I915_WRITE(pipeconf_reg, pipeconf | PIPECONF_FORCE_BORDER);
>>> -		POSTING_READ(pipeconf_reg);
>>> +		u32 pipeconf = intel_uncore_read(uncore, pipeconf_reg);
>>> +		intel_uncore_write(uncore,
>>> +				   pipeconf_reg,
>>> +				   pipeconf | PIPECONF_FORCE_BORDER);
>>> +		intel_uncore_posting_read(uncore, pipeconf_reg);
>>>   		/* Wait for next Vblank to substitue
>>>   		 * border color for Color info */
>>>   		intel_wait_for_vblank(dev_priv, pipe);
>>> -		st00 = I915_READ8(_VGA_MSR_WRITE);
>>> +		st00 = intel_uncore_read8(uncore, _VGA_MSR_WRITE);
>>>   		status = ((st00 & (1 << 4)) != 0) ?
>>>   			connector_status_connected :
>>>   			connector_status_disconnected;
>>>   
>>> -		I915_WRITE(pipeconf_reg, pipeconf);
>>> +		intel_uncore_write(uncore, pipeconf_reg, pipeconf);
>>>   	} else {
>>>   		bool restore_vblank = false;
>>>   		int count, detect;
>>> @@ -702,9 +705,10 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
>>>   			u32 vsync_start = (vsync & 0xffff) + 1;
>>>   
>>>   			vblank_start = vsync_start;
>>> -			I915_WRITE(vblank_reg,
>>> -				   (vblank_start - 1) |
>>> -				   ((vblank_end - 1) << 16));
>>> +			intel_uncore_write(uncore,
>>> +					   vblank_reg,
>>> +					   (vblank_start - 1) |
>>> +					   ((vblank_end - 1) << 16));
>>>   			restore_vblank = true;
>>>   		}
>>>   		/* sample in the vertical border, selecting the larger one */
>>> @@ -716,9 +720,10 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
>>>   		/*
>>>   		 * Wait for the border to be displayed
>>>   		 */
>>> -		while (I915_READ(pipe_dsl_reg) >= vactive)
>>> +		while (intel_uncore_read(uncore, pipe_dsl_reg) >= vactive)
>>>   			;
>>> -		while ((dsl = I915_READ(pipe_dsl_reg)) <= vsample)
>>> +		while ((dsl = intel_uncore_read(uncore, pipe_dsl_reg)) <=
>>> +		       vsample)
>>>   			;
>>>   		/*
>>>   		 * Watch ST00 for an entire scanline
>>> @@ -728,14 +733,14 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
>>>   		do {
>>>   			count++;
>>>   			/* Read the ST00 VGA status register */
>>> -			st00 = I915_READ8(_VGA_MSR_WRITE);
>>> +			st00 = intel_uncore_read8(uncore, _VGA_MSR_WRITE);
>>>   			if (st00 & (1 << 4))
>>>   				detect++;
>>> -		} while ((I915_READ(pipe_dsl_reg) == dsl));
>>> +		} while ((intel_uncore_read(uncore, pipe_dsl_reg) == dsl));
>>>   
>>>   		/* restore vblank if necessary */
>>>   		if (restore_vblank)
>>> -			I915_WRITE(vblank_reg, vblank);
>>> +			intel_uncore_write(uncore, vblank_reg, vblank);
>>>   		/*
>>>   		 * If more than 3/4 of the scanline detected a monitor,
>>>   		 * then it is assumed to be present. This works even on i830,
>>> @@ -748,7 +753,7 @@ intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
>>>   	}
>>>   
>>>   	/* Restore previous settings */
>>> -	I915_WRITE(bclrpat_reg, save_bclrpat);
>>> +	intel_uncore_write(uncore, bclrpat_reg, save_bclrpat);
>>>   
>>>   	return status;
>>>   }
>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>>> index d7272d4ff258..93e411e6ad19 100644
>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> @@ -8160,15 +8160,15 @@ unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
>>>   	return val;
>>>   }
>>>   
>>> -unsigned long i915_mch_val(struct drm_i915_private *dev_priv)
>>> +unsigned long i915_mch_val(struct drm_i915_private *i915)
>>>   {
>>>   	unsigned long m, x, b;
>>>   	u32 tsfs;
>>>   
>>> -	tsfs = I915_READ(TSFS);
>>> +	tsfs = intel_uncore_read(&i915->uncore, TSFS);
>>>   
>>>   	m = ((tsfs & TSFS_SLOPE_MASK) >> TSFS_SLOPE_SHIFT);
>>> -	x = I915_READ8(TR1);
>>> +	x = intel_uncore_read8(&i915->uncore, TR1);
>>>   
>>>   	b = tsfs & TSFS_INTR_MASK;
>> 

-- 
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:[~2019-06-07 13:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-07 12:08 [RFC 00/12] Legacy mmio accessor macro pruning Tvrtko Ursulin
2019-06-07 12:08 ` [RFC 01/12] drm/i915: Eliminate unused mmio accessors Tvrtko Ursulin
2019-06-07 12:08 ` [RFC 02/12] drm/i915: Convert i915_reg_read_ioctl to use explicit " Tvrtko Ursulin
2019-06-07 12:08 ` [RFC 03/12] drm/i915: Convert icl_get_stolen_reserved to uncore " Tvrtko Ursulin
2019-06-07 12:08 ` [RFC 04/12] drm/i915: Convert gem_record_fences " Tvrtko Ursulin
2019-06-07 12:08 ` [RFC 05/12] drm/i915: Convert intel_read_wm_latency " Tvrtko Ursulin
2019-06-07 12:08 ` [RFC 06/12] drm/i915: Remove I915_READ64 and I915_READ64_32x2 Tvrtko Ursulin
2019-06-07 12:44   ` Jani Nikula
2019-06-07 12:08 ` [RFC 07/12] drm/i915: Remove I915_READ8 Tvrtko Ursulin
2019-06-07 13:11   ` Jani Nikula
2019-06-07 13:19     ` Tvrtko Ursulin
2019-06-07 13:44       ` Jani Nikula [this message]
2019-06-11  8:47         ` Tvrtko Ursulin
2019-06-11  8:59           ` Jani Nikula
2019-06-11  8:58   ` Jani Nikula
2019-06-07 12:08 ` [RFC 08/12] drm/i915: Remove I915_POSTING_READ_FW Tvrtko Ursulin
2019-06-07 12:48   ` Jani Nikula
2019-06-07 12:08 ` [RFC 09/12] drm/i915: Remove POSTING_READ16 Tvrtko Ursulin
2019-06-07 12:49   ` Jani Nikula
2019-06-07 12:08 ` [RFC 10/12] drm/i915: Remove I915_WRITE_NOTRACE Tvrtko Ursulin
2019-06-07 12:50   ` Jani Nikula
2019-06-07 12:08 ` [RFC 11/12] drm/i915: Remove I915_READ_NOTRACE Tvrtko Ursulin
2019-06-11  8:57   ` Jani Nikula
2019-06-07 12:08 ` [RFC 12/12] drm/i915: Remove I915_READ16 and I915_WRITE16 Tvrtko Ursulin
2019-06-07 12:59   ` Jani Nikula
2019-06-07 14:36 ` ✗ Fi.CI.CHECKPATCH: warning for Legacy mmio accessor macro pruning Patchwork
2019-06-07 15:04 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-10  9:57 ` ✓ Fi.CI.IGT: " 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=87ef45zf02.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox