Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler

[Paulo Zanoni]

Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
> 
> Enable the flip done interrupt in IER.
> 
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
> 
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
> 
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
>  flips without pageflip events.
> 
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the beginning of
>  flip_done_handler to remove sporadic WARN_ON that is seen.
> 
> v4: -Calculate timestamps using flip done time stamp and current
>  timestamp for async flips (Ville)
> 
> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
>  static.(Reported-by: kernel test robot )
> -Fix the typo in commit message.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 10 +++
>  drivers/gpu/drm/i915/i915_irq.c  | 83 ++--
>  drivers/gpu/drm/i915/i915_irq.h  |  2 +
>  drivers/gpu/drm/i915/i915_reg.h  |  4 +-
>  4 files changed, 91 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index db2a5a1a9b35..b8ff032195d9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15562,6 +15562,13 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>  
>   intel_dbuf_pre_plane_update(state);
>  
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + skl_enable_flip_done(&crtc->base);
> + break;

Do we really want the break here? What if more than one CRTC wants an
async flip?

Perhaps you could extend IGT to try this.

> + }
> + }
> +
>   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
>   dev_priv->display.commit_modeset_enables(state);
>  
> @@ -15583,6 +15590,9 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   drm_atomic_helper_wait_for_flip_done(dev, &state->base);
>  
>   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(&crtc->base);

Here we don't break in the first found, so at least there's an
inconsistency.

> +
>   if (new_crtc_state->hw.active &&
>   !needs_modeset(new_crtc_state) &&
>   !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1fa67700d8f4..95953b393941 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
>   return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
>  }
>  
> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> +
> + return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
> +}
> +
>  u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>   enum pipe pipe = to_intel_crtc(crtc)->pipe;
>  
> + if (crtc->state->async_flip)
> + return g4x_get_flip_counter(crtc);
> +
>   return I915_READ(PIPE_FRMCOUNT_G4X(pipe));

I don't understand the intention behind this, can you please clarify?
This goes back to my reply of the cover letter. It seems that here
we're going to alternate between two different counters in our vblank
count. So if user space alternates between sometimes using async flips
and sometimes using normal flip it's going to get some very weird
deltas, isn't it? At least this is what I remember from when I played
with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
using async flips.

IMHO we really need our IGT to exercise this possibility.

>  }
> -

Don't remove this blank line, please.

>  /*
>   * On certain encoders on certain platforms, pipe
>   * scanline register will not work to get the scanline,
> @@ -737,17 +747,24 @@

Re: [Intel-gfx] [PATCH v5 2/5] drm/i915: Add support for async flips in I915

[Paulo Zanoni]

Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
> 
> v2: -Move the Async flip enablement to individual patch (Paulo)
> 
> v3: -Rebased.
> 
> v4: -Add separate plane hook for async flip case (Ville)
> 
> v5: -Rebased.
> 
> Signed-off-by: Karthik B S 
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  6 +
>  drivers/gpu/drm/i915/display/intel_sprite.c  | 25 
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  3 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b8ff032195d9..4773f39e5924 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4766,6 +4766,12 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
> *crtc_state,
>   const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
>   u32 plane_ctl;
>  
> + /* During Async flip, no other updates are allowed */

My understanding is that this function is fully setting the right bits
based on the chosen config (instead of doing read-modify-write), and
the checks for "other updates" were done before. So the logic
implemented here of early returning doesn't make sense.


> + if (crtc_state->uapi.async_flip) {
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;

I wonder why gcc does not complain we're ORing with an unitialized
value.


> + return plane_ctl;
> + }
> +
>   plane_ctl = PLANE_CTL_ENABLE;

It seems to be the return above means we'll never even try to enable
the plane, we're only relying on the fact that plane_ctl is not zero
initialize so maybe  bit 31 is already set.


>  
>   if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index c26ca029fc0a..3747482e8fa3 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -603,6 +603,24 @@ icl_program_input_csc(struct intel_plane *plane,
> PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
>  }
>  
> +static void
> +skl_program_async_surface_address(struct drm_i915_private *dev_priv,
> +   const struct intel_plane_state *plane_state,
> +   enum pipe pipe, enum plane_id plane_id,
> +   u32 surf_addr)
> +{
> + unsigned long irqflags;
> + u32 plane_ctl = plane_state->ctl;
> +
> + spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
> +   intel_plane_ggtt_offset(plane_state) + surf_addr);
> +
> + spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> +}
> +
>  static void
>  skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -631,6 +649,13 @@ skl_program_plane(struct intel_plane *plane,
>   u32 keymsk, keymax;
>   u32 plane_ctl = plane_state->ctl;
>  
> + /* During Async flip, no other updates are allowed */
> + if (crtc_state->uapi.async_flip) {
> + skl_program_async_surface_address(dev_priv, plane_state,
> +   pipe, plane_id, surf_addr);
> + return;
> + }


I'd vote for us to keep the "don't rewrite registers that shouldn't
change" part on its own commit, since it's just an optimization. It
could even go at the end of the series. But perhaps this is simple
enough and not needed.


> +
>   plane_ctl |= skl_plane_ctl_crtc(crtc_state);
>  
>   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8cee06314d5d..19aad4199874 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6935,6 +6935,7 @@ enum {
>  #define   PLANE_CTL_TILED_X  (1 << 10)
>  #define   PLANE_CTL_TILED_Y  (4 << 10)
>  #define   PLANE_CTL_TILED_YF (5 << 10)
> +#define   PLANE_CTL_ASYNC_FLIP   (1 << 9)
>  #define   PLANE_CTL_FLIP_HORIZONTAL  (1 << 8)
>  #define   PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE   (1 << 4) /* TGL+ */
>  #define   PLANE_CTL_ALPHA_MASK   (0x3 << 4) /* Pre-GLK */

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915

[Paulo Zanoni]

Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Without async flip support in the kernel, fullscreen apps where game
> resolution is equal to the screen resolution, must perform an extra blit
> per frame prior to flipping.
> 
> Asynchronous page flips will also boost the FPS of Mesa benchmarks.

We had a discussion in patch 1 of v3 regarding the semantics of
asynchronous flips from the point of view of the user space: how we
handle our vblank counters, how/when we increment the sequence events
and how we handle timestamps, how/when we deliver vblank events. Since
apparently AMD has already enabled this feature, our job would be to
implement their current behavior so KMS clients can continue to work
regardless of the driver. 

From reading this series it's not super clear to me what exactly is the
behavior that we're trying to follow. Can you please document somewhere
what are these rules and expectations? This way, people writing user
space code (or people improving the other drivers) will have an easier
time. In addition to text documentation, I believe all our assumptions
and rules should be coded in IGT: we want to be confident a driver
implements async page flips correctly when we can verify it passes the
IGT.

Also, in the other patches I raise some additional questions regarding
mixing async with non-async vblanks: IMHO this should also be
documented as text and as IGT.

> 
> v2: -Few patches have been squashed and patches have been shuffled as
>  per the reviews on the previous version.
> 
> v3: -Few patches have been squashed and patches have been shuffled as
>  per the reviews on the previous version.
> 
> v4: -Made changes to fix the sequence and time stamp issue as per the
>  comments received on the previous version.
> -Timestamps are calculated using the flip done time stamp and current
>  timestamp. Here I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used
>  for timestamp calculations.
> -Event is sent from the interrupt handler immediately using this
>  updated timestamps and sequence.
> -Added more state checks as async flip should only allow change in plane
>  surface address and nothing else should be allowed to change.
> -Added a separate plane hook for async flip.
> -Need to find a way to reject fbc enabling if it comes as part of this
>  flip as bspec states that changes to FBC are not allowed.
> 
> v5: -Fixed the Checkpatch and sparse warnings.
> 
> Karthik B S (5):
>   drm/i915: Add enable/disable flip done and flip done handler
>   drm/i915: Add support for async flips in I915
>   drm/i915: Add checks specific to async flips
>   drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
>   drm/i915: Enable async flips in i915
> 
>  drivers/gpu/drm/i915/display/intel_display.c | 123 +++
>  drivers/gpu/drm/i915/display/intel_sprite.c  |  33 -
>  drivers/gpu/drm/i915/i915_irq.c  |  83 +++--
>  drivers/gpu/drm/i915/i915_irq.h  |   2 +
>  drivers/gpu/drm/i915/i915_reg.h  |   5 +-
>  5 files changed, 237 insertions(+), 9 deletions(-)
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Add enable/disable flip done and flip done handler

[Paulo Zanoni]

Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
> 
> Enable the flip done interrupt in IER.
> 
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
> 
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
> 
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
>  flips without pageflip events.
> 
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the begining of
>  flip_done_handler to remove sporadic WARN_ON that is seen.
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 10 
>  drivers/gpu/drm/i915/i915_irq.c  | 52 
>  drivers/gpu/drm/i915/i915_irq.h  |  2 +
>  3 files changed, 64 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f40b909952cc..48cc1fc9bc5a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15530,6 +15530,13 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>  
>   intel_dbuf_pre_plane_update(state);
>  
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + skl_enable_flip_done(&crtc->base);
> + break;
> + }
> + }
> +
>   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
>   dev_priv->display.commit_modeset_enables(state);
>  
> @@ -15551,6 +15558,9 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   drm_atomic_helper_wait_for_flip_done(dev, &state->base);
>  
>   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(&crtc->base);
> +
>   if (new_crtc_state->hw.active &&
>   !needs_modeset(new_crtc_state) &&
>   !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index efdd4c7b8e92..632e7b1deb87 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1295,6 +1295,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private 
> *dev_priv,
>u32 crc4) {}
>  #endif
>  
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> +   unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_pending_vblank_event *e = crtc_state->event;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + crtc_state->event = NULL;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + drm_crtc_send_vblank_event(&crtc->base, e);

I don't think this is what we want. With this, the events the Kernel
sends us all have the same sequence and timestamp. In fact, the IGT
test you submitted fails because of this.

In my original hackish proof-of-concept patch I had changed
drm_update_vblank_count() to force diff=1 in order to always send
events and I also changed g4x_get_vblank_counter() to get the counter
from FLIPCOUNT (which updates every time there's a flip) instead of
FRMCOUNT (which doesn't seem to increment when you do async flips).
That is a drastic change, but the patch was just a PoC so I didn't care
about keeping anything else working.

One thing that confused me a little bit when dealing the the
vblank/flip event interface from drm.ko is that "flips" and "vblanks"
seem to be changed interchangeably, which is confusing for async flips:
if you keep forever doing async flips in the very first few scanlines
you never actually reach the "vblank" period, yet you keep flipping
your frame. Then, what should your expectation regarding events be?

I think we may need to check how the other drivers handle async vblanks
(or how drm.ko wants us to handle async vblanks). Should we increment
sequence on every async flip? What about the timestamp?

Daniel, Ville, do you happen to know the proper semantics here?

There's certainly some adjustment to do to both this patch and the 

Re: [Intel-gfx] [PATCH v3 0/5] Asynchronous flip implementation for i915

[Paulo Zanoni]

Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
> Without async flip support in the kernel, fullscreen apps where game
> resolution is equal to the screen resolution, must perform an extra blit
> per frame prior to flipping.
> 
> Asynchronous page flips will also boost the FPS of Mesa benchmarks.
> 
> v2: Few patches have been squashed and patches have been shuffled as
> per the reviews on the previous version.
> 
> v3: Few patches have been squashed and patches have been shuffled as
> per the reviews on the previous version.

Hello

I asked quite a few questions in the review of v2, but never got any
replies. I see some things regarding those questions are different in
v3, but I still would really like to have those answers in direct
text/email form in order to clarify my understanding of your original
intent (and also help me understand why things are different in v3).
Would you mind replying to those emails?

Thanks,
Paulo

> 
> Karthik B S (5):
>   drm/i915: Add enable/disable flip done and flip done handler
>   drm/i915: Add support for async flips in I915
>   drm/i915: Add checks specific to async flips
>   drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
>   drm/i915: Enable async flips in i915
> 
>  drivers/gpu/drm/i915/display/intel_display.c | 71 
>  drivers/gpu/drm/i915/display/intel_sprite.c  |  8 ++-
>  drivers/gpu/drm/i915/i915_irq.c  | 52 ++
>  drivers/gpu/drm/i915/i915_irq.h  |  2 +
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  5 files changed, 133 insertions(+), 1 deletion(-)
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915: Make commit call blocking in case of async flips

[Paulo Zanoni]

Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
> Make the commit call blocking in case of async flips
> so that there is no delay in completing the flip.
> 

I'm trying to understand the code. Can you please elaborate more here
in this commit message? Why exactly does the call need to block? What
would be the problem of not having this patch? And how does blocking
ensures no delay?

> v2: -Rebased
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8601b159f425..a5203de24045 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15563,7 +15563,9 @@ static int intel_atomic_commit(struct drm_device *dev,
>  {
>   struct intel_atomic_state *state = to_intel_atomic_state(_state);
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - int ret = 0;
> + struct intel_crtc_state *new_crtc_state;
> + struct intel_crtc *crtc;
> + int ret = 0, i;
>  
>   state->wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
>  
> @@ -15589,10 +15591,6 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>* (assuming we had any) would solve these problems.
>*/
>   if (INTEL_GEN(dev_priv) < 9 && state->base.legacy_cursor_update) {
> - struct intel_crtc_state *new_crtc_state;
> - struct intel_crtc *crtc;
> - int i;
> -
>   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
>   if (new_crtc_state->wm.need_postvbl_update ||
>   new_crtc_state->update_wm_post)
> @@ -15634,6 +15632,13 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>   drm_atomic_state_get(&state->base);
>   INIT_WORK(&state->base.commit_work, intel_atomic_commit_work);
>  
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + nonblock = false;
> + break;
> + }
> + }
> +
>   i915_sw_fence_commit(&state->commit_ready);
>   if (nonblock && state->modeset) {
>   queue_work(dev_priv->modeset_wq, &state->base.commit_work);

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add enable/disable flip done and flip done handler

[Paulo Zanoni]

Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
> 
> Enable the flip done interrupt in IER.
> 
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
> 
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
> 
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
>  flips without pageflip events.
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  7 +++
>  drivers/gpu/drm/i915/i915_irq.c  | 51 
>  drivers/gpu/drm/i915/i915_irq.h  |  2 +
>  3 files changed, 60 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index bae1d89875d6..3ce80634d047 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15391,6 +15391,13 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   if (state->modeset)
>   icl_dbuf_slice_pre_update(state);
>  
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + skl_enable_flip_done(&crtc->base);
> + break;
> + }
> + }
> +
>   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
>   dev_priv->display.commit_modeset_enables(state);
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1502ab44f1a5..9b64ed78523e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1253,6 +1253,22 @@ display_pipe_crc_irq_handler(struct drm_i915_private 
> *dev_priv,
>u32 crc4) {}
>  #endif
>  
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> +   unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + drm_crtc_send_vblank_event(&crtc->base, crtc_state->event);
> + crtc_state->event = NULL;
> +
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> + skl_disable_flip_done(&crtc->base);

I am trying to understand the code here but I'm not 100% confident, so
my comments may be wrong. Please correct me if needed.

Can you please elaborate on why we have to disable the interrupt from
the interrupt handler? This looks racy to me, but I may be wrong, so an
explanation would help.

In my head this would be the ideal:

- If the whole ioctl is blocked until we get the interrupt (which is
what patch 04 suggests), then whatever is blocking waiting on the
interrupt should enable+disable the interrupt (so no disable_flip_done
here).

- If the ioctl is not blocked, then isn't there a race risk in case
user space finds a way to submit 2 ioctls before we get an interrupt?
If no, why would this be impossible? Some sort of refcounting could
help in this case. I'm also thinking in cases like alternating between
flips requiring events and flips not requiring events.

> +}
>  
>  static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> @@ -2355,6 +2371,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   if (iir & GEN8_PIPE_VBLANK)
>   intel_handle_vblank(dev_priv, pipe);
>  
> + if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
> + flip_done_handler(dev_priv, pipe);
> +
>   if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
>   hsw_pipe_crc_irq_handler(dev_priv, pipe);
>  
> @@ -2636,6 +2655,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
>   return 0;
>  }
>  
> +void skl_enable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +
> + bdw_enable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +}
> +
>  /* Called f

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Enable async flips in i915

[Paulo Zanoni]

Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
> Enable asynchronous flips in i915 for gen9+ platforms.
> 
> v2: -Async flip enablement should be a stand alone patch (Paulo)

... and at the very end of the series.

If someone is bisecting the Kernel for some problem unrelated to async
flips, and they end up exactly at this commit, and their user space
happens to try to do async flips, will their system be broken? A quick
check at patches 4, 5 and 6 suggests they are necessary for the feature
to work, so here we're enabling a feature that we know won't work
because its support is not fully merged yet.

A patch series is not allowed to break the Kernel in the middle and
then fix it later.

> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index cf8f5779dee4..8601b159f425 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -17574,6 +17574,9 @@ static void intel_mode_config_init(struct 
> drm_i915_private *i915)
>  
>   mode_config->funcs = &intel_mode_funcs;
>  
> + if (INTEL_GEN(i915) >= 9)
> + mode_config->async_page_flip = true;
> +
>   /*
>* Maximum framebuffer dimensions, chosen to match
>* the maximum render engine surface size on gen4+.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Add checks specific to async flips

[Paulo Zanoni]

Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
> Support added only for async flips on primary plane.
> If flip is requested on any other plane, reject it.
> 
> Make sure there is no change in fbc, offset and framebuffer modifiers
> when async flip is requested.
> 
> If any of these are modified, reject async flip.
> 
> v2: -Replace DRM_ERROR (Paulo)
> -Add check for changes in OFFSET, FBC, RC(Paulo)
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 59 
>  1 file changed, 59 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a5203de24045..ac7f26a9ac4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14669,6 +14669,57 @@ static bool 
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
>   return false;
>  }
>  
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> + struct intel_plane_state *new_plane_state, *old_plane_state;
> + struct intel_crtc *crtc;
> + struct intel_plane *intel_plane;
> + int i, j;
> +
> + /*FIXME: Async flip is only supported for primary plane currently
> +  * Support for overlays to be added.
> +  */
> +
> + /*TODO: Check if the user space can handle the EINVAL return
> +  * or if it needs to be handled differently
> +  */

Does this mean we still didn't test the series against real user space?
I mean, X server with xf86-video-modesetting and some real workload
instead of just igt. I can't feel confident to give r-b tags if I know
the patches were not tested yet. The series should probably have been
marked as an RFC.


> + for_each_new_plane_in_state(&state->base, plane, plane_state, j) {
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> + DRM_DEBUG_KMS("Async flips is NOT supported for 
> non-primary plane\n");
> + return -EINVAL;
> + }
> + }
> +
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (old_crtc_state->enable_fbc != new_crtc_state->enable_fbc) {
> + DRM_DEBUG_KMS("FBC status cannot be changed in async 
> flip\n");
> + return -EINVAL;
> + }
> + }
> +
> + for_each_oldnew_intel_plane_in_state(state, intel_plane, 
> old_plane_state,
> +  new_plane_state, i) {
> + if ((old_plane_state->color_plane[0].x !=
> +  new_plane_state->color_plane[0].x) ||
> + (old_plane_state->color_plane[0].y !=
> +  new_plane_state->color_plane[0].y)) {
> + DRM_DEBUG_KMS("Offsets cannot be changed in async\n");
> + return -EINVAL;
> + }
> +
> + if (old_plane_state->uapi.fb->modifier !=
> + new_plane_state->uapi.fb->modifier) {
> + DRM_DEBUG_KMS("Framebuffer modifiers cannot be changed 
> in async flip\n");
> + return -EINVAL;
> + }
> + }
> + return 0;
> +}
> +
>  /**
>   * intel_atomic_check - validate state object
>   * @dev: drm device
> @@ -14697,6 +14748,14 @@ static int intel_atomic_check(struct drm_device *dev,
>   if (ret)
>   goto fail;
>  
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + ret = intel_atomic_check_async(state);
> + if  (ret)
> + goto fail;
> + }
> + }
> +
>   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
>   new_crtc_state, i) {
>   if (!needs_modeset(new_crtc_state)) {

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 0/7] Asynchronous flip implementation for i915

[Paulo Zanoni]

Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Without async flip support in the kernel, fullscreen apps where game
> resolution is equal to the screen resolution, must perform an extra blit
> per frame prior to flipping.
> 
> Asynchronous page flips will also boost the FPS of Mesa benchmarks.


Thanks a lot for doing this work!

I did some quick smoke tests on a Gemini Lake and while this appears to
be working fine with xf86-video-modesetting, the "pageflip.c" program I
shared previously breaks when you launch it as "./pageflip -n": this
argument makes the program *not* request for page flip events (by not
setting DRM_MODE_PAGE_FLIP_EVENT) and just try to flip as fast as it
can. I didn't investigate why this breaks, but it's probably some
corner case the series is forgetting.

Also, doesn't async pageflip interact with some other display features?
Don't we need to disable at least one of FBC, PSR and/or render
compression when using async page flips?

Ville mentioned some possible interactions with SURF/OFFSET tracking
too (framebuffers not being at the start of the bo), which doesn't seem
to be covered by the series.

Thanks,
Paulo

> 
> Karthik B S (7):
>   drm/i915: Define flip done functions and enable IER
>   drm/i915: Add support for async flips in I915
>   drm/i915: Make commit call blocking in case of async flips
>   drm/i915: Add checks specific to async flips
>   drm/i915: Add flip_done_handler definition
>   drm/i915: Enable and handle flip done interrupt
>   drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
> 
>  drivers/gpu/drm/i915/display/intel_display.c | 55 +--
>  drivers/gpu/drm/i915/display/intel_sprite.c  | 12 ++--
>  drivers/gpu/drm/i915/i915_irq.c  | 58 +++-
>  drivers/gpu/drm/i915/i915_irq.h  |  2 +
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  5 files changed, 117 insertions(+), 11 deletions(-)
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 5/7] drm/i915: Add flip_done_handler definition

[Paulo Zanoni]

Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Send the flip done event in the handler and disable the interrupt.
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 5955e737a45d..1feda9aecf4a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1243,6 +1243,24 @@ display_pipe_crc_irq_handler(struct drm_i915_private 
> *dev_priv,
>u32 crc4) {}
>  #endif
>  
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> +   unsigned int pipe)

The compiler is going to complain that we added a static function with
no caller.

See my comment on commit 1: please squash this patch with the one that
makes use of the new function.

> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + if (crtc_state->event->base.event->type == DRM_EVENT_FLIP_COMPLETE) {
> + drm_crtc_send_vblank_event(&crtc->base, crtc_state->event);
> + crtc_state->event = NULL;
> + }
> +
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> + icl_disable_flip_done(&crtc->base);
> +}
>  
>  static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 4/7] drm/i915: Add checks specific to async flips

[Paulo Zanoni]

Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Support added only for async flips on primary plane.
> If flip is requested on any other plane, reject it.
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 29 
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 25fad5d01e67..a8de08c3773e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14732,6 +14732,31 @@ static bool 
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
>   return false;
>  }
>  
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> + int i, j;
> +
> + /*FIXME: Async flip is only supported for primary plane currently
> +  * Support for overlays to be added.
> +  */
> + for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> + if (crtc_state->uapi.async_flip) {
> + for_each_new_plane_in_state(&state->base,
> + plane, plane_state, j) {
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> + DRM_ERROR("Async flips is NOT supported 
> for non-primary plane\n");

My understanding is that this is not a case of DRM_ERROR, since it's
just user space doing something it shouldn't.

Have we checked if xf86-video-modesetting or some other current user
space is going to try these calls on non-primary when async_flips are
enabled? Specifically, how does it react when it gets the EINVAL? We
should try to avoid the case where we release a Kernel that current
user space is not prepared for (even if it's not the Kernel's fault).


> + return -EINVAL;
> + }
> + }
> + }
> + }
> + return 0;
> +}
> +
>  /**
>   * intel_atomic_check - validate state object
>   * @dev: drm device
> @@ -14760,6 +14785,10 @@ static int intel_atomic_check(struct drm_device *dev,
>   if (ret)
>   goto fail;
>  
> + ret = intel_atomic_check_async(state);
> + if  (ret)
> + goto fail;
> +
>   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
>   new_crtc_state, i) {
>   if (!needs_modeset(new_crtc_state)) {

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 2/7] drm/i915: Add support for async flips in I915

[Paulo Zanoni]

Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Enable support for async flips in I915.
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 4 
>  drivers/gpu/drm/i915/i915_reg.h  | 1 +
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index dd47eb65b563..4ce9897f5c58 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4756,6 +4756,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
> *crtc_state,
>   plane_ctl |= PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE;
>   }
>  
> + if (crtc_state->uapi.async_flip)
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;
> +
>   plane_ctl |= skl_plane_ctl_format(fb->format->format);
>   plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
>   plane_ctl |= skl_plane_ctl_rotate(rotation & DRM_MODE_ROTATE_MASK);
> @@ -17738,6 +17741,7 @@ static void intel_mode_config_init(struct 
> drm_i915_private *i915)
>  
>   mode_config->funcs = &intel_mode_funcs;
>  
> + mode_config->async_page_flip = true;

We should only enable the feature to user space after it has been fully
implemented inside the Kernel. Think about the case where git-bisect
decides to land at exactly this commit when someone is debugging a
failure unrelated to async vblanks.

Also, when features have trivial on/off switches like the line above,
it's better if the patch that enables the feature only contains the
line that toggles the on/off switch. This way, if a revert is needed,
we can just switch it to off without removing more code. Also, it
enables us to land the rest of the code while keeping the feature off
for stabilization.

Also, the line above is enabling the feature for every platform, which
is probably not a goal of this series.


>   /*
>* Maximum framebuffer dimensions, chosen to match
>* the maximum render engine surface size on gen4+.
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 80cf02a6eec1..42037aee9b78 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6794,6 +6794,7 @@ enum {
>  #define   PLANE_CTL_TILED_X  (1 << 10)
>  #define   PLANE_CTL_TILED_Y  (4 << 10)
>  #define   PLANE_CTL_TILED_YF (5 << 10)
> +#define   PLANE_CTL_ASYNC_FLIP   (1 << 9)
>  #define   PLANE_CTL_FLIP_HORIZONTAL  (1 << 8)
>  #define   PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE   (1 << 4) /* TGL+ */
>  #define   PLANE_CTL_ALPHA_MASK   (0x3 << 4) /* Pre-GLK */

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 1/7] drm/i915: Define flip done functions and enable IER

[Paulo Zanoni]

Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and enable
> the flip done interrupt in IER.
> 
> Flip done interrupt is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> 
> Signed-off-by: Karthik B S 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 37 -
>  drivers/gpu/drm/i915/i915_irq.h |  2 ++
>  2 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ecf07b0faad2..5955e737a45d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2626,6 +2626,27 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
>   return 0;
>  }
>  
> +void icl_enable_flip_done(struct drm_crtc *crtc)


Platform prefixes indicate the first platform that is able to run this
function. In this case I can't even see which platforms will run the
function because it's only later in the series that this function will
get called. I'm not a fan of this patch splitting style where a
function gets added in patch X and then used in patch X+Y. IMHO
functions should only be introduced in patches where they are used.
This makes the code much easier to review.

So, shouldn't this be skl_enable_flip_done()?

> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + struct drm_vblank_crtc *vblank = &dev_priv->drm.vblank[pipe];
> + unsigned long irqflags;
> +
> + /* Make sure that vblank is not enabled, as we are already sending
> +  * the page flip event in the flip_done_handler.
> +  */
> + if (atomic_read(&vblank->refcount) != 0)
> + drm_crtc_vblank_put(crtc);

This is the kind of thing that will be much easier to review when this
patch gets squashed in the one that makes use of these functions.

Even after reading the whole series, this put() doesn't seem correct to
me. What is the problem with having vblanks enabled? Is it because we
were sending duplicate vblank events without these lines? Where is the
get() that triggers this put()? Please help me understand this.


> +
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +
> + bdw_enable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +
> +}
> +
>  /* Called from drm generic code, passed 'crtc' which
>   * we use as a pipe index
>   */
> @@ -2686,6 +2707,20 @@ void bdw_disable_vblank(struct drm_crtc *crtc)
>   spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
>  }
>  
> +
> +void icl_disable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +
> + bdw_disable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +}
> +
>  static void ibx_irq_reset(struct drm_i915_private *dev_priv)
>  {
>   struct intel_uncore *uncore = &dev_priv->uncore;
> @@ -3375,7 +3410,7 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   de_port_masked |= CNL_AUX_CHANNEL_F;
>  
>   de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> -GEN8_PIPE_FIFO_UNDERRUN;
> +   GEN8_PIPE_FIFO_UNDERRUN | GEN9_PIPE_PLANE1_FLIP_DONE;

This is going to set this bit for gen8 too, which is something we
probably don't want since it doesn't exist there.

The patch also does not add the handler for the interrupt, which
doesn't make sense (see my point above).

Also, don't we want to do like GEN8_PIPE_VBLANK and also set it on the
power_well_post_enable hook? If not, why? This is probably a case we
should write an IGT subtest for.

>  
>   de_port_enables = de_port_masked;
>   if (IS_GEN9_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
> index 812c47a9c2d6..6fc319980dd3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.h
> +++ b/drivers/gpu/drm/i915/i915_irq.h
> @@ -114,11 +114,13 @@ int i915gm_enable_vblank(struct drm_crtc *crtc);
>  int i965_enable_vblank(struct drm_crtc *crtc);
>  int ilk_enable_vblank(struct drm_crtc *crtc);
>  int bdw_enable_vblank(struct drm_crtc *crtc);
> +void icl_enable_flip_done(struct drm_crtc *crtc);
>  void i8xx_disable_vblank(struct drm_crtc *crtc);
>  void i915gm_disable_vblank(struct drm_crtc *crtc);
>  void i965_disable_vblank(struct drm_crtc *crtc);
>  void ilk_disable_vblank(struct drm_crtc *crtc);
>  void bdw_disable_vblank(struct drm_crtc *crtc);
> +void icl_disable_flip_done(struct drm_crtc *crtc);
>  
>  void gen2_irq_reset(struct intel_uncore *uncore);
>  void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,

Re: [Intel-gfx] [PATCH] drm/i915/dp: use logical operators with boolean type

[Paulo Zanoni]

Em qui, 2019-05-02 às 11:29 +0300, Jani Nikula escreveu:
> Using arithmetic operators with booleans is confusing. Switch to logical
> operators.
> 
> Cc: Paulo Zanoni 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4e7b8d..ef4992f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5094,7 +5094,7 @@ static void icl_update_tc_port_type(struct 
> drm_i915_private *dev_priv,
>   enum port port = intel_dig_port->base.port;
>   enum tc_port_type old_type = intel_dig_port->tc_type;
>  
> - WARN_ON(is_legacy + is_typec + is_tbt != 1);
> + WARN_ON(is_legacy || is_typec || !is_tbt);

This changes the meaning. You're interpreting this as:

WARN_ON(is_legacy + is_typec + (is_tbt != 1))

while the original intent of the code is to be:

WARN_ON((is_legacy + is_typec + is_tbt) != 1)

and a quick check on operator precedence tables leads me to think the
original code is indeed correct.

We're asserting exactly one of these bools enabled, so the logic
operation would be something like:

WARN_ON((is_legacy && (is_typec || is_tbt)) ||
(is_typec && (is_legacy || is_tbt)) ||
(is_tbt && (is_legacy || is_typec)) ||
(!is_legacy && !is_typec && !is_tbt))

I would still prefer the arithmetic operation.

>  
>   if (is_legacy)
>   intel_dig_port->tc_type = TC_PORT_LEGACY;

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: disable framebuffer compression on GeminiLake

[Paulo Zanoni]

Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > From: Daniel Drake 
> > 
> > On many (all?) the Gemini Lake systems we work with, there is frequent
> > momentary graphical corruption at the top of the screen, and it seems
> > that disabling framebuffer compression can avoid this.
> > 
> > The ticket was reported 6 months ago and has already affected a
> > multitude of users, without any real progress being made. So, lets
> > disable framebuffer compression on GeminiLake until a solution is found.
> > 
> > Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085
> > Signed-off-by: Daniel Drake 
> > Signed-off-by: Jian-Hong Pan 
> 
> Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") ?
> Cc: Paulo Zanoni 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc:  # v4.11+
> 
> glk landed 1 month before, so that seems the earliest broken point.
> 

The bug is well reported, the bug author is helpful and it even has a
description of "steps to reproduce" that looks very easy (although I
didn't try it). Everything suggests this is a bug the display team
could actually solve with not-so-many hours of debugging.

In the meantime, unbreak the systems:
Reviewed-by: Paulo Zanoni 

> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 656e684e7c9a..fc018f3f53a1 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1278,6 +1278,10 @@ static int intel_sanitize_fbc_option(struct 
> > drm_i915_private *dev_priv)
> > if (!HAS_FBC(dev_priv))
> > return 0;
> >  
> > +   /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
> > +   if (IS_GEMINILAKE(dev_priv))
> > +   return 0;
> > +
> > if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
> > return 1;
> >  
> > -- 
> > 2.21.0
> > 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for IRQ initialization debloat and conversion to uncore (rev2)

[Paulo Zanoni]

Em seg, 2019-04-15 às 09:42 +0300, Tomi Sarvela escreveu:
> On 4/12/19 11:57 PM, Paulo Zanoni wrote:
> > Em qui, 2019-04-11 às 01:08 +, Patchwork escreveu:
> > > == Series Details ==
> > > 
> > > Series: IRQ initialization debloat and conversion to uncore (rev2)
> > > URL   : https://patchwork.freedesktop.org/series/59202/
> > > State : success
> > 
> > So, this is the BAT email I got yesterday. I don't see the FI.CI.IGT
> > email anywhere: it's not showing on patchwork and it's also not showing
> > on https://intel-gfx-ci.01.org/queue/ as something to-do. Will CI run
> > the full IGT run in this series? Why not? I wanted to merge it.
> 
> On Thu and Fri the CI (or rather, our lab network) had serious issues 
> with DNS connectivity. We're mostly clear now, one issue remains but it 
> shouldn't affect productivity.

Thanks for letting me know. I was unsure if there was some new CI rule
in place or that maybe I just did something wrong.

> 
> Seems that the re-testing did the trick for you?

Yeah, I pushed the retest button a little later I sent the email.

Thanks,
Paulo

> 
> 
> Tomi

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for IRQ initialization debloat and conversion to uncore (rev2)

[Paulo Zanoni]

Em qui, 2019-04-11 às 01:08 +, Patchwork escreveu:
> == Series Details ==
> 
> Series: IRQ initialization debloat and conversion to uncore (rev2)
> URL   : https://patchwork.freedesktop.org/series/59202/
> State : success

So, this is the BAT email I got yesterday. I don't see the FI.CI.IGT
email anywhere: it's not showing on patchwork and it's also not showing
on https://intel-gfx-ci.01.org/queue/ as something to-do. Will CI run
the full IGT run in this series? Why not? I wanted to merge it.

Thanks,
Paulo

> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_5904 -> Patchwork_12760
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   External URL: 
> https://patchwork.freedesktop.org/api/1.0/series/59202/revisions/2/mbox/
> 
> Known issues
> 
> 
>   Here are the changes found in Patchwork_12760 that come from known issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@amdgpu/amd_cs_nop@fork-compute0:
> - fi-icl-y:   NOTRUN -> SKIP [fdo#109315] +17
> 
>   * igt@gem_exec_basic@basic-bsd2:
> - fi-icl-y:   NOTRUN -> SKIP [fdo#109276] +7
> 
>   * igt@gem_exec_basic@readonly-bsd1:
> - fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] +57
> 
>   * igt@gem_exec_parse@basic-rejected:
> - fi-icl-y:   NOTRUN -> SKIP [fdo#109289] +1
> 
>   * igt@i915_selftest@live_contexts:
> - fi-icl-y:   NOTRUN -> DMESG-FAIL [fdo#108569]
> 
>   * igt@i915_selftest@live_execlists:
> - fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720]
> 
>   * igt@i915_selftest@live_hangcheck:
> - fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927]
> 
>   * igt@kms_busy@basic-flip-c:
> - fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
> 
>   * igt@kms_chamelium@dp-crc-fast:
> - fi-icl-y:   NOTRUN -> SKIP [fdo#109284] +8
> 
>   * igt@kms_force_connector_basic@force-load-detect:
> - fi-icl-y:   NOTRUN -> SKIP [fdo#109285] +3
> 
>   * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
> - fi-byt-clapper: PASS -> FAIL [fdo#103191]
> 
>   * igt@kms_psr@primary_mmap_gtt:
> - fi-skl-guc: NOTRUN -> SKIP [fdo#109271] +49
> - fi-icl-y:   NOTRUN -> SKIP [fdo#110189] +3
> 
>   * igt@kms_psr@primary_page_flip:
> - fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50
> 
>   * igt@prime_vgem@basic-fence-flip:
> - fi-icl-y:   NOTRUN -> SKIP [fdo#109294]
> 
>   * igt@runner@aborted:
> - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]
> 
>   
>  Possible fixes 
> 
>   * igt@i915_selftest@live_contexts:
> - fi-bdw-gvtdvm:  DMESG-FAIL [fdo#110235 ] -> PASS
> 
>   * igt@i915_selftest@live_evict:
> - fi-bsw-kefka:   DMESG-WARN [fdo#107709] -> PASS
> 
>   * igt@kms_frontbuffer_tracking@basic:
> - fi-byt-clapper: FAIL [fdo#103167] -> PASS
> 
>   * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
> - fi-byt-clapper: FAIL [fdo#103191] -> PASS
> 
>   
>   [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
>   [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
>   [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
>   [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
>   [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
>   [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
>   [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
>   [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
>   [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
>   [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
>   [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
>   [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
>   [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
>   [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
>   [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
>   [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
>   [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 
> 
> 
> Participating hosts (45 -> 38)
> --
> 
>   Additional (4): fi-icl-y fi-skl-guc fi-apl-guc fi-snb-2520m 
>   Missing(11): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-glk-dsi 
> fi-byt-squawks fi-bwr-2160 fi-bsw-cyan fi-ctg-p8600 fi-blb-e6850 fi-bdw-samus 
> fi-kbl-r 
> 
> 
> Build changes
> -
> 
> * Linux: CI_DRM_5904 -> Patchwork_12760
> 
>   CI_DRM_5904: f0ba5aa7a6ab956f01dbaf1b16720da3ca859230 @ 
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_4942: ff8929d4d5b57b544e699fa428930f0fd66dd2dc @ 
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>   Patchwork_12760: 84a9eee43744c59bbfca952ea970891ee1076c77 @ 
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
>

[Intel-gfx] [PATCH 1/5] drm/i915: refactor the IRQ init/reset macros

[Paulo Zanoni]

The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen4,
with the usual VLV/CHV exceptions).

One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:

add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565)
Function old new   delta
gen3_irq_reset - 233+233
gen3_irq_init  - 151+151
i8xx_irq_postinstall 459 442 -17
gen11_irq_postinstall804 744 -60
ironlake_irq_postinstall 450 353 -97
vlv_display_irq_postinstall  348 245-103
i965_irq_postinstall 378 272-106
i915_irq_postinstall 333 227-106
gen8_irq_power_well_post_enable  374 240-134
ironlake_irq_reset   397 218-179
vlv_display_irq_reset616 433-183
i965_irq_reset   374 180-194
cherryview_irq_reset 379 185-194
i915_irq_reset   407 209-198
ibx_irq_reset332 133-199
gen5_gt_irq_postinstall  533 332-201
gen8_irq_power_well_pre_disable  434 204-230
gen8_gt_irq_postinstall  469 196-273
gen8_de_irq_postinstall 1200 836-364
gen5_gt_irq_reset471  76-395
gen8_gt_irq_reset775  99-676
gen8_irq_reset  1100 333-767
gen11_irq_reset 1959 686   -1273
Total: Before=2259222, After=2253657, chg -0.25%

v2:
 - Make checkpatch happy with a temporary which_ (Checkpatch).
 - Reorder the arguments for the INIT macros (Ville).
 - Correctly explain when the register offsets change in the commit
   message (Ville).
 - Use more line breaks in the macro calls to make the arguments look
   a little more organized/readable.
 - Update the bloat-o-meter output (minor change only).

Reviewed-by: Ville Syrjälä  (v1)
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 136 
 1 file changed, 86 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8d8935d71180..60a3f4203ac3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,36 +136,48 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
 };
 
-/* IIR can theoretically queue up two events. Be paranoid. */
-#define GEN8_IRQ_RESET_NDX(type, which) do { \
-   I915_WRITE(GEN8_##type##_IMR(which), 0x); \
-   POSTING_READ(GEN8_##type##_IMR(which)); \
-   I915_WRITE(GEN8_##type##_IER(which), 0); \
-   I915_WRITE(GEN8_##type##_IIR(which), 0x); \
-   POSTING_READ(GEN8_##type##_IIR(which)); \
-   I915_WRITE(GEN8_##type##_IIR(which), 0x); \
-   POSTING_READ(GEN8_##type##_IIR(which)); \
-} while (0)
-
-#define GEN3_IRQ_RESET(type) do { \
-   I915_WRITE(type##IMR, 0x); \
-   POSTING_READ(type##IMR); \
-   I915_WRITE(type##IER, 0); \
-   I915_WRITE(type##IIR, 0x); \
-   POSTING_READ(type##IIR); \
-   I915_WRITE(type##IIR, 0x); \
-   POSTING_READ(type##IIR); \
-} while (0)
-
-#define GEN2_IRQ_RESET(type) do { \
-   I915_WRITE16(type##IMR, 0x); \
-   POSTING_READ16(type##IMR); \
-   I915_WRITE16(type##IER, 0); \
-   I915_WRITE16(type##IIR, 0x); \
-   POSTING_READ16(type##IIR); \
-   I915_WRITE16(type##IIR, 0x); \
-   POSTING_READ16(type##IIR); \
-} while (0)
+static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+  i915_reg_t iir, i915_reg_t ier)
+{
+   I915_WRITE(imr, 0x);
+   POSTING_READ(imr);
+
+   I915_WRITE(ier, 0);
+
+   /* IIR can theoretically queue up two events. Be paranoid. */
+   I915_WRITE(iir, 0x);
+   POSTING_READ(iir);
+   I915_WRITE(iir, 0x);
+   POSTING_READ(iir);
+}
+
+static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+  i915_reg_t iir, i915_reg_t ier)
+{
+   I915_WRITE16(imr, 0x);
+   POSTING_READ16(imr);
+
+   I915_W

[Intel-gfx] [PATCH 5/5] drm/i915: fully convert the IRQ initialization macros to intel_uncore

[Paulo Zanoni]

Make them take the uncore argument from the caller instead of passing
the implicit &dev_priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.

v2: Rebase on top of the newer patches.

Reviewed-by: Ville Syrjälä  (v1)
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 144 +++-
 1 file changed, 88 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 22b89da25289..f6ab4c4c6388 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -165,18 +165,18 @@ static void gen2_irq_reset(struct intel_uncore *uncore)
intel_uncore_posting_read16(uncore, GEN2_IIR);
 }
 
-#define GEN8_IRQ_RESET_NDX(type, which) \
+#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
 ({ \
unsigned int which_ = which; \
-   gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which_), \
+   gen3_irq_reset((uncore), GEN8_##type##_IMR(which_), \
   GEN8_##type##_IIR(which_), GEN8_##type##_IER(which_)); \
 })
 
-#define GEN3_IRQ_RESET(type) \
-   gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
+#define GEN3_IRQ_RESET(uncore, type) \
+   gen3_irq_reset((uncore), type##IMR, type##IIR, type##IER)
 
-#define GEN2_IRQ_RESET() \
-   gen2_irq_reset(&dev_priv->uncore)
+#define GEN2_IRQ_RESET(uncore) \
+   gen2_irq_reset(uncore)
 
 /*
  * We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -233,23 +233,23 @@ static void gen2_irq_init(struct intel_uncore *uncore,
intel_uncore_posting_read16(uncore, GEN2_IMR);
 }
 
-#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
+#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
 ({ \
unsigned int which_ = which; \
-   gen3_irq_init(&dev_priv->uncore, \
+   gen3_irq_init((uncore), \
  GEN8_##type##_IMR(which_), imr_val, \
  GEN8_##type##_IER(which_), ier_val, \
  GEN8_##type##_IIR(which_)); \
 })
 
-#define GEN3_IRQ_INIT(type, imr_val, ier_val) \
-   gen3_irq_init(&dev_priv->uncore, \
+#define GEN3_IRQ_INIT(uncore, type, imr_val, ier_val) \
+   gen3_irq_init((uncore), \
  type##IMR, imr_val, \
  type##IER, ier_val, \
  type##IIR)
 
-#define GEN2_IRQ_INIT(imr_val, ier_val) \
-   gen2_irq_init(&dev_priv->uncore, imr_val, ier_val)
+#define GEN2_IRQ_INIT(uncore, imr_val, ier_val) \
+   gen2_irq_init((uncore), imr_val, ier_val)
 
 static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
 static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
@@ -3349,10 +3349,12 @@ static void i945gm_vblank_work_fini(struct 
drm_i915_private *dev_priv)
 
 static void ibx_irq_reset(struct drm_i915_private *dev_priv)
 {
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
if (HAS_PCH_NOP(dev_priv))
return;
 
-   GEN3_IRQ_RESET(SDE);
+   GEN3_IRQ_RESET(uncore, SDE);
 
if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT(dev_priv))
I915_WRITE(SERR_INT, 0x);
@@ -3380,13 +3382,17 @@ static void ibx_irq_pre_postinstall(struct drm_device 
*dev)
 
 static void gen5_gt_irq_reset(struct drm_i915_private *dev_priv)
 {
-   GEN3_IRQ_RESET(GT);
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
+   GEN3_IRQ_RESET(uncore, GT);
if (INTEL_GEN(dev_priv) >= 6)
-   GEN3_IRQ_RESET(GEN6_PM);
+   GEN3_IRQ_RESET(uncore, GEN6_PM);
 }
 
 static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
 {
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
if (IS_CHERRYVIEW(dev_priv))
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
else
@@ -3397,12 +3403,14 @@ static void vlv_display_irq_reset(struct 
drm_i915_private *dev_priv)
 
i9xx_pipestat_irq_reset(dev_priv);
 
-   GEN3_IRQ_RESET(VLV_);
+   GEN3_IRQ_RESET(uncore, VLV_);
dev_priv->irq_mask = ~0u;
 }
 
 static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
 {
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
u32 pipestat_mask;
u32 enable_mask;
enum pipe pipe;
@@ -3427,7 +3435,7 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)
 
dev_priv->irq_mask = ~enable_mask;
 
-   GEN3_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
+   GEN3_IRQ_INIT(uncore, VLV_, dev_priv->irq_mask, enable_mask);
 }
 
 /* drm_dma.h hooks
@@ -3435,8 +3443,9 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)
 static void ironlake_irq_reset(struct drm_device *d

[Intel-gfx] [PATCH 3/5] drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers

[Paulo Zanoni]

This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.

Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.

Cc: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  6 +--
 drivers/gpu/drm/i915/i915_gpu_error.c   |  4 +-
 drivers/gpu/drm/i915/i915_irq.c | 52 -
 drivers/gpu/drm/i915/i915_reg.h |  8 ++--
 drivers/gpu/drm/i915/i915_reset.c   |  3 +-
 drivers/gpu/drm/i915/intel_overlay.c|  4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++---
 7 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 77b3252bdb2e..5823ffb17821 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -833,11 +833,11 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
 
} else if (!HAS_PCH_SPLIT(dev_priv)) {
seq_printf(m, "Interrupt enable:%08x\n",
-  I915_READ(IER));
+  I915_READ(GEN2_IER));
seq_printf(m, "Interrupt identity:  %08x\n",
-  I915_READ(IIR));
+  I915_READ(GEN2_IIR));
seq_printf(m, "Interrupt mask:  %08x\n",
-  I915_READ(IMR));
+  I915_READ(GEN2_IMR));
for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat: %08x\n",
   pipe_name(pipe),
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 43b68fdc8967..f51ff683dd2e 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1635,9 +1635,9 @@ static void capture_reg_state(struct i915_gpu_state 
*error)
error->gtier[0] = I915_READ(GTIER);
error->ngtier = 1;
} else if (IS_GEN(dev_priv, 2)) {
-   error->ier = I915_READ16(IER);
+   error->ier = I915_READ16(GEN2_IER);
} else if (!IS_VALLEYVIEW(dev_priv)) {
-   error->ier = I915_READ(IER);
+   error->ier = I915_READ(GEN2_IER);
}
error->eir = I915_READ(EIR);
error->pgtbl_er = I915_READ(PGTBL_ER);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1f1db2bd879..2910b06913af 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -153,16 +153,16 @@ static void gen3_irq_reset(struct drm_i915_private 
*dev_priv, i915_reg_t imr,
 
 static void gen2_irq_reset(struct drm_i915_private *dev_priv)
 {
-   I915_WRITE16(IMR, 0x);
-   POSTING_READ16(IMR);
+   I915_WRITE16(GEN2_IMR, 0x);
+   POSTING_READ16(GEN2_IMR);
 
-   I915_WRITE16(IER, 0);
+   I915_WRITE16(GEN2_IER, 0);
 
/* IIR can theoretically queue up two events. Be paranoid. */
-   I915_WRITE16(IIR, 0x);
-   POSTING_READ16(IIR);
-   I915_WRITE16(IIR, 0x);
-   POSTING_READ16(IIR);
+   I915_WRITE16(GEN2_IIR, 0x);
+   POSTING_READ16(GEN2_IIR);
+   I915_WRITE16(GEN2_IIR, 0x);
+   POSTING_READ16(GEN2_IIR);
 }
 
 #define GEN8_IRQ_RESET_NDX(type, which) \
@@ -199,17 +199,17 @@ static void gen3_assert_iir_is_zero(struct 
drm_i915_private *dev_priv,
 
 static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
 {
-   u16 val = I915_READ16(IIR);
+   u16 val = I915_READ16(GEN2_IIR);
 
if (val == 0)
return;
 
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
-i915_mmio_reg_offset(IIR), val);
-   I915_WRITE16(IIR, 0x);
-   POSTING_READ16(IIR);
-   I915_WRITE16(IIR, 0x);
-   POSTING_READ16(IIR);
+i915_mmio_reg_offset(GEN2_IIR), val);
+   I915_WRITE16(GEN2_IIR, 0x);
+   POSTING_READ16(GEN2_IIR);
+   I915_WRITE16(GEN2_IIR, 0x);
+   POSTING_READ16(GEN2_IIR);
 }
 
 static void gen3_irq_init(struct drm_i915_private *dev_priv,
@@ -229,9 +229,9 @@ static void gen2_irq_init(struct drm_i915_private *dev_priv,
 {

[Intel-gfx] [PATCH 4/5] drm/i915: convert the IRQ initialization functions to intel_uncore

[Paulo Zanoni]

The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.

While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.

v2: Rebase on top of the new patches.

Reviewed-by: Ville Syrjälä  (v1)
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 97 -
 1 file changed, 48 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2910b06913af..22b89da25289 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,121 +136,120 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
 };
 
-static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
   i915_reg_t iir, i915_reg_t ier)
 {
-   I915_WRITE(imr, 0x);
-   POSTING_READ(imr);
+   intel_uncore_write(uncore, imr, 0x);
+   intel_uncore_posting_read(uncore, imr);
 
-   I915_WRITE(ier, 0);
+   intel_uncore_write(uncore, ier, 0);
 
/* IIR can theoretically queue up two events. Be paranoid. */
-   I915_WRITE(iir, 0x);
-   POSTING_READ(iir);
-   I915_WRITE(iir, 0x);
-   POSTING_READ(iir);
+   intel_uncore_write(uncore, iir, 0x);
+   intel_uncore_posting_read(uncore, iir);
+   intel_uncore_write(uncore, iir, 0x);
+   intel_uncore_posting_read(uncore, iir);
 }
 
-static void gen2_irq_reset(struct drm_i915_private *dev_priv)
+static void gen2_irq_reset(struct intel_uncore *uncore)
 {
-   I915_WRITE16(GEN2_IMR, 0x);
-   POSTING_READ16(GEN2_IMR);
+   intel_uncore_write16(uncore, GEN2_IMR, 0x);
+   intel_uncore_posting_read16(uncore, GEN2_IMR);
 
-   I915_WRITE16(GEN2_IER, 0);
+   intel_uncore_write16(uncore, GEN2_IER, 0);
 
/* IIR can theoretically queue up two events. Be paranoid. */
-   I915_WRITE16(GEN2_IIR, 0x);
-   POSTING_READ16(GEN2_IIR);
-   I915_WRITE16(GEN2_IIR, 0x);
-   POSTING_READ16(GEN2_IIR);
+   intel_uncore_write16(uncore, GEN2_IIR, 0x);
+   intel_uncore_posting_read16(uncore, GEN2_IIR);
+   intel_uncore_write16(uncore, GEN2_IIR, 0x);
+   intel_uncore_posting_read16(uncore, GEN2_IIR);
 }
 
 #define GEN8_IRQ_RESET_NDX(type, which) \
 ({ \
unsigned int which_ = which; \
-   gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which_), \
+   gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which_), \
   GEN8_##type##_IIR(which_), GEN8_##type##_IER(which_)); \
 })
 
 #define GEN3_IRQ_RESET(type) \
-   gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+   gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
 
 #define GEN2_IRQ_RESET() \
-   gen2_irq_reset(dev_priv)
+   gen2_irq_reset(&dev_priv->uncore)
 
 /*
  * We should clear IMR at preinstall/uninstall, and just check at postinstall.
  */
-static void gen3_assert_iir_is_zero(struct drm_i915_private *dev_priv,
-   i915_reg_t reg)
+static void gen3_assert_iir_is_zero(struct intel_uncore *uncore, i915_reg_t 
reg)
 {
-   u32 val = I915_READ(reg);
+   u32 val = intel_uncore_read(uncore, reg);
 
if (val == 0)
return;
 
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
 i915_mmio_reg_offset(reg), val);
-   I915_WRITE(reg, 0x);
-   POSTING_READ(reg);
-   I915_WRITE(reg, 0x);
-   POSTING_READ(reg);
+   intel_uncore_write(uncore, reg, 0x);
+   intel_uncore_posting_read(uncore, reg);
+   intel_uncore_write(uncore, reg, 0x);
+   intel_uncore_posting_read(uncore, reg);
 }
 
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
+static void gen2_assert_iir_is_zero(struct intel_uncore *uncore)
 {
-   u16 val = I915_READ16(GEN2_IIR);
+   u16 val = intel_uncore_read16(uncore, GEN2_IIR);
 
if (val == 0)
return;
 
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
 i915_mmio_reg_offset(GEN2_IIR), val);
-   I915_WRITE16(GEN2_IIR, 0x);
-   POSTING_READ16(GEN2_IIR);
-   I915_WRITE16(GEN2_IIR, 0x);
-   POSTING_READ16(GEN2_IIR);
+   intel_uncore_write16(uncore, GEN2_IIR, 0x);
+   intel_uncore_posting_read16(uncore, GEN2_IIR);
+   intel_uncore_write16(uncore, GEN2_IIR, 0x);
+   intel_uncore_posting_read16(uncore, GEN2_IIR);
 }
 
-static void gen3_irq_init(struct drm_i915_private *dev_priv,
+static 

[Intel-gfx] [PATCH 0/5] IRQ initialization debloat and conversion to uncore, v2

[Paulo Zanoni]

The first patch is a simple refactor to try to debloat our IRQ
initialization and the last ones are a tiny conversion to the new
intel_uncore model. I'm not sure how much we want patch 5 right now,
but my understanding is that we want to move in that direction anyway,
so why not now.

New in v2:
 - Two additional patches based on the discussion with Ville and Checkpatch.
 - No more checkpatch complaints.

Cc: Ville Syrjälä 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 

Paulo Zanoni (5):
  drm/i915: refactor the IRQ init/reset macros
  drm/i915: don't specify the IRQ register in the gen2 macros
  drm/i915: add GEN2_ prefix to the I{E,I,M,S}R registers
  drm/i915: convert the IRQ initialization functions to intel_uncore
  drm/i915: fully convert the IRQ initialization macros to intel_uncore

 drivers/gpu/drm/i915/i915_debugfs.c |   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c   |   4 +-
 drivers/gpu/drm/i915/i915_irq.c | 298 ++--
 drivers/gpu/drm/i915/i915_reg.h |   8 +-
 drivers/gpu/drm/i915/i915_reset.c   |   3 +-
 drivers/gpu/drm/i915/intel_overlay.c|   4 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  10 +-
 7 files changed, 197 insertions(+), 136 deletions(-)

-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/5] drm/i915: don't specify the IRQ register in the gen2 macros

[Paulo Zanoni]

Like the gen3+ macros, the gen2 versions of the IRQ initialization
macros take the register name in the 'type' argument. But gen2 only
has one set of registers, so there's really no need to specify the
type. This commit removes the type argument and uses the registers
directly instead of passing them through variables.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 57 +++--
 1 file changed, 25 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 60a3f4203ac3..b1f1db2bd879 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -151,19 +151,18 @@ static void gen3_irq_reset(struct drm_i915_private 
*dev_priv, i915_reg_t imr,
POSTING_READ(iir);
 }
 
-static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
-  i915_reg_t iir, i915_reg_t ier)
+static void gen2_irq_reset(struct drm_i915_private *dev_priv)
 {
-   I915_WRITE16(imr, 0x);
-   POSTING_READ16(imr);
+   I915_WRITE16(IMR, 0x);
+   POSTING_READ16(IMR);
 
-   I915_WRITE16(ier, 0);
+   I915_WRITE16(IER, 0);
 
/* IIR can theoretically queue up two events. Be paranoid. */
-   I915_WRITE16(iir, 0x);
-   POSTING_READ16(iir);
-   I915_WRITE16(iir, 0x);
-   POSTING_READ16(iir);
+   I915_WRITE16(IIR, 0x);
+   POSTING_READ16(IIR);
+   I915_WRITE16(IIR, 0x);
+   POSTING_READ16(IIR);
 }
 
 #define GEN8_IRQ_RESET_NDX(type, which) \
@@ -176,8 +175,8 @@ static void gen2_irq_reset(struct drm_i915_private 
*dev_priv, i915_reg_t imr,
 #define GEN3_IRQ_RESET(type) \
gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
 
-#define GEN2_IRQ_RESET(type) \
-   gen2_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+#define GEN2_IRQ_RESET() \
+   gen2_irq_reset(dev_priv)
 
 /*
  * We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -198,20 +197,19 @@ static void gen3_assert_iir_is_zero(struct 
drm_i915_private *dev_priv,
POSTING_READ(reg);
 }
 
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv,
-   i915_reg_t reg)
+static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
 {
-   u16 val = I915_READ16(reg);
+   u16 val = I915_READ16(IIR);
 
if (val == 0)
return;
 
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
-i915_mmio_reg_offset(reg), val);
-   I915_WRITE16(reg, 0x);
-   POSTING_READ16(reg);
-   I915_WRITE16(reg, 0x);
-   POSTING_READ16(reg);
+i915_mmio_reg_offset(IIR), val);
+   I915_WRITE16(IIR, 0x);
+   POSTING_READ16(IIR);
+   I915_WRITE16(IIR, 0x);
+   POSTING_READ16(IIR);
 }
 
 static void gen3_irq_init(struct drm_i915_private *dev_priv,
@@ -227,15 +225,13 @@ static void gen3_irq_init(struct drm_i915_private 
*dev_priv,
 }
 
 static void gen2_irq_init(struct drm_i915_private *dev_priv,
- i915_reg_t imr, u32 imr_val,
- i915_reg_t ier, u32 ier_val,
- i915_reg_t iir)
+ u32 imr_val, u32 ier_val)
 {
-   gen2_assert_iir_is_zero(dev_priv, iir);
+   gen2_assert_iir_is_zero(dev_priv);
 
-   I915_WRITE16(ier, ier_val);
-   I915_WRITE16(imr, imr_val);
-   POSTING_READ16(imr);
+   I915_WRITE16(IER, ier_val);
+   I915_WRITE16(IMR, imr_val);
+   POSTING_READ16(IMR);
 }
 
 #define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
@@ -253,11 +249,8 @@ static void gen2_irq_init(struct drm_i915_private 
*dev_priv,
  type##IER, ier_val, \
  type##IIR)
 
-#define GEN2_IRQ_INIT(type, imr_val, ier_val) \
-   gen2_irq_init(dev_priv, \
- type##IMR, imr_val, \
- type##IER, ier_val, \
- type##IIR)
+#define GEN2_IRQ_INIT(imr_val, ier_val) \
+   gen2_irq_init(dev_priv, imr_val, ier_val)
 
 static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
 static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
@@ -4247,7 +4240,7 @@ static int i8xx_irq_postinstall(struct drm_device *dev)
I915_MASTER_ERROR_INTERRUPT |
I915_USER_INTERRUPT;
 
-   GEN2_IRQ_INIT(, dev_priv->irq_mask, enable_mask);
+   GEN2_IRQ_INIT(dev_priv->irq_mask, enable_mask);
 
/* Interrupt setup is already guaranteed to be single-threaded, this is
 * just to make the assert_spin_locked check happy. */
-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for IRQ initialization debloat and conversion to uncore

[Paulo Zanoni]

Em ter, 2019-04-09 às 21:20 +0300, Ville Syrjälä escreveu:
> On Tue, Apr 09, 2019 at 10:34:22AM -0700, Paulo Zanoni wrote:
> > Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu:
> > > == Series Details ==
> > > 
> > > Series: IRQ initialization debloat and conversion to uncore
> > > URL   : https://patchwork.freedesktop.org/series/59202/
> > > State : warning
> > > 
> > > == Summary ==
> > > 
> > > $ dim checkpatch origin/drm-tip
> > > 7f73d1fe31bb drm/i915: refactor the IRQ init/reset macros
> > > -:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> > > side-effects?
> > > #114: FILE: drivers/gpu/drm/i915/i915_irq.c:169:
> > > +#define GEN8_IRQ_RESET_NDX(type, which) \
> > > + gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \
> > > +GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
> > > 
> > > -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> > > side-effects?
> > > #172: FILE: drivers/gpu/drm/i915/i915_irq.c:236:
> > > +#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
> > > + gen3_irq_init(dev_priv, GEN8_##type##_IMR(which), \
> > > +   GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \
> > > +   imr_val, ier_val)
> > > 
> > > total: 0 errors, 0 warnings, 2 checks, 135 lines checked
> > > 82160241d80f drm/i915: convert the IRQ initialization functions to 
> > > intel_uncore
> > > 8c1c76059a41 drm/i915: fully convert the IRQ initialization macros to 
> > > intel_uncore
> > > -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> > > side-effects?
> > > #24: FILE: drivers/gpu/drm/i915/i915_irq.c:169:
> > > +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
> > > + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \
> > >  GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
> > > 
> > > -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> > > side-effects?
> > > #46: FILE: drivers/gpu/drm/i915/i915_irq.c:236:
> > > +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
> > > + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \
> > > GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \
> > > imr_val, ier_val)
> > 
> > The whiches are not really a regression, but OK we can deal with them
> > to make the robots happy.
> > 
> > > -:401: ERROR:SPACING: space prohibited before that close parenthesis ')'
> > > #401: FILE: drivers/gpu/drm/i915/i915_irq.c:4228:
> > > + GEN2_IRQ_RESET(uncore, );
> > > 
> > > -:416: ERROR:SPACING: space prohibited before that ',' (ctx:WxW)
> > > #416: FILE: drivers/gpu/drm/i915/i915_irq.c:4252:
> > > + GEN2_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask);
> > > ^
> > > 
> > > -:433: ERROR:SPACING: space prohibited before that close parenthesis ')'
> > > #433: FILE: drivers/gpu/drm/i915/i915_irq.c:4397:
> > > + GEN3_IRQ_RESET(uncore, );
> > > 
> > > -:448: ERROR:SPACING: space prohibited before that ',' (ctx:WxW)
> > > #448: FILE: drivers/gpu/drm/i915/i915_irq.c:4430:
> > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask);
> > > ^
> > > 
> > > -:464: ERROR:SPACING: space prohibited before that close parenthesis ')'
> > > #464: FILE: drivers/gpu/drm/i915/i915_irq.c:4508:
> > > + GEN3_IRQ_RESET(uncore, );
> > > 
> > > -:479: ERROR:SPACING: space prohibited before that ',' (ctx:WxW)
> > > #479: FILE: drivers/gpu/drm/i915/i915_irq.c:4552:
> > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask);
> > 
> > For these ones I really think the spaces help. I would love to read
> > some opinions. Perhaps some comment like /* paste token here */ would
> > help make the code more readable and could help silence checkpatch.
> > Opinions?
> 
> Or maybe rename the registers to eg. I9XX_IIR?

That makes more sense. We use these regs on gen2 too, so I suppose
I8XX_IIR (or GEN2_IIR) would make more sense. OTOH it would break our
current naming rule.

I'll submit v2 soon. Thanks.

> 
> > > ^
> > > 
> > > total: 6 errors, 0 warnings, 2 checks, 432 lines checked
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: refactor the IRQ init/reset macros

[Paulo Zanoni]

Em ter, 2019-04-09 às 21:10 +0300, Ville Syrjälä escreveu:
> On Mon, Apr 08, 2019 at 05:37:27PM -0700, Paulo Zanoni wrote:
> > The whole point of having macros here is for the token pasting
> > necessary to automatically have IMR, IIR and IER selected. We don't
> > really need or want all the inlining that happens as a consequence.
> > The good thing about the current code is that it works regardless of
> > the relative offsets between these registers (they change after gen3).
> 
> Did you mean "after gen4"? The DE/GT split happened at ilk, and I
> guess that's when the four registers also got reshuffled for some
> reason. Ignoring the funkyness of vlv/chv or course :)
> 

You're right. I'll fix the commit message.


> > One thing which we can do is to split the logic of what we do with
> > imr/ier/iir to functions separate from the macros that pick them.
> > That's what we do in this commit. This allows us to get rid of the
> > gen8 duplicates and also all the inlining:
> > 
> > add/remove: 2/0 grow/shrink: 0/21 up/down: 383/-6006 (-5623)
> > Function old new   delta
> > gen3_irq_reset - 233+233
> > gen3_irq_init  - 150+150
> > i8xx_irq_postinstall 459 442 -17
> > gen11_irq_postinstall804 744 -60
> > ironlake_irq_postinstall 450 353 -97
> > vlv_display_irq_postinstall  348 245-103
> > i965_irq_postinstall 378 275-103
> > i915_irq_postinstall 333 228-105
> > gen8_irq_power_well_post_enable  374 210-164
> > ironlake_irq_reset   397 218-179
> > vlv_display_irq_reset616 433-183
> > i965_irq_reset   374 180-194
> > cherryview_irq_reset 379 185-194
> > i915_irq_reset   407 209-198
> > ibx_irq_reset332 133-199
> > gen5_gt_irq_postinstall  533 332-201
> > gen8_irq_power_well_pre_disable  434 204-230
> > gen8_gt_irq_postinstall  469 196-273
> > gen8_de_irq_postinstall 1200 805-395
> > gen5_gt_irq_reset471  76-395
> > gen8_gt_irq_reset    775  99-676
> > gen8_irq_reset  1100 333-767
> > gen11_irq_reset 1959 686   -1273
> > Total: Before=2262051, After=2256428, chg -0.25%
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 123 +++-
> >  1 file changed, 73 insertions(+), 50 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 6454ddc37f8b..a1e7944fb5d0 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -136,36 +136,45 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
> > [HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
> >  };
> >  
> > -/* IIR can theoretically queue up two events. Be paranoid. */
> > -#define GEN8_IRQ_RESET_NDX(type, which) do { \
> > -   I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > -   POSTING_READ(GEN8_##type##_IMR(which)); \
> > -   I915_WRITE(GEN8_##type##_IER(which), 0); \
> > -   I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> > -   POSTING_READ(GEN8_##type##_IIR(which)); \
> > -   I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> > -   POSTING_READ(GEN8_##type##_IIR(which)); \
> > -} while (0)
> > -
> > -#define GEN3_IRQ_RESET(type) do { \
> > -   I915_WRITE(type##IMR, 0x); \
> > -   POSTING_READ(type##IMR); \
> > -   I915_WRITE(type##IER, 0); \
> > -   I915_WRITE(type##IIR, 0x); \
> > -   POSTING_READ(type##IIR); \
> > -   I915_WRITE(type##IIR, 0x); \
> > -   POSTING_READ(type##IIR); \
> > -} while (0)
> > -
> > -#define GEN2_IRQ_RESET(type) do { \
> > -   I915_WRITE16(type##IMR, 0x); \
> > -   POSTING_READ16(type##IMR); \
> > -   I915_WRITE16(type##IER, 0); \
> > -   I915_WRITE16(type##IIR, 0x); \
> > -   POSTING_READ16(type##IIR); \
> > -   I915_WRITE16(type##IIR, 0x); \
> > -   POSTING_READ16(type#

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for IRQ initialization debloat and conversion to uncore

[Paulo Zanoni]

Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu:
> == Series Details ==
> 
> Series: IRQ initialization debloat and conversion to uncore
> URL   : https://patchwork.freedesktop.org/series/59202/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> 7f73d1fe31bb drm/i915: refactor the IRQ init/reset macros
> -:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> side-effects?
> #114: FILE: drivers/gpu/drm/i915/i915_irq.c:169:
> +#define GEN8_IRQ_RESET_NDX(type, which) \
> + gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \
> +GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
> 
> -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> side-effects?
> #172: FILE: drivers/gpu/drm/i915/i915_irq.c:236:
> +#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
> + gen3_irq_init(dev_priv, GEN8_##type##_IMR(which), \
> +   GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \
> +   imr_val, ier_val)
> 
> total: 0 errors, 0 warnings, 2 checks, 135 lines checked
> 82160241d80f drm/i915: convert the IRQ initialization functions to 
> intel_uncore
> 8c1c76059a41 drm/i915: fully convert the IRQ initialization macros to 
> intel_uncore
> -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> side-effects?
> #24: FILE: drivers/gpu/drm/i915/i915_irq.c:169:
> +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
> + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \
>  GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
> 
> -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible 
> side-effects?
> #46: FILE: drivers/gpu/drm/i915/i915_irq.c:236:
> +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
> + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \
> GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \
> imr_val, ier_val)

The whiches are not really a regression, but OK we can deal with them
to make the robots happy.

> 
> -:401: ERROR:SPACING: space prohibited before that close parenthesis ')'
> #401: FILE: drivers/gpu/drm/i915/i915_irq.c:4228:
> + GEN2_IRQ_RESET(uncore, );
> 
> -:416: ERROR:SPACING: space prohibited before that ',' (ctx:WxW)
> #416: FILE: drivers/gpu/drm/i915/i915_irq.c:4252:
> + GEN2_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask);
> ^
> 
> -:433: ERROR:SPACING: space prohibited before that close parenthesis ')'
> #433: FILE: drivers/gpu/drm/i915/i915_irq.c:4397:
> + GEN3_IRQ_RESET(uncore, );
> 
> -:448: ERROR:SPACING: space prohibited before that ',' (ctx:WxW)
> #448: FILE: drivers/gpu/drm/i915/i915_irq.c:4430:
> + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask);
> ^
> 
> -:464: ERROR:SPACING: space prohibited before that close parenthesis ')'
> #464: FILE: drivers/gpu/drm/i915/i915_irq.c:4508:
> + GEN3_IRQ_RESET(uncore, );
> 
> -:479: ERROR:SPACING: space prohibited before that ',' (ctx:WxW)
> #479: FILE: drivers/gpu/drm/i915/i915_irq.c:4552:
> + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask);

For these ones I really think the spaces help. I would love to read
some opinions. Perhaps some comment like /* paste token here */ would
help make the code more readable and could help silence checkpatch.
Opinions?

> ^
> 
> total: 6 errors, 0 warnings, 2 checks, 432 lines checked
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915: refactor the IRQ init/reset macros

[Paulo Zanoni]

The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen3).

One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:

add/remove: 2/0 grow/shrink: 0/21 up/down: 383/-6006 (-5623)
Function old new   delta
gen3_irq_reset - 233+233
gen3_irq_init  - 150+150
i8xx_irq_postinstall 459 442 -17
gen11_irq_postinstall804 744 -60
ironlake_irq_postinstall 450 353 -97
vlv_display_irq_postinstall  348 245-103
i965_irq_postinstall 378 275-103
i915_irq_postinstall 333 228-105
gen8_irq_power_well_post_enable  374 210-164
ironlake_irq_reset   397 218-179
vlv_display_irq_reset616 433-183
i965_irq_reset   374 180-194
cherryview_irq_reset 379 185-194
i915_irq_reset   407 209-198
ibx_irq_reset332 133-199
gen5_gt_irq_postinstall  533 332-201
gen8_irq_power_well_pre_disable  434 204-230
gen8_gt_irq_postinstall  469 196-273
gen8_de_irq_postinstall 1200 805-395
gen5_gt_irq_reset471  76-395
gen8_gt_irq_reset775  99-676
gen8_irq_reset  1100 333-767
gen11_irq_reset 1959 686   -1273
Total: Before=2262051, After=2256428, chg -0.25%

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 123 +++-
 1 file changed, 73 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6454ddc37f8b..a1e7944fb5d0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,36 +136,45 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
 };
 
-/* IIR can theoretically queue up two events. Be paranoid. */
-#define GEN8_IRQ_RESET_NDX(type, which) do { \
-   I915_WRITE(GEN8_##type##_IMR(which), 0x); \
-   POSTING_READ(GEN8_##type##_IMR(which)); \
-   I915_WRITE(GEN8_##type##_IER(which), 0); \
-   I915_WRITE(GEN8_##type##_IIR(which), 0x); \
-   POSTING_READ(GEN8_##type##_IIR(which)); \
-   I915_WRITE(GEN8_##type##_IIR(which), 0x); \
-   POSTING_READ(GEN8_##type##_IIR(which)); \
-} while (0)
-
-#define GEN3_IRQ_RESET(type) do { \
-   I915_WRITE(type##IMR, 0x); \
-   POSTING_READ(type##IMR); \
-   I915_WRITE(type##IER, 0); \
-   I915_WRITE(type##IIR, 0x); \
-   POSTING_READ(type##IIR); \
-   I915_WRITE(type##IIR, 0x); \
-   POSTING_READ(type##IIR); \
-} while (0)
-
-#define GEN2_IRQ_RESET(type) do { \
-   I915_WRITE16(type##IMR, 0x); \
-   POSTING_READ16(type##IMR); \
-   I915_WRITE16(type##IER, 0); \
-   I915_WRITE16(type##IIR, 0x); \
-   POSTING_READ16(type##IIR); \
-   I915_WRITE16(type##IIR, 0x); \
-   POSTING_READ16(type##IIR); \
-} while (0)
+static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+  i915_reg_t iir, i915_reg_t ier)
+{
+   I915_WRITE(imr, 0x);
+   POSTING_READ(imr);
+
+   I915_WRITE(ier, 0);
+
+   /* IIR can theoretically queue up two events. Be paranoid. */
+   I915_WRITE(iir, 0x);
+   POSTING_READ(iir);
+   I915_WRITE(iir, 0x);
+   POSTING_READ(iir);
+}
+
+static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+  i915_reg_t iir, i915_reg_t ier)
+{
+   I915_WRITE16(imr, 0x);
+   POSTING_READ16(imr);
+
+   I915_WRITE16(ier, 0);
+
+   /* IIR can theoretically queue up two events. Be paranoid. */
+   I915_WRITE16(iir, 0x);
+   POSTING_READ16(iir);
+   I915_WRITE16(iir, 0x);
+   POSTING_READ16(iir);
+}
+
+#define GEN8_IRQ_RESET_NDX(type, which) \
+   gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \
+  GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
+
+#define GEN3_IRQ_

[Intel-gfx] [PATCH 3/3] drm/i915: fully convert the IRQ initialization macros to intel_uncore

[Paulo Zanoni]

Make them take the uncore argument from the caller instead of passing
the implicit &dev_priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 144 +++-
 1 file changed, 88 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 99a6527568cf..b6361bab1086 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -166,15 +166,15 @@ static void gen2_irq_reset(struct intel_uncore *uncore, 
i915_reg_t imr,
intel_uncore_posting_read16(uncore, iir);
 }
 
-#define GEN8_IRQ_RESET_NDX(type, which) \
-   gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which), \
+#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
+   gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \
   GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
 
-#define GEN3_IRQ_RESET(type) \
-   gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
+#define GEN3_IRQ_RESET(uncore, type) \
+   gen3_irq_reset((uncore), type##IMR, type##IIR, type##IER)
 
-#define GEN2_IRQ_RESET(type) \
-   gen2_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
+#define GEN2_IRQ_RESET(uncore, type) \
+   gen2_irq_reset((uncore), type##IMR, type##IIR, type##IER)
 
 /*
  * We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -233,17 +233,17 @@ static void gen2_irq_init(struct intel_uncore *uncore, 
i915_reg_t imr,
intel_uncore_posting_read16(uncore, imr);
 }
 
-#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
-   gen3_irq_init(&dev_priv->uncore, GEN8_##type##_IMR(which), \
+#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
+   gen3_irq_init((uncore), GEN8_##type##_IMR(which), \
  GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \
  imr_val, ier_val)
 
-#define GEN3_IRQ_INIT(type, imr_val, ier_val) \
-   gen3_irq_init(&dev_priv->uncore, type##IMR, type##IIR, type##IER, \
+#define GEN3_IRQ_INIT(uncore, type, imr_val, ier_val) \
+   gen3_irq_init((uncore), type##IMR, type##IIR, type##IER, \
  imr_val, ier_val)
 
-#define GEN2_IRQ_INIT(type, imr_val, ier_val) \
-   gen2_irq_init(&dev_priv->uncore, type##IMR, type##IIR, type##IER, \
+#define GEN2_IRQ_INIT(uncore, type, imr_val, ier_val) \
+   gen2_irq_init((uncore), type##IMR, type##IIR, type##IER, \
  imr_val, ier_val)
 
 static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32 
pm_iir);
@@ -3331,10 +3331,12 @@ static void i945gm_vblank_work_fini(struct 
drm_i915_private *dev_priv)
 
 static void ibx_irq_reset(struct drm_i915_private *dev_priv)
 {
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
if (HAS_PCH_NOP(dev_priv))
return;
 
-   GEN3_IRQ_RESET(SDE);
+   GEN3_IRQ_RESET(uncore, SDE);
 
if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT(dev_priv))
I915_WRITE(SERR_INT, 0x);
@@ -3362,13 +3364,17 @@ static void ibx_irq_pre_postinstall(struct drm_device 
*dev)
 
 static void gen5_gt_irq_reset(struct drm_i915_private *dev_priv)
 {
-   GEN3_IRQ_RESET(GT);
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
+   GEN3_IRQ_RESET(uncore, GT);
if (INTEL_GEN(dev_priv) >= 6)
-   GEN3_IRQ_RESET(GEN6_PM);
+   GEN3_IRQ_RESET(uncore, GEN6_PM);
 }
 
 static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
 {
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
if (IS_CHERRYVIEW(dev_priv))
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
else
@@ -3379,12 +3385,14 @@ static void vlv_display_irq_reset(struct 
drm_i915_private *dev_priv)
 
i9xx_pipestat_irq_reset(dev_priv);
 
-   GEN3_IRQ_RESET(VLV_);
+   GEN3_IRQ_RESET(uncore, VLV_);
dev_priv->irq_mask = ~0u;
 }
 
 static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
 {
+   struct intel_uncore *uncore = &dev_priv->uncore;
+
u32 pipestat_mask;
u32 enable_mask;
enum pipe pipe;
@@ -3409,7 +3417,7 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)
 
dev_priv->irq_mask = ~enable_mask;
 
-   GEN3_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
+   GEN3_IRQ_INIT(uncore, VLV_, dev_priv->irq_mask, enable_mask);
 }
 
 /* drm_dma.h hooks
@@ -3417,8 +3425,9 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)
 static void ironlake_irq_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_uncore *unco

[Intel-gfx] [PATCH 0/3] IRQ initialization debloat and conversion to uncore

[Paulo Zanoni]

The first patch is a simple refactor to try to debloat our IRQ
initialization and the second is a tiny conversion to the new
intel_uncore model. I'm not sure how much we want patch 3 right now,
but my understanding is that we want to move in that direction anyway,
so why not now.

Cc: Daniele Ceraolo Spurio 

Paulo Zanoni (3):
  drm/i915: refactor the IRQ init/reset macros
  drm/i915: convert the IRQ initialization functions to intel_uncore
  drm/i915: fully convert the IRQ initialization macros to intel_uncore

 drivers/gpu/drm/i915/i915_irq.c | 275 +++-
 1 file changed, 165 insertions(+), 110 deletions(-)

-- 
2.20.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: convert the IRQ initialization functions to intel_uncore

[Paulo Zanoni]

The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.

While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_irq.c | 100 
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a1e7944fb5d0..99a6527568cf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,115 +136,115 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
 };
 
-static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
   i915_reg_t iir, i915_reg_t ier)
 {
-   I915_WRITE(imr, 0x);
-   POSTING_READ(imr);
+   intel_uncore_write(uncore, imr, 0x);
+   intel_uncore_posting_read(uncore, imr);
 
-   I915_WRITE(ier, 0);
+   intel_uncore_write(uncore, ier, 0);
 
/* IIR can theoretically queue up two events. Be paranoid. */
-   I915_WRITE(iir, 0x);
-   POSTING_READ(iir);
-   I915_WRITE(iir, 0x);
-   POSTING_READ(iir);
+   intel_uncore_write(uncore, iir, 0x);
+   intel_uncore_posting_read(uncore, iir);
+   intel_uncore_write(uncore, iir, 0x);
+   intel_uncore_posting_read(uncore, iir);
 }
 
-static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen2_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
   i915_reg_t iir, i915_reg_t ier)
 {
-   I915_WRITE16(imr, 0x);
-   POSTING_READ16(imr);
+   intel_uncore_write16(uncore, imr, 0x);
+   intel_uncore_posting_read16(uncore, imr);
 
-   I915_WRITE16(ier, 0);
+   intel_uncore_write16(uncore, ier, 0);
 
/* IIR can theoretically queue up two events. Be paranoid. */
-   I915_WRITE16(iir, 0x);
-   POSTING_READ16(iir);
-   I915_WRITE16(iir, 0x);
-   POSTING_READ16(iir);
+   intel_uncore_write16(uncore, iir, 0x);
+   intel_uncore_posting_read16(uncore, iir);
+   intel_uncore_write16(uncore, iir, 0x);
+   intel_uncore_posting_read16(uncore, iir);
 }
 
 #define GEN8_IRQ_RESET_NDX(type, which) \
-   gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \
+   gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which), \
   GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
 
 #define GEN3_IRQ_RESET(type) \
-   gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+   gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
 
 #define GEN2_IRQ_RESET(type) \
-   gen2_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+   gen2_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
 
 /*
  * We should clear IMR at preinstall/uninstall, and just check at postinstall.
  */
-static void gen3_assert_iir_is_zero(struct drm_i915_private *dev_priv,
+static void gen3_assert_iir_is_zero(struct intel_uncore *uncore,
i915_reg_t reg)
 {
-   u32 val = I915_READ(reg);
+   u32 val = intel_uncore_read(uncore, reg);
 
if (val == 0)
return;
 
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
 i915_mmio_reg_offset(reg), val);
-   I915_WRITE(reg, 0x);
-   POSTING_READ(reg);
-   I915_WRITE(reg, 0x);
-   POSTING_READ(reg);
+   intel_uncore_write(uncore, reg, 0x);
+   intel_uncore_posting_read(uncore, reg);
+   intel_uncore_write(uncore, reg, 0x);
+   intel_uncore_posting_read(uncore, reg);
 }
 
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv,
+static void gen2_assert_iir_is_zero(struct intel_uncore *uncore,
i915_reg_t reg)
 {
-   u16 val = I915_READ16(reg);
+   u16 val = intel_uncore_read16(uncore, reg);
 
if (val == 0)
return;
 
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
 i915_mmio_reg_offset(reg), val);
-   I915_WRITE16(reg, 0x);
-   POSTING_READ16(reg);
-   I915_WRITE16(reg, 0x);
-   POSTING_READ16(reg);
+   intel_uncore_write16(uncore, reg, 0x);
+   intel_uncore_posting_read16(uncore, reg);
+   intel_uncore_write16(uncore, reg, 0x);
+   intel_uncore_posting_read16(uncore, reg);
 }
 
-static void gen3_irq_init(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen3_irq_init(struct intel_uncore *uncore, i915_reg_t imr,
  

Re: [Intel-gfx] [PATCH v2] drm/i915: Convert i915_reset.c over to using uncore mmio

[Paulo Zanoni]

Em sex, 2019-04-05 às 21:24 +0100, Chris Wilson escreveu:
> Currently i915_reset.c mixes calls to intel_uncore, pci and our old
> style I915_READ mmio interfaces. Cast aside the old implicit macros,
> and harmonise on using uncore throughout.
> 
> add/remove: 1/1 grow/shrink: 0/4 up/down: 65/-207 (-142)
> Function old new   delta
> rmw_register   -  65 +65
> gen8_reset_engines   945 942  -3
> g4x_do_reset 407 376 -31
> intel_gpu_reset  545 509 -36
> clear_register63   - -63
> i915_clear_error_registers   461 387 -74
> 
> A little bit of pointer dancing elimination works wonders.
> 
> v2: Roll up the helpers into intel_uncore for general use
> 
> With the helpers gcc was a little more eager to inline:
> add/remove: 0/1 grow/shrink: 1/3 up/down: 99/-133 (-34)
> Function old new   delta
> i915_clear_error_registers   461 560 +99
> gen8_reset_engines   945 942  -3
> g4x_do_reset 407 376 -31
> intel_gpu_reset  545 509 -36
> clear_register63   - -63
> Total: Before=1544400, After=1544366, chg -0.00%
> 
> Win some, lose some, gcc is gcc.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> Reviewed-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reset.c   | 122 
>  drivers/gpu/drm/i915/intel_uncore.h |  23 +-
>  2 files changed, 89 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reset.c 
> b/drivers/gpu/drm/i915/i915_reset.c
> index d44dc8422e8c..ac168de6a66e 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -18,6 +18,26 @@
>  /* XXX How to handle concurrent GGTT updates using tiling registers? */
>  #define RESET_UNDER_STOP_MACHINE 0
>  
> +static void rmw_set(struct intel_uncore *uncore, i915_reg_t reg, u32 set)
> +{
> + intel_uncore_rmw(uncore, reg, 0, set);
> +}
> +
> +static void rmw_clear(struct intel_uncore *uncore, i915_reg_t reg, u32 clr)
> +{
> + intel_uncore_rmw(uncore, reg, clr, 0);
> +}
> +
> +static void rwm_set_fw(struct intel_uncore *uncore, i915_reg_t reg, u32 set)

We're not reading, writing and then modifying :).


> +{
> + intel_uncore_rmw_fw(uncore, reg, 0, set);
> +}
> +
> +static void rmw_clear_fw(struct intel_uncore *uncore, i915_reg_t reg, u32 
> clr)
> +{
> + intel_uncore_rmw_fw(uncore, reg, clr, 0);
> +}
> +
>  static void engine_skip_context(struct i915_request *rq)
>  {
>   struct intel_engine_cs *engine = rq->engine;
> @@ -119,7 +139,7 @@ void i915_reset_request(struct i915_request *rq, bool 
> guilty)
>  
>  static void gen3_stop_engine(struct intel_engine_cs *engine)
>  {
> - struct drm_i915_private *dev_priv = engine->i915;
> + struct intel_uncore *uncore = engine->uncore;
>   const u32 base = engine->mmio_base;
>  
>   GEM_TRACE("%s\n", engine->name);
> @@ -127,20 +147,23 @@ static void gen3_stop_engine(struct intel_engine_cs 
> *engine)
>   if (intel_engine_stop_cs(engine))
>   GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
>  
> - I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
> - POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
> + intel_uncore_write_fw(uncore,
> +   RING_HEAD(base),
> +   intel_uncore_read_fw(uncore, RING_TAIL(base)));
> + intel_uncore_posting_read_fw(uncore, RING_HEAD(base)); /* paranoia */
>  
> - I915_WRITE_FW(RING_HEAD(base), 0);
> - I915_WRITE_FW(RING_TAIL(base), 0);
> - POSTING_READ_FW(RING_TAIL(base));
> + intel_uncore_write_fw(uncore, RING_HEAD(base), 0);
> + intel_uncore_write_fw(uncore, RING_TAIL(base), 0);
> + intel_uncore_posting_read_fw(uncore, RING_TAIL(base));
>  
>   /* The ring must be empty before it is disabled */
> - I915_WRITE_FW(RING_CTL(base), 0);
> + intel_uncore_write_fw(uncore, RING_CTL(base), 0);
>  
>   /* Check acts as a post */
> - if (I915_READ_FW(RING_HEAD(base)))
> + if (intel_uncore_read_fw(uncore, RING_HEAD(base)))
>   GEM_TRACE("%s: ring head [%x] not parked\n",
> -   engine->name, I915_READ_FW(RING_HEAD(base)));
> +

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Convert i915_reset.c over to using uncore mmio

[Paulo Zanoni]

Em sex, 2019-04-05 às 19:57 +0100, Chris Wilson escreveu:
> Currently i915_reset.c mixes calls to intel_uncore, pci and our old
> style I915_READ mmio interfaces. Cast aside the old implicit macros,
> and harmonise on using uncore throughout.
> 
> add/remove: 1/1 grow/shrink: 0/4 up/down: 65/-207 (-142)
> Function old new   delta
> rmw_register   -  65 +65
> gen8_reset_engines   945 942  -3
> g4x_do_reset 407 376 -31
> intel_gpu_reset  545 509 -36
> clear_register63   - -63
> i915_clear_error_registers   461 387 -74
> 
> A little bit of pointer dancing elimination works wonders.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reset.c | 125 +-
>  1 file changed, 73 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reset.c 
> b/drivers/gpu/drm/i915/i915_reset.c
> index d44dc8422e8c..f50534a833ca 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -18,6 +18,28 @@
>  /* XXX How to handle concurrent GGTT updates using tiling registers? */
>  #define RESET_UNDER_STOP_MACHINE 0
>  
> +static void rmw_register(struct intel_uncore *uncore,
> +  i915_reg_t reg, u32 clr, u32 set)
> +{
> + u32 val;
> +
> + val = intel_uncore_read(uncore, reg);
> + val &= ~clr;
> + val |= set;
> + intel_uncore_write(uncore, reg, val);
> +}
> +
> +static void rmw_register_fw(struct intel_uncore *uncore,
> + i915_reg_t reg, u32 clr, u32 set)
> +{
> + u32 val;
> +
> + val = intel_uncore_read_fw(uncore, reg);
> + val &= ~clr;
> + val |= set;
> + intel_uncore_write_fw(uncore, reg, val);
> +}

I like the idea here, maybe we could expose these concepts to the whole
driver.

But one thing I did notice is that in all of the calls there's an
argument that's zero. It's easy to get confused on the set/clear
parameter order and make a mistake. Also, when reading the code we have
to keep remembering which one comes first. Perhaps some small wrappers
for the cases where we only set or clear something (currently, 100% of
the cases) would make the code even more readable:

static inline void rmw_register_set(uncore, reg, bits_to_set)
{
rmw_register(uncore, reg, 0, bits);
}

static inline void rmw_register_clear(uncore, reg, bits_to_clear)
{
rmw_register(uncore, reg, bits, 0);
}

IMHO that would make the code much more comfortable to read. But maybe
that's because my brain is just too small.



> +
>  static void engine_skip_context(struct i915_request *rq)
>  {
>   struct intel_engine_cs *engine = rq->engine;
> @@ -119,7 +141,7 @@ void i915_reset_request(struct i915_request *rq, bool 
> guilty)
>  
>  static void gen3_stop_engine(struct intel_engine_cs *engine)
>  {
> - struct drm_i915_private *dev_priv = engine->i915;
> + struct intel_uncore *uncore = engine->uncore;
>   const u32 base = engine->mmio_base;
>  
>   GEM_TRACE("%s\n", engine->name);
> @@ -127,20 +149,23 @@ static void gen3_stop_engine(struct intel_engine_cs 
> *engine)
>   if (intel_engine_stop_cs(engine))
>   GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
>  
> - I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
> - POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
> + intel_uncore_write_fw(uncore,
> +   RING_HEAD(base),
> +   intel_uncore_read_fw(uncore, RING_TAIL(base)));
> + intel_uncore_posting_read_fw(uncore, RING_HEAD(base)); /* paranoia */
>  
> - I915_WRITE_FW(RING_HEAD(base), 0);
> - I915_WRITE_FW(RING_TAIL(base), 0);
> - POSTING_READ_FW(RING_TAIL(base));
> + intel_uncore_write_fw(uncore, RING_HEAD(base), 0);
> + intel_uncore_write_fw(uncore, RING_TAIL(base), 0);
> + intel_uncore_posting_read_fw(uncore, RING_TAIL(base));
>  
>   /* The ring must be empty before it is disabled */
> - I915_WRITE_FW(RING_CTL(base), 0);
> + intel_uncore_write_fw(uncore, RING_CTL(base), 0);
>  
>   /* Check acts as a post */
> - if (I915_READ_FW(RING_HEAD(base)))
> + if (intel_uncore_read_fw(uncore, RING_HEAD(base)))
>   GEM_TRACE("%s: ring head [%x] not parked\n",
> -   engine->name, I915_READ_FW(RING_HEAD(base)));
> +   

Re: [Intel-gfx] [PATCH] drm/i915: Make use of 'engine->uncore'

[Paulo Zanoni]

Em sex, 2019-04-05 às 17:34 +0100, Chris Wilson escreveu:
> The engine has a direct link to the intel_uncore mmio handler, so make
> use of it rather than going indirectly via &engine->i915->uncore.

Does it make sense to patch the uncore assignment in gen11_lock_sfc()
too in this file?

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Chris Wilson 
> Cc: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reset.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reset.c 
> b/drivers/gpu/drm/i915/i915_reset.c
> index ddc403ee8855..7e7342b82b78 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -469,10 +469,11 @@ static int gen11_reset_engines(struct drm_i915_private 
> *i915,
>  
>  static int gen8_engine_reset_prepare(struct intel_engine_cs *engine)
>  {
> - struct intel_uncore *uncore = &engine->i915->uncore;
> + struct intel_uncore *uncore = engine->uncore;
>   int ret;
>  
> - intel_uncore_write_fw(uncore, RING_RESET_CTL(engine->mmio_base),
> + intel_uncore_write_fw(uncore,
> +   RING_RESET_CTL(engine->mmio_base),
> _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET));
>  
>   ret = __intel_wait_for_register_fw(uncore,
> @@ -647,7 +648,7 @@ static void reset_prepare_engine(struct intel_engine_cs 
> *engine)
>* written to the powercontext is undefined and so we may lose
>* GPU state upon resume, i.e. fail to restart after a reset.
>*/
> - intel_uncore_forcewake_get(&engine->i915->uncore, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(engine->uncore, FORCEWAKE_ALL);
>   engine->reset.prepare(engine);
>  }
>  
> @@ -719,7 +720,7 @@ static int gt_reset(struct drm_i915_private *i915,
>  static void reset_finish_engine(struct intel_engine_cs *engine)
>  {
>   engine->reset.finish(engine);
> - intel_uncore_forcewake_put(&engine->i915->uncore, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(engine->uncore, FORCEWAKE_ALL);
>  }
>  
>  struct i915_gpu_restart {

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915: add uncore flags for unclaimed mmio

[Paulo Zanoni]

Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> Save the HW capabilities to avoid having to jump back to dev_priv
> every time.
> 

Reviewed-by: Paulo Zanoni 

> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   |  4 +-
>  drivers/gpu/drm/i915/intel_display.c  |  2 +-
>  drivers/gpu/drm/i915/intel_hangcheck.c|  2 +-
>  drivers/gpu/drm/i915/intel_uncore.c   | 57 ++-
>  drivers/gpu/drm/i915/intel_uncore.h   |  7 ++-
>  drivers/gpu/drm/i915/selftests/intel_uncore.c | 15 ++---
>  6 files changed, 47 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5465b99b4392..85e80701a4c6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2854,7 +2854,7 @@ static int intel_runtime_suspend(struct device *kdev)
>   enable_rpm_wakeref_asserts(dev_priv);
>   intel_runtime_pm_cleanup(dev_priv);
>  
> - if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> + if (intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore))
>   DRM_ERROR("Unclaimed access detected prior to suspending\n");
>  
>   dev_priv->runtime_pm.suspended = true;
> @@ -2908,7 +2908,7 @@ static int intel_runtime_resume(struct device *kdev)
>  
>   intel_opregion_notify_adapter(dev_priv, PCI_D0);
>   dev_priv->runtime_pm.suspended = false;
> - if (intel_uncore_unclaimed_mmio(dev_priv))
> + if (intel_uncore_unclaimed_mmio(&dev_priv->uncore))
>   DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
>  
>   if (INTEL_GEN(dev_priv) >= 11) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 008560ef4db0..9a9b78c120b1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13533,7 +13533,7 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>* so enable debugging for the next modeset - and hope we catch
>* the culprit.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
>   intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET, 
> wakeref);
>   }
>  
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 57ed49dc19c4..125662c64934 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -270,7 +270,7 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>* periodically arm the mmio checker to see if we are triggering
>* any invalid access.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
>  
>   for_each_engine(engine, dev_priv, id) {
>   struct hangcheck hc;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 0259a61a745f..1a327828f220 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -509,18 +509,17 @@ gen6_check_for_fifo_debug(struct intel_uncore *uncore)
>  }
>  
>  static bool
> -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +check_for_unclaimed_mmio(struct intel_uncore *uncore)
>  {
> - struct intel_uncore *uncore = &dev_priv->uncore;
>   bool ret = false;
>  
> - if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> + if (uncore->flags & UNCORE_HAS_FPGA_DBG_UNCLAIMED)
>   ret |= fpga_check_for_unclaimed_mmio(uncore);
>  
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + if (uncore->flags & UNCORE_HAS_DBG_UNCLAIMED)
>   ret |= vlv_check_for_unclaimed_mmio(uncore);
>  
> - if (IS_GEN_RANGE(dev_priv, 6, 7))
> + if (uncore->flags & UNCORE_HAS_FIFO)
>   ret |= gen6_check_for_fifo_debug(uncore);
>  
>   return ret;
> @@ -529,14 +528,12 @@ check_for_unclaimed_mmio(struct drm_i915_private 
> *dev_priv)
>  static void __intel_uncore_early_sanitize(struct intel_uncore *uncore,
> unsigned int restore_forcewake)
>  {
> - struct drm_i915_private *i915 = uncore_to_i915(uncore);
> -
>   /* clear out unclaimed reg detection bit */
> - if (check_for_unclaimed_mmio

Re: [Intel-gfx] [PATCH 2/9] drm/i915: add HAS_FORCEWAKE flag to uncore

[Paulo Zanoni]

Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> We have several cases where we don't have forcewake (older gens, GVT and
> planned display-only uncore), so, instead of checking every time against
> the various condition, save the info in a flag and use that.
> 
> Note that this patch also change the behavior for gen5 with vpgu
> enabled, but this is not an issue since we don't support vgpu on gen5.
> 
> v2: split out from previous path, fix check for missing case (Paulo)

Much better as a separate patch. Thanks.

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 31 +++--
>  drivers/gpu/drm/i915/intel_uncore.h |  3 +++
>  2 files changed, 24 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 3f74889c4212..0259a61a745f 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1391,7 +1391,7 @@ static void intel_uncore_fw_domains_init(struct 
> intel_uncore *uncore)
>  {
>   struct drm_i915_private *i915 = uncore_to_i915(uncore);
>  
> - if (INTEL_GEN(i915) <= 5 || intel_vgpu_active(i915))
> + if (!(uncore->flags & UNCORE_HAS_FORCEWAKE))
>   return;
>  
>   if (INTEL_GEN(i915) >= 11) {
> @@ -1590,6 +1590,9 @@ int intel_uncore_init(struct intel_uncore *uncore)
>  
>   i915_check_vgpu(i915);
>  
> + if (INTEL_GEN(i915) > 5 && !intel_vgpu_active(i915))
> + uncore->flags |= UNCORE_HAS_FORCEWAKE;
> +
>   intel_uncore_edram_detect(i915);
>   intel_uncore_fw_domains_init(uncore);
>   __intel_uncore_early_sanitize(uncore, 0);
> @@ -1598,12 +1601,14 @@ int intel_uncore_init(struct intel_uncore *uncore)
>   uncore->pmic_bus_access_nb.notifier_call =
>   i915_pmic_bus_access_notifier;
>  
> - if (IS_GEN_RANGE(i915, 2, 4) || intel_vgpu_active(i915)) {
> - ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen2);
> - ASSIGN_READ_MMIO_VFUNCS(uncore, gen2);
> - } else if (IS_GEN(i915, 5)) {
> - ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen5);
> - ASSIGN_READ_MMIO_VFUNCS(uncore, gen5);
> + if (!(uncore->flags & UNCORE_HAS_FORCEWAKE)) {
> + if (IS_GEN(i915, 5)) {
> + ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen5);
> + ASSIGN_READ_MMIO_VFUNCS(uncore, gen5);
> + } else {
> + ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen2);
> + ASSIGN_READ_MMIO_VFUNCS(uncore, gen2);
> + }
>   } else if (IS_GEN_RANGE(i915, 6, 7)) {
>   ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen6);
>  
> @@ -1912,7 +1917,10 @@ intel_uncore_forcewake_for_read(struct 
> drm_i915_private *dev_priv,
>   } else if (INTEL_GEN(dev_priv) >= 6) {
>   fw_domains = __gen6_reg_read_fw_domains(uncore, offset);
>   } else {
> - WARN_ON(!IS_GEN_RANGE(dev_priv, 2, 5));
> + /* on devices with FW we expect to hit one of the above cases */
> + if (unlikely(uncore->flags & UNCORE_HAS_FORCEWAKE))
> + MISSING_CASE(INTEL_GEN(dev_priv));
> +
>   fw_domains = 0;
>   }
>  
> @@ -1938,7 +1946,10 @@ intel_uncore_forcewake_for_write(struct 
> drm_i915_private *dev_priv,
>   } else if (IS_GEN_RANGE(dev_priv, 6, 7)) {
>   fw_domains = FORCEWAKE_RENDER;
>   } else {
> - WARN_ON(!IS_GEN_RANGE(dev_priv, 2, 5));
> + /* on devices with FW we expect to hit one of the above cases */
> + if (unlikely(uncore->flags & UNCORE_HAS_FORCEWAKE))
> + MISSING_CASE(INTEL_GEN(dev_priv));
> +
>   fw_domains = 0;
>   }
>  
> @@ -1969,7 +1980,7 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private 
> *dev_priv,
>  
>   WARN_ON(!op);
>  
> - if (intel_vgpu_active(dev_priv))
> + if (!(dev_priv->uncore.flags & UNCORE_HAS_FORCEWAKE))
>   return 0;
>  
>   if (op & FW_REG_READ)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
> b/drivers/gpu/drm/i915/intel_uncore.h
> index f7670cbc41c9..4947542c6ea7 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -127,6 +127,9 @@ struct intel_uncore {
>   } user_forcewake;
>  
>   int unclaimed_mmio_check;
> +
> + u32 flags;
> +#define UNCORE_HAS_FORCEWAKE BIT(0)
>  };
>  
>  /* Iterate over initialised fw domains */

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/9] drm/i915: rename raw reg access functions

[Paulo Zanoni]

Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> They now work on uncore, so use raw_uncore_ prefix. Also move them to
> uncore.h
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 32 ++-
>  drivers/gpu/drm/i915/i915_vgpu.c|  6 ++--
>  drivers/gpu/drm/i915/intel_uncore.c | 48 ++---
>  drivers/gpu/drm/i915/intel_uncore.h | 27 
>  4 files changed, 57 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4e30f7b19b51..558d40f07ffe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3507,32 +3507,6 @@ static inline u64 intel_rc6_residency_us(struct 
> drm_i915_private *dev_priv,
>  #define POSTING_READ(reg)(void)I915_READ_NOTRACE(reg)
>  #define POSTING_READ16(reg)  (void)I915_READ16_NOTRACE(reg)
>  
> -#define __raw_read(x, s) \
> -static inline uint##x##_t __raw_i915_read##x(const struct intel_uncore 
> *uncore, \
> -  i915_reg_t reg) \
> -{ \
> - return read##s(uncore->regs + i915_mmio_reg_offset(reg)); \
> -}
> -
> -#define __raw_write(x, s) \
> -static inline void __raw_i915_write##x(const struct intel_uncore *uncore, \
> -i915_reg_t reg, uint##x##_t val) \
> -{ \
> - write##s(val, uncore->regs + i915_mmio_reg_offset(reg)); \
> -}
> -__raw_read(8, b)
> -__raw_read(16, w)
> -__raw_read(32, l)
> -__raw_read(64, q)
> -
> -__raw_write(8, b)
> -__raw_write(16, w)
> -__raw_write(32, l)
> -__raw_write(64, q)
> -
> -#undef __raw_read
> -#undef __raw_write
> -
>  /* These are untraced mmio-accessors that are only valid to be used inside
>   * critical sections, such as inside IRQ handlers, where forcewake is 
> explicitly
>   * controlled.
> @@ -3559,9 +3533,9 @@ __raw_write(64, q)
>   * therefore generally be serialised, by either the dev_priv->uncore.lock or
>   * a more localised lock guarding all access to that bank of registers.
>   */
> -#define I915_READ_FW(reg__) __raw_i915_read32(&dev_priv->uncore, (reg__))
> -#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(&dev_priv->uncore, 
> (reg__), (val__))
> -#define I915_WRITE64_FW(reg__, val__) __raw_i915_write64(&dev_priv->uncore, 
> (reg__), (val__))
> +#define I915_READ_FW(reg__) __raw_uncore_read32(&dev_priv->uncore, (reg__))
> +#define I915_WRITE_FW(reg__, val__) __raw_uncore_write32(&dev_priv->uncore, 
> (reg__), (val__))
> +#define I915_WRITE64_FW(reg__, val__) 
> __raw_uncore_write64(&dev_priv->uncore, (reg__), (val__))
>  #define POSTING_READ_FW(reg__) (void)I915_READ_FW(reg__)
>  
>  /* "Broadcast RGB" property */
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 3d0b493e4200..94d3992b599d 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -66,17 +66,17 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
>  
>   BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>  
> - magic = __raw_i915_read64(uncore, vgtif_reg(magic));
> + magic = __raw_uncore_read64(uncore, vgtif_reg(magic));
>   if (magic != VGT_MAGIC)
>   return;
>  
> - version_major = __raw_i915_read16(uncore, vgtif_reg(version_major));
> + version_major = __raw_uncore_read16(uncore, vgtif_reg(version_major));
>   if (version_major < VGT_VERSION_MAJOR) {
>   DRM_INFO("VGT interface version mismatch!\n");
>   return;
>   }
>  
> - dev_priv->vgpu.caps = __raw_i915_read32(uncore, vgtif_reg(vgt_caps));
> + dev_priv->vgpu.caps = __raw_uncore_read32(uncore, vgtif_reg(vgt_caps));
>  
>   dev_priv->vgpu.active = true;
>   DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 1816eeae3ba9..3f74889c4212 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -31,7 +31,7 @@
>  #define FORCEWAKE_ACK_TIMEOUT_MS 50
>  #define GT_FIFO_TIMEOUT_MS10
>  
> -#define __raw_posting_read(uncore__, reg__) 
> (void)__raw_i915_read32((uncore__), (reg__))
> +#define __raw_posting_read(...) ((void)__raw_uncore_read32(__VA_ARGS__))

Now the person trying to figure out what __raw_posting_read() does will
have to chase __raw_uncore_read32(), which is not even greppable. I'm
not sure this is an improvement to our codebase, bu

Re: [Intel-gfx] [PATCH v2 09/10] drm/i915: add uncore flags

[Paulo Zanoni]

Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> Save some uncore properties to avoid having to jump back to
> dev_priv every time
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   |  4 +-
>  drivers/gpu/drm/i915/intel_display.c  |  2 +-
>  drivers/gpu/drm/i915/intel_hangcheck.c|  2 +-
>  drivers/gpu/drm/i915/intel_uncore.c   | 82 ++-
>  drivers/gpu/drm/i915/intel_uncore.h   | 10 ++-
>  drivers/gpu/drm/i915/selftests/intel_uncore.c | 15 ++--
>  6 files changed, 65 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ca41a3da1918..c609bcac8577 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2849,7 +2849,7 @@ static int intel_runtime_suspend(struct device *kdev)
>   enable_rpm_wakeref_asserts(dev_priv);
>   intel_runtime_pm_cleanup(dev_priv);
>  
> - if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> + if (intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore))
>   DRM_ERROR("Unclaimed access detected prior to suspending\n");
>  
>   dev_priv->runtime_pm.suspended = true;
> @@ -2903,7 +2903,7 @@ static int intel_runtime_resume(struct device *kdev)
>  
>   intel_opregion_notify_adapter(dev_priv, PCI_D0);
>   dev_priv->runtime_pm.suspended = false;
> - if (intel_uncore_unclaimed_mmio(dev_priv))
> + if (intel_uncore_unclaimed_mmio(&dev_priv->uncore))
>   DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
>  
>   if (INTEL_GEN(dev_priv) >= 11) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d4fcad136120..cfe379e938e6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13517,7 +13517,7 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>* so enable debugging for the next modeset - and hope we catch
>* the culprit.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
>   intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET, 
> wakeref);
>   }
>  
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 57ed49dc19c4..125662c64934 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -270,7 +270,7 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>* periodically arm the mmio checker to see if we are triggering
>* any invalid access.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
>  
>   for_each_engine(engine, dev_priv, id) {
>   struct hangcheck hc;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 1816eeae3ba9..26b28afb4500 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -509,18 +509,17 @@ gen6_check_for_fifo_debug(struct intel_uncore *uncore)
>  }
>  
>  static bool
> -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +check_for_unclaimed_mmio(struct intel_uncore *uncore)
>  {
> - struct intel_uncore *uncore = &dev_priv->uncore;
>   bool ret = false;
>  
> - if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> + if (uncore->flags & UNCORE_HAS_FPGA_DBG_UNCLAIMED)
>   ret |= fpga_check_for_unclaimed_mmio(uncore);
>  
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + if (uncore->flags & UNCORE_HAS_DBG_UNCLAIMED)
>   ret |= vlv_check_for_unclaimed_mmio(uncore);
>  
> - if (IS_GEN_RANGE(dev_priv, 6, 7))
> + if (uncore->flags & UNCORE_HAS_FIFO)
>   ret |= gen6_check_for_fifo_debug(uncore);
>  
>   return ret;
> @@ -529,14 +528,12 @@ check_for_unclaimed_mmio(struct drm_i915_private 
> *dev_priv)
>  static void __intel_uncore_early_sanitize(struct intel_uncore *uncore,
> unsigned int restore_forcewake)
>  {
> - struct drm_i915_private *i915 = uncore_to_i915(uncore);
> -
>   /* clear out unclaimed reg detection bit */
> - if (check_for_unclaimed_mmio(i915))
> + if (check_for_unclaimed_mmio(uncore))
> 

Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: move regs pointer inside the uncore structure

[Paulo Zanoni]

Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> This will allow futher simplifications in the uncore handling.
> 
> v2: move register access setup under uncore (Chris)

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 49 +++---
>  drivers/gpu/drm/i915/i915_drv.h |  6 ++--
>  drivers/gpu/drm/i915/i915_irq.c | 22 ++--
>  drivers/gpu/drm/i915/intel_lrc.c|  6 ++--
>  drivers/gpu/drm/i915/intel_uncore.c | 54 ++---
>  drivers/gpu/drm/i915/intel_uncore.h |  4 ++-
>  6 files changed, 74 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5561488ecfcd..ca41a3da1918 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -930,46 +930,6 @@ static void i915_driver_cleanup_early(struct 
> drm_i915_private *dev_priv)
>   i915_engines_cleanup(dev_priv);
>  }
>  
> -static int i915_mmio_setup(struct drm_i915_private *dev_priv)
> -{
> - struct pci_dev *pdev = dev_priv->drm.pdev;
> - int mmio_bar;
> - int mmio_size;
> -
> - mmio_bar = IS_GEN(dev_priv, 2) ? 1 : 0;
> - /*
> -  * Before gen4, the registers and the GTT are behind different BARs.
> -  * However, from gen4 onwards, the registers and the GTT are shared
> -  * in the same BAR, so we want to restrict this ioremap from
> -  * clobbering the GTT which we want ioremap_wc instead. Fortunately,
> -  * the register BAR remains the same size for all the earlier
> -  * generations up to Ironlake.
> -  */
> - if (INTEL_GEN(dev_priv) < 5)
> - mmio_size = 512 * 1024;
> - else
> - mmio_size = 2 * 1024 * 1024;
> - dev_priv->regs = pci_iomap(pdev, mmio_bar, mmio_size);
> - if (dev_priv->regs == NULL) {
> - DRM_ERROR("failed to map registers\n");
> -
> - return -EIO;
> - }
> -
> - /* Try to make sure MCHBAR is enabled before poking at it */
> - intel_setup_mchbar(dev_priv);
> -
> - return 0;
> -}
> -
> -static void i915_mmio_cleanup(struct drm_i915_private *dev_priv)
> -{
> - struct pci_dev *pdev = dev_priv->drm.pdev;
> -
> - intel_teardown_mchbar(dev_priv);
> - pci_iounmap(pdev, dev_priv->regs);
> -}
> -
>  /**
>   * i915_driver_init_mmio - setup device MMIO
>   * @dev_priv: device private
> @@ -989,11 +949,12 @@ static int i915_driver_init_mmio(struct 
> drm_i915_private *dev_priv)
>   if (i915_get_bridge_dev(dev_priv))
>   return -EIO;
>  
> - ret = i915_mmio_setup(dev_priv);
> + ret = intel_uncore_init(&dev_priv->uncore);
>   if (ret < 0)
>   goto err_bridge;
>  
> - intel_uncore_init(&dev_priv->uncore);
> + /* Try to make sure MCHBAR is enabled before poking at it */
> + intel_setup_mchbar(dev_priv);
>  
>   intel_device_info_init_mmio(dev_priv);
>  
> @@ -1010,8 +971,8 @@ static int i915_driver_init_mmio(struct drm_i915_private 
> *dev_priv)
>   return 0;
>  
>  err_uncore:
> + intel_teardown_mchbar(dev_priv);
>   intel_uncore_fini(&dev_priv->uncore);
> - i915_mmio_cleanup(dev_priv);
>  err_bridge:
>   pci_dev_put(dev_priv->bridge_dev);
>  
> @@ -1024,8 +985,8 @@ static int i915_driver_init_mmio(struct drm_i915_private 
> *dev_priv)
>   */
>  static void i915_driver_cleanup_mmio(struct drm_i915_private *dev_priv)
>  {
> + intel_teardown_mchbar(dev_priv);
>   intel_uncore_fini(&dev_priv->uncore);
> - i915_mmio_cleanup(dev_priv);
>   pci_dev_put(dev_priv->bridge_dev);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 64f0e13d6912..58a77b01fe71 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1505,8 +1505,6 @@ struct drm_i915_private {
>*/
>   resource_size_t stolen_usable_size; /* Total size minus reserved 
> ranges */
>  
> - void __iomem *regs;
> -
>   struct intel_uncore uncore;
>  
>   struct i915_virtual_gpu vgpu;
> @@ -3488,14 +3486,14 @@ static inline u64 intel_rc6_residency_us(struct 
> drm_i915_private *dev_priv,
>  static inline uint##x##_t __raw_i915_read##x(const struct drm_i915_private 
> *dev_priv, \
>i915_reg_t reg) \
>  { \
> - return read##s(dev_priv->regs + i915_mmio_reg_offset(reg)); \
> + return read##s(dev_priv

Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: use intel_uncore for all forcewake get/put

[Paulo Zanoni]

Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> Now that the internal code all works on intel_uncore, flip the
> external-facing interface.
> 
> v2: fix GVT.

Could maybe use some local intel_uncore variables in functions, but
let's go with the current color:

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/gvt/mmio_context.c   |  8 +--
>  drivers/gpu/drm/i915/gvt/scheduler.c  |  4 +-
>  drivers/gpu/drm/i915/i915_debugfs.c   | 12 ++---
>  drivers/gpu/drm/i915/i915_gem.c   | 20 +++
>  drivers/gpu/drm/i915/i915_perf.c  |  6 +--
>  drivers/gpu/drm/i915/i915_reset.c | 12 ++---
>  drivers/gpu/drm/i915/intel_display.c  |  4 +-
>  drivers/gpu/drm/i915/intel_engine_cs.c|  4 +-
>  drivers/gpu/drm/i915/intel_guc.c  |  8 +--
>  drivers/gpu/drm/i915/intel_guc_fw.c   |  4 +-
>  drivers/gpu/drm/i915/intel_huc_fw.c   |  4 +-
>  drivers/gpu/drm/i915/intel_pm.c   | 52 +--
>  drivers/gpu/drm/i915/intel_ringbuffer.c   |  8 +--
>  drivers/gpu/drm/i915/intel_uncore.c   | 52 ---
>  drivers/gpu/drm/i915/intel_uncore.h   | 12 ++---
>  drivers/gpu/drm/i915/intel_workarounds.c  |  4 +-
>  drivers/gpu/drm/i915/selftests/intel_uncore.c |  4 +-
>  17 files changed, 105 insertions(+), 113 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
> b/drivers/gpu/drm/i915/gvt/mmio_context.c
> index f64c76dd11d4..a00a807a1d55 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@ -356,7 +356,7 @@ static void handle_tlb_pending_event(struct intel_vgpu 
> *vgpu, int ring_id)
>   if (ring_id == RCS0 && INTEL_GEN(dev_priv) >= 9)
>   fw |= FORCEWAKE_RENDER;
>  
> - intel_uncore_forcewake_get(dev_priv, fw);
> + intel_uncore_forcewake_get(&dev_priv->uncore, fw);
>  
>   I915_WRITE_FW(reg, 0x1);
>  
> @@ -365,7 +365,7 @@ static void handle_tlb_pending_event(struct intel_vgpu 
> *vgpu, int ring_id)
>   else
>   vgpu_vreg_t(vgpu, reg) = 0;
>  
> - intel_uncore_forcewake_put(dev_priv, fw);
> + intel_uncore_forcewake_put(&dev_priv->uncore, fw);
>  
>   gvt_dbg_core("invalidate TLB for ring %d\n", ring_id);
>  }
> @@ -552,9 +552,9 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
>* performace for batch mmio read/write, so we need
>* handle forcewake mannually.
>*/
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
>   switch_mmio(pre, next, ring_id);
> - intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(&dev_priv->uncore, FORCEWAKE_ALL);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 7550e09939ae..3faf2438b9bc 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -988,7 +988,7 @@ static int workload_thread(void *priv)
>   workload->ring_id, workload);
>  
>   if (need_force_wake)
> - intel_uncore_forcewake_get(gvt->dev_priv,
> + intel_uncore_forcewake_get(&gvt->dev_priv->uncore,
>   FORCEWAKE_ALL);
>  
>   ret = dispatch_workload(workload);
> @@ -1010,7 +1010,7 @@ static int workload_thread(void *priv)
>   complete_current_workload(gvt, ring_id);
>  
>   if (need_force_wake)
> - intel_uncore_forcewake_put(gvt->dev_priv,
> + intel_uncore_forcewake_put(&gvt->dev_priv->uncore,
>   FORCEWAKE_ALL);
>  
>   intel_runtime_pm_put_unchecked(gvt->dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a52b7cf1525d..0dd8b3fa7fb9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1094,7 +1094,7 @@ static int i915_frequency_info(struct seq_file *m, void 
> *unused)
>   }
>  
>   /* RPSTAT1 is in the GT power well */
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
>  
>   reqf = I915_READ(GEN6_RPNSWREQ);
>   if (INTEL_GEN(dev_priv) >

Re: [Intel-gfx] [PATCH v2 01/10] drm/i915: always use masks on FW regs

[Paulo Zanoni]

Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> Upper bits are reserved on gen6, so no issue if we write them. Note that
> we're already doing this in the non-MT case of IVB, which uses the same
> register.

If, and only if, you can guarantee that writing ones to the reserved
bits in gen6 is not an issue, then everything else looks correct:

Reviewed-by: Paulo Zanoni 

I also couldn't find information about WaRsClearFWBitsAtReset. Don't we
need to update its tags to include the most recent platforms and
ivb/hsw/vlv?

> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Paulo Zanoni 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 44 +++--
>  drivers/gpu/drm/i915/intel_uncore.h |  4 ---
>  2 files changed, 16 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 7129eebc333b..b4cea3cf3915 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -59,18 +59,19 @@ intel_uncore_forcewake_domain_to_str(const enum 
> forcewake_domain_id id)
>  }
>  
>  #define fw_ack(d) readl((d)->reg_ack)
> -#define fw_set(d, val) writel((val), (d)->reg_set)
> +#define fw_set(d, val) writel(_MASKED_BIT_ENABLE((val)), (d)->reg_set)
> +#define fw_clear(d, val) writel(_MASKED_BIT_DISABLE((val)), (d)->reg_set)
>  
>  static inline void
> -fw_domain_reset(const struct intel_uncore *uncore,
> - const struct intel_uncore_forcewake_domain *d)
> +fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
>  {
>   /*
>* We don't really know if the powerwell for the forcewake domain we are
>* trying to reset here does exist at this point (engines could be fused
>* off in ICL+), so no waiting for acks
>*/
> - fw_set(d, uncore->fw_reset);
> + /* WaRsClearFWBitsAtReset:bdw,skl */
> + fw_clear(d, 0x);
>  }
>  
>  static inline void
> @@ -146,14 +147,14 @@ fw_domain_wait_ack_with_fallback(const struct 
> intel_uncore_forcewake_domain *d,
>   do {
>   wait_ack_clear(d, FORCEWAKE_KERNEL_FALLBACK);
>  
> - fw_set(d, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL_FALLBACK));
> + fw_set(d, FORCEWAKE_KERNEL_FALLBACK);
>   /* Give gt some time to relax before the polling frenzy */
>   udelay(10 * pass);
>   wait_ack_set(d, FORCEWAKE_KERNEL_FALLBACK);
>  
>   ack_detected = (fw_ack(d) & ack_bit) == value;
>  
> - fw_set(d, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL_FALLBACK));
> + fw_clear(d, FORCEWAKE_KERNEL_FALLBACK);
>   } while (!ack_detected && pass++ < 10);
>  
>   DRM_DEBUG_DRIVER("%s had to use fallback to %s ack, 0x%x (passes %u)\n",
> @@ -176,10 +177,9 @@ fw_domain_wait_ack_clear_fallback(const struct 
> intel_uncore_forcewake_domain *d)
>  }
>  
>  static inline void
> -fw_domain_get(const struct intel_uncore *uncore,
> -   const struct intel_uncore_forcewake_domain *d)
> +fw_domain_get(const struct intel_uncore_forcewake_domain *d)
>  {
> - fw_set(d, uncore->fw_set);
> + fw_set(d, FORCEWAKE_KERNEL);
>  }
>  
>  static inline void
> @@ -201,10 +201,9 @@ fw_domain_wait_ack_set_fallback(const struct 
> intel_uncore_forcewake_domain *d)
>  }
>  
>  static inline void
> -fw_domain_put(const struct intel_uncore *uncore,
> -   const struct intel_uncore_forcewake_domain *d)
> +fw_domain_put(const struct intel_uncore_forcewake_domain *d)
>  {
> - fw_set(d, uncore->fw_clear);
> + fw_clear(d, FORCEWAKE_KERNEL);
>  }
>  
>  static void
> @@ -218,7 +217,7 @@ fw_domains_get(struct drm_i915_private *i915, enum 
> forcewake_domains fw_domains)
>  
>   for_each_fw_domain_masked(d, fw_domains, i915, tmp) {
>   fw_domain_wait_ack_clear(d);
> - fw_domain_get(uncore, d);
> + fw_domain_get(d);
>   }
>  
>   for_each_fw_domain_masked(d, fw_domains, i915, tmp)
> @@ -239,7 +238,7 @@ fw_domains_get_with_fallback(struct drm_i915_private 
> *i915,
>  
>   for_each_fw_domain_masked(d, fw_domains, i915, tmp) {
>   fw_domain_wait_ack_clear_fallback(d);
> - fw_domain_get(uncore, d);
> + fw_domain_get(d);
>   }
>  
>   for_each_fw_domain_masked(d, fw_domains, i915, tmp)
> @@ -258,7 +257,7 @@ fw_domains_put(struct drm_i915_private *i915, enum 
> forcewake_domains fw_domains)
>   GEM_BUG_ON(fw_domains & ~uncore->fw_domains);
>  
>   for_each_fw_domain_masked(d, fw_domains,

Re: [Intel-gfx] [RFC 08/10] drm/i915: make raw access function work on uncore

[Paulo Zanoni]

Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> This allows us to ditch i915 in some more places.
> 
> RFC: should we just make them work directly on the regs pointer instead?

Both options look better than passing God Object dev_priv, so I'm fine
with either.

To give a parallel with other parts of the driver, in display code we
tend to pass struct intel_crtc as much as possible and only pass enum
pipe when it doesn't make sense anymore to pass a CRTC. So uncore makes
sense here.

More below:

> 
> Cc: Paulo Zanoni 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 14 ++---
>  drivers/gpu/drm/i915/i915_vgpu.c|  8 ++-
>  drivers/gpu/drm/i915/intel_uncore.c | 90 +++--
>  3 files changed, 58 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 293bf68fd8ba..a1b8059cd7f8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3485,17 +3485,17 @@ static inline u64 intel_rc6_residency_us(struct 
> drm_i915_private *dev_priv,
>  #define POSTING_READ16(reg)  (void)I915_READ16_NOTRACE(reg)
>  
>  #define __raw_read(x, s) \
> -static inline uint##x##_t __raw_i915_read##x(const struct drm_i915_private 
> *dev_priv, \
> +static inline uint##x##_t __raw_i915_read##x(const struct intel_uncore 
> *uncore, \
>i915_reg_t reg) \
>  { \
> - return read##s(dev_priv->uncore.regs + i915_mmio_reg_offset(reg)); \
> + return read##s(uncore->regs + i915_mmio_reg_offset(reg)); \
>  }
>  
>  #define __raw_write(x, s) \
> -static inline void __raw_i915_write##x(const struct drm_i915_private 
> *dev_priv, \
> +static inline void __raw_i915_write##x(const struct intel_uncore *uncore, \
>  i915_reg_t reg, uint##x##_t val) \
>  { \
> - write##s(val, dev_priv->uncore.regs + i915_mmio_reg_offset(reg)); \
> + write##s(val, uncore->regs + i915_mmio_reg_offset(reg)); \
>  }
>  __raw_read(8, b)
>  __raw_read(16, w)
> @@ -3536,9 +3536,9 @@ __raw_write(64, q)
>   * therefore generally be serialised, by either the dev_priv->uncore.lock or
>   * a more localised lock guarding all access to that bank of registers.
>   */
> -#define I915_READ_FW(reg__) __raw_i915_read32(dev_priv, (reg__))
> -#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(dev_priv, (reg__), 
> (val__))
> -#define I915_WRITE64_FW(reg__, val__) __raw_i915_write64(dev_priv, (reg__), 
> (val__))
> +#define I915_READ_FW(reg__) __raw_i915_read32(&dev_priv->uncore, (reg__))
> +#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(&dev_priv->uncore, 
> (reg__), (val__))
> +#define I915_WRITE64_FW(reg__, val__) __raw_i915_write64(&dev_priv->uncore, 
> (reg__), (val__))

Looking forward to the day dev_priv won't be implicit in register
read/write macros :).


>  #define POSTING_READ_FW(reg__) (void)I915_READ_FW(reg__)
>  
>  /* "Broadcast RGB" property */
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 869cf4a3b6de..51e5e2630eec 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -65,17 +65,19 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)

You could have gone for a local intel_uncore variable here too.

With or without that:

Reviewed-by: Paulo Zanoni 

>  
>   BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>  
> - magic = __raw_i915_read64(dev_priv, vgtif_reg(magic));
> + magic = __raw_i915_read64(&dev_priv->uncore, vgtif_reg(magic));
>   if (magic != VGT_MAGIC)
>   return;
>  
> - version_major = __raw_i915_read16(dev_priv, vgtif_reg(version_major));
> + version_major = __raw_i915_read16(&dev_priv->uncore,
> +   vgtif_reg(version_major));
>   if (version_major < VGT_VERSION_MAJOR) {
>   DRM_INFO("VGT interface version mismatch!\n");
>   return;
>   }
>  
> - dev_priv->vgpu.caps = __raw_i915_read32(dev_priv, vgtif_reg(vgt_caps));
> + dev_priv->vgpu.caps = __raw_i915_read32(&dev_priv->uncore,
> + vgtif_reg(vgt_caps));
>  
>   dev_priv->vgpu.active = true;
>   DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index ce076d046b65..4c20b2fc33fe 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>

Re: [Intel-gfx] [RFC 06/10] drm/i915: reduce the dev_priv->uncore dance in uncore.c

[Paulo Zanoni]

Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Use a local variable where it makes sense.

Also worth it on its own IMHO.

Reviewed-by: Paulo Zanoni 

> 
> Cc: Paulo Zanoni 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 79 -
>  1 file changed, 43 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index afbbefc32227..32c75337b96d 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -311,6 +311,7 @@ static inline u32 fifo_free_entries(struct 
> drm_i915_private *dev_priv)
>  
>  static void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
>  {
> + struct intel_uncore *uncore = &dev_priv->uncore;
>   u32 n;
>  
>   /* On VLV, FIFO will be shared by both SW and HW.
> @@ -318,7 +319,7 @@ static void __gen6_gt_wait_for_fifo(struct 
> drm_i915_private *dev_priv)
>   if (IS_VALLEYVIEW(dev_priv))
>   n = fifo_free_entries(dev_priv);
>   else
> - n = dev_priv->uncore.fifo_count;
> + n = uncore->fifo_count;
>  
>   if (n <= GT_FIFO_NUM_RESERVED_ENTRIES) {
>   if (wait_for_atomic((n = fifo_free_entries(dev_priv)) >
> @@ -329,7 +330,7 @@ static void __gen6_gt_wait_for_fifo(struct 
> drm_i915_private *dev_priv)
>   }
>   }
>  
> - dev_priv->uncore.fifo_count = n - 1;
> + uncore->fifo_count = n - 1;
>  }
>  
>  static enum hrtimer_restart
> @@ -793,7 +794,7 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
>  #define GEN11_NEEDS_FORCE_WAKE(reg) \
>   ((reg) < 0x4 || ((reg) >= 0x1c && (reg) < 0x1dc000))
>  
> -#define __gen6_reg_read_fw_domains(offset) \
> +#define __gen6_reg_read_fw_domains(uncore, offset) \
>  ({ \
>   enum forcewake_domains __fwd; \
>   if (NEEDS_FORCE_WAKE(offset)) \
> @@ -879,19 +880,19 @@ static const struct intel_forcewake_range 
> __vlv_fw_ranges[] = {
>   GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_MEDIA),
>  };
>  
> -#define __fwtable_reg_read_fw_domains(offset) \
> +#define __fwtable_reg_read_fw_domains(uncore, offset) \
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
>   __fwd; \
>  })
>  
> -#define __gen11_fwtable_reg_read_fw_domains(offset) \
> +#define __gen11_fwtable_reg_read_fw_domains(uncore, offset) \
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (GEN11_NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
>   __fwd; \
>  })
>  
> @@ -943,7 +944,7 @@ static bool is_gen##x##_shadowed(u32 offset) \
>  __is_genX_shadowed(8)
>  __is_genX_shadowed(11)
>  
> -#define __gen8_reg_write_fw_domains(offset) \
> +#define __gen8_reg_write_fw_domains(uncore, offset) \
>  ({ \
>   enum forcewake_domains __fwd; \
>   if (NEEDS_FORCE_WAKE(offset) && !is_gen8_shadowed(offset)) \
> @@ -973,19 +974,19 @@ static const struct intel_forcewake_range 
> __chv_fw_ranges[] = {
>   GEN_FW_RANGE(0x3, 0x37fff, FORCEWAKE_MEDIA),
>  };
>  
> -#define __fwtable_reg_write_fw_domains(offset) \
> +#define __fwtable_reg_write_fw_domains(uncore, offset) \
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (NEEDS_FORCE_WAKE((offset)) && !is_gen8_shadowed(offset)) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
>   __fwd; \
>  })
>  
> -#define __gen11_fwtable_reg_write_fw_domains(offset) \
> +#define __gen11_fwtable_reg_write_fw_domains(uncore, offset) \
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (GEN11_NEEDS_FORCE_WAKE((offset)) && !is_gen11_shadowed(offset)) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
>   __fwd; \
>  })
>  
> @@ -1135,16 +1136,17 @@ __gen2_read(64)
>  #undef GEN2_READ_HEADER
>  
>  #define GEN6_READ_HEADER(x) \
> + struct intel_uncore *uncore = &dev_priv->uncore; \
>   u32 offset = i915_mmio_reg_offset(reg); \
>   unsigned long irqflags; \
>   u##x val = 0; \
>   assert_rpm_wakelock_held(dev_priv); \
> - spin_lock_irqsave(&dev_priv->uncore.lock, irqflags

Re: [Intel-gfx] [RFC 05/10] drm/i915: make find_fw_domain work on intel_uncore

[Paulo Zanoni]

Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Remove unneeded usage of dev_priv from 1 extra function.
> 

Reviewed-by: Paulo Zanoni 

> Cc: Paulo Zanoni 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index dd81c2655e2d..afbbefc32227 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -833,13 +833,13 @@ static int fw_range_cmp(u32 offset, const struct 
> intel_forcewake_range *entry)
>  })
>  
>  static enum forcewake_domains
> -find_fw_domain(struct drm_i915_private *dev_priv, u32 offset)
> +find_fw_domain(struct intel_uncore *uncore, u32 offset)
>  {
>   const struct intel_forcewake_range *entry;
>  
>   entry = BSEARCH(offset,
> - dev_priv->uncore.fw_domains_table,
> - dev_priv->uncore.fw_domains_table_entries,
> + uncore->fw_domains_table,
> + uncore->fw_domains_table_entries,
>   fw_range_cmp);
>  
>   if (!entry)
> @@ -851,11 +851,11 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32 
> offset)
>* translate it here to the list of available domains.
>*/
>   if (entry->domains == FORCEWAKE_ALL)
> - return dev_priv->uncore.fw_domains;
> + return uncore->fw_domains;
>  
> - WARN(entry->domains & ~dev_priv->uncore.fw_domains,
> + WARN(entry->domains & ~uncore->fw_domains,
>"Uninitialized forcewake domain(s) 0x%x accessed at 0x%x\n",
> -  entry->domains & ~dev_priv->uncore.fw_domains, offset);
> +  entry->domains & ~uncore->fw_domains, offset);
>  
>   return entry->domains;
>  }
> @@ -883,7 +883,7 @@ static const struct intel_forcewake_range 
> __vlv_fw_ranges[] = {
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
>   __fwd; \
>  })
>  
> @@ -891,7 +891,7 @@ static const struct intel_forcewake_range 
> __vlv_fw_ranges[] = {
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (GEN11_NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
>   __fwd; \
>  })
>  
> @@ -977,7 +977,7 @@ static const struct intel_forcewake_range 
> __chv_fw_ranges[] = {
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (NEEDS_FORCE_WAKE((offset)) && !is_gen8_shadowed(offset)) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
>   __fwd; \
>  })
>  
> @@ -985,7 +985,7 @@ static const struct intel_forcewake_range 
> __chv_fw_ranges[] = {
>  ({ \
>   enum forcewake_domains __fwd = 0; \
>   if (GEN11_NEEDS_FORCE_WAKE((offset)) && !is_gen11_shadowed(offset)) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
>   __fwd; \
>  })
>  

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 04/10] drm/i915: make more uncore function work on intel_uncore

[Paulo Zanoni]

Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Move the init, fini, prune, suspend, resume function to work on
> intel_uncore instead of dev_priv
> 

A common theme in this series is the last sentence of a commit message
missing the final period ("."). Please fix all of them :).

I think the s/dev_priv/i915/ here is a little unnecessary since it
inflates the diff even more (when will we settle with a single name?),
but okay let's go with it.

Patch still worth on its own IMHO due to all the dev_priv->uncore to
just uncore reduction.

Reviewed-by: Paulo Zanoni 

> Cc: Paulo Zanoni 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   |  20 +-
>  drivers/gpu/drm/i915/intel_uncore.c   | 290 +-
>  drivers/gpu/drm/i915/intel_uncore.h   |  12 +-
>  .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +-
>  drivers/gpu/drm/i915/selftests/mock_uncore.c  |   6 +-
>  drivers/gpu/drm/i915/selftests/mock_uncore.h  |   2 +-
>  6 files changed, 168 insertions(+), 164 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4ace6fadfbc2..a2e039f523c0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -993,11 +993,11 @@ static int i915_driver_init_mmio(struct 
> drm_i915_private *dev_priv)
>   if (ret < 0)
>   goto err_bridge;
>  
> - intel_uncore_init(dev_priv);
> + intel_uncore_init(&dev_priv->uncore);
>  
>   intel_device_info_init_mmio(dev_priv);
>  
> - intel_uncore_prune(dev_priv);
> + intel_uncore_prune(&dev_priv->uncore);
>  
>   intel_uc_init_mmio(dev_priv);
>  
> @@ -1010,7 +1010,7 @@ static int i915_driver_init_mmio(struct 
> drm_i915_private *dev_priv)
>   return 0;
>  
>  err_uncore:
> - intel_uncore_fini(dev_priv);
> + intel_uncore_fini(&dev_priv->uncore);
>   i915_mmio_cleanup(dev_priv);
>  err_bridge:
>   pci_dev_put(dev_priv->bridge_dev);
> @@ -1024,7 +1024,7 @@ static int i915_driver_init_mmio(struct 
> drm_i915_private *dev_priv)
>   */
>  static void i915_driver_cleanup_mmio(struct drm_i915_private *dev_priv)
>  {
> - intel_uncore_fini(dev_priv);
> + intel_uncore_fini(&dev_priv->uncore);
>   i915_mmio_cleanup(dev_priv);
>   pci_dev_put(dev_priv->bridge_dev);
>  }
> @@ -2086,7 +2086,7 @@ static int i915_drm_suspend_late(struct drm_device 
> *dev, bool hibernation)
>  
>   i915_gem_suspend_late(dev_priv);
>  
> - intel_uncore_suspend(dev_priv);
> + intel_uncore_suspend(&dev_priv->uncore);
>  
>   intel_power_domains_suspend(dev_priv,
>   get_suspend_mode(dev_priv, hibernation));
> @@ -2282,7 +2282,9 @@ static int i915_drm_resume_early(struct drm_device *dev)
>   DRM_ERROR("Resume prepare failed: %d, continuing anyway\n",
> ret);
>  
> - intel_uncore_resume_early(dev_priv);
> + intel_uncore_resume_early(&dev_priv->uncore);
> +
> + i915_check_and_clear_faults(dev_priv);
>  
>   if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv)) {
>   gen9_sanitize_dc_state(dev_priv);
> @@ -2852,7 +2854,7 @@ static int intel_runtime_suspend(struct device *kdev)
>  
>   intel_runtime_pm_disable_interrupts(dev_priv);
>  
> - intel_uncore_suspend(dev_priv);
> + intel_uncore_suspend(&dev_priv->uncore);
>  
>   ret = 0;
>   if (INTEL_GEN(dev_priv) >= 11) {
> @@ -2869,7 +2871,7 @@ static int intel_runtime_suspend(struct device *kdev)
>  
>   if (ret) {
>   DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
> - intel_uncore_runtime_resume(dev_priv);
> + intel_uncore_runtime_resume(&dev_priv->uncore);
>  
>   intel_runtime_pm_enable_interrupts(dev_priv);
>  
> @@ -2966,7 +2968,7 @@ static int intel_runtime_resume(struct device *kdev)
>   ret = vlv_resume_prepare(dev_priv, true);
>   }
>  
> - intel_uncore_runtime_resume(dev_priv);
> + intel_uncore_runtime_resume(&dev_priv->uncore);
>  
>   intel_runtime_pm_enable_interrupts(dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 75279c627388..dd81c2655e2d 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -523,62 +523,58 @@ check_for_unclaimed_mmio(struct drm_i915_private 
> *dev_priv)
>   return ret;
>  }
>  
> -static void __intel_uncore_earl

Re: [Intel-gfx] [RFC 03/10] drm/i915: use intel_uncore for all forcewake get/put

[Paulo Zanoni]

Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Now that the internal code all works on intel_uncore, flip the
> external-facing interface.

Long but trivial patch. It breaks compilation of gvt but that's also
trivial to fix.

Unlike patches 1 and 2, this one doesn't add much value on its own IMHO
(i.e., without the rest of the series), but it still helps intel_uncore
move away from the God Object pattern of dev_priv. I'll add my r-b to
the version with the gvt fix when it's sent.


> 
> Cc: Paulo Zanoni 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/gvt/mmio_context.c   |  8 +--
>  drivers/gpu/drm/i915/i915_debugfs.c   | 12 ++---
>  drivers/gpu/drm/i915/i915_gem.c   | 20 +++
>  drivers/gpu/drm/i915/i915_perf.c  |  6 +--
>  drivers/gpu/drm/i915/i915_reset.c | 12 ++---
>  drivers/gpu/drm/i915/intel_display.c  |  4 +-
>  drivers/gpu/drm/i915/intel_engine_cs.c|  4 +-
>  drivers/gpu/drm/i915/intel_guc.c  |  8 +--
>  drivers/gpu/drm/i915/intel_guc_fw.c   |  4 +-
>  drivers/gpu/drm/i915/intel_huc_fw.c   |  4 +-
>  drivers/gpu/drm/i915/intel_pm.c   | 52 +--
>  drivers/gpu/drm/i915/intel_ringbuffer.c   |  8 +--
>  drivers/gpu/drm/i915/intel_uncore.c   | 50 --
>  drivers/gpu/drm/i915/intel_uncore.h   | 12 ++---
>  drivers/gpu/drm/i915/intel_workarounds.c  |  4 +-
>  drivers/gpu/drm/i915/selftests/intel_uncore.c |  4 +-
>  16 files changed, 102 insertions(+), 110 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
> b/drivers/gpu/drm/i915/gvt/mmio_context.c
> index f64c76dd11d4..a00a807a1d55 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@ -356,7 +356,7 @@ static void handle_tlb_pending_event(struct intel_vgpu 
> *vgpu, int ring_id)
>   if (ring_id == RCS0 && INTEL_GEN(dev_priv) >= 9)
>   fw |= FORCEWAKE_RENDER;
>  
> - intel_uncore_forcewake_get(dev_priv, fw);
> + intel_uncore_forcewake_get(&dev_priv->uncore, fw);
>  
>   I915_WRITE_FW(reg, 0x1);
>  
> @@ -365,7 +365,7 @@ static void handle_tlb_pending_event(struct intel_vgpu 
> *vgpu, int ring_id)
>   else
>   vgpu_vreg_t(vgpu, reg) = 0;
>  
> - intel_uncore_forcewake_put(dev_priv, fw);
> + intel_uncore_forcewake_put(&dev_priv->uncore, fw);
>  
>   gvt_dbg_core("invalidate TLB for ring %d\n", ring_id);
>  }
> @@ -552,9 +552,9 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
>* performace for batch mmio read/write, so we need
>* handle forcewake mannually.
>*/
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
>   switch_mmio(pre, next, ring_id);
> - intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(&dev_priv->uncore, FORCEWAKE_ALL);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3bcf0e07b614..0c037bbcf4c8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1094,7 +1094,7 @@ static int i915_frequency_info(struct seq_file *m, void 
> *unused)
>   }
>  
>   /* RPSTAT1 is in the GT power well */
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
>  
>   reqf = I915_READ(GEN6_RPNSWREQ);
>   if (INTEL_GEN(dev_priv) >= 9)
> @@ -1122,7 +1122,7 @@ static int i915_frequency_info(struct seq_file *m, void 
> *unused)
>   cagf = intel_gpu_freq(dev_priv,
> intel_get_cagf(dev_priv, rpstat));
>  
> - intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(&dev_priv->uncore, FORCEWAKE_ALL);
>  
>   if (INTEL_GEN(dev_priv) >= 11) {
>   pm_ier = I915_READ(GEN11_GPM_WGBOXPERF_INTR_ENABLE);
> @@ -2060,12 +2060,12 @@ static int i915_rps_boost_info(struct seq_file *m, 
> void *data)
>   u32 rpup, rpupei;
>   u32 rpdown, rpdownei;
>  
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
>   rpup = I915_READ_FW(GEN6_RP_CUR_UP) & GEN6_RP_EI_MASK;
>   rpupei = I915_READ_FW(GEN6_RP_CUR_UP_EI) &

Re: [Intel-gfx] [RFC 02/10] drm/i915: use intel_uncore in fw get/put internal paths

[Paulo Zanoni]

Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Get/put functions used outside of uncore.c are updated in the next
> patch for a nicer split
> 
> Cc: Paulo Zanoni 
> Signed-off-by: Daniele Ceraolo Spurio 

I really like this one, replacing a gazillion i915->uncore.x with only
uncore->x and just very few instances where you need to go from uncore
back to i915. IMHO this patch is worth it on its own, not considering
the rest of the series.

A single comment below:

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |   5 +-
>  drivers/gpu/drm/i915/i915_drv.c   |   2 +-
>  drivers/gpu/drm/i915/i915_drv.h   |   5 +
>  drivers/gpu/drm/i915/intel_uncore.c   | 203 +-
>  drivers/gpu/drm/i915/intel_uncore.h   |  17 +-
>  drivers/gpu/drm/i915/selftests/intel_uncore.c |   2 +-
>  6 files changed, 125 insertions(+), 109 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 6a90558de213..3bcf0e07b614 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1414,13 +1414,14 @@ static int ironlake_drpc_info(struct seq_file *m)
>  static int i915_forcewake_domains(struct seq_file *m, void *data)
>  {
>   struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct intel_uncore *uncore = &i915->uncore;
>   struct intel_uncore_forcewake_domain *fw_domain;
>   unsigned int tmp;
>  
>   seq_printf(m, "user.bypass_count = %u\n",
> -i915->uncore.user_forcewake.count);
> +uncore->user_forcewake.count);
>  
> - for_each_fw_domain(fw_domain, i915, tmp)
> + for_each_fw_domain(fw_domain, uncore, tmp)
>   seq_printf(m, "%s.wake_count = %u\n",
>  intel_uncore_forcewake_domain_to_str(fw_domain->id),
>  READ_ONCE(fw_domain->wake_count));
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 0d743907e7bc..4ace6fadfbc2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2914,7 +2914,7 @@ static int intel_runtime_suspend(struct device *kdev)
>   intel_opregion_notify_adapter(dev_priv, PCI_D1);
>   }
>  
> - assert_forcewakes_inactive(dev_priv);
> + assert_forcewakes_inactive(&dev_priv->uncore);
>  
>   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
>   intel_hpd_poll_init(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dccb6006aabf..8a4b5bbac02e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2102,6 +2102,11 @@ static inline struct drm_i915_private 
> *huc_to_i915(struct intel_huc *huc)
>   return container_of(huc, struct drm_i915_private, huc);
>  }
>  
> +static inline struct drm_i915_private *uncore_to_i915(struct intel_uncore 
> *uncore)
> +{
> + return container_of(uncore, struct drm_i915_private, uncore);
> +}
> +
>  /* Simple iterator over all initialised engines */
>  #define for_each_engine(engine__, dev_priv__, id__) \
>   for ((id__) = 0; \
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index cb78dcddc9cb..a2d9490739a0 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -205,60 +205,60 @@ fw_domain_put(const struct 
> intel_uncore_forcewake_domain *d)
>  }
>  
>  static void
> -fw_domains_get(struct drm_i915_private *i915, enum forcewake_domains 
> fw_domains)
> +fw_domains_get(struct intel_uncore *uncore, enum forcewake_domains 
> fw_domains)
>  {
>   struct intel_uncore_forcewake_domain *d;
>   unsigned int tmp;
>  
> - GEM_BUG_ON(fw_domains & ~i915->uncore.fw_domains);
> + GEM_BUG_ON(fw_domains & ~uncore->fw_domains);
>  
> - for_each_fw_domain_masked(d, fw_domains, i915, tmp) {
> + for_each_fw_domain_masked(d, fw_domains, uncore, tmp) {
>   fw_domain_wait_ack_clear(d);
>   fw_domain_get(d);
>   }
>  
> - for_each_fw_domain_masked(d, fw_domains, i915, tmp)
> + for_each_fw_domain_masked(d, fw_domains, uncore, tmp)
>   fw_domain_wait_ack_set(d);
>  
> - i915->uncore.fw_domains_active |= fw_domains;
> + uncore->fw_domains_active |= fw_domains;
>  }
>  
>  static void
> -fw_domains_get_with_fallback(struct drm_i915_private *i915,
> +fw_domains_get_with_fallback(struct intel_uncor

Re: [Intel-gfx] [RFC 01/10] drm/i915: do not pass dev_priv to low-level forcewake functions

[Paulo Zanoni]

Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> The only usage we have for it is for the regs pointer. Save a pointer to
> the set and ack registers instead of the register offsets to remove this
> requirement

Reviewed-by: Paulo Zanoni 

> 
> Cc: Paulo Zanoni 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 100 +---
>  drivers/gpu/drm/i915/intel_uncore.h |   9 ++-
>  2 files changed, 52 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 75646a1e0051..cb78dcddc9cb 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -58,16 +58,18 @@ intel_uncore_forcewake_domain_to_str(const enum 
> forcewake_domain_id id)
>   return "unknown";
>  }
>  
> +#define fw_ack(d) readl((d)->reg_ack)
> +#define fw_set(d, val) writel((val), (d)->reg_set)
> +
>  static inline void
> -fw_domain_reset(struct drm_i915_private *i915,
> - const struct intel_uncore_forcewake_domain *d)
> +fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
>  {
>   /*
>* We don't really know if the powerwell for the forcewake domain we are
>* trying to reset here does exist at this point (engines could be fused
>* off in ICL+), so no waiting for acks
>*/
> - __raw_i915_write32(i915, d->reg_set, i915->uncore.fw_reset);
> + fw_set(d, forcewake_domain_to_uncore(d)->fw_reset);
>  }
>  
>  static inline void
> @@ -81,36 +83,32 @@ fw_domain_arm_timer(struct intel_uncore_forcewake_domain 
> *d)
>  }
>  
>  static inline int
> -__wait_for_ack(const struct drm_i915_private *i915,
> -const struct intel_uncore_forcewake_domain *d,
> +__wait_for_ack(const struct intel_uncore_forcewake_domain *d,
>  const u32 ack,
>  const u32 value)
>  {
> - return wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) & ack) == 
> value,
> + return wait_for_atomic((fw_ack(d) & ack) == value,
>  FORCEWAKE_ACK_TIMEOUT_MS);
>  }
>  
>  static inline int
> -wait_ack_clear(const struct drm_i915_private *i915,
> -const struct intel_uncore_forcewake_domain *d,
> +wait_ack_clear(const struct intel_uncore_forcewake_domain *d,
>  const u32 ack)
>  {
> - return __wait_for_ack(i915, d, ack, 0);
> + return __wait_for_ack(d, ack, 0);
>  }
>  
>  static inline int
> -wait_ack_set(const struct drm_i915_private *i915,
> -  const struct intel_uncore_forcewake_domain *d,
> +wait_ack_set(const struct intel_uncore_forcewake_domain *d,
>const u32 ack)
>  {
> - return __wait_for_ack(i915, d, ack, ack);
> + return __wait_for_ack(d, ack, ack);
>  }
>  
>  static inline void
> -fw_domain_wait_ack_clear(const struct drm_i915_private *i915,
> -  const struct intel_uncore_forcewake_domain *d)
> +fw_domain_wait_ack_clear(const struct intel_uncore_forcewake_domain *d)
>  {
> - if (wait_ack_clear(i915, d, FORCEWAKE_KERNEL))
> + if (wait_ack_clear(d, FORCEWAKE_KERNEL))
>   DRM_ERROR("%s: timed out waiting for forcewake ack to clear.\n",
> intel_uncore_forcewake_domain_to_str(d->id));
>  }
> @@ -121,8 +119,7 @@ enum ack_type {
>  };
>  
>  static int
> -fw_domain_wait_ack_with_fallback(const struct drm_i915_private *i915,
> -  const struct intel_uncore_forcewake_domain *d,
> +fw_domain_wait_ack_with_fallback(const struct intel_uncore_forcewake_domain 
> *d,
>const enum ack_type type)
>  {
>   const u32 ack_bit = FORCEWAKE_KERNEL;
> @@ -146,72 +143,65 @@ fw_domain_wait_ack_with_fallback(const struct 
> drm_i915_private *i915,
>  
>   pass = 1;
>   do {
> - wait_ack_clear(i915, d, FORCEWAKE_KERNEL_FALLBACK);
> + wait_ack_clear(d, FORCEWAKE_KERNEL_FALLBACK);
>  
> - __raw_i915_write32(i915, d->reg_set,
> -
> _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL_FALLBACK));
> + fw_set(d, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL_FALLBACK));
>   /* Give gt some time to relax before the polling frenzy */
>   udelay(10 * pass);
> - wait_ack_set(i915, d, FORCEWAKE_KERNEL_FALLBACK);
> + wait_ack_set(d, FORCEWAKE_KERNEL_FALLBACK);
>  
> - ack_detected = (__raw_i915_read32(i915, d->reg_ack) & ack_bit) 
> == value;

Re: [Intel-gfx] [PATCH] drm/i915: Drop platform_mask

[Paulo Zanoni]

Em sex, 2019-03-15 às 06:56 +, Tvrtko Ursulin escreveu:
> On 15/03/2019 00:52, Chris Wilson wrote:
> > Quoting José Roberto de Souza (2019-03-15 00:42:35)
> > > We don't have any platform that is composed by 2 or more platforms so
> > > we don't need a mask, lets drop it and remove the actual limit of 32
> > > platforms.
> 
> Platform mask was a nifty trick to compile tests like IS_SKYLAKE || 
> IS_BROADWELL etc into a single conditional.
> 

So perhaps the code would benefit from a small comment that says
exactly that, so the next person looking at it won't propose its
removal again. José, would you volunteer for that patch?
 

> > gcc doesn't entirely agree, this is a net loss here (i.e. code size
> > increases).
> 
> Perhaps the size re-gain of dropping the platform mask could be checked 
> against the size gain of making the mask 64 bit.
> 
> However, one other benefit of the mask will also help with dead code 
> elimination once per SKU build work is resurfaced. For the single 
> selected platforms it doesn't matter, but for a subset it still does I 
> think.
> 
> So I think we got two questions here - checking between size gains of 
> the two options, and how interesting would multi-platform builds be.
> 
> One use case for the latter I had in mind was legacy vs execlists driver 
> build but that wasn't based on any formal feature requests as far as I 
> am aware.
> 
> Regards,
> 
> Tvrtko
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Pick the first unused PLL once again

[Paulo Zanoni]

Em qua, 2019-01-30 às 20:13 +0200, Ville Syrjala escreveu:
> From: Ville Syrjälä 
> 
> commit 5b0bd14dcc6b ("drm/i915/icl: keep track of unused pll while
> looping") inadvertently (I presume) changed the code to pick the
> last unused dpll rather than the first unused one like we did before.
> 
> While there should most likely be no harm in changing the order
> let's change back just to avoid a change in the behaviour. At
> least it might reduce the confusion when staring at logs (took
> me a while to figure out why DPLL1 being picked over DPLL0
> when the latter was most definitely available).

Reviewed-by: Paulo Zanoni 


> 
> Cc: Lucas De Marchi 
> Cc: Paulo Zanoni 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 8f70838ac7d8..0a42d11c4c33 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -258,7 +258,8 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
>  
>   /* Only want to check enabled timings first */
>   if (shared_dpll[i].crtc_mask == 0) {
> - unused_pll = pll;
> + if (!unused_pll)
> + unused_pll = pll;
>   continue;
>   }
>  

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915/icl: use tc_port in MG_PLL macros

[Paulo Zanoni]

Em qui, 2019-01-24 às 10:52 -0800, Lucas De Marchi escreveu:
> On Wed, Jan 23, 2019 at 05:15:26PM -0800, Paulo Zanoni wrote:
> > Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
> > > Fix the TODO leftover in the code by changing the argument in MG_PLL
> > > macros. The MG_PLL ids used to access the register values can be
> > > converted from tc_port rather than port.
> > > 
> > 
> > An explanation on why the new model is better would be amazing. It may
> > be obvious to you, but it's not to other people.
> 
> What about:
> 
> All these registers can use the TC port to calculate the right offsets
> because they are only available for TC ports. The range (PORT_C onwards)
> may not be stable and change from platform to platform. So by using the
> TC id directly we avoid having to check for the platform in the "leaf
> functions" and thus passing dev_priv around.

Works for me. Thanks.

> 
> 
> > 
> > > The helper functions were also renamed to use "tc" as prefix to make
> > > them more generic.
> > > 
> > > Signed-off-by: Lucas De Marchi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h   | 52 +-
> > >  drivers/gpu/drm/i915/intel_ddi.c  |  7 ++-
> > >  drivers/gpu/drm/i915/intel_display.c  |  3 +-
> > >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 79 +--
> > >  drivers/gpu/drm/i915/intel_dpll_mgr.h |  2 +-
> > >  5 files changed, 72 insertions(+), 71 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 9a1340cfda6c..de209e0fdc01 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -9545,7 +9545,7 @@ enum skl_power_gate {
> > >  #define _MG_PLL3_ENABLE  0x46038
> > >  #define _MG_PLL4_ENABLE  0x4603C
> > >  /* Bits are the same as DPLL0_ENABLE */
> > > -#define MG_PLL_ENABLE(port)  _MMIO_PORT((port) - PORT_C, 
> > > _MG_PLL1_ENABLE, \
> > > +#define MG_PLL_ENABLE(tc_port)   _MMIO_PORT((tc_port), _MG_PLL1_ENABLE, \
> > >  _MG_PLL2_ENABLE)
> > > 
> > >  #define _MG_REFCLKIN_CTL_PORT1   0x16892C
> > > @@ -9554,9 +9554,9 @@ enum skl_power_gate {
> > >  #define _MG_REFCLKIN_CTL_PORT4   0x16B92C
> > >  #define   MG_REFCLKIN_CTL_OD_2_MUX(x)((x) << 8)
> > >  #define   MG_REFCLKIN_CTL_OD_2_MUX_MASK  (0x7 << 8)
> > > -#define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
> > > -  _MG_REFCLKIN_CTL_PORT1, \
> > > -  _MG_REFCLKIN_CTL_PORT2)
> > > +#define MG_REFCLKIN_CTL(tc_port) _MMIO_PORT((tc_port), \
> > > + _MG_REFCLKIN_CTL_PORT1, \
> > > + _MG_REFCLKIN_CTL_PORT2)
> > > 
> > >  #define _MG_CLKTOP2_CORECLKCTL1_PORT10x1688D8
> > >  #define _MG_CLKTOP2_CORECLKCTL1_PORT20x1698D8
> > > @@ -9566,9 +9566,9 @@ enum skl_power_gate {
> > >  #define   MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO_MASK (0xff << 16)
> > >  #define   MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x)   ((x) << 8)
> > >  #define   MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK (0xff << 8)
> > > -#define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C, \
> > > - _MG_CLKTOP2_CORECLKCTL1_PORT1, \
> > > - _MG_CLKTOP2_CORECLKCTL1_PORT2)
> > > +#define MG_CLKTOP2_CORECLKCTL1(tc_port) _MMIO_PORT((tc_port), \
> > > +
> > > _MG_CLKTOP2_CORECLKCTL1_PORT1, \
> > > +
> > > _MG_CLKTOP2_CORECLKCTL1_PORT2)
> > > 
> > >  #define _MG_CLKTOP2_HSCLKCTL_PORT1   0x1688D4
> > >  #define _MG_CLKTOP2_HSCLKCTL_PORT2   0x1698D4
> > > @@ -9586,9 +9586,9 @@ enum skl_power_gate {
> > >  #define   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) << 8)
> > >  #define   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_SHIFT  8
> > >  #define   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK   (0xf << 8)
> > > -#define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
> > > -

Re: [Intel-gfx] [PATCH 4/5] drm/i915/icl: keep track of unused pll while looping

[Paulo Zanoni]

Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
> Instead of looping again on the range of plls, just keep track of one
> unused one and use it later.
> 

Reviewed-by: Paulo Zanoni 

> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 211b3ffa5bed..8f70838ac7d8 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -247,7 +247,7 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
>  enum intel_dpll_id range_max)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct intel_shared_dpll *pll;
> + struct intel_shared_dpll *pll, *unused_pll = NULL;
>   struct intel_shared_dpll_state *shared_dpll;
>   enum intel_dpll_id i;
>  
> @@ -257,8 +257,10 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
>   pll = &dev_priv->shared_dplls[i];
>  
>   /* Only want to check enabled timings first */
> - if (shared_dpll[i].crtc_mask == 0)
> + if (shared_dpll[i].crtc_mask == 0) {
> + unused_pll = pll;
>   continue;
> + }
>  
>   if (memcmp(&crtc_state->dpll_hw_state,
>  &shared_dpll[i].hw_state,
> @@ -273,14 +275,11 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
>   }
>  
>   /* Ok no matching timings, maybe there's a free one? */
> - for (i = range_min; i <= range_max; i++) {
> - pll = &dev_priv->shared_dplls[i];
> - if (shared_dpll[i].crtc_mask == 0) {
> - DRM_DEBUG_KMS("[CRTC:%d:%s] allocated %s\n",
> -   crtc->base.base.id, crtc->base.name,
> -   pll->info->name);
> - return pll;
> - }
> + if (unused_pll) {
> + DRM_DEBUG_KMS("[CRTC:%d:%s] allocated %s\n",
> +   crtc->base.base.id, crtc->base.name,
> +   unused_pll->info->name);
> + return unused_pll;
>   }
>  
>   return NULL;

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915/icl: remove dpll from clk_sel

[Paulo Zanoni]

Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
> We should not pass DPLL_ID_ICL_DPLL0 or DPLL_ID_ICL_DPLL1 to this
> function because the path is only taken for non-combophy ports. Let the
> warning trigger if improper value is given.
> 
> While at it, rename the function to match the register name we are
> trying to program.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 4dc03e8c6c10..94d0fdc14b42 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -995,7 +995,7 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const struct 
> intel_shared_dpll *pll)
>   }
>  }
>  
> -static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
> +static uint32_t icl_pll_to_ddi_clk_sel(struct intel_encoder *encoder,
>  const struct intel_crtc_state 
> *crtc_state)
>  {
>   const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
> @@ -1004,10 +1004,11 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct 
> intel_encoder *encoder,
>  
>   switch (id) {
>   default:
> + /*
> +  * DPLL_ID_ICL_DPLL0 and DPLL_ID_ICL_DPLL1 should not be use

s/use/used/

With that:
Reviewed-by: Paulo Zanoni 

> +  * here, so do warn if this get passed in
> +  */
>   MISSING_CASE(id);
> - /* fall through */
> - case DPLL_ID_ICL_DPLL0:
> - case DPLL_ID_ICL_DPLL1:
>   return DDI_CLK_SEL_NONE;
>   case DPLL_ID_ICL_TBTPLL:
>   switch (clock) {
> @@ -2869,7 +2870,7 @@ static void intel_ddi_clk_select(struct intel_encoder 
> *encoder,
>   if (IS_ICELAKE(dev_priv)) {
>   if (!intel_port_is_combophy(dev_priv, port))
>   I915_WRITE(DDI_CLK_SEL(port),
> -icl_pll_to_ddi_pll_sel(encoder, crtc_state));
> +icl_pll_to_ddi_clk_sel(encoder, crtc_state));
>   } else if (IS_CANNONLAKE(dev_priv)) {
>   /* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
>   val = I915_READ(DPCLKA_CFGCR0);

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915/icl: use tc_port in MG_PLL macros

[Paulo Zanoni]

enum port port)
>  {
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
>   u32 mg_pll_div0, mg_clktop_hsclkctl;
>   u32 m1, m2_int, m2_frac, div1, div2, refclk;
>   u64 tmp;
>  
>   refclk = dev_priv->cdclk.hw.ref;
>  
> - mg_pll_div0 = I915_READ(MG_PLL_DIV0(port));
> - mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(port));
> + mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
> + mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
>  
> - m1 = I915_READ(MG_PLL_DIV1(port)) & MG_PLL_DIV1_FBPREDIV_MASK;
> + m1 = I915_READ(MG_PLL_DIV1(tc_port)) & MG_PLL_DIV1_FBPREDIV_MASK;
>   m2_int = mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
>   m2_frac = (mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
> (mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 62d61fcad89c..a5de70e6bf59 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9415,7 +9415,8 @@ static void icelake_get_ddi_pll(struct drm_i915_private 
> *dev_priv,
>   if (WARN_ON(!intel_dpll_is_combophy(id)))
>   return;
>   } else if (intel_port_is_tc(dev_priv, port)) {
> - id = icl_port_to_mg_pll_id(port);
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + id = icl_tc_port_to_pll_id(tc_port);

Checkpatch's complaint makes sense here. You could also opt to simply
to:

id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv, port));

>   } else {
>   WARN(1, "Invalid port %x\n", port);
>   return;
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 606f54dde086..211b3ffa5bed 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2639,14 +2639,14 @@ int icl_calc_dp_combo_pll_link(struct 
> drm_i915_private *dev_priv,
>   return link_clock;
>  }
>  
> -static enum port icl_mg_pll_id_to_port(enum intel_dpll_id id)
> +static enum tc_port icl_pll_id_to_tc_port(enum intel_dpll_id id)
>  {
> - return id - DPLL_ID_ICL_MGPLL1 + PORT_C;
> + return id - DPLL_ID_ICL_MGPLL1;
>  }
>  
> -enum intel_dpll_id icl_port_to_mg_pll_id(enum port port)
> +enum intel_dpll_id icl_tc_port_to_pll_id(enum tc_port tc_port)
>  {
> - return port - PORT_C + DPLL_ID_ICL_MGPLL1;
> + return tc_port + DPLL_ID_ICL_MGPLL1;
>  }

The "_mg_" in the name was supposed to help callers easily realize that
these functions don't make sense without mg plls. I kinda liked them,
especially in the first case where you can pass any id, which would
result in wrong code.


So, one of my fears is that there may be other patches in-flight which
touch these registers and will silently make our code use port again.
The cherry on top of this patch would be to put those enums inside
single-element structs in a way that would make gcc complain when you
accessed one instead of the other (including inside macros). Feel free
to implement this if you like the idea.

With the checkpatch error addressed and the improved commit message:
Reviewed-by: Paulo Zanoni 

>  
>  bool intel_dpll_is_combophy(enum intel_dpll_id id)
> @@ -2925,7 +2925,10 @@ icl_get_dpll(struct intel_crtc *crtc, struct 
> intel_crtc_state *crtc_state,
>   ret = icl_calc_dpll_state(crtc_state, encoder, clock,
> &pll_state);
>   } else {
> - min = icl_port_to_mg_pll_id(port);
> + enum tc_port tc_port;
> +
> + tc_port = intel_port_to_tc(dev_priv, port);
> + min = icl_tc_port_to_pll_id(tc_port);
>   max = min;
>   ret = icl_calc_mg_pll_state(crtc_state, encoder, clock,
>   &pll_state);
> @@ -2959,12 +2962,8 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum 
> intel_dpll_id id)
>   return CNL_DPLL_ENABLE(id);
>   else if (id == DPLL_ID_ICL_TBTPLL)
>   return TBT_PLL_ENABLE;
> - else
> - /*
> -  * TODO: Make MG_PLL macros use
> -  * tc port id instead of port id
> -  */
> - return MG_PLL_ENABLE(icl_mg_pll_id_to_port(id));
> +
> + return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
>  }
>  
>  static bool icl_pll_get_hw_state(struct drm_i915_private *dev_priv,
> @@ -2974,7 +2973,6 @@ static bool icl_pll_get_hw_state(struct 
>

[Intel-gfx] [CI] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

[Paulo Zanoni]

BSpec does not show these WAs as applicable to GLK, and for CNL it
only shows them applicable for a super early pre-production stepping
we shouldn't be caring about anymore. Remove these so we can avoid
them on ICL too.

v2: Change how we check for gen9 display platforms (Ville).

Cc: Matt Roper 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 43 ++---
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27498ded4949..18914c4ca070 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4755,28 +4755,31 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
 wp->plane_blocks_per_line);
 
-   /* Display WA #1125: skl,bxt,kbl,glk */
-   if (level == 0 && wp->rc_surface)
-   res_blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
+   if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
+   /* Display WA #1125: skl,bxt,kbl */
+   if (level == 0 && wp->rc_surface)
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+
+   /* Display WA #1126: skl,bxt,kbl */
+   if (level >= 1 && level <= 7) {
+   if (wp->y_tiled) {
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+   res_lines += wp->y_min_scanlines;
+   } else {
+   res_blocks++;
+   }
 
-   /* Display WA #1126: skl,bxt,kbl,glk */
-   if (level >= 1 && level <= 7) {
-   if (wp->y_tiled) {
-   res_blocks += fixed16_to_u32_round_up(
-   wp->y_tile_minimum);
-   res_lines += wp->y_min_scanlines;
-   } else {
-   res_blocks++;
+   /*
+* Make sure result blocks for higher latency levels are
+* atleast as high as level below the current level.
+* Assumption in DDB algorithm optimization for special
+* cases. Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
-
-   /*
-* Make sure result blocks for higher latency levels are atleast
-* as high as level below the current level.
-* Assumption in DDB algorithm optimization for special cases.
-* Also covers Display WA #1125 for RC.
-*/
-   if (result_prev->plane_res_b > res_blocks)
-   res_blocks = result_prev->plane_res_b;
}
 
if (INTEL_GEN(dev_priv) >= 11) {
-- 
2.17.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 3/3] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()

[Paulo Zanoni]

I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.

I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.

v2: Switch numerator to 1 from 1000 and adjust calculations
accordingly (Ville).

Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 37 -
 1 file changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 928671936286..25e3aba9cded 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
}
 
rawclk = CNP_RAWCLK_DIV(divider / 1000);
-   if (fraction)
-   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
-  fraction) - 1);
+   if (fraction) {
+   int numerator = 1;
 
-   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
-   return divider + fraction;
-}
-
-static int icp_rawclk(struct drm_i915_private *dev_priv)
-{
-   u32 rawclk;
-   int divider, numerator, denominator, frequency;
-
-   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
-   frequency = 24000;
-   divider = 24;
-   numerator = 0;
-   denominator = 0;
-   } else {
-   frequency = 19200;
-   divider = 19;
-   numerator = 1;
-   denominator = 4;
+   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator * 1000,
+  fraction) - 1);
+   if (HAS_PCH_ICP(dev_priv))
+   rawclk |= ICP_RAWCLK_NUM(numerator);
}
 
-   rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-CNP_RAWCLK_DEN(denominator);
-
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
-   return frequency;
+   return divider + fraction;
 }
 
 static int pch_rawclk(struct drm_i915_private *dev_priv)
@@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_ICP(dev_priv))
-   dev_priv->rawclk_freq = icp_rawclk(dev_priv);
-   else if (HAS_PCH_CNP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 2/3] drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DEN

[Paulo Zanoni]

Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h| 3 +--
 drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe4b913e46ac..16f0d73bb4fe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7907,8 +7907,7 @@ enum {
 #define  CNP_RAWCLK_DIV_MASK   (0x3ff << 16)
 #define  CNP_RAWCLK_DIV(div)   ((div) << 16)
 #define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
-#define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
-#define  ICP_RAWCLK_DEN(den)   ((den) << 26)
+#define  CNP_RAWCLK_DEN(den)   ((den) << 26)
 #define  ICP_RAWCLK_NUM(num)   ((num) << 11)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 810670976e86..928671936286 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2662,8 +2662,8 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
 
rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
-   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
-   fraction) - 1);
+   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
+  fraction) - 1);
 
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return divider + fraction;
@@ -2687,7 +2687,7 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
}
 
rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-ICP_RAWCLK_DEN(denominator);
+CNP_RAWCLK_DEN(denominator);
 
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return frequency;
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 1/3] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations

[Paulo Zanoni]

BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.

It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.

Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 8d74276029e6..810670976e86 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2660,7 +2660,7 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
fraction = 200;
}
 
-   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+   rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
fraction) - 1);
@@ -2676,12 +2676,12 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
 
if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
frequency = 24000;
-   divider = 23;
+   divider = 24;
numerator = 0;
denominator = 0;
} else {
frequency = 19200;
-   divider = 18;
+   divider = 19;
numerator = 1;
denominator = 4;
}
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3 v2] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()

[Paulo Zanoni]

I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.

I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.

v2: Switch numerator to 1 from 1000 and adjust calculations
accordingly (Ville).

Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 37 -
 1 file changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 928671936286..25e3aba9cded 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
}
 
rawclk = CNP_RAWCLK_DIV(divider / 1000);
-   if (fraction)
-   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
-  fraction) - 1);
+   if (fraction) {
+   int numerator = 1;
 
-   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
-   return divider + fraction;
-}
-
-static int icp_rawclk(struct drm_i915_private *dev_priv)
-{
-   u32 rawclk;
-   int divider, numerator, denominator, frequency;
-
-   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
-   frequency = 24000;
-   divider = 24;
-   numerator = 0;
-   denominator = 0;
-   } else {
-   frequency = 19200;
-   divider = 19;
-   numerator = 1;
-   denominator = 4;
+   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator * 1000,
+  fraction) - 1);
+   if (HAS_PCH_ICP(dev_priv))
+   rawclk |= ICP_RAWCLK_NUM(numerator);
}
 
-   rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-CNP_RAWCLK_DEN(denominator);
-
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
-   return frequency;
+   return divider + fraction;
 }
 
 static int pch_rawclk(struct drm_i915_private *dev_priv)
@@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_ICP(dev_priv))
-   dev_priv->rawclk_freq = icp_rawclk(dev_priv);
-   else if (HAS_PCH_CNP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()

[Paulo Zanoni]

Em Seg, 2018-11-12 às 16:54 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 09, 2018 at 04:23:50PM -0800, Paulo Zanoni wrote:
> > I think I'm probably the one who argued in favor of having separate
> > implementations for both PCHs, but the calculations are actually
> > the
> > same, the clocks are the same and the only difference is that on
> > ICP
> > we write the numerator to the register.
> > 
> > I have previously suggested to kill cnp_rawclk() and keep the
> > icp_rawclk() style, but Ville gave some good arguments that what's
> > in
> > this patch may be the better choice.
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_cdclk.c | 37 
> > -
> >  1 file changed, 8 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 928671936286..60437675354e 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct
> > drm_i915_private *dev_priv)
> > }
> >  
> > rawclk = CNP_RAWCLK_DIV(divider / 1000);
> > -   if (fraction)
> > -   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
> > -  fractio
> > n) - 1);
> > +   if (fraction) {
> > +   int numerator = 1000;
> >  
> > -   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
> > -   return divider + fraction;
> > -}
> > -
> > -static int icp_rawclk(struct drm_i915_private *dev_priv)
> > -{
> > -   u32 rawclk;
> > -   int divider, numerator, denominator, frequency;
> > -
> > -   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
> > -   frequency = 24000;
> > -   divider = 24;
> > -   numerator = 0;
> > -   denominator = 0;
> > -   } else {
> > -   frequency = 19200;
> > -   divider = 19;
> > -   numerator = 1;
> > -   denominator = 4;
> > +   rawclk |=
> > CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator,
> > +  fractio
> > n) - 1);
> > +   if (HAS_PCH_ICP(dev_priv))
> > +   rawclk |= ICP_RAWCLK_NUM(numerator /
> > 1000);
> 
> Maybe
> int numerator = 1;
> ...
> DIV_ROUND_CLOSEST(numerator * 1000, ... ?

Will do. I guess I tried to keep the logic of "local variables should
be in KHz and conversion to MHz goes inside the reg-writing macros",
but I don't feel it is better or worse than the suggestion.


> 
> The fixed numerator is OK since we only have to support 19.2 for
> now. If in the future we get more frequencies we may want to make
> this more flexible. But not much point in worrying about that now.
> 
> Series is
> Reviewed-by: Ville Syrjälä 

Thanks a lot. Sorry for the huge delay in the follow-up.

> 
> > }
> >  
> > -   rawclk = CNP_RAWCLK_DIV(divider) |
> > ICP_RAWCLK_NUM(numerator) |
> > -CNP_RAWCLK_DEN(denominator);
> > -
> > I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
> > -   return frequency;
> > +   return divider + fraction;
> >  }
> >  
> >  static int pch_rawclk(struct drm_i915_private *dev_priv)
> > @@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct
> > drm_i915_private *dev_priv)
> >   */
> >  void intel_update_rawclk(struct drm_i915_private *dev_priv)
> >  {
> > -   if (HAS_PCH_ICP(dev_priv))
> > -   dev_priv->rawclk_freq = icp_rawclk(dev_priv);
> > -   else if (HAS_PCH_CNP(dev_priv))
> > +   if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
> > dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
> > else if (HAS_PCH_SPLIT(dev_priv))
> > dev_priv->rawclk_freq = pch_rawclk(dev_priv);
> > -- 
> > 2.14.4
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations

[Paulo Zanoni]

BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.

It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.

Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 8d74276029e6..810670976e86 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2660,7 +2660,7 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
fraction = 200;
}
 
-   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+   rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
fraction) - 1);
@@ -2676,12 +2676,12 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
 
if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
frequency = 24000;
-   divider = 23;
+   divider = 24;
numerator = 0;
denominator = 0;
} else {
frequency = 19200;
-   divider = 18;
+   divider = 19;
numerator = 1;
denominator = 4;
}
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()

[Paulo Zanoni]

I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.

I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.

Cc: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 37 -
 1 file changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 928671936286..60437675354e 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
}
 
rawclk = CNP_RAWCLK_DIV(divider / 1000);
-   if (fraction)
-   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
-  fraction) - 1);
+   if (fraction) {
+   int numerator = 1000;
 
-   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
-   return divider + fraction;
-}
-
-static int icp_rawclk(struct drm_i915_private *dev_priv)
-{
-   u32 rawclk;
-   int divider, numerator, denominator, frequency;
-
-   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
-   frequency = 24000;
-   divider = 24;
-   numerator = 0;
-   denominator = 0;
-   } else {
-   frequency = 19200;
-   divider = 19;
-   numerator = 1;
-   denominator = 4;
+   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator,
+  fraction) - 1);
+   if (HAS_PCH_ICP(dev_priv))
+   rawclk |= ICP_RAWCLK_NUM(numerator / 1000);
}
 
-   rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-CNP_RAWCLK_DEN(denominator);
-
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
-   return frequency;
+   return divider + fraction;
 }
 
 static int pch_rawclk(struct drm_i915_private *dev_priv)
@@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_ICP(dev_priv))
-   dev_priv->rawclk_freq = icp_rawclk(dev_priv);
-   else if (HAS_PCH_CNP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DEN

[Paulo Zanoni]

Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h| 3 +--
 drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe4b913e46ac..16f0d73bb4fe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7907,8 +7907,7 @@ enum {
 #define  CNP_RAWCLK_DIV_MASK   (0x3ff << 16)
 #define  CNP_RAWCLK_DIV(div)   ((div) << 16)
 #define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
-#define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
-#define  ICP_RAWCLK_DEN(den)   ((den) << 26)
+#define  CNP_RAWCLK_DEN(den)   ((den) << 26)
 #define  ICP_RAWCLK_NUM(num)   ((num) << 11)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 810670976e86..928671936286 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2662,8 +2662,8 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
 
rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
-   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
-   fraction) - 1);
+   rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
+  fraction) - 1);
 
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return divider + fraction;
@@ -2687,7 +2687,7 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
}
 
rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-ICP_RAWCLK_DEN(denominator);
+CNP_RAWCLK_DEN(denominator);
 
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return frequency;
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

[Paulo Zanoni]

BSpec does not show these WAs as applicable to GLK, and for CNL it
only shows them applicable for a super early pre-production stepping
we shouldn't be caring about anymore. Remove these so we can avoid
them on ICL too.

v2: Change how we check for gen9 display platforms (Ville).

Cc: Matt Roper 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 43 ++---
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9da8ff263d36..b5623a70c19c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4754,28 +4754,31 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
 wp->plane_blocks_per_line);
 
-   /* Display WA #1125: skl,bxt,kbl,glk */
-   if (level == 0 && wp->rc_surface)
-   res_blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
+   if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
+   /* Display WA #1125: skl,bxt,kbl */
+   if (level == 0 && wp->rc_surface)
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+
+   /* Display WA #1126: skl,bxt,kbl */
+   if (level >= 1 && level <= 7) {
+   if (wp->y_tiled) {
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+   res_lines += wp->y_min_scanlines;
+   } else {
+   res_blocks++;
+   }
 
-   /* Display WA #1126: skl,bxt,kbl,glk */
-   if (level >= 1 && level <= 7) {
-   if (wp->y_tiled) {
-   res_blocks += fixed16_to_u32_round_up(
-   wp->y_tile_minimum);
-   res_lines += wp->y_min_scanlines;
-   } else {
-   res_blocks++;
+   /*
+* Make sure result blocks for higher latency levels are
+* atleast as high as level below the current level.
+* Assumption in DDB algorithm optimization for special
+* cases. Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
-
-   /*
-* Make sure result blocks for higher latency levels are atleast
-* as high as level below the current level.
-* Assumption in DDB algorithm optimization for special cases.
-* Also covers Display WA #1125 for RC.
-*/
-   if (result_prev->plane_res_b > res_blocks)
-   res_blocks = result_prev->plane_res_b;
}
 
if (INTEL_GEN(dev_priv) >= 11) {
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Simplify has_sagv

[Paulo Zanoni]

Em Seg, 2018-10-22 às 17:06 -0700, Rodrigo Vivi escreveu:
> On Mon, Oct 22, 2018 at 04:48:50PM -0700, Paulo Zanoni wrote:
> > Em Seg, 2018-10-22 às 09:57 -0700, Rodrigo Vivi escreveu:
> > > Let's add a platform has_sagv instead of having a full
> > > function that handle platform by platform.
> > > 
> > > The specially case for SKL for not controlled sagv
> > > is already taken care inside intel_enable_sagv, so there's
> > > no need to duplicate the check here.
> > > 
> > > v2: Go one step further and remove skl special case. (Jani)
> > > 
> > > v3: Separate runtime status handle from has_sagv flag. (Jani)
> > 
> > I know this has probably been discussed in the past and I missed it
> > (since I know this was done a few times for other things), but
> > how/why
> > is this approach better than the current one? Can you please write
> > it
> > in the commit message?
> 
> my bad... after stripping this out of my RFC series this got
> indeed out of context.
> 
> I'm trying to get rid of many platform codename checks spread
> around the code.
> 
> I believe we should do most of the decisions based on display_gen
> or has_feature. And use the platform codename as the last resource
> only when gen or feature cannot describe things better.

In terms of "describing things better", I don't see a lot of difference
between HAS_SOMETHING() and intel_has_something(). The
intel_has_something() version even already gives us a signal that maybe
the decision is made based on runtime information instead of being
simply per-platform, which is this case.

> 
> > Quickly checking the implementation of intel_has_sagv() seems much
> > easier than swimming through the nested macros of i915_pci.c. And
> > the 
> > special-caseness of the NOT_CONTROLLED case being restricted to
> > gen9 in
> > the current (non-patched) code also at first appears to be better
> > than
> > this proposal. But I'm totally willing to read your arguments and
> > reevaluate my decisions based on them, so please present them.
> 
> When you are looking only to a single feature this might be true.
> When you are looking to the platform itself consolidating the
> features
> definitions in a single place is easier to check legacy features and
> add new platforms.

So please make sure this is in the commit message. I may or may not
agree this is the best way to proceed, but at least now I can know why
it is the way it is when I git-blame/git-log.


> 
> Specially I'd like to add a new platform gen line gen++ without
> need to use any codename. Or without mixing things up.
> INTEL_GEN >= 11 || IS_CANNONLAKE :/

You can achieve this by redefining intel_has_sagv() instead of killing
it. Currently, our code assumes new platforms won't support sagv, but
that seems unlikely considering the recent history. Just invert it:

has_sagv() {
if (is_gen9_lp || intel_gen < 9)
return false;

if (!is_skl)
return true;

return (status != controlled)
}


Note: I'm not blocking this patch.

> 
> So adding gen_n+1 should be as trivial
> as gen_n + 1 legacy...
> 
> > 
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Lucas De Marchi 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > >  drivers/gpu/drm/i915/i915_pci.c  |  1 +
> > >  drivers/gpu/drm/i915/intel_device_info.h |  1 +
> > >  drivers/gpu/drm/i915/intel_pm.c  | 29 
> > > 
> > > 
> > >  4 files changed, 13 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 3017ef037fed..9b98ceb2d029 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2650,6 +2650,7 @@ intel_info(const struct drm_i915_private
> > > *dev_priv)
> > >  #define HAS_DDI(dev_priv) ((dev_priv)-
> > > >info.has_ddi)
> > >  #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) ((dev_priv)-
> > > > info.has_fpga_dbg)
> > > 
> > >  #define HAS_PSR(dev_priv) ((dev_priv)-
> > > >info.has_psr)
> > > +#define HAS_SAGV(dev_priv)((dev_priv)-
> > > > info.has_sagv)
> > > 
> > >  
> > >  #define HAS_RC6(dev_priv) ((dev_priv)-
> > > >info.has_rc6)
> > >  #define HAS_RC6p(dev_priv)((dev_priv)-
>

Re: [Intel-gfx] [PATCH 01/11] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

[Paulo Zanoni]

Em Seg, 2018-10-22 às 16:55 -0700, Rodrigo Vivi escreveu:
> On Mon, Oct 22, 2018 at 04:32:00PM -0700, Paulo Zanoni wrote:
> > Em Qui, 2018-10-18 às 16:14 +0300, Ville Syrjälä escreveu:
> > > On Tue, Oct 16, 2018 at 03:01:23PM -0700, Paulo Zanoni wrote:
> > > > BSpec does not show these WAs as applicable to GLK, and for CNL
> > > > it
> > > > only shows them applicable for a super early pre-production
> > > > stepping
> > > > we shouldn't be caring about anymore. Remove these so we can
> > > > avoid
> > > > them on ICL too.
> > > > 
> > > > Cc: Matt Roper 
> > > > Signed-off-by: Paulo Zanoni 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_pm.c | 43 ++---
> > > > 
> > > > 
> > > >  1 file changed, 23 insertions(+), 20 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 67a4d0735291..18157c6ee126 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -4696,28 +4696,31 @@ static int skl_compute_plane_wm(const
> > > > struct drm_i915_private *dev_priv,
> > > > res_lines = div_round_up_fixed16(selected_result,
> > > >  wp-
> > > > > plane_blocks_per_line);
> > > > 
> > > > -   /* Display WA #1125: skl,bxt,kbl,glk */
> > > > -   if (level == 0 && wp->rc_surface)
> > > > -   res_blocks += fixed16_to_u32_round_up(wp-
> > > > > y_tile_minimum);
> > > > 
> > > > +   if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
> > > 
> > > IS_GEN9_BC || IS_BXT
> > > 
> > > would be a little easier to parse, me thinks.
> > 
> > I can do that, but what I really want is "DISPLAY_GEN(dev_priv) ==
> > 9".
> 
> work in progress...
> 
> btw...
> 
> DISPLAY_GEN(dev_priv) == 9 or simply DISPLAY(dev_priv, 9) ?

It should mimic the model we already use: INTEL_GEN(dev_priv) >= 9.

I would expect a macro called DISPLAY() to return *the* Display or to
simply display somewhere the thing I pass as an argument. Now
DISPLAY_GEN() sounds more like it returns the GEN of the DISPLAY (or
generates a Display).


> 
> I'm play around here with:
> 
> #define DISPLAY(dev_priv, g)(!!((dev_priv)->info.display_mask &
> BIT(g-1)))
> #define DISPLAY_RANGE(dev_priv, s, e) \
> (!!((dev_priv)->info.display_mask &
> INTEL_GEN_MASK((s), (e
> 
> thoughts? comments? ideas?

#define DISPLAY_GEN(dev_priv) ((dev_priv)->info.display_gen)

> 
> > 
> > /me looks at Rodrigo
> > 
> > > 
> > > > +   /* Display WA #1125: skl,bxt,kbl */
> > > > +   if (level == 0 && wp->rc_surface)
> > > > +   res_blocks +=
> > > > +   fixed16_to_u32_round_up(wp-
> > > > > y_tile_minimum);
> > > > 
> > > > +
> > > > +   /* Display WA #1126: skl,bxt,kbl */
> > > > +   if (level >= 1 && level <= 7) {
> > > > +   if (wp->y_tiled) {
> > > > +   res_blocks +=
> > > > +   fixed16_to_u32_round_up(wp
> > > > -
> > > > > y_tile_minimum);
> > > > 
> > > > +   res_lines += wp-
> > > > >y_min_scanlines;
> > > > +   } else {
> > > > +   res_blocks++;
> > > > +   }
> > > > 
> > > > -   /* Display WA #1126: skl,bxt,kbl,glk */
> > > > -   if (level >= 1 && level <= 7) {
> > > > -   if (wp->y_tiled) {
> > > > -   res_blocks += fixed16_to_u32_round_up(
> > > > -   wp-
> > > > > y_tile_minimum);
> > > > 
> > > > -   res_lines += wp->y_min_scanlines;
> > > > -   } else {
> > > > -   res_blocks++;
> > > > +   /*
> > > > +   

Re: [Intel-gfx] [PATCH] drm/i915: Simplify has_sagv

[Paulo Zanoni]

Em Seg, 2018-10-22 às 09:57 -0700, Rodrigo Vivi escreveu:
> Let's add a platform has_sagv instead of having a full
> function that handle platform by platform.
> 
> The specially case for SKL for not controlled sagv
> is already taken care inside intel_enable_sagv, so there's
> no need to duplicate the check here.
> 
> v2: Go one step further and remove skl special case. (Jani)
> 
> v3: Separate runtime status handle from has_sagv flag. (Jani)

I know this has probably been discussed in the past and I missed it
(since I know this was done a few times for other things), but how/why
is this approach better than the current one? Can you please write it
in the commit message?

Quickly checking the implementation of intel_has_sagv() seems much
easier than swimming through the nested macros of i915_pci.c. And the 
special-caseness of the NOT_CONTROLLED case being restricted to gen9 in
the current (non-patched) code also at first appears to be better than
this proposal. But I'm totally willing to read your arguments and
reevaluate my decisions based on them, so please present them.

> 
> Cc: Jani Nikula 
> Cc: Lucas De Marchi 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_pci.c  |  1 +
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c  | 29 
> 
>  4 files changed, 13 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 3017ef037fed..9b98ceb2d029 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2650,6 +2650,7 @@ intel_info(const struct drm_i915_private
> *dev_priv)
>  #define HAS_DDI(dev_priv) ((dev_priv)->info.has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) ((dev_priv)-
> >info.has_fpga_dbg)
>  #define HAS_PSR(dev_priv) ((dev_priv)->info.has_psr)
> +#define HAS_SAGV(dev_priv)((dev_priv)-
> >info.has_sagv)
>  
>  #define HAS_RC6(dev_priv) ((dev_priv)->info.has_rc6)
>  #define HAS_RC6p(dev_priv)((dev_priv)-
> >info.has_rc6p)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index 44e745921ac1..0b09155eab62 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -465,6 +465,7 @@ static const struct intel_device_info
> intel_cherryview_info = {
>   .has_csr = 1, \
>   .has_guc = 1, \
>   .has_ipc = 1, \
> + .has_sagv = 1, \
>   .ddb_size = 896
>  
>  #define SKL_PLATFORM \
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index af7002640cdf..e77c8b62783f 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -117,6 +117,7 @@ enum intel_ppgtt {
>   func(hws_needs_physical); \
>   func(overlay_needs_physical); \
>   func(supports_tv); \
> + func(has_sagv); \
>   func(has_ipc);
>  
>  #define GEN_MAX_SLICES   (6) /* CNL upper bound */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 67a4d0735291..7e38ed8421c7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3609,20 +3609,6 @@ static bool skl_needs_memory_bw_wa(struct
> intel_atomic_state *state)
>   return false;
>  }
>  
> -static bool
> -intel_has_sagv(struct drm_i915_private *dev_priv)
> -{
> - if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> - IS_CANNONLAKE(dev_priv) || IS_ICELAKE(dev_priv))
> - return true;
> -
> - if (IS_SKYLAKE(dev_priv) &&
> - dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED)
> - return true;
> -
> - return false;
> -}
> -
>  /*
>   * SAGV dynamically adjusts the system agent voltage and clock
> frequencies
>   * depending on power and performance requirements. The display
> engine access
> @@ -3639,10 +3625,11 @@ intel_enable_sagv(struct drm_i915_private
> *dev_priv)
>  {
>   int ret;
>  
> - if (!intel_has_sagv(dev_priv))
> + if (!HAS_SAGV(dev_priv))
>   return 0;
>  
> - if (dev_priv->sagv_status == I915_SAGV_ENABLED)
> + if (dev_priv->sagv_status == I915_SAGV_ENABLED ||
> + dev_priv->sagv_status == I915_SAGV_NOT_CONTROLLED)
>   return 0;
>  
>   DRM_DEBUG_KMS("Enabling the SAGV\n");
> @@ -3676,10 +3663,11 @@ intel_disable_sagv(struct drm_i915_private
> *dev_priv)
>  {
>   int ret;
>  
> - if (!intel_has_sagv(dev_priv))
> + if (!HAS_SAGV(dev_priv))
>   return 0;
>  
> - if (dev_priv->sagv_status == I915_SAGV_DISABLED)
> + if (dev_priv->sagv_status == I915_SAGV_DISABLED ||
> + dev_priv->sagv_status == I915_SAGV_NOT_CONTROLLED)
>   return 0;
>  
>   DRM_DEBUG_KMS("Disabling the SAGV\n");
> @@ -3721,7 +3709,10 @@ bool intel_can_enable_sag

Re: [Intel-gfx] [PATCH 01/11] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

[Paulo Zanoni]

Em Qui, 2018-10-18 às 16:14 +0300, Ville Syrjälä escreveu:
> On Tue, Oct 16, 2018 at 03:01:23PM -0700, Paulo Zanoni wrote:
> > BSpec does not show these WAs as applicable to GLK, and for CNL it
> > only shows them applicable for a super early pre-production
> > stepping
> > we shouldn't be caring about anymore. Remove these so we can avoid
> > them on ICL too.
> > 
> > Cc: Matt Roper 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 43 ++---
> > 
> >  1 file changed, 23 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 67a4d0735291..18157c6ee126 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4696,28 +4696,31 @@ static int skl_compute_plane_wm(const
> > struct drm_i915_private *dev_priv,
> > res_lines = div_round_up_fixed16(selected_result,
> >  wp-
> > >plane_blocks_per_line);
> >  
> > -   /* Display WA #1125: skl,bxt,kbl,glk */
> > -   if (level == 0 && wp->rc_surface)
> > -   res_blocks += fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > +   if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
> 
> IS_GEN9_BC || IS_BXT
> 
> would be a little easier to parse, me thinks.

I can do that, but what I really want is "DISPLAY_GEN(dev_priv) == 9".

/me looks at Rodrigo

> 
> > +   /* Display WA #1125: skl,bxt,kbl */
> > +   if (level == 0 && wp->rc_surface)
> > +   res_blocks +=
> > +   fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > +
> > +   /* Display WA #1126: skl,bxt,kbl */
> > +   if (level >= 1 && level <= 7) {
> > +   if (wp->y_tiled) {
> > +   res_blocks +=
> > +   fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > +   res_lines += wp->y_min_scanlines;
> > +   } else {
> > +   res_blocks++;
> > +   }
> >  
> > -   /* Display WA #1126: skl,bxt,kbl,glk */
> > -   if (level >= 1 && level <= 7) {
> > -   if (wp->y_tiled) {
> > -   res_blocks += fixed16_to_u32_round_up(
> > -   wp-
> > >y_tile_minimum);
> > -   res_lines += wp->y_min_scanlines;
> > -   } else {
> > -   res_blocks++;
> > +   /*
> > +* Make sure result blocks for higher
> > latency levels are
> > +* atleast as high as level below the
> > current level.
> > +* Assumption in DDB algorithm
> > optimization for special
> > +* cases. Also covers Display WA #1125 for
> > RC.
> > +*/
> > +   if (result_prev->plane_res_b > res_blocks)
> > +   res_blocks = result_prev-
> > >plane_res_b;
> > }
> > -
> > -   /*
> > -* Make sure result blocks for higher latency
> > levels are atleast
> > -* as high as level below the current level.
> > -* Assumption in DDB algorithm optimization for
> > special cases.
> > -* Also covers Display WA #1125 for RC.
> > -*/
> > -   if (result_prev->plane_res_b > res_blocks)
> > -   res_blocks = result_prev->plane_res_b;
> 
> This last thing is part of the glk+ watermark formula as well.
>  But
> I'm not 100% convinced that it's needed.

I simply can't find where this is documented. WAs 1125 and 1126, which
contain text that match this code exactly, are not applicable to GLK.
Which BSpec page and paragraph/section mentions this?


>  One might assume that the the
> non-decrasing latency values guarantee that the resulting watermarks
> are also non-decreasing. But I've not actually done the math to see
> if
> that's true.
> 
> Hmm. It might not actually be true on account of the 'memory latency
> microseconds >= line time microseconds' check when selecting which
> method to use to calculate the watermark. Not quite sure which way
> that would make things go.
> 
> We also seem to be missing the res_lines handling here. But given
> that we only did this for compressed fbs before I don't think this
> patch is making things much worse by limiting this to pre-glk only.
> The glk+ handling and res_lines fix could be done as a followup.
> 
> Reviewed-by: Ville Syrjälä 
> 
> 
> > }
> >  
> > if (INTEL_GEN(dev_priv) >= 11) {
> > -- 
> > 2.14.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/11] drm/i915: move ddb_blocks to be a watermark parameter

[Paulo Zanoni]

Em Qui, 2018-10-18 às 16:41 +0300, Ville Syrjälä escreveu:
> On Tue, Oct 16, 2018 at 03:01:29PM -0700, Paulo Zanoni wrote:
> > The goal of struct skl_wm_params is to cache every watermark
> > parameter so the other functions can just use them without worrying
> > about the appropriate place to fetch each parameter requested by
> > the
> > spec, and without having to recompute parameters that are used in
> > different steps of the calculation.
> > 
> > The ddb_blocks parameter is one that is used by both the the plane
> > watermarks and the transition watermarks. Move ddb_blocks to the
> > parameter struct so we can simplify the code.
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/intel_pm.c | 44 -
> > 
> >  2 files changed, 18 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 4b1e8471609b..b32d680d9bf0 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1255,6 +1255,7 @@ struct skl_wm_params {
> > bool rc_surface;
> > bool is_planar;
> > uint32_t width;
> > +   uint16_t ddb_blocks;
> > uint8_t cpp;
> > uint32_t plane_pixel_rate;
> > uint32_t y_min_scanlines;
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index f388bfa99a97..4053f4a68657 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4522,11 +4522,13 @@ static int
> >  skl_compute_plane_wm_params(const struct drm_i915_private
> > *dev_priv,
> > struct intel_crtc_state *cstate,
> > const struct intel_plane_state
> > *intel_pstate,
> > +   const struct skl_ddb_allocation *ddb,
> > struct skl_wm_params *wp, int
> > plane_id)
> >  {
> > struct intel_plane *plane = to_intel_plane(intel_pstate-
> > >base.plane);
> > const struct drm_plane_state *pstate = &intel_pstate-
> > >base;
> > const struct drm_framebuffer *fb = pstate->fb;
> > +   enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe;
> > uint32_t interm_pbpl;
> > struct intel_atomic_state *state =
> > to_intel_atomic_state(cstate->base.state);
> > @@ -4624,13 +4626,16 @@ skl_compute_plane_wm_params(const struct
> > drm_i915_private *dev_priv,
> > wp->linetime_us = fixed16_to_u32_round_up(
> > intel_get_linetime_us(csta
> > te));
> >  
> > +   wp->ddb_blocks = plane_id ?
> 
> Ugh. That 'plane_id' really should be renamed to something else.
> 'color_plane' would be the newfangled name I started to use
> elsewhere.

I completely agree: there's plane_id and plane->id and they mean
different things.

If you're already using color_plane I can totally go with it so we have
consistency. But, well, for RGB planes, plane 0 does contain color
information... But can I suggest us to use "subplane" terminology when
talking about the planes of a plane? What about subplane_index?
Something that does not use the word "plane" is probably better.

> 
> Patch looks good to me.
> Reviewed-by: Ville Syrjälä 
> 
> > +skl_ddb_entry_size(&ddb-
> > >uv_plane[pipe][plane->id]) :
> > +skl_ddb_entry_size(&ddb->plane[pipe][plane-
> > >id]);
> > +
> > return 0;
> >  }
> >  
> >  static int skl_compute_plane_wm(const struct drm_i915_private
> > *dev_priv,
> > struct intel_crtc_state *cstate,
> > const struct intel_plane_state
> > *intel_pstate,
> > -   uint16_t ddb_allocation,
> > int level,
> > const struct skl_wm_params *wp,
> > const struct skl_wm_level
> > *result_prev,
> > @@ -4674,7 +4679,7 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >  wp->dbuf_block_size < 1) &&
> >  (wp->plane_bytes_per_line / wp-
> > >dbuf_block_size < 1)) {
> > selected_result = method2;
> > -   } else if (ddb_allocation >=
> > +   } else if (wp->ddb_blocks >=
&

Re: [Intel-gfx] [PATCH 08/11] drm/i915: reorganize the error message for invalid watermarks

[Paulo Zanoni]

Em Qui, 2018-10-18 às 16:55 +0300, Ville Syrjälä escreveu:
> On Tue, Oct 16, 2018 at 03:01:30PM -0700, Paulo Zanoni wrote:
> > Print a more generic "failed to compute watermark levels" whenever
> > any
> > of skl_compute_wm_levels() fail, and print only the specific error
> > message for the specific cases. This allows us to stop passing
> > pstate
> > everywhere, making the watermarks computation code a little less
> > dependent on random intel state structs.
> 
> Nothing random about those structs. They are *the* state.

What I'm about to say is all probably a reflex of my own incompetence
to understand the flows of our code, but here it goes.

1. There's duplication in those structs. At any given point of our
source code, should you use state structs passed as parameters, or
should you use object->state (e.g., intel_crtc->state)? Sometimes one
thing is the new state and the other thing is the old state, sometimes
it is the opposite, and checking which one is which is never trivial. I
always have to go back to intel_display.c and try to find that point in
the modeset where we assign crtc_config to crtc->config and then try to
figure out if my code runs before or after that point. And I'm never
100% confident I'm using the correct struct.

2. There's a lot of duplication in members of those structs. There are
like 5 different things that could mean "pixel rate" (for real mode,
for adjusted mode, considering/not-considering scaling, rotation, etc),
there are many things that could mean "source width", etc. So when you
need a specific value, it's not always clear where to get it from in
our driver.

3. The names inside the watermarks calculation page (or anywhere else
in our spec) don't easily translate to any of those struct members
mentioned in item 2. E.g., plane pixel rate.

I mean, look at how many times the spec (not only for watermarks, but
for other stuff too, like FBC and PSR) had wording like "source size"
and we fetched the value from one place, but then we learned that we
needed to fetch the value from this other place that was the same in
most cases except for these X and Y corner cases. You reviewed some of
those patches.

So, to conclude the argument, the nice thing about struct skl_wm_params
is that it allows us to have a single point where we translate "i915
terminology" to "watermarks calculation algorithm terminology", so we
can fix that single place if/when needed. And then everywhere else in
watermarks code we just fetch the value from this struct without having
to worry "at this point in the sequence, where should this value come
from?", allowing us to focus on the algorithm specifically. On top of
that, there's the fact that we only compute things once instead of up
to 8 times per plane (7 levels + transition watermarks).

Of course, the downside is that we address the problem of "too many
places to fetch information from" by introducing a new place where
information is fetched from, so I definitely can't argue that the
current solution is good either. I would really like to know what are
your proposals here: if we decide to remove the params struct, would
you suggest we simply fetch everything directly from the passed structs
and recompute all the values that are computed multiple times? I'm
totally willing to implement something better if you have it in your
head.


> Using them directly rather than duplicating informationa in the
> wm_params struct would probably make the code look a bit less alien.
> 
> But given that the information is duplicated I guess we don't have to
> pass in the plane state. So the patch seems fine in that sense.

> 
> Reviewed-by: Ville Syrjälä 

Thanks for the reviews!

> 
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 27 ---
> >  1 file changed, 12 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 4053f4a68657..1290efc64869 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4635,13 +4635,11 @@ skl_compute_plane_wm_params(const struct
> > drm_i915_private *dev_priv,
> >  
> >  static int skl_compute_plane_wm(const struct drm_i915_private
> > *dev_priv,
> > struct intel_crtc_state *cstate,
> > -   const struct intel_plane_state
> > *intel_pstate,
> > int level,
> > const struct skl_wm_params *wp,
> > const struct skl_wm_level
> > *result_prev,
> > s

Re: [Intel-gfx] [PATCH] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations

[Paulo Zanoni]

Em Sex, 2018-10-12 às 15:42 +0300, Ville Syrjälä escreveu:
> On Thu, Oct 11, 2018 at 05:40:45PM -0700, Paulo Zanoni wrote:
> > These are the new recommended values provided by our spec (18 -> 19
> > and 23 -> 24). It seems this should help fixing GMBUS issues. Since
> > we're doing pretty much the same thing for both CNP and ICP now,
> > unify
> > the functions using the ICP version since it's more straightforward
> > by
> > just matching the values listed in BSpec instead of recalculating
> > them.
> 
> IMO calculating would be better. Would be trivial to see that the
> values
> are at least consistent. With four magic numbers you have no choice
> but
> to dig up the spec, which is painful. I don't like needless pain that
> much.

Then I guess our workloads are different. IMHO the code is trivial when
we can easily see that we set the exact magic values that the spec
tells us to set.  With the formula, you have to do the calculations for
both frequencies, then you take those values and compare against the
spec, which is an extra step. Developing without the spec open is
something that I never even consider.

Anyway, I can submit another version with the cnl model, no problem.

> 
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h|  1 -
> >  drivers/gpu/drm/i915/intel_cdclk.c | 37 ++--
> > -
> >  2 files changed, 6 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 20785417953d..ffd564a8d339 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7832,7 +7832,6 @@ enum {
> >  #define  CNP_RAWCLK_DIV(div)   ((div) << 16)
> >  #define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
> >  #define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
> > -#define  ICP_RAWCLK_DEN(den)   ((den) << 26)
> >  #define  ICP_RAWCLK_NUM(num)   ((num) << 11)
> >  
> >  #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 29075c763428..17d3f13d89db 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -2660,48 +2660,25 @@ void intel_update_cdclk(struct
> > drm_i915_private *dev_priv)
> >  }
> >  
> >  static int cnp_rawclk(struct drm_i915_private *dev_priv)
> > -{
> > -   u32 rawclk;
> > -   int divider, fraction;
> > -
> > -   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
> > -   /* 24 MHz */
> > -   divider = 24000;
> > -   fraction = 0;
> > -   } else {
> > -   /* 19.2 MHz */
> > -   divider = 19000;
> > -   fraction = 200;
> > -   }
> > -
> > -   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
> > -   if (fraction)
> > -   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
> > -   fracti
> > on) - 1);
> > -
> > -   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
> > -   return divider + fraction;
> > -}
> > -
> > -static int icp_rawclk(struct drm_i915_private *dev_priv)
> >  {
> > u32 rawclk;
> > int divider, numerator, denominator, frequency;
> >  
> > if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
> > frequency = 24000;
> > -   divider = 23;
> > +   divider = 24;
> > numerator = 0;
> > denominator = 0;
> > } else {
> > frequency = 19200;
> > -   divider = 18;
> > +   divider = 19;
> > numerator = 1;
> > denominator = 4;
> 
> These numbers are extremely confusing. The hardware wants the
> numerator
> as is but then it wants denominator-1. Which is a but odd. I think
> I'd
> move the -1 for the denominator into the macro (or the invocation of
> the
> macro, like cnp had). Alternatively we could at least write this as
> 5-1
> here, so that the reader has at least some chance to figure out what
> this means.
> 
> > }
> >  
> > -   rawclk = CNP_RAWCLK_DIV(divider) |
> > ICP_RAWCLK_NUM(numerator) |
> > -ICP_RAWCLK_DEN(denominator);
> > +   rawclk = CNP_RAWCLK_DIV(divider) |
> > CNP_RAWCLK_FRAC(denominator);
> > +   if (HAS_PCH_ICP(dev_priv))
> > +   raw

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for More watermarks improvements

[Paulo Zanoni]

Em Ter, 2018-10-16 às 22:39 +, Patchwork escreveu:
> == Series Details ==
> 
> Series: More watermarks improvements
> URL   : https://patchwork.freedesktop.org/series/51086/
> State : failure
> 
> == Summary ==
> 
> = CI Bug Log - changes from CI_DRM_4990 -> Patchwork_10481 =
> 
> == Summary - FAILURE ==
> 
>   Serious unknown changes coming with Patchwork_10481 absolutely need
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the
> changes
>   introduced in Patchwork_10481, please notify your bug team to allow
> them
>   to document this new failure mode, which will reduce false
> positives in CI.
> 
>   External URL: https://patchwork.freedesktop.org/api/1.0/series/5108
> 6/revisions/1/mbox/
> 
> == Possible new issues ==
> 
>   Here are the unknown changes that may have been introduced in
> Patchwork_10481:
> 
>   === IGT changes ===
> 
>  Possible regressions 
> 
> igt@pm_rpm@module-reload:
>   fi-glk-j4005:   PASS -> DMESG-FAIL


EDID shows invalid data after module reload, triggering error during
mode comparison in the subtest. Hard to think how this series could
cause that.

> 
> 
> == Known issues ==
> 
>   Here are the changes found in Patchwork_10481 that come from known
> issues:
> 
>   === IGT changes ===
> 
>  Issues hit 
> 
> igt@gem_exec_suspend@basic-s3:
>   fi-kbl-soraka:  NOTRUN -> INCOMPLETE (fdo#107859,
> fdo#107774, fdo#107556)
> 
> igt@kms_flip@basic-flip-vs-dpms:
>   fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106000, fdo#106097)
> 
> igt@kms_flip@basic-plain-flip:
>   fi-ilk-650: PASS -> DMESG-WARN (fdo#106387) +2
> 
> igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
>   fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362)
> 
> 
>  Possible fixes 
> 
> igt@drv_module_reload@basic-reload:
>   fi-glk-j4005:   DMESG-WARN (fdo#106248, fdo#106725) -> PASS
> 
> igt@drv_selftest@live_hangcheck:
>   fi-icl-u2:  INCOMPLETE (fdo#108315) -> PASS
> 
> igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
>   fi-glk-j4005:   FAIL (fdo#106765) -> PASS
> 
> igt@kms_flip@basic-flip-vs-dpms:
>   fi-hsw-4770r:   DMESG-WARN (fdo#105602) -> PASS
> 
> igt@kms_flip@basic-flip-vs-wf_vblank:
>   fi-glk-j4005:   FAIL (fdo#100368) -> PASS
> 
> igt@kms_flip@basic-plain-flip:
>   fi-glk-j4005:   DMESG-WARN (fdo#106097) -> PASS
> 
> igt@kms_frontbuffer_tracking@basic:
>   fi-icl-u2:  FAIL (fdo#103167) -> PASS
>   fi-byt-clapper: FAIL (fdo#103167) -> PASS
> 
> 
>   fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
>   fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
>   fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
>   fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
>   fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
>   fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
>   fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
>   fdo#106387 https://bugs.freedesktop.org/show_bug.cgi?id=106387
>   fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
>   fdo#106765 https://bugs.freedesktop.org/show_bug.cgi?id=106765
>   fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
>   fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556
>   fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774
>   fdo#107859 https://bugs.freedesktop.org/show_bug.cgi?id=107859
>   fdo#108315 https://bugs.freedesktop.org/show_bug.cgi?id=108315
> 
> 
> == Participating hosts (46 -> 38) ==
> 
>   Additional (1): fi-kbl-soraka 
>   Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-skl-guc
> fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-pnv-d510 fi-kbl-7560u 
> 
> 
> == Build changes ==
> 
> * Linux: CI_DRM_4990 -> Patchwork_10481
> 
>   CI_DRM_4990: 0bd34d92e9a27784cb988a300619f497ca0e99ec @
> git://anongit.freedesktop.org/gfx-ci/linux
>   IGT_4681: 959d6f95cb1344e0c0dace5b236e17755826fac1 @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>   Patchwork_10481: 4a4d7716aeaa870a7d0aaa1e541706cb919096cd @
> git://anongit.freedesktop.org/gfx-ci/linux
> 
> 
> == Linux commits ==
> 
> 4a4d7716aeaa drm/i915: pass dev_priv instead of cstate to
> skl_compute_transition_wm()
> 03f7a31192d8 drm/i915: add pipe_htotal to struct skl_wm_params
> e541090ceec3 drm/i915: make skl_needs_memory_bw_wa() take dev_priv
> instead of state
> c801352ac21a drm/i915: reorganize the error message for invalid
> watermarks
> 52262264df7e drm/i915: move ddb_blocks to be a watermark parameter
> b6f917785676 drm/i915: refactor skl_write_plane_wm()
> 10134ecdb23d drm/i915: simplify wm->is_planar assignment
> 20ce35c3029a drm/i915: remove useless memset() for watermarks
> parameters
> 7d4eced125cf drm/i915: fix handling of invisible planes in watermarks
> code
> 6165f42570

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More watermarks improvements

[Paulo Zanoni]

Em Ter, 2018-10-16 às 22:21 +, Patchwork escreveu:
> == Series Details ==
> 
> Series: More watermarks improvements
> URL   : https://patchwork.freedesktop.org/series/51086/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> 6a8c3f3d3663 drm/i915: don't apply Display WAs 1125 and 1126 to
> GLK/CNL+
> 6165f4257098 drm/i915: remove padding from struct skl_wm_level
> -:25: CHECK:BOOL_MEMBER: Avoid using bool structure members because
> of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/
> 384
> #25: FILE: drivers/gpu/drm/i915/i915_drv.h:1248:
> + bool plane_en;
> 
> total: 0 errors, 0 warnings, 1 checks, 10 lines checked

That won't save us anything in this specific case, and it's not our
usual coding standard. If we conclude i915.ko should go this way, I'd
be happy to comply. Maintainers?

> 7d4eced125cf drm/i915: fix handling of invisible planes in watermarks
> code
> -:41: CHECK:BOOL_MEMBER: Avoid using bool structure members because
> of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/
> 384
> #41: FILE: drivers/gpu/drm/i915/i915_drv.h:1253:
> + bool plane_visible;

The rest of the struct also uses bools like this. If we go this route,
we should probably change the whole struct.

> 
> total: 0 errors, 0 warnings, 1 checks, 52 lines checked
> 20ce35c3029a drm/i915: remove useless memset() for watermarks
> parameters
> 10134ecdb23d drm/i915: simplify wm->is_planar assignment
> b6f917785676 drm/i915: refactor skl_write_plane_wm()
> -:8: ERROR:GIT_COMMIT_ID: Please use git commit description style
> 'commit <12+ chars of sha1> ("")' - ie: 'commit
> 9e44b180f81b ("drm/i915: don't write PLANE_BUF_CFG twice every
> time")'
> #8: 
> 9e44b180f81b ("drm/i915: don't write PLANE_BUF_CFG twice every time")

Well, I used that description style, but it's in the middle of a
paragraph so the word "commit" is in the line above. If that's not what
you're asking, then I don't know.


> 
> -:16: WARNING:BAD_SIGN_OFF: Non-standard signature: Requested-by:
> #16: 
> Requested-by: Matt Roper 

Is this really undesirable?


> 
> total: 1 errors, 1 warnings, 0 checks, 41 lines checked
> 52262264df7e drm/i915: move ddb_blocks to be a watermark parameter
> c801352ac21a drm/i915: reorganize the error message for invalid
> watermarks
> e541090ceec3 drm/i915: make skl_needs_memory_bw_wa() take dev_priv
> instead of state
> 03f7a31192d8 drm/i915: add pipe_htotal to struct skl_wm_params
> 4a4d7716aeaa drm/i915: pass dev_priv instead of cstate to
> skl_compute_transition_wm()
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/11] drm/i915: fix handling of invisible planes in watermarks code

[Paulo Zanoni]

Before the patch, if a plane was not visible,
skl_compute_plane_wm_params() would return early without writing
anything to the wm_params struct. This would leave garbage in the
struct since it is not previously zeroed, and then we would later
check for wm_params.is_planar, which could be true due to the usage of
uninitialized memory. This would lead us to calculate the zeroed
watermarks for the second inexistent plane and mark the plane as a
planar plane. Then later this check would affect our decisions in
skl_write_plane_wm().

I can't see how this would lead to a noticeable bug in our code, but
it leads us to calculate watermarks for every level + transition
watermarks, twice (due to the is_planar bug). So the fix saves us a
lot of instructions.

This problem was found when I decided to add a DRM_ERROR for the
currently unsupported planar formats on ICL: kms_cursor_legacy would
trigger the error message without using planar formats.

So the fix we adopt in this patch is to create a new watermark
parameter called plane_visible and use it to avoid computing the
watermarks for invisible planes later. We also remove the checks that
are now made redundant by it.

Testcase: igt/kms_cursor_legacy/nonblocking-modeset-vs-cursor-atomic
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 15 ++-
 2 files changed, 7 insertions(+), 9 deletions(-)

The error message mentioned above isd the one added by patch 06 of the
series.

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3616b718b5d2..4b1e8471609b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1250,6 +1250,7 @@ struct skl_wm_level {
 
 /* Stores plane specific WM parameters */
 struct skl_wm_params {
+   bool plane_visible;
bool x_tiled, y_tiled;
bool rc_surface;
bool is_planar;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 18157c6ee126..9043ffe40ce8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4532,7 +4532,8 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
to_intel_atomic_state(cstate->base.state);
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
 
-   if (!intel_wm_plane_visible(cstate, intel_pstate))
+   wp->plane_visible = intel_wm_plane_visible(cstate, intel_pstate);
+   if (!wp->plane_visible)
return 0;
 
/* only NV12 format has two planes */
@@ -4645,8 +4646,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
uint32_t min_disp_buf_needed;
 
-   if (latency == 0 ||
-   !intel_wm_plane_visible(cstate, intel_pstate)) {
+   if (latency == 0) {
result->plane_en = false;
return 0;
}
@@ -4805,9 +4805,6 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
enum plane_id intel_plane_id = intel_plane->id;
int ret;
 
-   if (WARN_ON(!intel_pstate->base.fb))
-   return -EINVAL;
-
ddb_blocks = plane_id ?
 skl_ddb_entry_size(&ddb->uv_plane[pipe][intel_plane_id]) :
 skl_ddb_entry_size(&ddb->plane[pipe][intel_plane_id]);
@@ -4876,9 +4873,6 @@ static void skl_compute_transition_wm(struct 
intel_crtc_state *cstate,
const uint16_t trans_amount = 10; /* This is configurable amount */
uint16_t wm0_sel_res_b, trans_offset_b, res_blocks;
 
-   if (!cstate->base.active)
-   goto exit;
-
/* Transition WM are not recommended by HW team for GEN9 */
if (INTEL_GEN(dev_priv) <= 9)
goto exit;
@@ -4965,6 +4959,9 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
if (ret)
return ret;
 
+   if (!wm_params.plane_visible)
+   continue;
+
ret = skl_compute_wm_levels(dev_priv, ddb, cstate,
intel_pstate, &wm_params, wm, 0);
if (ret)
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 10/11] drm/i915: add pipe_htotal to struct skl_wm_params

[Paulo Zanoni]

With this one here we can finally drop the intel state structures from
the functions that compute watermark values: they all rely on struct
skl_wm_params now. This should help the watermarks code be a little
more clear on its intent and also match the spec a little bit more
with the carefully chosen names for its parameters.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 20 
 2 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b32d680d9bf0..4712eaea9744 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1254,6 +1254,7 @@ struct skl_wm_params {
bool x_tiled, y_tiled;
bool rc_surface;
bool is_planar;
+   uint32_t pipe_htotal;
uint32_t width;
uint16_t ddb_blocks;
uint8_t cpp;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d101c542f10d..b01f3d807ff6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4549,6 +4549,8 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
 fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
wp->is_planar = fb->format->format == DRM_FORMAT_NV12;
 
+   wp->pipe_htotal = cstate->base.adjusted_mode.crtc_htotal;
+
if (plane->id == PLANE_CURSOR) {
wp->width = intel_pstate->base.crtc_w;
} else {
@@ -4630,7 +4632,6 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
 }
 
 static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
-   struct intel_crtc_state *cstate,
int level,
const struct skl_wm_params *wp,
const struct skl_wm_level *result_prev,
@@ -4659,17 +4660,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
method1 = skl_wm_method1(dev_priv, wp->plane_pixel_rate,
 wp->cpp, latency, wp->dbuf_block_size);
-   method2 = skl_wm_method2(wp->plane_pixel_rate,
-cstate->base.adjusted_mode.crtc_htotal,
+   method2 = skl_wm_method2(wp->plane_pixel_rate, wp->pipe_htotal,
 latency,
 wp->plane_blocks_per_line);
 
if (wp->y_tiled) {
selected_result = max_fixed16(method2, wp->y_tile_minimum);
} else {
-   if ((wp->cpp * cstate->base.adjusted_mode.crtc_htotal /
-wp->dbuf_block_size < 1) &&
-(wp->plane_bytes_per_line / wp->dbuf_block_size < 1)) {
+   if ((wp->cpp * wp->pipe_htotal / wp->dbuf_block_size < 1) &&
+   (wp->plane_bytes_per_line / wp->dbuf_block_size < 1)) {
selected_result = method2;
} else if (wp->ddb_blocks >=
 fixed16_to_u32_round_up(wp->plane_blocks_per_line)) {
@@ -4782,7 +4781,6 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
 static int
 skl_compute_wm_levels(const struct drm_i915_private *dev_priv,
- struct intel_crtc_state *cstate,
  const struct skl_wm_params *wm_params,
  struct skl_plane_wm *wm,
  int plane_id)
@@ -4802,7 +4800,6 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
result_prev = plane_id ? &wm->uv_wm[0] : &wm->wm[0];
 
ret = skl_compute_plane_wm(dev_priv,
-  cstate,
   level,
   wm_params,
   result_prev,
@@ -4937,8 +4934,7 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
if (!wm_params.plane_visible)
continue;
 
-   ret = skl_compute_wm_levels(dev_priv, cstate, &wm_params, wm,
-   0);
+   ret = skl_compute_wm_levels(dev_priv, &wm_params, wm, 0);
if (ret) {
DRM_DEBUG_KMS("[PLANE:%d:%s] failed to compute 
watermark levels\n",
  plane->base.id, plane->name);
@@ -4956,8 +4952,8 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
if (ret)
return ret;
 
-   ret = skl_compute_wm_levels(dev_priv, cstate,
-   &wm_params, wm, 1);

[Intel-gfx] [PATCH 09/11] drm/i915: make skl_needs_memory_bw_wa() take dev_priv instead of state

[Paulo Zanoni]

The function only really needs dev_priv to make its decision. If we
ever need more, we can change it again. But then, in this case we
should make needs_memory_bw_wa be a variable inside struct
skl_wm_params so we won't need to keep passing intel states deep
inside pure watermark value calculation functions.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1290efc64869..d101c542f10d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3599,10 +3599,8 @@ static u8 intel_enabled_dbuf_slices_num(struct 
drm_i915_private *dev_priv)
  * FIXME: We still don't have the proper code detect if we need to apply the 
WA,
  * so assume we'll always need it in order to avoid underruns.
  */
-static bool skl_needs_memory_bw_wa(struct intel_atomic_state *state)
+static bool skl_needs_memory_bw_wa(const struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
-
if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv))
return true;
 
@@ -3765,7 +3763,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
 
latency = dev_priv->wm.skl_latency[level];
 
-   if (skl_needs_memory_bw_wa(intel_state) &&
+   if (skl_needs_memory_bw_wa(dev_priv) &&
plane->base.state->fb->modifier ==
I915_FORMAT_MOD_X_TILED)
latency += 15;
@@ -4530,9 +4528,7 @@ skl_compute_plane_wm_params(const struct drm_i915_private 
*dev_priv,
const struct drm_framebuffer *fb = pstate->fb;
enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe;
uint32_t interm_pbpl;
-   struct intel_atomic_state *state =
-   to_intel_atomic_state(cstate->base.state);
-   bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+   bool apply_memory_bw_wa = skl_needs_memory_bw_wa(dev_priv);
 
wp->plane_visible = intel_wm_plane_visible(cstate, intel_pstate);
if (!wp->plane_visible)
@@ -4644,9 +4640,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint_fixed_16_16_t method1, method2;
uint_fixed_16_16_t selected_result;
uint32_t res_blocks, res_lines;
-   struct intel_atomic_state *state =
-   to_intel_atomic_state(cstate->base.state);
-   bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+   bool apply_memory_bw_wa = skl_needs_memory_bw_wa(dev_priv);
uint32_t min_disp_buf_needed;
 
if (latency == 0) {
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/11] drm/i915: reorganize the error message for invalid watermarks

[Paulo Zanoni]

Print a more generic "failed to compute watermark levels" whenever any
of skl_compute_wm_levels() fail, and print only the specific error
message for the specific cases. This allows us to stop passing pstate
everywhere, making the watermarks computation code a little less
dependent on random intel state structs.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4053f4a68657..1290efc64869 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4635,13 +4635,11 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
 
 static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
-   const struct intel_plane_state *intel_pstate,
int level,
const struct skl_wm_params *wp,
const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
 {
-   const struct drm_plane_state *pstate = &intel_pstate->base;
uint32_t latency = dev_priv->wm.skl_latency[level];
uint_fixed_16_16_t method1, method2;
uint_fixed_16_16_t selected_result;
@@ -4763,11 +4761,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if (level) {
return 0;
} else {
-   struct drm_plane *plane = pstate->plane;
-
-   DRM_DEBUG_KMS("Requested display configuration exceeds 
system watermark limitations\n");
-   DRM_DEBUG_KMS("[PLANE:%d:%s] blocks required = %u/%u, 
lines required = %u/31\n",
- plane->base.id, plane->name,
+   DRM_DEBUG_KMS("Requested display configuration exceeds 
system watermark limitations: blocks required = %u/%u, lines required = 
%u/31\n",
  res_blocks, wp->ddb_blocks, res_lines);
return -EINVAL;
}
@@ -4795,7 +4789,6 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 static int
 skl_compute_wm_levels(const struct drm_i915_private *dev_priv,
  struct intel_crtc_state *cstate,
- const struct intel_plane_state *intel_pstate,
  const struct skl_wm_params *wm_params,
  struct skl_plane_wm *wm,
  int plane_id)
@@ -4816,7 +4809,6 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
 
ret = skl_compute_plane_wm(dev_priv,
   cstate,
-  intel_pstate,
   level,
   wm_params,
   result_prev,
@@ -4951,10 +4943,13 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
if (!wm_params.plane_visible)
continue;
 
-   ret = skl_compute_wm_levels(dev_priv, cstate,
-   intel_pstate, &wm_params, wm, 0);
-   if (ret)
+   ret = skl_compute_wm_levels(dev_priv, cstate, &wm_params, wm,
+   0);
+   if (ret) {
+   DRM_DEBUG_KMS("[PLANE:%d:%s] failed to compute 
watermark levels\n",
+ plane->base.id, plane->name);
return ret;
+   }
 
skl_compute_transition_wm(cstate, &wm_params, &wm->wm[0],
  &wm->trans_wm);
@@ -4968,10 +4963,12 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
return ret;
 
ret = skl_compute_wm_levels(dev_priv, cstate,
-   intel_pstate, &wm_params,
-   wm, 1);
-   if (ret)
+   &wm_params, wm, 1);
+   if (ret) {
+   DRM_DEBUG_KMS("[PLANE:%d:%s] failed to compute 
planar watermark levels\n",
+ plane->base.id, plane->name);
return ret;
+   }
}
}
 
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/11] drm/i915: remove useless memset() for watermarks parameters

[Paulo Zanoni]

The skl_compute_plane_wm_params() already completely sets the contents
of its struct, or returns plane_visible=0 or returns an error code.
There's no need to memset() it at this point for the same reason we
don't zero-initialize it up when dealing with plane 0.

If we want to keep the memset "just to be safe", then we should also
zero initialize it when we use it for plane 0.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9043ffe40ce8..d1dd3ae408f9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4972,7 +4972,6 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
 
/* uv plane watermarks must also be validated for NV12/Planar */
if (wm_params.is_planar) {
-   memset(&wm_params, 0, sizeof(struct skl_wm_params));
wm->is_planar = true;
 
ret = skl_compute_plane_wm_params(dev_priv, cstate,
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 00/11] More watermarks improvements

[Paulo Zanoni]

Except for maybe patch 1, I don't believe this series will allow us to
close any real bugs, but at least it should make the code more
readable. Please notice that we removed more lines than we added :).

Thanks,
Paulo

Paulo Zanoni (11):
  drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+
  drm/i915: remove padding from struct skl_wm_level
  drm/i915: fix handling of invisible planes in watermarks code
  drm/i915: remove useless memset() for watermarks parameters
  drm/i915: simplify wm->is_planar assignment
  drm/i915: refactor skl_write_plane_wm()
  drm/i915: move ddb_blocks to be a watermark parameter
  drm/i915: reorganize the error message for invalid watermarks
  drm/i915: make skl_needs_memory_bw_wa() take dev_priv instead of state
  drm/i915: add pipe_htotal to struct skl_wm_params
  drm/i915: pass dev_priv instead of cstate to
skl_compute_transition_wm()

 drivers/gpu/drm/i915/i915_drv.h |   5 +-
 drivers/gpu/drm/i915/intel_pm.c | 198 ++--
 2 files changed, 92 insertions(+), 111 deletions(-)

-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/11] drm/i915: refactor skl_write_plane_wm()

[Paulo Zanoni]

Its control flow is not as easy to follow as it could be. We recently
even had a double register write that went unnoticed until commit
9e44b180f81b ("drm/i915: don't write PLANE_BUF_CFG twice every time")
fixed it. The return statement in the middle along with the fact that
it's on a void function really doesn't help readability IMHO.

Refactor the function so that the first level of checks is per
platform and the second level is for planar planes. IMHO that makes
the code much more readable.

Requested-by: Matt Roper 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7fd344b81d66..f388bfa99a97 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5033,21 +5033,28 @@ static void skl_write_plane_wm(struct intel_crtc 
*intel_crtc,
skl_write_wm_level(dev_priv, PLANE_WM_TRANS(pipe, plane_id),
   &wm->trans_wm);
 
-   /* FIXME: add proper NV12 support for ICL. */
-   if (INTEL_GEN(dev_priv) >= 11)
-   return skl_ddb_entry_write(dev_priv,
-  PLANE_BUF_CFG(pipe, plane_id),
-  &ddb->plane[pipe][plane_id]);
-   if (wm->is_planar) {
-   skl_ddb_entry_write(dev_priv, PLANE_BUF_CFG(pipe, plane_id),
-   &ddb->uv_plane[pipe][plane_id]);
+   if (INTEL_GEN(dev_priv) >= 11) {
+   /* FIXME: add proper NV12 support for ICL. */
+   if (wm->is_planar)
+   DRM_ERROR("No DDB support for planar formats yet\n");
+
skl_ddb_entry_write(dev_priv,
-   PLANE_NV12_BUF_CFG(pipe, plane_id),
-   &ddb->plane[pipe][plane_id]);
+  PLANE_BUF_CFG(pipe, plane_id),
+  &ddb->plane[pipe][plane_id]);
} else {
-   skl_ddb_entry_write(dev_priv, PLANE_BUF_CFG(pipe, plane_id),
-   &ddb->plane[pipe][plane_id]);
-   I915_WRITE(PLANE_NV12_BUF_CFG(pipe, plane_id), 0x0);
+   if (wm->is_planar) {
+   skl_ddb_entry_write(dev_priv,
+   PLANE_BUF_CFG(pipe, plane_id),
+   &ddb->uv_plane[pipe][plane_id]);
+   skl_ddb_entry_write(dev_priv,
+   PLANE_NV12_BUF_CFG(pipe, plane_id),
+   &ddb->plane[pipe][plane_id]);
+   } else {
+   skl_ddb_entry_write(dev_priv,
+   PLANE_BUF_CFG(pipe, plane_id),
+   &ddb->plane[pipe][plane_id]);
+   I915_WRITE(PLANE_NV12_BUF_CFG(pipe, plane_id), 0x0);
+   }
}
 }
 
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/11] drm/i915: move ddb_blocks to be a watermark parameter

[Paulo Zanoni]

The goal of struct skl_wm_params is to cache every watermark
parameter so the other functions can just use them without worrying
about the appropriate place to fetch each parameter requested by the
spec, and without having to recompute parameters that are used in
different steps of the calculation.

The ddb_blocks parameter is one that is used by both the the plane
watermarks and the transition watermarks. Move ddb_blocks to the
parameter struct so we can simplify the code.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 44 -
 2 files changed, 18 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4b1e8471609b..b32d680d9bf0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1255,6 +1255,7 @@ struct skl_wm_params {
bool rc_surface;
bool is_planar;
uint32_t width;
+   uint16_t ddb_blocks;
uint8_t cpp;
uint32_t plane_pixel_rate;
uint32_t y_min_scanlines;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f388bfa99a97..4053f4a68657 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4522,11 +4522,13 @@ static int
 skl_compute_plane_wm_params(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
+   const struct skl_ddb_allocation *ddb,
struct skl_wm_params *wp, int plane_id)
 {
struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
const struct drm_plane_state *pstate = &intel_pstate->base;
const struct drm_framebuffer *fb = pstate->fb;
+   enum pipe pipe = to_intel_crtc(cstate->base.crtc)->pipe;
uint32_t interm_pbpl;
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
@@ -4624,13 +4626,16 @@ skl_compute_plane_wm_params(const struct 
drm_i915_private *dev_priv,
wp->linetime_us = fixed16_to_u32_round_up(
intel_get_linetime_us(cstate));
 
+   wp->ddb_blocks = plane_id ?
+skl_ddb_entry_size(&ddb->uv_plane[pipe][plane->id]) :
+skl_ddb_entry_size(&ddb->plane[pipe][plane->id]);
+
return 0;
 }
 
 static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
const struct intel_plane_state *intel_pstate,
-   uint16_t ddb_allocation,
int level,
const struct skl_wm_params *wp,
const struct skl_wm_level *result_prev,
@@ -4674,7 +4679,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 wp->dbuf_block_size < 1) &&
 (wp->plane_bytes_per_line / wp->dbuf_block_size < 1)) {
selected_result = method2;
-   } else if (ddb_allocation >=
+   } else if (wp->ddb_blocks >=
 fixed16_to_u32_round_up(wp->plane_blocks_per_line)) {
if (INTEL_GEN(dev_priv) == 9 &&
!IS_GEMINILAKE(dev_priv))
@@ -4747,8 +4752,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
}
 
if ((level > 0 && res_lines > 31) ||
-   res_blocks >= ddb_allocation ||
-   min_disp_buf_needed >= ddb_allocation) {
+   res_blocks >= wp->ddb_blocks ||
+   min_disp_buf_needed >= wp->ddb_blocks) {
result->plane_en = false;
 
/*
@@ -4763,7 +4768,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
DRM_DEBUG_KMS("Requested display configuration exceeds 
system watermark limitations\n");
DRM_DEBUG_KMS("[PLANE:%d:%s] blocks required = %u/%u, 
lines required = %u/31\n",
  plane->base.id, plane->name,
- res_blocks, ddb_allocation, res_lines);
+ res_blocks, wp->ddb_blocks, res_lines);
return -EINVAL;
}
}
@@ -4789,26 +4794,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
 static int
 skl_compute_wm_levels(const struct drm_i915_private *dev_priv,
- struct skl_ddb_allocation *ddb,
  struct intel_crtc_state *cstate,
   

[Intel-gfx] [PATCH 11/11] drm/i915: pass dev_priv instead of cstate to skl_compute_transition_wm()

[Paulo Zanoni]

Stop passing modeset state structures to functions that should work
only with the skl_wm_params. The only use for cstate there was to
reach dev_priv, so pass it directly.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b01f3d807ff6..dac26133 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4836,13 +4836,11 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
return linetime_wm;
 }
 
-static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
+static void skl_compute_transition_wm(const struct drm_i915_private *dev_priv,
  struct skl_wm_params *wp,
  struct skl_wm_level *wm_l0,
  struct skl_wm_level *trans_wm /* out */)
 {
-   struct drm_device *dev = cstate->base.crtc->dev;
-   const struct drm_i915_private *dev_priv = to_i915(dev);
uint16_t trans_min, trans_y_tile_min;
const uint16_t trans_amount = 10; /* This is configurable amount */
uint16_t wm0_sel_res_b, trans_offset_b, res_blocks;
@@ -4941,7 +4939,7 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
return ret;
}
 
-   skl_compute_transition_wm(cstate, &wm_params, &wm->wm[0],
+   skl_compute_transition_wm(dev_priv, &wm_params, &wm->wm[0],
  &wm->trans_wm);
 
/* uv plane watermarks must also be validated for NV12/Planar */
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/11] drm/i915: simplify wm->is_planar assignment

[Paulo Zanoni]

We're currently doing it in two different ways, none of them based on
the wm_params struct. Both places are correct, so I chose to keep the
one in skl_compute_wm_levels() since it's the function that sets the
other values for the same struct. But I'm open to better suggestions
on the place to assign it.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d1dd3ae408f9..7fd344b81d66 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4832,8 +4832,7 @@ skl_compute_wm_levels(const struct drm_i915_private 
*dev_priv,
return ret;
}
 
-   if (intel_pstate->base.fb->format->format == DRM_FORMAT_NV12)
-   wm->is_planar = true;
+   wm->is_planar = wm_params->is_planar;
 
return 0;
 }
@@ -4972,8 +4971,6 @@ static int skl_build_pipe_wm(struct intel_crtc_state 
*cstate,
 
/* uv plane watermarks must also be validated for NV12/Planar */
if (wm_params.is_planar) {
-   wm->is_planar = true;
-
ret = skl_compute_plane_wm_params(dev_priv, cstate,
  intel_pstate,
  &wm_params, 1);
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 02/11] drm/i915: remove padding from struct skl_wm_level

[Paulo Zanoni]

This reduces the size of struct skl_wm_level from 6 to 4, which
reduces the size of struct skl_plane_wm from 104 to 70, which reduces
the size of struct skl_pipe_wm from 524 to 356. A reduction of 168
padding bytes per pipe. This will increase even more the next time we
bump I915_MAX_PLANES.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef037fed..3616b718b5d2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1243,9 +1243,9 @@ struct skl_ddb_values {
 };
 
 struct skl_wm_level {
-   bool plane_en;
uint16_t plane_res_b;
uint8_t plane_res_l;
+   bool plane_en;
 };
 
 /* Stores plane specific WM parameters */
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/11] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

[Paulo Zanoni]

BSpec does not show these WAs as applicable to GLK, and for CNL it
only shows them applicable for a super early pre-production stepping
we shouldn't be caring about anymore. Remove these so we can avoid
them on ICL too.

Cc: Matt Roper 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 43 ++---
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 67a4d0735291..18157c6ee126 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4696,28 +4696,31 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
 wp->plane_blocks_per_line);
 
-   /* Display WA #1125: skl,bxt,kbl,glk */
-   if (level == 0 && wp->rc_surface)
-   res_blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
+   if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
+   /* Display WA #1125: skl,bxt,kbl */
+   if (level == 0 && wp->rc_surface)
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+
+   /* Display WA #1126: skl,bxt,kbl */
+   if (level >= 1 && level <= 7) {
+   if (wp->y_tiled) {
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+   res_lines += wp->y_min_scanlines;
+   } else {
+   res_blocks++;
+   }
 
-   /* Display WA #1126: skl,bxt,kbl,glk */
-   if (level >= 1 && level <= 7) {
-   if (wp->y_tiled) {
-   res_blocks += fixed16_to_u32_round_up(
-   wp->y_tile_minimum);
-   res_lines += wp->y_min_scanlines;
-   } else {
-   res_blocks++;
+   /*
+* Make sure result blocks for higher latency levels are
+* atleast as high as level below the current level.
+* Assumption in DDB algorithm optimization for special
+* cases. Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
-
-   /*
-* Make sure result blocks for higher latency levels are atleast
-* as high as level below the current level.
-* Assumption in DDB algorithm optimization for special cases.
-* Also covers Display WA #1125 for RC.
-*/
-   if (result_prev->plane_res_b > res_blocks)
-   res_blocks = result_prev->plane_res_b;
}
 
if (INTEL_GEN(dev_priv) >= 11) {
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations

[Paulo Zanoni]

These are the new recommended values provided by our spec (18 -> 19
and 23 -> 24). It seems this should help fixing GMBUS issues. Since
we're doing pretty much the same thing for both CNP and ICP now, unify
the functions using the ICP version since it's more straightforward by
just matching the values listed in BSpec instead of recalculating
them.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h|  1 -
 drivers/gpu/drm/i915/intel_cdclk.c | 37 ++---
 2 files changed, 6 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 20785417953d..ffd564a8d339 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7832,7 +7832,6 @@ enum {
 #define  CNP_RAWCLK_DIV(div)   ((div) << 16)
 #define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
 #define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
-#define  ICP_RAWCLK_DEN(den)   ((den) << 26)
 #define  ICP_RAWCLK_NUM(num)   ((num) << 11)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 29075c763428..17d3f13d89db 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2660,48 +2660,25 @@ void intel_update_cdclk(struct drm_i915_private 
*dev_priv)
 }
 
 static int cnp_rawclk(struct drm_i915_private *dev_priv)
-{
-   u32 rawclk;
-   int divider, fraction;
-
-   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
-   /* 24 MHz */
-   divider = 24000;
-   fraction = 0;
-   } else {
-   /* 19.2 MHz */
-   divider = 19000;
-   fraction = 200;
-   }
-
-   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
-   if (fraction)
-   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
-   fraction) - 1);
-
-   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
-   return divider + fraction;
-}
-
-static int icp_rawclk(struct drm_i915_private *dev_priv)
 {
u32 rawclk;
int divider, numerator, denominator, frequency;
 
if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
frequency = 24000;
-   divider = 23;
+   divider = 24;
numerator = 0;
denominator = 0;
} else {
frequency = 19200;
-   divider = 18;
+   divider = 19;
numerator = 1;
denominator = 4;
}
 
-   rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-ICP_RAWCLK_DEN(denominator);
+   rawclk = CNP_RAWCLK_DIV(divider) | CNP_RAWCLK_FRAC(denominator);
+   if (HAS_PCH_ICP(dev_priv))
+   rawclk |= ICP_RAWCLK_NUM(numerator);
 
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return frequency;
@@ -2754,9 +2731,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_ICP(dev_priv))
-   dev_priv->rawclk_freq = icp_rawclk(dev_priv);
-   else if (HAS_PCH_CNP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/icl: enable SAGV for ICL platform

[Paulo Zanoni]

From: Mahesh Kumar 

Enable SAGV for ICL platform.

Cc: Gwan-gyeong Mun 
Reviewed-by: James Ausmus 
Reviewed-by: Paulo Zanoni 
Signed-off-by: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

I had previously blocked this patch in January:
  https://patchwork.freedesktop.org/patch/200285/

But since then the spec was fixed and now the requirements listed for
sagv on ICL are the same as for the previous platforms, so the patch
is now valid. Thanks to Gwan-gyeong Mun for re-checking that.

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7a53079f3196..b9febe1d2f6b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3613,7 +3613,7 @@ static bool
 intel_has_sagv(struct drm_i915_private *dev_priv)
 {
if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
-   IS_CANNONLAKE(dev_priv))
+   IS_CANNONLAKE(dev_priv) || IS_ICELAKE(dev_priv))
return true;
 
if (IS_SKYLAKE(dev_priv) &&
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11

[Paulo Zanoni]

Em Qua, 2018-09-05 às 16:41 -0700, Rodrigo Vivi escreveu:
> On Wed, Sep 05, 2018 at 02:32:38PM +0530, Karthik B S wrote:
> > Display Workarounds #1125 and #1126 are intended for Gen10 and
> > below platforms. These workarounds can be avoided in Gen11.
> > 
> > The result blocks for WM1-WM7 should be atleast as high as the
> > level below
> > the current level(Part of Display WA #1125). This part is
> > applicable even
> > for Gen11, so it is taken out of the condition check.
> > 
> > v2: Improved Commit Message and addresed other review
> > comments(Rodrigo).
> > 
> 
> Cc: José Roberto de Souza 
> > Signed-off-by: Karthik B S 
> 
> 
> Reviewed-by: Rodrigo Vivi 
> (but before pushing I'd like to get an ack from Jose since CI is not
> there yet with ICL)

Sorry, I didn't look at this patch earlier.

My understanding is that we also want to avoid this code in Gen10 since
only early CNL wants it, and GLK doesn't want it.

See https://patchwork.freedesktop.org/patch/254881/

> 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 37 +--
> > --
> >  1 file changed, 21 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index d99e5fa..b5db6a3 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4677,26 +4677,31 @@ static int skl_compute_plane_wm(const
> > struct drm_i915_private *dev_priv,
> > res_lines = div_round_up_fixed16(selected_result,
> >  wp-
> > >plane_blocks_per_line);
> >  
> > -   /* Display WA #1125: skl,bxt,kbl,glk */
> > -   if (level == 0 && wp->rc_surface)
> > -   res_blocks += fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > -
> > -   /* Display WA #1126: skl,bxt,kbl,glk */
> > -   if (level >= 1 && level <= 7) {
> > -   if (wp->y_tiled) {
> > +   if (INTEL_GEN(dev_priv) < 11) {
> > +   /* Display WA #1125: skl,bxt,kbl,glk */
> > +   if (level == 0 && wp->rc_surface)
> > res_blocks += fixed16_to_u32_round_up(
> > wp-
> > >y_tile_minimum);
> > -   res_lines += wp->y_min_scanlines;
> > -   } else {
> > -   res_blocks++;
> > +
> > +   /* Display WA #1126: skl,bxt,kbl,glk */
> > +   if (level >= 1 && level <= 7) {
> > +   if (wp->y_tiled) {
> > +   res_blocks +=
> > fixed16_to_u32_round_up
> > +   (wp-
> > >y_tile_minimum);
> > +   res_lines += wp->y_min_scanlines;
> > +   } else {
> > +   res_blocks++;
> > +   }
> > }
> > +   }
> >  
> > -   /*
> > -* Make sure result blocks for higher latency
> > levels are atleast
> > -* as high as level below the current level.
> > -* Assumption in DDB algorithm optimization for
> > special cases.
> > -* Also covers Display WA #1125 for RC.
> > -*/
> > +   /*
> > +* Make sure result blocks for higher latency levels are
> > atleast
> > +* as high as level below the current level.
> > +* Assumption in DDB algorithm optimization for special
> > cases.
> > +* Also covers Display WA #1125 for RC.
> > +*/
> > +   if (level >= 1 && level <= 7) {
> > if (result_prev->plane_res_b > res_blocks)
> > res_blocks = result_prev->plane_res_b;
> > }
> > -- 
> > 2.7.4
> > 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

[Paulo Zanoni]

Em Ter, 2018-10-09 às 16:55 -0700, Matt Roper escreveu:
> On Thu, Oct 04, 2018 at 04:15:55PM -0700, Paulo Zanoni wrote:
> > BSpec does not show these WAs as applicable to GLK, and for CNL it
> > only shows them applicable for a super early pre-production
> > stepping
> > we shouldn't be caring about anymore. Remove these so we can avoid
> > them on ICL too.
> > 
> > Signed-off-by: Paulo Zanoni 
> 
> From a quick grep, it looks like there's a couple other CNL A0-
> specific
> workarounds in the codebase (in the watermark code).  If we don't
> want
> to handle CNL A0 in this patch, then I think we should first land a
> patch that removes the others and updates
> intel_detect_preproduction_hw() to make it explicit that this is no
> longer a supported stepping.

This patch (and series) is potentially a "bug fix" due to changes in
real-world not-A0 hardware (although I didn't mark this one as a fix
since I doubt it will close anything in Bugzilla). The patch to remove
the implementation of WAs in CNL:A0 is not a bug fix, but a rework.
Fixes should always come before the reworks in order to facilitate
backporting efforts.

I do intend to propose patches removing the CNL A0 watermarks code
(along with other reworks I have in mind), but I wanted to sort the
bugs first.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 43 ++---
> > 
> >  1 file changed, 23 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 1392aa56a55a..910551e04d16 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4687,28 +4687,31 @@ static int skl_compute_plane_wm(const
> > struct drm_i915_private *dev_priv,
> > res_lines = div_round_up_fixed16(selected_result,
> >  wp-
> > >plane_blocks_per_line);
> >  
> > -   /* Display WA #1125: skl,bxt,kbl,glk */
> > -   if (level == 0 && wp->rc_surface)
> > -   res_blocks += fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > +   if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
> > +   /* Display WA #1125: skl,bxt,kbl */
> 
> Although the code is right, should we just write "gen9" (or
> gen9display)
> in this comment (and the one for 1126)?  That's how the bspec lists
> it
> (GEN9:All), and removes the ambiguity of whether "kbl" in this
> context
> is also supposed to cover CFL, AML, WHL (which it does).

Although that makes sense, it doesn't seem to follow the current
(undocumented?) standard we have for display WAs. I can totally do
this, but I would like some more opinions first. CC'ing the
maintainers.

Thanks for the reviews,
Paulo
> 
> 
> Matt
> 
> > +   if (level == 0 && wp->rc_surface)
> > +   res_blocks +=
> > +   fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > +
> > +   /* Display WA #1126: skl,bxt,kbl */
> > +   if (level >= 1 && level <= 7) {
> > +   if (wp->y_tiled) {
> > +   res_blocks +=
> > +   fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > +   res_lines += wp->y_min_scanlines;
> > +   } else {
> > +   res_blocks++;
> > +   }
> >  
> > -   /* Display WA #1126: skl,bxt,kbl,glk */
> > -   if (level >= 1 && level <= 7) {
> > -   if (wp->y_tiled) {
> > -   res_blocks += fixed16_to_u32_round_up(
> > -   wp-
> > >y_tile_minimum);
> > -   res_lines += wp->y_min_scanlines;
> > -   } else {
> > -   res_blocks++;
> > +   /*
> > +* Make sure result blocks for higher
> > latency levels are
> > +* atleast as high as level below the
> > current level.
> > +* Assumption in DDB algorithm
> > optimization for special
> > +* cases. Also covers Display WA #1125 for
> > RC.
> > +*/
> > +   if (result_prev->plane_res_b > res_blocks)
> > +   res_blocks = result_prev-
> > >plane_res_b;
> > }
> > -
> > -   /*
> > -* Make sure 

Re: [Intel-gfx] [PATCH] firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake.

[Paulo Zanoni]

Em Qui, 2018-10-04 às 15:36 -0700, Rodrigo Vivi escreveu:
> From: Anusha Srivatsa 
> 
> Add missing MODULE_FIRMWARE while loading DMC ICL.
> 
> v2: Add Fixes tag. (Rodrigo)
> v3: Rebase by Rodrigo after commit 7fe78985cd08 ("drm/i915/csr:
>  restructure CSR firmware definition macros")
> v4: Rodrigo fixing his own mess on commit mentioning on v3
> comment above.
> 
> Fixes: 4445930f1c4a ("firmware/dmc/icl: load v1.07 on icelake.")

Yes, please. I wasted time because I lacked this commit.

Tested-by: Paulo Zanoni 

> Cc: Rodrigo Vivi 
> Cc: Paulo Zanoni 
> Cc: Jani Nikula 
> Signed-off-by: Anusha Srivatsa 
> Reviewed-by: Rodrigo Vivi  (v2)
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_csr.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index e4e310b0ef78..fc7bd21fa586 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -37,6 +37,7 @@
>  #define ICL_CSR_PATH "i915/icl_dmc_ver1_07.bi
> n"
>  #define ICL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
>  #define ICL_CSR_MAX_FW_SIZE  0x6000
> +MODULE_FIRMWARE(ICL_CSR_PATH);
>  
>  #define CNL_CSR_PATH "i915/cnl_dmc_ver1_07.bi
> n"
>  #define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915: don't write PLANE_BUF_CFG twice every time

[Paulo Zanoni]

We were writing to PLANE_BUF_CFG(pipe, plane_id) twice for every
platform, and we were even using different values on the gen10- planar
case. The first write is useless since it just gets replaced with the
next one, so kill it.

There's a lot to improve in the DDB code, but let's start by avoiding
the double write.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 14f13a371989..53b4a9a2de69 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5040,8 +5040,6 @@ static void skl_write_plane_wm(struct intel_crtc 
*intel_crtc,
skl_write_wm_level(dev_priv, PLANE_WM_TRANS(pipe, plane_id),
   &wm->trans_wm);
 
-   skl_ddb_entry_write(dev_priv, PLANE_BUF_CFG(pipe, plane_id),
-   &ddb->plane[pipe][plane_id]);
/* FIXME: add proper NV12 support for ICL. */
if (INTEL_GEN(dev_priv) >= 11)
return skl_ddb_entry_write(dev_priv,
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/6] drm/i915: transition WMs ask for Selected Result Blocks

[Paulo Zanoni]

The transition watermarks ask for Selected Result Blocks (the real
value), not Result Blocks (the integer value). Given how ceilings are
applied in both the non-transition and the transition watermarks
calculations, we can get away with assuming that Selected Result
Blocks is actually Result Blocks minus 1 without any rounding errors.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 40ce99c455f3..14f13a371989 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4874,7 +4874,7 @@ static void skl_compute_transition_wm(struct 
intel_crtc_state *cstate,
const struct drm_i915_private *dev_priv = to_i915(dev);
uint16_t trans_min, trans_y_tile_min;
const uint16_t trans_amount = 10; /* This is configurable amount */
-   uint16_t trans_offset_b, res_blocks;
+   uint16_t wm0_sel_res_b, trans_offset_b, res_blocks;
 
if (!cstate->base.active)
goto exit;
@@ -4893,13 +4893,25 @@ static void skl_compute_transition_wm(struct 
intel_crtc_state *cstate,
 
trans_offset_b = trans_min + trans_amount;
 
+   /*
+* The spec asks for Selected Result Blocks for wm0 (the real value),
+* not Result Blocks (the integer value). Pay attention to the capital
+* letters. The value wm_l0->plane_res_b is actually Result Blocks, but
+* since Result Blocks is the ceiling of Selected Result Blocks plus 1,
+* and since we later will have to get the ceiling of the sum in the
+* transition watermarks calculation, we can just pretend Selected
+* Result Blocks is Result Blocks minus 1 and it should work for the
+* current platforms.
+*/
+   wm0_sel_res_b = wm_l0->plane_res_b - 1;
+
if (wp->y_tiled) {
trans_y_tile_min = (uint16_t) mul_round_up_u32_fixed16(2,
wp->y_tile_minimum);
-   res_blocks = max(wm_l0->plane_res_b, trans_y_tile_min) +
+   res_blocks = max(wm0_sel_res_b, trans_y_tile_min) +
trans_offset_b;
} else {
-   res_blocks = wm_l0->plane_res_b + trans_offset_b;
+   res_blocks = wm0_sel_res_b + trans_offset_b;
 
/* WA BUG:1938466 add one block for non y-tile planes */
if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/6] Watermarks small fixes/improvements

[Paulo Zanoni]

I'm investigating ICL watermarks failures and these are some of the immediate
problems I was able to find in the watermarks code. I don't think they're enough
to fix the problems our CI is able to reproduce, but I do think these changes
are worth having.

Paulo Zanoni (6):
  drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+
  drm/i915: fix the transition minimums for gen9+ watermarks
  drm/i915: fix the watermark result selection on glk/gen10+
  drm/i915: transition WMs ask for Selected Result Blocks
  drm/i915: don't write PLANE_BUF_CFG twice every time
  drm/i915: promote ddb update message to DRM_DEBUG_KMS

 drivers/gpu/drm/i915/intel_pm.c | 100 
 1 file changed, 61 insertions(+), 39 deletions(-)

-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915: fix the watermark result selection on glk/gen10+

[Paulo Zanoni]

On these platforms we're supposed to unconditonally pick the method 2
result instead of the minimum.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cab86690a0ba..40ce99c455f3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4672,15 +4672,24 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
} else {
if ((wp->cpp * cstate->base.adjusted_mode.crtc_htotal /
 wp->dbuf_block_size < 1) &&
-(wp->plane_bytes_per_line / wp->dbuf_block_size < 1))
+(wp->plane_bytes_per_line / wp->dbuf_block_size < 1)) {
selected_result = method2;
-   else if (ddb_allocation >=
-fixed16_to_u32_round_up(wp->plane_blocks_per_line))
-   selected_result = min_fixed16(method1, method2);
-   else if (latency >= wp->linetime_us)
-   selected_result = min_fixed16(method1, method2);
-   else
+   } else if (ddb_allocation >=
+fixed16_to_u32_round_up(wp->plane_blocks_per_line)) {
+   if (INTEL_GEN(dev_priv) == 9 &&
+   !IS_GEMINILAKE(dev_priv))
+   selected_result = min_fixed16(method1, method2);
+   else
+   selected_result = method2;
+   } else if (latency >= wp->linetime_us) {
+   if (INTEL_GEN(dev_priv) == 9 &&
+   !IS_GEMINILAKE(dev_priv))
+   selected_result = min_fixed16(method1, method2);
+   else
+   selected_result = method2;
+   } else {
selected_result = method1;
+   }
}
 
res_blocks = fixed16_to_u32_round_up(selected_result) + 1;
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/6] drm/i915: fix the transition minimums for gen9+ watermarks

[Paulo Zanoni]

The transition minimum is 14 blocks for gens 9 and 10, and 4 blocks
for gen 11. This minimum value is supposed to be added to the
configurable trans_amount. This matches both BSpec and additional
information provided by our HW engineers.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 910551e04d16..cab86690a0ba 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4878,8 +4878,8 @@ static void skl_compute_transition_wm(struct 
intel_crtc_state *cstate,
if (!dev_priv->ipc_enabled)
goto exit;
 
-   trans_min = 0;
-   if (INTEL_GEN(dev_priv) >= 10)
+   trans_min = 14;
+   if (INTEL_GEN(dev_priv) >= 11)
trans_min = 4;
 
trans_offset_b = trans_min + trans_amount;
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/6] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+

[Paulo Zanoni]

BSpec does not show these WAs as applicable to GLK, and for CNL it
only shows them applicable for a super early pre-production stepping
we shouldn't be caring about anymore. Remove these so we can avoid
them on ICL too.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 43 ++---
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1392aa56a55a..910551e04d16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4687,28 +4687,31 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
 wp->plane_blocks_per_line);
 
-   /* Display WA #1125: skl,bxt,kbl,glk */
-   if (level == 0 && wp->rc_surface)
-   res_blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
+   if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
+   /* Display WA #1125: skl,bxt,kbl */
+   if (level == 0 && wp->rc_surface)
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+
+   /* Display WA #1126: skl,bxt,kbl */
+   if (level >= 1 && level <= 7) {
+   if (wp->y_tiled) {
+   res_blocks +=
+   fixed16_to_u32_round_up(wp->y_tile_minimum);
+   res_lines += wp->y_min_scanlines;
+   } else {
+   res_blocks++;
+   }
 
-   /* Display WA #1126: skl,bxt,kbl,glk */
-   if (level >= 1 && level <= 7) {
-   if (wp->y_tiled) {
-   res_blocks += fixed16_to_u32_round_up(
-   wp->y_tile_minimum);
-   res_lines += wp->y_min_scanlines;
-   } else {
-   res_blocks++;
+   /*
+* Make sure result blocks for higher latency levels are
+* atleast as high as level below the current level.
+* Assumption in DDB algorithm optimization for special
+* cases. Also covers Display WA #1125 for RC.
+*/
+   if (result_prev->plane_res_b > res_blocks)
+   res_blocks = result_prev->plane_res_b;
}
-
-   /*
-* Make sure result blocks for higher latency levels are atleast
-* as high as level below the current level.
-* Assumption in DDB algorithm optimization for special cases.
-* Also covers Display WA #1125 for RC.
-*/
-   if (result_prev->plane_res_b > res_blocks)
-   res_blocks = result_prev->plane_res_b;
}
 
if (INTEL_GEN(dev_priv) >= 11) {
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915: promote ddb update message to DRM_DEBUG_KMS

[Paulo Zanoni]

This message is currently marked as DRM_DEBUG_ATOMIC. I would like it
to be DRM_DEBUG_KMS since it is more KMS than atomic, and this will
also make the message appear in the CI logs, which may or may not help
us with some FIFO underrun bugs.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 53b4a9a2de69..6cacddd16010 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5233,11 +5233,11 @@ skl_print_wm_changes(const struct drm_atomic_state 
*state)
if (skl_ddb_entry_equal(old, new))
continue;
 
-   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] ddb (%d - %d) -> (%d - 
%d)\n",
-intel_plane->base.base.id,
-intel_plane->base.name,
-old->start, old->end,
-new->start, new->end);
+   DRM_DEBUG_KMS("[PLANE:%d:%s] ddb (%d - %d) -> (%d - 
%d)\n",
+ intel_plane->base.base.id,
+ intel_plane->base.name,
+ old->start, old->end,
+ new->start, new->end);
}
}
 }
-- 
2.14.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: DRM_FORMAT_C8 is not possible with Yf tiling

[Paulo Zanoni]

Em Qui, 2018-09-27 às 17:16 +0300, Ville Syrjälä escreveu:
> On Tue, Sep 25, 2018 at 03:02:21PM -0700, Paulo Zanoni wrote:
> > Em Ter, 2018-09-25 às 15:02 +0300, Ville Syrjälä escreveu:
> > > On Mon, Sep 24, 2018 at 05:19:11PM -0700, Paulo Zanoni wrote:
> > > > Function intel_framebuffer_init() checks for the possibilities
> > > > during
> > > > framebuffer creation (addfb ioctl time). It is missing the fact
> > > > that
> > > > the indexed format is not supported with Yf tiling.
> > > > 
> > > > It is worth noticing that skl_plane_format_mod_supported()
> > > > correctly
> > > > handles for the C8/Yf combination, but this function runs
> > > > during
> > > > modeset time, so we only reject the combination later.
> > > > 
> > > > Ville recently proposed a new IGT test that only uses addfb to
> > > > assert
> > > > supported formats, so that IGT was failing. Add the check so we
> > > > get
> > > > green squares right from the start after Ville merges his test.
> > > 
> > > I have two of three (possibly) nicer ways to solve this:
> > > https://patchwork.freedesktop.org/series/39700/
> > 
> > I thought about implementing this one when looking at the code. I
> > agree
> > the duplicated checks are horrible. I thought maybe this model
> > wouldn't
> > be acceptable due to the inefficiency of always looping over
> > everything
> > vs the current linear solution.
> > 
> > I see no review comments on this series besides the vc4 patch. Did
> > you
> > get anything that's not appearing on patchwork?
> > 
> > > https://patchwork.freedesktop.org/series/39383/
> > 
> > You have blocked your own patch with your own review here.
> > 
> > > https://patchwork.freedesktop.org/series/39813/
> > 
> > Looks like there's some potential controversy to be untangled here
> > if
> > we wish to follow this route.
> > 
> > > solution 4
> > 
> > I guess it would be to simply not have the checks at all. But this
> > would be an interface change instead of just refactoring code
> > duplication.
> > 
> > 
> > > 
> > > Would be nice if someone could figure out a solution (one of
> > > those or
> > > perhaps some other solution I didn't think of) that enough people
> > > are
> > > willing to accept.
> > 
> > I could see solution 1 moving forward more easily, and even could
> > volunteer myself to review a rebased version.
> > 
> > In the meantime, we could actually review/commit this immediate fix
> > and
> > have a correct-but-not-yet-reworked codebase instead of waiting for
> > a
> > patch that has been abandoned since March. I don't think one series
> > should block the other.
> 
> Sure. Was just trying to trick someone into finishing what I started
> ;)
> 
> Patch is
> Reviewed-by: Ville Syrjälä 

Thanks a lot! Feel free to CC me on the series that kills the whole
thing, I agree it's a good thing to do.

> 
> > 
> > 
> > > 
> > > > 
> > > > Also drive-by fix the missing /* fall through */ in the chunk
> > > > we
> > > > modified by just turning it into a "break;" since IMHO breaks
> > > > are
> > > > easier to read than fall-throughs.
> > > > 
> > > > BSpec: 18565
> > > > Testcase: igt/kms_addfb_basic/expected-formats (not merged yet)
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: Paulo Zanoni 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 8 +++-
> > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index eb25037d7b38..fdff1779f778 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -14473,13 +14473,19 @@ static int
> > > > intel_framebuffer_init(struct
> > > > intel_framebuffer *intel_fb,
> > > > goto err;
> > > > }
> > > > /* fall through */
> > > > -   case I915_FORMAT_MOD_Y_TILED:
> > > > case I915_FORMAT_MOD_Yf_TILED:
> > > > +   if (mode_cmd->pixel_format == DRM_FORMAT_C8) {
> > > > +   DRM_DEBUG_KMS("Indexed format does not
> > > > support Yf tiling\n");
> > > > +   goto err;
> > > > +   }
> > > > +   /* fall through */
> > > > +   case I915_FORMAT_MOD_Y_TILED:
> > > > if (INTEL_GEN(dev_priv) < 9) {
> > > > DRM_DEBUG_KMS("Unsupported tiling
> > > > 0x%llx!\n",
> > > >   mode_cmd->modifier[0]);
> > > > goto err;
> > > > }
> > > > +   break;
> > > > case DRM_FORMAT_MOD_LINEAR:
> > > > case I915_FORMAT_MOD_X_TILED:
> > > > break;
> > > > -- 
> > > > 2.14.4
> > > 
> > > 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: make the primary plane func structs const

[Paulo Zanoni]

Em Ter, 2018-09-25 às 15:05 +0300, Ville Syrjälä escreveu:
> On Mon, Sep 24, 2018 at 05:19:12PM -0700, Paulo Zanoni wrote:
> > Because we can, the places where we use them already expect const
> > structs.
> 
> https://patchwork.freedesktop.org/series/44104/ already has the rest
> of
> the series covered. It didn't get pushed due to lack of drm-misc
> backmerge. I suppose that's no longer an issue, but now the series
> most likely needs a rebase.

Please try to move forward with what's already reviewed so we can
prevent a third person from reimplementing these improvements :).


> 
> > 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index fdff1779f778..a21ec8ae46f6 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13467,7 +13467,7 @@ static bool
> > intel_cursor_format_mod_supported(struct drm_plane *_plane,
> > format == DRM_FORMAT_ARGB;
> >  }
> >  
> > -static struct drm_plane_funcs skl_plane_funcs = {
> > +static const struct drm_plane_funcs skl_plane_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > .destroy = intel_plane_destroy,
> > @@ -13478,7 +13478,7 @@ static struct drm_plane_funcs
> > skl_plane_funcs = {
> > .format_mod_supported = skl_plane_format_mod_supported,
> >  };
> >  
> > -static struct drm_plane_funcs i965_plane_funcs = {
> > +static const struct drm_plane_funcs i965_plane_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > .destroy = intel_plane_destroy,
> > @@ -13489,7 +13489,7 @@ static struct drm_plane_funcs
> > i965_plane_funcs = {
> > .format_mod_supported = i965_plane_format_mod_supported,
> >  };
> >  
> > -static struct drm_plane_funcs i8xx_plane_funcs = {
> > +static const struct drm_plane_funcs i8xx_plane_funcs = {
> > .update_plane = drm_atomic_helper_update_plane,
> > .disable_plane = drm_atomic_helper_disable_plane,
> > .destroy = intel_plane_destroy,
> > -- 
> > 2.14.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: DRM_FORMAT_C8 is not possible with Yf tiling

[Paulo Zanoni]

Em Ter, 2018-09-25 às 15:02 +0300, Ville Syrjälä escreveu:
> On Mon, Sep 24, 2018 at 05:19:11PM -0700, Paulo Zanoni wrote:
> > Function intel_framebuffer_init() checks for the possibilities
> > during
> > framebuffer creation (addfb ioctl time). It is missing the fact
> > that
> > the indexed format is not supported with Yf tiling.
> > 
> > It is worth noticing that skl_plane_format_mod_supported()
> > correctly
> > handles for the C8/Yf combination, but this function runs during
> > modeset time, so we only reject the combination later.
> > 
> > Ville recently proposed a new IGT test that only uses addfb to
> > assert
> > supported formats, so that IGT was failing. Add the check so we get
> > green squares right from the start after Ville merges his test.
> 
> I have two of three (possibly) nicer ways to solve this:
> https://patchwork.freedesktop.org/series/39700/

I thought about implementing this one when looking at the code. I agree
the duplicated checks are horrible. I thought maybe this model wouldn't
be acceptable due to the inefficiency of always looping over everything
vs the current linear solution.

I see no review comments on this series besides the vc4 patch. Did you
get anything that's not appearing on patchwork?

> https://patchwork.freedesktop.org/series/39383/

You have blocked your own patch with your own review here.

> https://patchwork.freedesktop.org/series/39813/

Looks like there's some potential controversy to be untangled here if
we wish to follow this route.

> solution 4

I guess it would be to simply not have the checks at all. But this
would be an interface change instead of just refactoring code
duplication.


> 
> Would be nice if someone could figure out a solution (one of those or
> perhaps some other solution I didn't think of) that enough people are
> willing to accept.

I could see solution 1 moving forward more easily, and even could
volunteer myself to review a rebased version.

In the meantime, we could actually review/commit this immediate fix and
have a correct-but-not-yet-reworked codebase instead of waiting for a
patch that has been abandoned since March. I don't think one series
should block the other.


> 
> > 
> > Also drive-by fix the missing /* fall through */ in the chunk we
> > modified by just turning it into a "break;" since IMHO breaks are
> > easier to read than fall-throughs.
> > 
> > BSpec: 18565
> > Testcase: igt/kms_addfb_basic/expected-formats (not merged yet)
> > Cc: Ville Syrjälä 
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index eb25037d7b38..fdff1779f778 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14473,13 +14473,19 @@ static int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > goto err;
> > }
> > /* fall through */
> > -   case I915_FORMAT_MOD_Y_TILED:
> > case I915_FORMAT_MOD_Yf_TILED:
> > +   if (mode_cmd->pixel_format == DRM_FORMAT_C8) {
> > +   DRM_DEBUG_KMS("Indexed format does not
> > support Yf tiling\n");
> > +   goto err;
> > +   }
> > +   /* fall through */
> > +   case I915_FORMAT_MOD_Y_TILED:
> > if (INTEL_GEN(dev_priv) < 9) {
> > DRM_DEBUG_KMS("Unsupported tiling
> > 0x%llx!\n",
> >   mode_cmd->modifier[0]);
> > goto err;
> > }
> > +   break;
> > case DRM_FORMAT_MOD_LINEAR:
> > case I915_FORMAT_MOD_X_TILED:
> > break;
> > -- 
> > 2.14.4
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx