Re: [Intel-gfx] [PATCH] drm/i915/psr : Add psr1 live status

[vathsala nagaraju]

On Wednesday 25 April 2018 06:26 AM, Dhinakaran Pandiyan wrote:



On Fri, 2018-04-20 at 17:14 +, Souza, Jose wrote:

On Fri, 2018-04-20 at 15:06 +0530, vathsala nagaraju wrote:

From: Vathsala Nagaraju 

Prints live state of psr1.Extending the existing
PSR2 live state function to cover psr1.

Tested on KBL with psr2 and psr1 panel.

Cc: Rodrigo Vivi 
Cc: Dhinakaran Pandiyan 

Signed-off-by: Vathsala Nagaraju 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 68 ---
--
  drivers/gpu/drm/i915/i915_reg.h |  1 +
  2 files changed, 45 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e0274f4..3056f04 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2580,25 +2580,42 @@ static int i915_guc_log_relay_release(struct
inode *inode, struct file *file)
.release = i915_guc_log_relay_release,
  };
  
-static const char *psr2_live_status(u32 val)

-{
-   static const char * const live_status[] = {
-   "IDLE",
-   "CAPTURE",
-   "CAPTURE_FS",
-   "SLEEP",
-   "BUFON_FW",
-   "ML_UP",
-   "SU_STANDBY",
-   "FAST_SLEEP",
-   "DEEP_SLEEP",
-   "BUF_ON",
-   "TG_ON"
-   };
-
-   val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
EDP_PSR2_STATUS_STATE_SHIFT;
-   if (val < ARRAY_SIZE(live_status))
-   return live_status[val];
+static const char *psr_live_status(bool is_psr2_enabled, u32 val)
+{
+   if (is_psr2_enabled) {
+   static const char * const live_status[] = {
+   "IDLE",
+   "CAPTURE",
+   "CAPTURE_FS",
+   "SLEEP",
+   "BUFON_FW",
+   "ML_UP",
+   "SU_STANDBY",
+   "FAST_SLEEP",
+   "DEEP_SLEEP",
+   "BUF_ON",
+   "TG_ON"
+   };
+   val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
+   EDP_PSR2_STATUS_STATE_SHIFT;
+   if (val < ARRAY_SIZE(live_status))
+   return live_status[val];
+   } else {
+   static const char * const live_status[] = {
+   "IDLE",
+   "SRDONACK",
+   "SRDENT",
+   "BUFOFF",
+   "BUFON",
+   "AUXACK",
+   "SRDOFFACK",
+   "SRDENT_ON",
+   };
+   val = (val & EDP_PSR_STATUS_STATE_MASK) >>
+   EDP_PSR_STATUS_STATE_SHIFT;
+   if (val < ARRAY_SIZE(live_status))
+   return live_status[val];
+   }
  
  	return "unknown";

  }
@@ -2611,6 +2628,7 @@ static int i915_edp_psr_status(struct seq_file
*m, void *data)
enum pipe pipe;
bool enabled = false;
bool sink_support;
+   u32 psr_status;
  
  	if (!HAS_PSR(dev_priv))

return -ENODEV;
@@ -2678,12 +2696,14 @@ static int i915_edp_psr_status(struct
seq_file *m, void *data)
  
  		seq_printf(m, "Performance_Counter: %u\n", psrperf);

}
-   if (dev_priv->psr.psr2_enabled) {
-   u32 psr2 = I915_READ(EDP_PSR2_STATUS);
  
-		seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",

-  psr2, psr2_live_status(psr2));
-   }
+   psr_status = (dev_priv->psr.psr2_enabled) ?
I915_READ(EDP_PSR2_STATUS) :
+   I915_READ(EDP_PS
R_STATUS);

Maybe move the read of the PSR or PSR2 status to inside of
psr_live_status()
We are printing psr_status  and it's live status[ additional debug 
information] ,
reading the psr_status here and only getting live status from 
psr_live_status function.


I am thinking we could reduce some clutter by changing both the status
functions to have this signature.


static void psr_source_status(dev_priv, m)
{

}

static void psr_sink_status(dev_priv, m)
{

}


Sure , we can change. Will send the v2 version.



Other than that looks good to me.


+   seq_printf(m, "EDP_PSR%s_STATUS: %x [%s]\n",

^source_status or whatever the correct parallel to sink 
status that
Jose is using.



+ dev_priv->psr.psr2_enabled ? "2" : "1",
+ psr_status,
+ psr_live_status(dev_priv->psr.psr2_enabled,
psr_status));
+
mutex_unlock(_priv->psr.lock);
  
  	intel_runtime_pm_put(dev_priv);

diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index fb10602..c9598b4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ 

[Intel-gfx] [drm-intel:topic/core-for-CI 9/9] backtracetest.c:undefined reference to `save_stack_trace'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head:   1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects: 
capture stack traces at _init() time
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   kernel/backtracetest.o: In function `backtrace_regression_test':
>> backtracetest.c:(.text+0xd8): undefined reference to `save_stack_trace'
   mm/slub.o: In function `set_track':
   slub.c:(.text+0x12d2): undefined reference to `save_stack_trace'
   fs/btrfs/ref-verify.o: In function `btrfs_ref_tree_mod':
>> ref-verify.c:(.text+0x92e): undefined reference to `save_stack_trace'
   lib/debugobjects.o: In function `save_stack.isra.0':
   debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915: Rework "Potential atomic update error" to handle PSR exit

[Tarun Vyas]

On Thu, Apr 26, 2018 at 02:39:04PM -0700, Tarun Vyas wrote:
> On Thu, Apr 26, 2018 at 10:47:40AM -0700, Dhinakaran Pandiyan wrote:
> > 
> > 
> > 
> > On Thu, 2018-04-26 at 16:41 +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> > > > From: Tarun 
> > > > 
> > > > The Display scanline counter freezes on PSR entry. Inside
> > > > intel_pipe_update_start, once Vblank interrupts are enabled, we start
> > > > exiting PSR, but by the time the scanline counter is read, we may not
> > > > have completely exited PSR which leads us to schedule out and check back
> > > > later.
> > > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but
> > > > lags w.r.t core kernel code, hot plugging an external display triggers
> > > > tons of "potential atomic update errors" in the dmesg, on *pipe A*. A
> > > > closer analysis reveals that we try to read the scanline 3 times and
> > > > eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL 
> > > > stuck @
> > > > 1599.
> > > > This issue is not seen on upstream kernels, b/c for *some* reason we
> > > > loop inside intel_pipe_update start for ~2+ msec which in this case is
> > > > more than enough to exit PSR fully, hence an *unstuck* PIPEDSL counter,
> > > > hence no error. On the other hand, the ChromeOS kernel spends ~1.1 msec
> > > > looping inside intel_pipe_update_start and hence errors out b/c the
> > > > source is still in PSR.
> > > > 
> > > > If PSR is enabled, then we should *wait* for  the PSR
> > > > state to move to IDLE before re-reading the PIPEDSL so as to avoid bogus
> > > > and annoying "potential atomic update error" messages.
> > > > 
> > > > P.S: This scenario applies to a configuration with an additional pipe,
> > > > as of now.
> > > > 
> > 
> > Ville, 
> > 
> > Any idea what could be the reason the warnings start appearing when an
> > external display is connected? We couldn't come up with an explanation.
> > 
> Another source of confusion for me is that on the upstream kernels, it 
> *appears* to take more time for us to get *re-scheduled* after we call 
> schedule_timeout(). So with ~2+msec spent in the loop, it seems to be not 
> working as intended b/c we end up spending a lot more time in the loop, which 
> in turn contributes to this issue not being seen on upstream kernels.
> > 
> > > > Signed-off-by: Tarun 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_sprite.c | 19 +++
> > > >  1 file changed, 15 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > > > b/drivers/gpu/drm/i915/intel_sprite.c
> > > > index aa1dfaa692b9..77dd3b936131 100644
> > > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > > @@ -92,11 +92,13 @@ void intel_pipe_update_start(const struct 
> > > > intel_crtc_state *new_crtc_state)
> > > > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > const struct drm_display_mode *adjusted_mode = 
> > > > _crtc_state->base.adjusted_mode;
> > > > long timeout = msecs_to_jiffies_timeout(1);
> > > > -   int scanline, min, max, vblank_start;
> > > > +   int scanline, min, max, vblank_start, old_scanline, 
> > > > new_scanline;
> > > > +   bool retried = false;
> > > > wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> > > > bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
> > > > IS_CHERRYVIEW(dev_priv)) &&
> > > > intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> > > > DEFINE_WAIT(wait);
> > > > +   old_scanline = new_scanline = -1;
> > > >  
> > > > vblank_start = adjusted_mode->crtc_vblank_start;
> > > > if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> > > > @@ -126,15 +128,24 @@ void intel_pipe_update_start(const struct 
> > > > intel_crtc_state *new_crtc_state)
> > > >  * read the scanline.
> > > >  */
> > > > prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
> > > > -
> > > > +retry:
> > > > scanline = intel_get_crtc_scanline(crtc);
> > > > +   old_scanline = new_scanline, new_scanline = scanline;
> > > > +
> > > > if (scanline < min || scanline > max)
> > > > break;
> > > >  
> > > > if (timeout <= 0) {
> > > > -   DRM_ERROR("Potential atomic update failure on 
> > > > pipe %c\n",
> > > > +   if(!i915.enable_psr || retried) {
> > 
> > You could use the CAN_PSR() macro that checks for source and sink
> > support.
> > 
> Will do.
> > > > +   DRM_ERROR("Potential atomic update 
> > > > failure on pipe %c\n",
> > > >   pipe_name(crtc->pipe));
> > > > -   break;
> > > > +   break;
> > > > + 

[Intel-gfx] [drm-intel:topic/core-for-CI 9/9] slub.c:undefined reference to `save_stack_trace'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head:   1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects: 
capture stack traces at _init() time
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   mm/slub.o: In function `set_track':
>> slub.c:(.text+0x12d2): undefined reference to `save_stack_trace'
   lib/debugobjects.o: In function `save_stack.isra.0':
>> debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915/psr/skl+: Print information about what caused a PSR exit

[Rodrigo Vivi]

On Wed, Apr 25, 2018 at 02:53:25PM -0700, Rodrigo Vivi wrote:
> On Wed, Apr 25, 2018 at 02:47:35PM -0700, Souza, Jose wrote:
> > On Wed, 2018-04-25 at 14:40 -0700, Rodrigo Vivi wrote:
> > > On Wed, Apr 25, 2018 at 02:23:32PM -0700, José Roberto de Souza
> > > wrote:
> > > > This will be helpful to debug what hardware is actually tracking
> > > > and causing PSR to exit.
> > > > 
> > > > BSpec: 7721
> > > > 
> > > > v4:
> > > > - Using _MMIO_TRANS2() in PSR_EVENT
> > > > - Cleaning events before printing
> > > > 
> > > > Signed-off-by: José Roberto de Souza 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Rodrigo Vivi 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_reg.h  | 23 
> > > >  drivers/gpu/drm/i915/intel_psr.c | 45
> > > > 
> > > >  2 files changed, 68 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > index 2dad655a710c..391825ae2361 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -4095,6 +4095,29 @@ enum {
> > > >  #define   EDP_PSR2_IDLE_FRAME_MASK 0xf
> > > >  #define   EDP_PSR2_IDLE_FRAME_SHIFT0
> > > >  
> > > > +#define _PSR_EVENT_TRANS_A 0x60848
> > > > +#define _PSR_EVENT_TRANS_B 0x61848
> > > > +#define _PSR_EVENT_TRANS_C 0x62848
> > > > +#define _PSR_EVENT_TRANS_D 0x63848
> > > > +#define _PSR_EVENT_TRANS_EDP   0x6F848
> > > > +#define PSR_EVENT(trans)   _MMIO_TRANS2(trans
> > > > , _PSR_EVENT_TRANS_A)
> > > > +#define  PSR_EVENT_PSR2_WD_TIMER_EXPIRE(1 << 17)
> > > > +#define  PSR_EVENT_PSR2_DISABLED   (1 << 16)
> > > > +#define  PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN  (1 << 15)
> > > > +#define  PSR_EVENT_SU_CRC_FIFO_UNDERRUN(1 << 14)
> > > > +#define  PSR_EVENT_GRAPHICS_RESET  (1 << 12)
> > > > +#define  PSR_EVENT_PCH_INTERRUPT   (1 << 11)
> > > > +#define  PSR_EVENT_MEMORY_UP   (1 << 10)
> > > > +#define  PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
> > > > +#define  PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
> > > > +#define  PSR_EVENT_PIPE_REGISTERS_UPDATE   (1 << 6)
> > > > +#define  PSR_EVENT_REGISTER_UPDATE (1 << 5)
> > > > +#define  PSR_EVENT_HDCP_ENABLE (1 << 4)
> > > > +#define  PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
> > > > +#define  PSR_EVENT_VBI_ENABLE  (1 << 2)
> > > > +#define  PSR_EVENT_LPSP_MODE_EXIT  (1 << 1)
> > > > +#define  PSR_EVENT_PSR_DISABLE (1 << 0)
> > > > +
> > > >  #define EDP_PSR2_STATUS_MMIO(0x6f940)
> > > >  #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> > > >  #define EDP_PSR2_STATUS_STATE_SHIFT28
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index e35a3b94fa69..c8d5cdce544f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -125,6 +125,43 @@ void intel_psr_irq_control(struct
> > > > drm_i915_private *dev_priv, bool debug)
> > > > I915_WRITE(EDP_PSR_IMR, ~mask);
> > > >  }
> > > >  
> > > > +static void psr_event_print(u32 val, bool psr2_enabled)
> > > > +{
> > > > +   DRM_DEBUG_KMS("PSR exit events: 0x%x\n", val);
> > > > +   if (val & PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > > > +   DRM_DEBUG_KMS("\tPSR2 watchdog timer expired\n");
> > > > +   if ((val & PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > > 
> > > I'm not sure if we should add this extra psr2_enable check here.
> > > Probably better to just print the bit reference and move one.
> > > 
> > > otherwise we might have the risk of having a message
> > > "PSR exit events:"
> > > followed by nothing below it
> > 
> > I'm okay with this too but I think is not necessary have 'PSR2
> > disabled' printed everytime when PSR is enabled.
> 
> oh! I see your point now...
> Makes sense to minimize this noise, and let's hope we
> don't face the empty case.
> 
> > 
> > > 
> > > > +   DRM_DEBUG_KMS("\tPSR2 disabled\n");
> > > > +   if (val & PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > > > +   DRM_DEBUG_KMS("\tSU dirty FIFO underrun\n");
> > > > +   if (val & PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > > > +   DRM_DEBUG_KMS("\tSU CRC FIFO underrun\n");
> > > > +   if (val & PSR_EVENT_GRAPHICS_RESET)
> > > > +   DRM_DEBUG_KMS("\tGraphics reset\n");
> > > > +   if (val & PSR_EVENT_PCH_INTERRUPT)
> > > > +   DRM_DEBUG_KMS("\tPCH interrupt\n");
> > > > +   if (val & PSR_EVENT_MEMORY_UP)
> > > > +   DRM_DEBUG_KMS("\tMemory up\n");
> > > > +   if (val & PSR_EVENT_FRONT_BUFFER_MODIFY)
> > > > +   

Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/dp: Move code to check if aux ch is busy to a function

[Dhinakaran Pandiyan]

On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> This reduces the spaghetti that intel_dp_aux_xfer().
> 
> Moved doing less changes possible here, improvements to the new
> function in further patch.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> ---
> 
> New patch in this series.
> 
>  drivers/gpu/drm/i915/intel_dp.c | 52 +
>  1 file changed, 34 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 701963a192ee..a11465c62950 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1062,6 +1062,38 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
> *intel_dp,
>  DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
>  }
>  
> +static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> + i915_reg_t ch_ctl;
> + uint32_t status;
> + int try;
> +
> + ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> +
> + for (try = 0; try < 3; try++) {
> + status = I915_READ_NOTRACE(ch_ctl);
> + if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
> + break;

Did you mean to return false here?

Anyway, this code here looks very similar to intel_dp_aux_wait_done().
Might be worth checking if it can be reused.

> + msleep(1);
> + }
> +
> + if (try == 3) {
> + static u32 last_status = -1;
> + const u32 status = I915_READ(ch_ctl);
> +
> + if (status != last_status) {
> + WARN(1, "dp_aux_ch not started status 0x%08x\n",
> +  status);
> + last_status = status;
> + }
> + }
> +
> + return true;
> +}
> +
>  static int
>  intel_dp_aux_xfer(struct intel_dp *intel_dp,
> const uint8_t *send, int send_bytes,
> @@ -1074,7 +1106,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   i915_reg_t ch_ctl, ch_data[5];
>   uint32_t aux_clock_divider;
>   int i, ret, recv_bytes;
> - uint32_t status;
> + uint32_t status = 0;
>   int try, clock = 0;
>   bool has_aux_irq = HAS_AUX_IRQ(dev_priv);
>   bool vdd;
> @@ -1102,23 +1134,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   intel_dp_check_edp(intel_dp);
>  
>   /* Try to wait for any previous AUX channel activity */
> - for (try = 0; try < 3; try++) {
> - status = I915_READ_NOTRACE(ch_ctl);
> - if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
> - break;
> - msleep(1);
> - }
> -
> - if (try == 3) {
> - static u32 last_status = -1;
> - const u32 status = I915_READ(ch_ctl);
> -
> - if (status != last_status) {
> - WARN(1, "dp_aux_ch not started status 0x%08x\n",
> -  status);
> - last_status = status;
> - }
> -
> + if (intel_dp_aux_is_busy(intel_dp)) {
>   ret = -EBUSY;
>   goto out;
>   }

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

Re: [Intel-gfx] [PATCH v2 5/9] drm/i915/psr: Handle PSR RFB storage error

[Dhinakaran Pandiyan]

On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> Sink will interrupt source when it have any problem saving or reading
> the remote frame buffer.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> ---
> 
> Changes from v1:
> - printing a debug message when sink assert a error
> 
>  drivers/gpu/drm/i915/intel_psr.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 4cb27faab707..558b08a43f9e 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -1156,6 +1156,18 @@ void intel_psr_hpd_short_pulse_handle(struct intel_dp 
> *intel_dp)
>   intel_psr_exit(dev_priv);
>   }
>  
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_ERROR_STATUS, ) != 1) {
> + DRM_DEBUG_KMS("PSR_ERROR_STATUS read failed\n");
> + goto dpcd_error;
> + }
> +
> + if (val & DP_PSR_RFB_STORAGE_ERROR) {
> + DRM_DEBUG_KMS("PSR RFB storage error, exiting PSR\n");
> + intel_psr_exit(dev_priv);

What do we achieve with an exit? Resetting PSR? I don't think that's
enough if the sink has storage errors. I think we should just disable
PSR here too.

> + }
> + /* clear status register */
> + drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);

So the other two errors are not handled, silently clearing them isn't
right. How about at least printing a debug with the read value and
saying the error wasn't handled?

> +
>   /* TODO: handle other PSR/PSR2 errors */
>  dpcd_error:
>   intel_psr_schedule_activate_work(dev_priv);

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

Re: [Intel-gfx] [PATCH v2 4/9] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink

[Dhinakaran Pandiyan]

On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote:
> eDP spec states that sink device will do a short pulse in HPD
> line when there is a PSR/PSR2 error that needs to be handled by
> source, this is handling the first and most simples error:
> DP_PSR_SINK_INTERNAL_ERROR.
> 
> Signed-off-by: José Roberto de Souza 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> ---
> 
> Changes from v1:
> - printing a debug message when sink assert a error
> 
>  drivers/gpu/drm/i915/intel_dp.c  |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 48 +---
>  3 files changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..701963a192ee 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4462,6 +4462,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>   if (intel_dp_needs_link_retrain(intel_dp))
>   return false;
>  
> + intel_psr_hpd_short_pulse_handle(intel_dp);
 intel_psr_short_pulse() should be sufficient.

> +
>   if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
>   DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
>   /* Send a Hotplug Uevent to userspace to start modeset */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5bd2263407b2..b79e15ecd052 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1901,6 +1901,7 @@ void intel_psr_single_frame_update(struct 
> drm_i915_private *dev_priv,
>  unsigned frontbuffer_bits);
>  void intel_psr_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state);
> +void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp);
>  
>  /* intel_runtime_pm.c */
>  int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 934498505356..4cb27faab707 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -996,6 +996,15 @@ void intel_psr_invalidate(struct drm_i915_private 
> *dev_priv,
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> +static void intel_psr_schedule_activate_work(struct drm_i915_private 
> *dev_priv)
> +{
> + if (dev_priv->psr.active || dev_priv->psr.busy_frontbuffer_bits
> + || work_busy(_priv->psr.work.work))
> + return;
> +
> + schedule_delayed_work(_priv->psr.work, msecs_to_jiffies(100));
> +}
> +
>  /**
>   * intel_psr_flush - Flush PSR
>   * @dev_priv: i915 device
> @@ -1052,10 +1061,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   }
>   }
>  
> - if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> - if (!work_busy(_priv->psr.work.work))
> - schedule_delayed_work(_priv->psr.work,
> -   msecs_to_jiffies(100));
> + intel_psr_schedule_activate_work(dev_priv);
> +
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> @@ -1122,3 +1129,36 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
>   dev_priv->psr.exit = hsw_psr_exit;
>   }
>  }
> +
> +void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct i915_psr *psr = _priv->psr;
> + uint8_t val;
> +
> + if (!HAS_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
> + return;
> +
> + mutex_lock(>lock);
> +
> + if (psr->enabled != intel_dp)
> + goto not_enabled;
> +
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, ) != 1) {
> + DRM_DEBUG_KMS("PSR_STATUS read failed\n");

Since we can't handle the irq without reading the dpcd and the irq is
potentially an error condition, I think this should be DRM_ERROR.


> + goto dpcd_error;
> + }
> +
> + if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) {
> + DRM_DEBUG_KMS("PSR sink internal error, exiting PSR\n");
> + intel_psr_exit(dev_priv);

Shouldn't this be disabling PSR? Exit will allow for re-activation
immediately. An unknown error in the sink IMO should disable PSR for
good.

> + }
> +
> + /* TODO: handle other PSR/PSR2 errors */
> +dpcd_error:
> + intel_psr_schedule_activate_work(dev_priv);

Why? There is no intel_psr_exit() before the goto.


> +not_enabled:
> + mutex_unlock(>lock);
> +}

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH] drm/dp: Rename the edp_sdp_header as dp_sdp_header

[Manasi Navare]

No functional changes in this patch.

The SDP Header is a generic header for secondary data packets for
both eDP and DP so call it dp_sdp_header. This header gets used for
different SDP types already defined.
Also header bytes 2 and 3 are secondary data packet specific header bytes.
So change the comment to indicate the same.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Manasi Navare 
---
 include/drm/drm_dp_helper.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 91c9bcd..2d55036 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -977,18 +977,18 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw);
 #define DP_SDP_VSC_EXT_CEA 0x21 /* DP 1.4 */
 /* 0x80+ CEA-861 infoframe types */
 
-struct edp_sdp_header {
+struct dp_sdp_header {
u8 HB0; /* Secondary Data Packet ID */
u8 HB1; /* Secondary Data Packet Type */
-   u8 HB2; /* 7:5 reserved, 4:0 revision number */
-   u8 HB3; /* 7:5 reserved, 4:0 number of valid data bytes */
+   u8 HB2; /* Secondary Data Packet Specific header, Byte 0 */
+   u8 HB3; /* Secondary Data packet Specific header, Byte 1 */
 } __packed;
 
 #define EDP_SDP_HEADER_REVISION_MASK   0x1F
 #define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F
 
 struct edp_vsc_psr {
-   struct edp_sdp_header sdp_header;
+   struct dp_sdp_header sdp_header;
u8 DB0; /* Stereo Interface */
u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
-- 
2.7.4

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

[Intel-gfx] [PATCH 6/7] drm/i915: Split i915_gem_timeline into individual timelines

[Chris Wilson]

We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.

By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.

v2: Tweak wait_for_idle to stop the compiling thinking that ret may be
uninitialised.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_gem.c   | 129 +---
 drivers/gpu/drm/i915/i915_gem_context.c   |  49 ++---
 drivers/gpu/drm/i915/i915_gem_context.h   |   2 -
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   3 +-
 drivers/gpu/drm/i915/i915_gem_timeline.c  | 198 --
 drivers/gpu/drm/i915/i915_gpu_error.c |   4 +-
 drivers/gpu/drm/i915/i915_perf.c  |  10 +-
 drivers/gpu/drm/i915/i915_request.c   |  68 +++---
 drivers/gpu/drm/i915/i915_request.h   |   3 +-
 drivers/gpu/drm/i915/i915_timeline.c  | 105 ++
 .../{i915_gem_timeline.h => i915_timeline.h}  |  67 +++---
 drivers/gpu/drm/i915/intel_engine_cs.c|  27 ++-
 drivers/gpu/drm/i915/intel_guc_submission.c   |   4 +-
 drivers/gpu/drm/i915/intel_lrc.c  |  48 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  25 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  11 +-
 .../{i915_gem_timeline.c => i915_timeline.c}  |  94 +++--
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  32 ++-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  10 +-
 .../gpu/drm/i915/selftests/mock_timeline.c|  45 ++--
 .../gpu/drm/i915/selftests/mock_timeline.h|  28 +--
 23 files changed, 398 insertions(+), 570 deletions(-)
 delete mode 100644 drivers/gpu/drm/i915/i915_gem_timeline.c
 create mode 100644 drivers/gpu/drm/i915/i915_timeline.c
 rename drivers/gpu/drm/i915/{i915_gem_timeline.h => i915_timeline.h} (68%)
 rename drivers/gpu/drm/i915/selftests/{i915_gem_timeline.c => i915_timeline.c} 
(70%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9bee52a949a9..120db21fcd50 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -67,11 +67,11 @@ i915-y += i915_cmd_parser.o \
  i915_gem_shrinker.o \
  i915_gem_stolen.o \
  i915_gem_tiling.o \
- i915_gem_timeline.o \
  i915_gem_userptr.o \
  i915_gemfs.o \
  i915_query.o \
  i915_request.o \
+ i915_timeline.o \
  i915_trace_points.o \
  i915_vma.o \
  intel_breadcrumbs.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b9bd8328f501..dab15b6abc3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,10 +72,10 @@
 #include "i915_gem_fence_reg.h"
 #include "i915_gem_object.h"
 #include "i915_gem_gtt.h"
-#include "i915_gem_timeline.h"
 #include "i915_gpu_error.h"
 #include "i915_request.h"
 #include "i915_scheduler.h"
+#include "i915_timeline.h"
 #include "i915_vma.h"
 
 #include "intel_gvt.h"
@@ -2058,8 +2058,6 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct i915_gem_timeline execution_timeline;
-   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
 
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 438a2fc5bba0..484354f25f98 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -162,7 +162,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
synchronize_irq(i915->drm.irq);
 
intel_engines_park(i915);
-   i915_gem_timelines_park(i915);
+   i915_timelines_park(i915);
 
i915_pmu_gt_parked(i915);
 
@@ -2977,8 +2977,8 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine)
 * extra delay for a recent interrupt is pointless. Hence, we do
 * not need an engine->irq_seqno_barrier() before the seqno reads.
 */
-   spin_lock_irqsave(>timeline->lock, flags);
-   list_for_each_entry(request, >timeline->requests, link) {
+   spin_lock_irqsave(>timeline.lock, flags);
+   list_for_each_entry(request, >timeline.requests, link) {
if (__i915_request_completed(request, request->global_seqno))
  

[Intel-gfx] [PATCH 5/7] drm/i915: Move timeline from GTT to ring

[Chris Wilson]

In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands inside the ringbuffer. This timeline is one that
maps to userspace's expectations when submitting requests (i.e. given the
same context, batch A is executed before batch B). As the rings's
timelines map to userspace and the GTT timeline an implementation
detail, move the timeline from the GTT into the ring itself (per-context
in logical-ring-contexts/execlists, or a global per-engine timeline for
the shared ringbuffers in legacy submission.

The two timelines are still assumed to be equivalent at the moment (no
migrating requests between engines yet) and so we can simply move from
one to the other without adding extra ordering.

v2: Reinforce that one isn't allowed to mix the engine execution
timeline with the client timeline from userspace (on the ring).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   | 13 +
 drivers/gpu/drm/i915/i915_gem.c   |  9 ++--
 drivers/gpu/drm/i915/i915_gem_context.c   | 15 +-
 drivers/gpu/drm/i915/i915_gem_context.h   |  2 +
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  3 --
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  1 -
 drivers/gpu/drm/i915/i915_gem_timeline.c  | 54 +--
 drivers/gpu/drm/i915/i915_gem_timeline.h  |  4 ++
 drivers/gpu/drm/i915/i915_request.c   | 13 +++--
 drivers/gpu/drm/i915/intel_engine_cs.c|  3 +-
 drivers/gpu/drm/i915/intel_lrc.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 10 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  5 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  3 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  4 +-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 -
 16 files changed, 101 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54351cace362..b9bd8328f501 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,7 +2058,8 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct i915_gem_timeline global_timeline;
+   struct i915_gem_timeline execution_timeline;
+   struct i915_gem_timeline legacy_timeline;
struct list_head timelines;
 
struct list_head active_rings;
@@ -3234,16 +3235,6 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
-static inline struct intel_timeline *
-i915_gem_context_lookup_timeline(struct i915_gem_context *ctx,
-struct intel_engine_cs *engine)
-{
-   struct i915_address_space *vm;
-
-   vm = ctx->ppgtt ? >ppgtt->base : >i915->ggtt.base;
-   return >timeline.engine[engine->id];
-}
-
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
 int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fa1d94a4eb5f..438a2fc5bba0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,10 +3110,10 @@ static void engine_skip_context(struct i915_request 
*request)
 {
struct intel_engine_cs *engine = request->engine;
struct i915_gem_context *hung_ctx = request->ctx;
-   struct intel_timeline *timeline;
+   struct intel_timeline *timeline = request->timeline;
unsigned long flags;
 
-   timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
+   GEM_BUG_ON(timeline == engine->timeline);
 
spin_lock_irqsave(>timeline->lock, flags);
spin_lock(>lock);
@@ -3782,7 +3782,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915, 
unsigned int flags)
 
ret = wait_for_engines(i915);
} else {
-   ret = wait_for_timeline(>gt.global_timeline, flags);
+   ret = wait_for_timeline(>gt.execution_timeline, flags);
}
 
return ret;
@@ -5652,7 +5652,8 @@ void i915_gem_cleanup_early(struct drm_i915_private 
*dev_priv)
WARN_ON(dev_priv->mm.object_count);
 
mutex_lock(_priv->drm.struct_mutex);
-   i915_gem_timeline_fini(_priv->gt.global_timeline);
+   i915_gem_timeline_fini(_priv->gt.legacy_timeline);
+   i915_gem_timeline_fini(_priv->gt.execution_timeline);
WARN_ON(!list_empty(_priv->gt.timelines));
mutex_unlock(_priv->drm.struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 

[Intel-gfx] [PATCH 4/7] drm/i915: Only track live rings for retiring

[Chris Wilson]

We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.

v2: s/live/active/ for consistency with gt.active_requests

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c  |  6 --
 drivers/gpu/drm/i915/i915_request.c  | 10 --
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  4 
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  2 +-
 drivers/gpu/drm/i915/selftests/mock_engine.c |  4 
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  5 +++--
 7 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1837c01d44d0..54351cace362 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2060,7 +2060,8 @@ struct drm_i915_private {
 
struct i915_gem_timeline global_timeline;
struct list_head timelines;
-   struct list_head rings;
+
+   struct list_head active_rings;
u32 active_requests;
u32 request_serial;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f0644d1fbd75..fa1d94a4eb5f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -141,6 +141,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
 {
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(i915->gt.active_requests);
+   GEM_BUG_ON(!list_empty(>gt.active_rings));
 
if (!i915->gt.awake)
return I915_EPOCH_INVALID;
@@ -5599,9 +5600,10 @@ int i915_gem_init_early(struct drm_i915_private 
*dev_priv)
if (!dev_priv->priorities)
goto err_dependencies;
 
-   mutex_lock(_priv->drm.struct_mutex);
-   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
+   INIT_LIST_HEAD(_priv->gt.active_rings);
+
+   mutex_lock(_priv->drm.struct_mutex);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index e6535255d445..c8fc4b323e62 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -322,6 +322,7 @@ static void advance_ring(struct i915_request *request)
 * noops - they are safe to be replayed on a reset.
 */
tail = READ_ONCE(request->tail);
+   list_del(>active_link);
} else {
tail = request->postfix;
}
@@ -1096,6 +1097,8 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
i915_gem_active_set(>last_request, request);
 
list_add_tail(>ring_link, >request_list);
+   if (list_is_first(>ring_link, >request_list))
+   list_add(>active_link, >i915->gt.active_rings);
request->emitted_jiffies = jiffies;
 
/*
@@ -1418,14 +1421,17 @@ static void ring_retire_requests(struct intel_ring 
*ring)
 
 void i915_retire_requests(struct drm_i915_private *i915)
 {
-   struct intel_ring *ring, *next;
+   struct intel_ring *ring, *tmp;
 
lockdep_assert_held(>drm.struct_mutex);
 
if (!i915->gt.active_requests)
return;
 
-   list_for_each_entry_safe(ring, next, >gt.rings, link)
+   /* An outstanding request must be on a still active ring somewhere */
+   GEM_BUG_ON(list_empty(>gt.active_rings));
+
+   list_for_each_entry_safe(ring, tmp, >gt.active_rings, active_link)
ring_retire_requests(ring);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ae8958007df5..007449cfa22b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1150,8 +1150,6 @@ intel_engine_create_ring(struct intel_engine_cs *engine, 
int size)
}
ring->vma = vma;
 
-   list_add(>link, >i915->gt.rings);
-
return ring;
 }
 
@@ -1163,8 +1161,6 @@ intel_ring_free(struct intel_ring *ring)
i915_vma_close(ring->vma);
__i915_gem_object_release_unless_active(obj);
 
-   list_del(>link);
-
kfree(ring);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index deb80d01e0bd..fd679cec9ac6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -130,7 +130,7 @@ struct intel_ring {
void *vaddr;
 
 

[Intel-gfx] [PATCH 2/7] drm/i915: Wrap engine->context_pin() and engine->context_unpin()

[Chris Wilson]

Make life easier in upcoming patches by moving the context_pin and
context_unpin vfuncs into inline helpers.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/mmio_context.c  |  2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c | 20 ++---
 drivers/gpu/drm/i915/i915_debugfs.c  | 20 +++--
 drivers/gpu/drm/i915/i915_gem.c  |  4 +--
 drivers/gpu/drm/i915/i915_gem_context.c  |  8 +++---
 drivers/gpu/drm/i915/i915_gem_context.h  | 30 +++-
 drivers/gpu/drm/i915/i915_gpu_error.c|  3 +-
 drivers/gpu/drm/i915/i915_perf.c |  9 +++---
 drivers/gpu/drm/i915/i915_request.c  |  6 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c   | 13 -
 drivers/gpu/drm/i915/intel_guc_ads.c |  3 +-
 drivers/gpu/drm/i915/intel_guc_submission.c  |  5 ++--
 drivers/gpu/drm/i915/intel_lrc.c | 29 +++
 drivers/gpu/drm/i915/intel_lrc.h |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 19 +++--
 drivers/gpu/drm/i915/selftests/mock_engine.c |  2 +-
 16 files changed, 108 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index a5bac83d53a9..0f949554d118 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -448,7 +448,7 @@ static void switch_mocs(struct intel_vgpu *pre, struct 
intel_vgpu *next,
 
 bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id)
 {
-   u32 *reg_state = ctx->engine[ring_id].lrc_reg_state;
+   u32 *reg_state = ctx->__engine[ring_id].lrc_reg_state;
u32 inhibit_mask =
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
 
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 35f7cfd7a6b4..ffb45a9ee228 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -58,7 +58,7 @@ static void update_shadow_pdps(struct intel_vgpu_workload 
*workload)
int ring_id = workload->ring_id;
struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   shadow_ctx->__engine[ring_id].state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
 
@@ -130,7 +130,7 @@ static int populate_shadow_context(struct 
intel_vgpu_workload *workload)
int ring_id = workload->ring_id;
struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   shadow_ctx->__engine[ring_id].state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
void *dst;
@@ -283,7 +283,7 @@ static int shadow_context_status_change(struct 
notifier_block *nb,
 static void shadow_context_descriptor_update(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
 {
-   struct intel_context *ce = >engine[engine->id];
+   struct intel_context *ce = to_intel_context(ctx, engine);
u64 desc = 0;
 
desc = ce->lrc_desc;
@@ -389,7 +389,7 @@ int intel_gvt_scan_and_shadow_workload(struct 
intel_vgpu_workload *workload)
 * shadow_ctx pages invalid. So gvt need to pin itself. After update
 * the guest context, gvt can unpin the shadow_ctx safely.
 */
-   ring = engine->context_pin(engine, shadow_ctx);
+   ring = intel_context_pin(shadow_ctx, engine);
if (IS_ERR(ring)) {
ret = PTR_ERR(ring);
gvt_vgpu_err("fail to pin shadow context\n");
@@ -403,7 +403,7 @@ int intel_gvt_scan_and_shadow_workload(struct 
intel_vgpu_workload *workload)
return 0;
 
 err_unpin:
-   engine->context_unpin(engine, shadow_ctx);
+   intel_context_unpin(shadow_ctx, engine);
 err_shadow:
release_shadow_wa_ctx(>wa_ctx);
 err_scan:
@@ -437,7 +437,7 @@ static int intel_gvt_generate_request(struct 
intel_vgpu_workload *workload)
return 0;
 
 err_unpin:
-   engine->context_unpin(engine, shadow_ctx);
+   intel_context_unpin(shadow_ctx, engine);
release_shadow_wa_ctx(>wa_ctx);
return ret;
 }
@@ -526,7 +526,7 @@ static int update_wa_ctx_2_shadow_ctx(struct 
intel_shadow_wa_ctx *wa_ctx)
struct intel_vgpu_submission *s = >vgpu->submission;
struct i915_gem_context *shadow_ctx = s->shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
-   shadow_ctx->engine[ring_id].state->obj;
+   shadow_ctx->__engine[ring_id].state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
 
@@ -688,7 +688,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
 
ret = 

[Intel-gfx] [PATCH 1/7] drm/i915: Stop tracking timeline->inflight_seqnos

[Chris Wilson]

In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to preserve the semantics that no engine wraps in the
middle of a submit. (Although this semantic is now only required for gen7
semaphore support, which only supports greater-then comparisons!)

v2: Keep a global counter of all requests ever submitted and force the
reset when it wraps.

References: 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  5 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem_timeline.h |  6 -
 drivers/gpu/drm/i915/i915_request.c  | 33 
 drivers/gpu/drm/i915/intel_engine_cs.c   |  5 ++--
 5 files changed, 22 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1c88805d3354..83c86257fe1c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1340,10 +1340,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
struct rb_node *rb;
 
seq_printf(m, "%s:\n", engine->name);
-   seq_printf(m, "\tseqno = %x [current %x, last %x], inflight 
%d\n",
+   seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
   engine->hangcheck.seqno, seqno[id],
-  intel_engine_last_submit(engine),
-  engine->timeline->inflight_seqnos);
+  intel_engine_last_submit(engine));
seq_printf(m, "\twaiters? %s, fake irq active? %s, stalled? 
%s\n",
   yesno(intel_engine_has_waiter(engine)),
   yesno(test_bit(engine->id,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..8fd9fb6efba5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,6 +2061,7 @@ struct drm_i915_private {
struct list_head timelines;
struct i915_gem_timeline global_timeline;
u32 active_requests;
+   u32 request_serial;
 
/**
 * Is the GPU currently considered idle, or busy executing
diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.h 
b/drivers/gpu/drm/i915/i915_gem_timeline.h
index 33e01bf6aa36..6e82119e2cd8 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.h
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.h
@@ -37,12 +37,6 @@ struct intel_timeline {
u64 fence_context;
u32 seqno;
 
-   /**
-* Count of outstanding requests, from the time they are constructed
-* to the moment they are retired. Loosely coupled to hardware.
-*/
-   u32 inflight_seqnos;
-
spinlock_t lock;
 
/**
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index b692a9f7c357..b1993d4a1a53 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -241,6 +241,7 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
   sizeof(timeline->engine[id].global_sync));
}
 
+   i915->gt.request_serial = seqno;
return 0;
 }
 
@@ -257,18 +258,22 @@ int i915_gem_set_global_seqno(struct drm_device *dev, u32 
seqno)
return reset_all_global_seqno(i915, seqno - 1);
 }
 
-static int reserve_engine(struct intel_engine_cs *engine)
+static int reserve_gt(struct drm_i915_private *i915)
 {
-   struct drm_i915_private *i915 = engine->i915;
-   u32 active = ++engine->timeline->inflight_seqnos;
-   u32 seqno = engine->timeline->seqno;
int ret;
 
-   /* Reservation is fine until we need to wrap around */
-   if (unlikely(add_overflows(seqno, active))) {
+   /*
+* Reservation is fine until we may need to wrap around
+*
+* By incrementing the serial for every request, we know that no
+* individual engine may exceed that serial (as each is reset to 0
+* on any wrap). This protects even the most pessimistic of migrations
+* of every request from all engines onto just one.
+*/
+   while (unlikely(++i915->gt.request_serial == 0)) {
ret = reset_all_global_seqno(i915, 0);
if (ret) {
-   engine->timeline->inflight_seqnos--;
+   i915->gt.request_serial--;
return ret;
}
}
@@ -279,15 +284,10 @@ static int reserve_engine(struct intel_engine_cs *engine)
return 0;
 }
 

[Intel-gfx] [PATCH 3/7] drm/i915: Retire requests along rings

[Chris Wilson]

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).

v3: Not just a reference to the context, but we need to keep it pinned
as we manipulate the rings; i.e. we need a pin for both the manipulation
of the engine state during its retirements, and a separate pin for the
manipulation of the ring state.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |   3 +-
 drivers/gpu/drm/i915/i915_gem.c   |   1 +
 drivers/gpu/drm/i915/i915_request.c   | 150 +++---
 drivers/gpu/drm/i915/i915_utils.h |   6 +
 drivers/gpu/drm/i915/intel_ringbuffer.c   |   6 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |   1 +
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  27 +++-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +
 8 files changed, 131 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8fd9fb6efba5..1837c01d44d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct list_head timelines;
struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
u32 request_serial;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4090bfdda340..f0644d1fbd75 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
 
mutex_lock(_priv->drm.struct_mutex);
+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 9358f2cf0c32..e6535255d445 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -286,6 +286,7 @@ static int reserve_gt(struct drm_i915_private *i915)
 
 static void unreserve_gt(struct drm_i915_private *i915)
 {
+   GEM_BUG_ON(!i915->gt.active_requests);
if (!--i915->gt.active_requests)
i915_gem_park(i915);
 }
@@ -298,6 +299,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
 
 static void advance_ring(struct i915_request *request)
 {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
 
/*
@@ -309,7 +311,8 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(!list_is_first(>ring_link, >request_list));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
} else {
tail = request->postfix;
}
-   list_del(>ring_link);
+   list_del_init(>ring_link);
 
-   request->ring->head = tail;
+   ring->head = tail;
 }
 
 static void free_capture_list(struct i915_request *request)
@@ -340,30 +343,84 @@ static void free_capture_list(struct i915_request 
*request)
}
 }
 
+static void 

[Intel-gfx] [PATCH 7/7] drm/i915: Lazily unbind vma on close

[Chris Wilson]

When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the page tables and maintain the drm_mm range manager
every time.

However, since the object still exists and it is only the local handle
that disappears, if we are lazy and do not unbind the VMA immediately
when the local user closes the object but defer it until the GPU is
idle, then we can reuse the same VMA binding. We still have to be
careful to mark the handle and lookup tables as closed to maintain the
uABI, just allowing the underlying VMA to be resurrected if the user is
able to access the same object from the same context again.

If the object itself is destroyed (neither userspace keeping a handle to
it), the VMA will be reaped immediately as usual.

In the future, this will be even more useful as instantiating a new VMA
for use on the GPU will become heavier. A nuisance indeed, so nip it in
the bud.

v2: s/__i915_vma_final_close/i915_vma_destroy/ etc.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_gem.c   |  4 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c|  3 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 14 +++--
 drivers/gpu/drm/i915/i915_vma.c   | 61 +--
 drivers/gpu/drm/i915/i915_vma.h   |  6 ++
 drivers/gpu/drm/i915/selftests/huge_pages.c   |  2 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  1 +
 8 files changed, 67 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dab15b6abc3c..d4da9f941d04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2061,6 +2061,7 @@ struct drm_i915_private {
struct list_head timelines;
 
struct list_head active_rings;
+   struct list_head closed_vma;
u32 active_requests;
u32 request_serial;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 484354f25f98..5ece6ae4bdff 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -165,6 +165,7 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
i915_timelines_park(i915);
 
i915_pmu_gt_parked(i915);
+   i915_vma_parked(i915);
 
i915->gt.awake = false;
 
@@ -4795,7 +4796,7 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
 >vma_list, obj_link) {
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
-   i915_vma_close(vma);
+   i915_vma_destroy(vma);
}
GEM_BUG_ON(!list_empty(>vma_list));
GEM_BUG_ON(!RB_EMPTY_ROOT(>vma_tree));
@@ -5598,6 +5599,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
 
INIT_LIST_HEAD(_priv->gt.timelines);
INIT_LIST_HEAD(_priv->gt.active_rings);
+   INIT_LIST_HEAD(_priv->gt.closed_vma);
 
i915_gem_init__mm(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c74f5df3fb5a..f627a8c47c58 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -762,7 +762,8 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
}
 
/* transfer ref to ctx */
-   vma->open_count++;
+   if (!vma->open_count++)
+   i915_vma_reopen(vma);
list_add(>obj_link, >lut_list);
list_add(>ctx_link, >ctx->handles_list);
lut->ctx = eb->ctx;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e9d828324f67..272d6bb407cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2218,6 +2218,12 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
 }
 
 void i915_ppgtt_close(struct i915_address_space *vm)
+{
+   GEM_BUG_ON(vm->closed);
+   vm->closed = true;
+}
+
+static void ppgtt_destroy_vma(struct i915_address_space *vm)
 {
struct list_head *phases[] = {
>active_list,
@@ -2226,15 +2232,12 @@ void i915_ppgtt_close(struct i915_address_space *vm)
NULL,
}, **phase;
 
-   GEM_BUG_ON(vm->closed);
vm->closed = true;
-
for (phase = phases; *phase; phase++) {
struct i915_vma *vma, *vn;
 
list_for_each_entry_safe(vma, vn, *phase, vm_link)
-   if (!i915_vma_is_closed(vma))
-

Re: [Intel-gfx] [RFC] drm/i915: Rework "Potential atomic update error" to handle PSR exit

[Dhinakaran Pandiyan]

On Thu, 2018-04-26 at 16:41 +0300, Ville Syrjälä wrote:
> On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> > From: Tarun 
> > 
> > The Display scanline counter freezes on PSR entry. Inside
> > intel_pipe_update_start, once Vblank interrupts are enabled, we start
> > exiting PSR, but by the time the scanline counter is read, we may not
> > have completely exited PSR which leads us to schedule out and check back
> > later.
> > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but
> > lags w.r.t core kernel code, hot plugging an external display triggers
> > tons of "potential atomic update errors" in the dmesg, on *pipe A*. A
> > closer analysis reveals that we try to read the scanline 3 times and
> > eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL stuck @
> > 1599.
> > This issue is not seen on upstream kernels, b/c for *some* reason we
> > loop inside intel_pipe_update start for ~2+ msec which in this case is
> > more than enough to exit PSR fully, hence an *unstuck* PIPEDSL counter,
> > hence no error. On the other hand, the ChromeOS kernel spends ~1.1 msec
> > looping inside intel_pipe_update_start and hence errors out b/c the
> > source is still in PSR.
> > 
> > If PSR is enabled, then we should *wait* for  the PSR
> > state to move to IDLE before re-reading the PIPEDSL so as to avoid bogus
> > and annoying "potential atomic update error" messages.
> > 
> > P.S: This scenario applies to a configuration with an additional pipe,
> > as of now.
> > 

Ville, 

Any idea what could be the reason the warnings start appearing when an
external display is connected? We couldn't come up with an explanation.


> > Signed-off-by: Tarun 
> > ---
> >  drivers/gpu/drm/i915/intel_sprite.c | 19 +++
> >  1 file changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index aa1dfaa692b9..77dd3b936131 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -92,11 +92,13 @@ void intel_pipe_update_start(const struct 
> > intel_crtc_state *new_crtc_state)
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > const struct drm_display_mode *adjusted_mode = 
> > _crtc_state->base.adjusted_mode;
> > long timeout = msecs_to_jiffies_timeout(1);
> > -   int scanline, min, max, vblank_start;
> > +   int scanline, min, max, vblank_start, old_scanline, new_scanline;
> > +   bool retried = false;
> > wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> > bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
> > IS_CHERRYVIEW(dev_priv)) &&
> > intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
> > DEFINE_WAIT(wait);
> > +   old_scanline = new_scanline = -1;
> >  
> > vblank_start = adjusted_mode->crtc_vblank_start;
> > if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> > @@ -126,15 +128,24 @@ void intel_pipe_update_start(const struct 
> > intel_crtc_state *new_crtc_state)
> >  * read the scanline.
> >  */
> > prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
> > -
> > +retry:
> > scanline = intel_get_crtc_scanline(crtc);
> > +   old_scanline = new_scanline, new_scanline = scanline;
> > +
> > if (scanline < min || scanline > max)
> > break;
> >  
> > if (timeout <= 0) {
> > -   DRM_ERROR("Potential atomic update failure on pipe 
> > %c\n",
> > +   if(!i915.enable_psr || retried) {

You could use the CAN_PSR() macro that checks for source and sink
support.

> > +   DRM_ERROR("Potential atomic update failure on 
> > pipe %c\n",
> >   pipe_name(crtc->pipe));
> > -   break;
> > +   break;
> > +   }
> > +   else if(old_scanline == new_scanline && !retried) {
> > +   retried = true;
> > +   intel_wait_for_register(dev_priv, 
> > EDP_PSR_STATUS_CTL, EDP_PSR_STATUS_STATE_MASK, EDP_PSR_STATUS_STATE_IDLE, 
> > 10);
> 
> What's the point of obfuscating the loop with this stuff?
> Just wait for the PSR exit before we even enter the loop?
> 
> > +   goto retry;
> > +   }
> > }
> >  
> > local_irq_enable();
> > -- 
> > 2.13.5
> > 
> > ___
> > 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/selftests: Wait for idle between idle resets as well

[Chris Wilson]

Quoting Michał Winiarski (2018-04-26 17:21:39)
> On Wed, Apr 11, 2018 at 01:03:46PM +0100, Chris Wilson wrote:
> > Even though we weren't injecting guilty requests to be reset, we could
> > still fall over the issue of resetting the same request too fast -- where
> > the GPU refuses to start again. (Although it is interesting to note that
> > reloading the driver is sufficient, suggesting that we could recover if
> > we delayed the setup after reset?) Continue to paper over the problem by
> > adding a small delay by waiting for the engine to idle between tests,
> > and ensure that the engines are idle before starting the idle tests.
> > 
> > References: 028666793a02 ("drm/i915/selftests: Avoid repeatedly harming the 
> > same innocent context")
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Michał Winiarski 
> > Cc: Michel Thierry 
> > Cc: Tvrtko Ursulin 
> > ---
> >  .../gpu/drm/i915/selftests/intel_hangcheck.c  | 48 ++-
> >  1 file changed, 47 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > index 24f913f26a7b..7e23e6a6719c 100644
> > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > @@ -454,6 +454,11 @@ static int igt_global_reset(void *arg)
> >   return err;
> >  }
> >  
> 
> #define IGT_IDLE_TIMEOUT 50 ?
> It should even fit within a line.
> 
> With or without that:
> 
> Reviewed-by: Michał Winiarski 

Done. Thanks for the review, pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout

[Ville Syrjala]

From: Ville Syrjälä 

During state readout we first read out the pipe src size, store
that information in the user mode h/vdisplay, but later on we overwrite
that with the actual crtc timings. That makes our read out crtc state
inconsistent with itself when the BIOS has enabled the panel fitter to
scale the pipe contents. Let's preserve the pipe src size based
information in the user mode to make things consistent again.

This fixes a problem introduced by commit a2936e3d9a9c ("drm/i915:
Use drm_mode_get_hv_timing() to populate plane clip rectangle")
where the inconsistent state is now leading the plane clipping code
to report a failure on account the plane dst coordinates not matching
the user mode size. Previously we did the plane clipping based on
the pipe src size instead and thus never noticed the inconsistency.

The failure manifests as a WARN:
[0.762117] [drm:intel_dump_pipe_config [i915]] requested mode:
[0.762142] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1366x768" 
60 72143 1366 1414 1446 1526 768 771 777 784 0x40 0xa
...
[0.762327] [drm:intel_dump_pipe_config [i915]] port clock: 72143, pipe src 
size: 1024x768, pixel rate 72143
...
[0.764666] [drm:drm_atomic_helper_check_plane_state [drm_kms_helper]] Plane 
must cover entire CRTC
[0.764690] [drm:drm_rect_debug_print [drm]] dst: 1024x768+0+0
[0.764711] [drm:drm_rect_debug_print [drm]] clip: 1366x768+0+0
[0.764713] [ cut here ]
[0.764714] Could not determine valid watermarks for inherited state
[0.764792] WARNING: CPU: 4 PID: 159 at 
drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3ce/0x19d0 
[i915]
...

Cc: FadeMind 
Cc: Dave Jones 
Cc: Daniel Vetter 
Reported-by: FadeMind 
Reported-by: Dave Jones 
Tested-by: Dave Jones 
References: 
https://lists.freedesktop.org/archives/intel-gfx/2018-April/163186.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105992
Fixes: a2936e3d9a9c ("drm/i915: Use drm_mode_get_hv_timing() to populate plane 
clip rectangle")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 09e96d547c01..5afb5a4cc67e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15288,6 +15288,8 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
memset(>base.mode, 0, sizeof(crtc->base.mode));
if (crtc_state->base.active) {
intel_mode_from_pipe_config(>base.mode, 
crtc_state);
+   crtc->base.mode.hdisplay = crtc_state->pipe_src_w;
+   crtc->base.mode.vdisplay = crtc_state->pipe_src_h;

intel_mode_from_pipe_config(_state->base.adjusted_mode, crtc_state);
WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, 
>base.mode));
 
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait for idle between idle resets as well

[Michał Winiarski]

On Wed, Apr 11, 2018 at 01:03:46PM +0100, Chris Wilson wrote:
> Even though we weren't injecting guilty requests to be reset, we could
> still fall over the issue of resetting the same request too fast -- where
> the GPU refuses to start again. (Although it is interesting to note that
> reloading the driver is sufficient, suggesting that we could recover if
> we delayed the setup after reset?) Continue to paper over the problem by
> adding a small delay by waiting for the engine to idle between tests,
> and ensure that the engines are idle before starting the idle tests.
> 
> References: 028666793a02 ("drm/i915/selftests: Avoid repeatedly harming the 
> same innocent context")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michał Winiarski 
> Cc: Michel Thierry 
> Cc: Tvrtko Ursulin 
> ---
>  .../gpu/drm/i915/selftests/intel_hangcheck.c  | 48 ++-
>  1 file changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index 24f913f26a7b..7e23e6a6719c 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -454,6 +454,11 @@ static int igt_global_reset(void *arg)
>   return err;
>  }
>  

#define IGT_IDLE_TIMEOUT 50 ?
It should even fit within a line.

With or without that:

Reviewed-by: Michał Winiarski 

-Michał

> +static bool wait_for_idle(struct intel_engine_cs *engine)
> +{
> + return wait_for(intel_engine_is_idle(engine), 50) == 0;
> +}
> +
>  static int __igt_reset_engine(struct drm_i915_private *i915, bool active)
>  {
>   struct intel_engine_cs *engine;
> @@ -481,6 +486,13 @@ static int __igt_reset_engine(struct drm_i915_private 
> *i915, bool active)
>   if (active && !intel_engine_can_store_dword(engine))
>   continue;
>  
> + if (!wait_for_idle(engine)) {
> + pr_err("%s failed to idle before reset\n",
> +engine->name);
> + err = -EIO;
> + break;
> + }
> +
>   reset_count = i915_reset_count(>gpu_error);
>   reset_engine_count = i915_reset_engine_count(>gpu_error,
>engine);
> @@ -542,6 +554,19 @@ static int __igt_reset_engine(struct drm_i915_private 
> *i915, bool active)
>   err = -EINVAL;
>   break;
>   }
> +
> + if (!wait_for_idle(engine)) {
> + struct drm_printer p =
> + drm_info_printer(i915->drm.dev);
> +
> + pr_err("%s failed to idle after reset\n",
> +engine->name);
> + intel_engine_dump(engine, ,
> +   "%s\n", engine->name);
> +
> + err = -EIO;
> + break;
> + }
>   } while (time_before(jiffies, end_time));
>   clear_bit(I915_RESET_ENGINE + id, >gpu_error.flags);
>  
> @@ -696,6 +721,13 @@ static int __igt_reset_engines(struct drm_i915_private 
> *i915,
>   !intel_engine_can_store_dword(engine))
>   continue;
>  
> + if (!wait_for_idle(engine)) {
> + pr_err("i915_reset_engine(%s:%s): failed to idle before 
> reset\n",
> +engine->name, test_name);
> + err = -EIO;
> + break;
> + }
> +
>   memset(threads, 0, sizeof(threads));
>   for_each_engine(other, i915, tmp) {
>   struct task_struct *tsk;
> @@ -772,6 +804,20 @@ static int __igt_reset_engines(struct drm_i915_private 
> *i915,
>   i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
>   i915_request_put(rq);
>   }
> +
> + if (!(flags & TEST_SELF) && !wait_for_idle(engine)) {
> + struct drm_printer p =
> + drm_info_printer(i915->drm.dev);
> +
> + pr_err("i915_reset_engine(%s:%s):"
> +" failed to idle after reset\n",
> +engine->name, test_name);
> + intel_engine_dump(engine, ,
> +   "%s\n", engine->name);
> +
> + err = -EIO;
> + break;
> + }
>   } while 

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

[Dave Jones]

On Thu, Apr 26, 2018 at 06:25:13PM +0300, Ville Syrjälä wrote:
 > On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote:
 > > On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
 > > > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
 > > > > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A 
 > > > > with fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
 > > > > [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] 
 > > > > creating preallocated stolen object: stolen_offset=0x, 
 > > > > gtt_offset=0x, size=0x001d5000
 > > > > [1.176312] [drm:intel_alloc_initial_plane_obj.isra.127] initial 
 > > > > plane fb obj (ptrval)
 > > > > [1.176351] [drm:intel_modeset_init] pipe A active planes 0x1
 > > > > [1.176456] [drm:drm_atomic_helper_check_plane_state] Plane must 
 > > > > cover entire CRTC
 > > > > [1.176481] [drm:drm_rect_debug_print] dst: 800x600+0+0
 > > > > [1.176494] [drm:drm_rect_debug_print] clip: 1366x768+0+0
 > > > 
 > > > OK, so that's the problem right there. The fb we took over from the
 > > > BIOS was 800x600, but now we're trying to set up a 1366x768 mode.
 > > > 
 > > > We seem to be missing checks to make sure the initial fb is actually
 > > > big enough for the mode we're currently using :(
 > > 
 > Hmm. Or maybe we should just stick to the pipe src size.
 > 
 > I'm curious whether this fixes the problem?
 > 
 > diff --git a/drivers/gpu/drm/i915/intel_display.c 
 > b/drivers/gpu/drm/i915/intel_display.c
 > index 0f8c7389e87d..30824beedef7 100644
 > --- a/drivers/gpu/drm/i915/intel_display.c
 > +++ b/drivers/gpu/drm/i915/intel_display.c
 > @@ -15284,6 +15284,8 @@ static void intel_modeset_readout_hw_state(struct 
 > drm_device *dev)
 >  memset(>base.mode, 0, sizeof(crtc->base.mode));
 >  if (crtc_state->base.active) {
 >  intel_mode_from_pipe_config(>base.mode, 
 > crtc_state);
 > +crtc->base.mode.hdisplay = crtc_state->pipe_src_w;
 > +crtc->base.mode.vdisplay = crtc_state->pipe_src_h;
 >  
 > intel_mode_from_pipe_config(_state->base.adjusted_mode, crtc_state);
 >  WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, 
 > >base.mode));
 > 

It does!

Feel free to throw a Tested-by: Dave Jones  in there.

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

Re: [Intel-gfx] [PATCH] drm/i915: remove check for aux irq

[Ville Syrjälä]

On Thu, Apr 26, 2018 at 08:42:54AM -0700, Lucas De Marchi wrote:
> On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > > 
> > > > > Cc: Ville Syrjälä 
> > > > > Signed-off-by: Lucas De Marchi 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.h  |  3 +--
> > > > >  drivers/gpu/drm/i915/intel_dp.c  | 22 +++---
> > > > >  drivers/gpu/drm/i915/intel_drv.h |  1 -
> > > > >  drivers/gpu/drm/i915/intel_psr.c |  2 +-
> > > > >  4 files changed, 9 insertions(+), 19 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index 8444ca8d5aa3..09e1c2289ea1 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private 
> > > > > *dev_priv)
> > > > >IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > > >  
> > > > >  /*
> > > > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> > > > > interrupts
> > > > > + * gmbus irq on gen4 seems to be able to generate legacy interrupts
> > > > 
> > > > Why are you removing vital information from the comment?
> > > 
> > > Because it wouldn't match the code anymore. We always use aux irq.
> > 
> > The comment is documenting the hardware behaviour. We don't want to lose
> > that information.
> 
> IMO it's confusing to have the comment saying one thing and then code
> not following it. Reading it again I see the second paragraph you added
> actually document the code and the first the HW behavior. Maybe starting
> the second paragraph with a "However" would make it clearer.  Or I can just
> drop this change in the comment.

Or you can move the relevant parts of the comment to the place where
we do the "MSI or not to MSI" decision.

-- 
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] drm/i915: remove check for aux irq

[Lucas De Marchi]

On Thu, Apr 26, 2018 at 06:27:26PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> > On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: Lucas De Marchi 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  3 +--
> > > >  drivers/gpu/drm/i915/intel_dp.c  | 22 +++---
> > > >  drivers/gpu/drm/i915/intel_drv.h |  1 -
> > > >  drivers/gpu/drm/i915/intel_psr.c |  2 +-
> > > >  4 files changed, 9 insertions(+), 19 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 8444ca8d5aa3..09e1c2289ea1 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private 
> > > > *dev_priv)
> > > >  IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > >  
> > > >  /*
> > > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> > > > interrupts
> > > > + * gmbus irq on gen4 seems to be able to generate legacy interrupts
> > > 
> > > Why are you removing vital information from the comment?
> > 
> > Because it wouldn't match the code anymore. We always use aux irq.
> 
> The comment is documenting the hardware behaviour. We don't want to lose
> that information.

IMO it's confusing to have the comment saying one thing and then code
not following it. Reading it again I see the second paragraph you added
actually document the code and the first the HW behavior. Maybe starting
the second paragraph with a "However" would make it clearer.  Or I can just
drop this change in the comment.

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

Re: [Intel-gfx] [PATCH 03/22] drm/i915/icl: WaGAPZPriorityScheme

[Mika Kuoppala]

Oscar Mateo  writes:

> The default GAPZ arbitrer priority value at power-on has been found
> to be incorrect.
>
> v2: Now renamed to Wa_1405543622
>
> v3: Rebased on top of the WA refactoring
>

I have suggested that when implementing workarounds,
authors, for example, add

References: HSDES#1405542622, HSDES#1207131207

as a first tagline to ease up the review.
I do that again :) No need to resend,

Reviewed-by: Mika Kuoppala 

> Cc: Mika Kuoppala 
> Signed-off-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 5 +++--
>  drivers/gpu/drm/i915/intel_workarounds.c | 6 ++
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4b7e6bc..a6b1f85 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8215,8 +8215,9 @@ enum {
>  #define   GEN8_DOP_CLOCK_GATE_GUC_ENABLE (1<<4)
>  #define   GEN8_DOP_CLOCK_GATE_MEDIA_ENABLE (1<<6)
>  
> -#define GEN8_GARBCNTL   _MMIO(0xB004)
> -#define   GEN9_GAPS_TSV_CREDIT_DISABLE  (1<<7)
> +#define GEN8_GARBCNTL_MMIO(0xB004)
> +#define   GEN9_GAPS_TSV_CREDIT_DISABLE   (1 << 7)
> +#define   GEN11_ARBITRATION_PRIO_ORDER_MASK  (0x3f << 22)
>  
>  #define GEN10_DFR_RATIO_EN_AND_CHICKEN   _MMIO(0x9550)
>  #define   DFR_DISABLE(1 << 9)
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c 
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 60a5b1d..ffd27a1 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -703,6 +703,12 @@ static void icl_gt_workarounds_apply(struct 
> drm_i915_private *dev_priv)
>   /* WaPipelineFlushCoherentLines:icl */
>   I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
>   GEN8_LQSC_FLUSH_COHERENT_LINES));
> +
> + /* Wa_1405543622:icl
> +  * Formerly known as WaGAPZPriorityScheme
> +  */
> + I915_WRITE(GEN8_GARBCNTL, (I915_READ(GEN8_GARBCNTL) |
> +GEN11_ARBITRATION_PRIO_ORDER_MASK));
>  }
>  
>  void intel_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> -- 
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: remove check for aux irq

[Ville Syrjälä]

On Thu, Apr 26, 2018 at 08:22:12AM -0700, Lucas De Marchi wrote:
> On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > GMBUS and AUX interrupts on gen4/g4x").
> > > 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Lucas De Marchi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  3 +--
> > >  drivers/gpu/drm/i915/intel_dp.c  | 22 +++---
> > >  drivers/gpu/drm/i915/intel_drv.h |  1 -
> > >  drivers/gpu/drm/i915/intel_psr.c |  2 +-
> > >  4 files changed, 9 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 8444ca8d5aa3..09e1c2289ea1 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> > >IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > >  
> > >  /*
> > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> > > interrupts
> > > + * gmbus irq on gen4 seems to be able to generate legacy interrupts
> > 
> > Why are you removing vital information from the comment?
> 
> Because it wouldn't match the code anymore. We always use aux irq.

The comment is documenting the hardware behaviour. We don't want to lose
that information.

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

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

[Ville Syrjälä]

On Thu, Apr 26, 2018 at 06:16:41PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with 
> > > fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
> > > [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] 
> > > creating preallocated stolen object: stolen_offset=0x, 
> > > gtt_offset=0x, size=0x001d5000
> > > [1.176312] [drm:intel_alloc_initial_plane_obj.isra.127] initial plane 
> > > fb obj (ptrval)
> > > [1.176351] [drm:intel_modeset_init] pipe A active planes 0x1
> > > [1.176456] [drm:drm_atomic_helper_check_plane_state] Plane must cover 
> > > entire CRTC
> > > [1.176481] [drm:drm_rect_debug_print] dst: 800x600+0+0
> > > [1.176494] [drm:drm_rect_debug_print] clip: 1366x768+0+0
> > 
> > OK, so that's the problem right there. The fb we took over from the
> > BIOS was 800x600, but now we're trying to set up a 1366x768 mode.
> > 
> > We seem to be missing checks to make sure the initial fb is actually
> > big enough for the mode we're currently using :(
> 
> Actually we do read out the pipe src size as 800x600 initially, which
> make sense. And we even stuff that into the mode.h/vdisplay, so up to
> that point everything is pretty much correct. It goes wrong is when
> intel_modeset_readout_hw_state() calls intel_mode_from_pipe_config()
> as that will override the h/vdisplay with the actual crtc timings
> instead of the pipe src size.
> 
> So I suppose we should be able to just add the sanity checks for the
> fb vs. h/vdisplay, and at least we should get past this error. A
> slightly bigger mystery is what will happen later when our pipe src
> size doesn't actually agree with the h/vdisplay. The first modeset
> will correct it, but we might want some kind of extra sanitize step
> for fastboot type of stuff.

Hmm. Or maybe we should just stick to the pipe src size.

I'm curious whether this fixes the problem?

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0f8c7389e87d..30824beedef7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15284,6 +15284,8 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
memset(>base.mode, 0, sizeof(crtc->base.mode));
if (crtc_state->base.active) {
intel_mode_from_pipe_config(>base.mode, 
crtc_state);
+   crtc->base.mode.hdisplay = crtc_state->pipe_src_w;
+   crtc->base.mode.vdisplay = crtc_state->pipe_src_h;

intel_mode_from_pipe_config(_state->base.adjusted_mode, crtc_state);
WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, 
>base.mode));

-- 
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 v2 0/7] drm/i915/dp: link config compute refactoring

[Jani Nikula]

On Thu, 26 Apr 2018, Jani Nikula  wrote:
> v2 of https://patchwork.freedesktop.org/series/41215/

And pushed the lot after the CI results. Thanks for the review!

BR,
Jani.

>
> Jani Nikula (7):
>   drm/i915/dp: remove stale comment about bw constants
>   drm/i915/dp: move link_bw and rate_select debugging where used
>   drm/i915/dp: abstract dp link config computation from the rest
>   drm/i915/dp: move eDP VBT bpp clamping code to intel_dp_compute_bpp()
>   drm/i915/dp: group link config limits in a struct
>   drm/i915/dp: abstract link config selection
>   drm/i915/dp: fix compliance test adjustments
>
>  drivers/gpu/drm/i915/intel_dp.c   | 277 
> +++---
>  drivers/gpu/drm/i915/intel_dp_link_training.c |   5 +
>  2 files changed, 169 insertions(+), 113 deletions(-)

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

Re: [Intel-gfx] [PATCH] drm/i915: remove check for aux irq

[Lucas De Marchi]

On Thu, Apr 26, 2018 at 04:43:38PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > GMBUS and AUX interrupts on gen4/g4x").
> > 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Lucas De Marchi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  3 +--
> >  drivers/gpu/drm/i915/intel_dp.c  | 22 +++---
> >  drivers/gpu/drm/i915/intel_drv.h |  1 -
> >  drivers/gpu/drm/i915/intel_psr.c |  2 +-
> >  4 files changed, 9 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8444ca8d5aa3..09e1c2289ea1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> >  
> >  /*
> > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> > interrupts
> > + * gmbus irq on gen4 seems to be able to generate legacy interrupts
> 
> Why are you removing vital information from the comment?

Because it wouldn't match the code anymore. We always use aux irq.

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

Re: [Intel-gfx] [PATCH v2 RESEND] drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

[Jani Nikula]

On Thu, 26 Apr 2018, Tvrtko Ursulin  wrote:
> On 26/04/2018 12:35, Jani Nikula wrote:
>> Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
>> circumstances.
>> 
>> v2: don't change device info dump (Chris)
>> 
>> Cc: Tvrtko Ursulin 
>> Cc: Mika Kuoppala 
>> Signed-off-by: Jani Nikula 
>> ---
>>   drivers/gpu/drm/i915/intel_device_info.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
>> b/drivers/gpu/drm/i915/intel_device_info.c
>> index a32ba72c514e..0fd13df424cf 100644
>> --- a/drivers/gpu/drm/i915/intel_device_info.c
>> +++ b/drivers/gpu/drm/i915/intel_device_info.c
>> @@ -848,7 +848,7 @@ void intel_device_info_runtime_init(struct 
>> intel_device_info *info)
>>  gen9_sseu_info_init(dev_priv);
>>  else if (INTEL_GEN(dev_priv) == 10)
>>  gen10_sseu_info_init(dev_priv);
>> -else if (INTEL_INFO(dev_priv)->gen >= 11)
>> +else if (INTEL_GEN(dev_priv) >= 11)
>>  gen11_sseu_info_init(dev_priv);
>>   
>>  /* Initialize command stream timestamp frequency */
>> 
>
> Reviewed-by: Tvrtko Ursulin 

Thanks, pushed to dinq.

I'm having second thoughts on the ->gen to ->__gen change. There were
after all some legit users of it.

BR,
Jani.

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

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

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

[Ville Syrjälä]

On Thu, Apr 26, 2018 at 05:56:14PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> > [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with 
> > fb: size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
> > [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] 
> > creating preallocated stolen object: stolen_offset=0x, 
> > gtt_offset=0x, size=0x001d5000
> > [1.176312] [drm:intel_alloc_initial_plane_obj.isra.127] initial plane 
> > fb obj (ptrval)
> > [1.176351] [drm:intel_modeset_init] pipe A active planes 0x1
> > [1.176456] [drm:drm_atomic_helper_check_plane_state] Plane must cover 
> > entire CRTC
> > [1.176481] [drm:drm_rect_debug_print] dst: 800x600+0+0
> > [1.176494] [drm:drm_rect_debug_print] clip: 1366x768+0+0
> 
> OK, so that's the problem right there. The fb we took over from the
> BIOS was 800x600, but now we're trying to set up a 1366x768 mode.
> 
> We seem to be missing checks to make sure the initial fb is actually
> big enough for the mode we're currently using :(

Actually we do read out the pipe src size as 800x600 initially, which
make sense. And we even stuff that into the mode.h/vdisplay, so up to
that point everything is pretty much correct. It goes wrong is when
intel_modeset_readout_hw_state() calls intel_mode_from_pipe_config()
as that will override the h/vdisplay with the actual crtc timings
instead of the pipe src size.

So I suppose we should be able to just add the sanity checks for the
fb vs. h/vdisplay, and at least we should get past this error. A
slightly bigger mystery is what will happen later when our pipe src
size doesn't actually agree with the h/vdisplay. The first modeset
will correct it, but we might want some kind of extra sanitize step
for fastboot type of stuff.

-- 
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 01/22] drm/i915/icl: Introduce initial Icelake Workarounds

[Mika Kuoppala]

Oscar Mateo  writes:

> Inherit workarounds from previous platforms that are still valid for
> Icelake.
>
> v2: GEN7_ROW_CHICKEN2 is masked
> v3:
>   - Since it has been fixed already in upstream, removed the TODO
> comment about WA_SET_BIT for WaInPlaceDecompressionHang.
>   - Squashed with this patch:
>   drm/i915/icl: add icelake_init_clock_gating()
> from Paulo Zanoni 
>   - Squashed with this patch:
>   drm/i915/icl: WaForceEnableNonCoherent
> from Oscar Mateo 
>   - WaPushConstantDereferenceHoldDisable is now Wa_1604370585 and
> applies to B0 as well.
>   - WaPipeControlBefore3DStateSamplePattern WABB was being applied
> to ICL incorrectly.
> v4:
>   - Wrap the commit message
>   - s/dev_priv/p to please checkpatch
> v5: Rebased on top of the WA refactoring
> v6: Rebased on top of further whitelist registers refactoring (Michel)
> v7: Added WaRsForcewakeAddDelayForAck
>
> Cc: Tomasz Lis 
> Cc: Mika Kuoppala 
> Signed-off-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  9 +++
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |  4 +--
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  drivers/gpu/drm/i915/intel_lrc.c |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c  |  4 ++-
>  drivers/gpu/drm/i915/intel_uncore.c  |  7 +++--
>  drivers/gpu/drm/i915/intel_workarounds.c | 46 
> 
>  7 files changed, 68 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0286911..1dc157f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2462,6 +2462,15 @@ static inline unsigned int i915_sg_segment_size(void)
>  #define IS_CNL_REVID(p, since, until) \
>   (IS_CANNONLAKE(p) && IS_REVID(p, since, until))
>  
> +#define ICL_REVID_A0 0x0
> +#define ICL_REVID_A2 0x1

Just noted that for some reason bspec puts A0 and A2 under
same revid. Bspec err?

> +#define ICL_REVID_B0 0x3
> +#define ICL_REVID_B2 0x4
> +#define ICL_REVID_C0 0x5
> +
> +#define IS_ICL_REVID(p, since, until) \
> + (IS_ICELAKE(p) && IS_REVID(p, since, until))
> +
>  /*
>   * The genX designation typically refers to the render engine, so render
>   * capability related checks should use IS_GEN, while display and other 
> checks
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 21d72f6..221b873 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2140,12 +2140,12 @@ static void gtt_write_workarounds(struct 
> drm_i915_private *dev_priv)
>* called on driver load and after a GPU reset, so you can place
>* workarounds here even if they get overwritten by GPU reset.
>*/
> - /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk,cfl,cnl */
> + /* WaIncreaseDefaultTLBEntries:chv,bdw,skl,bxt,kbl,glk,cfl,cnl,icl */
>   if (IS_BROADWELL(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_BDW);
>   else if (IS_CHERRYVIEW(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN8_L3_LRA_1_GPGPU_DEFAULT_VALUE_CHV);
> - else if (IS_GEN9_BC(dev_priv) || IS_GEN10(dev_priv))
> + else if (IS_GEN9_BC(dev_priv) || IS_GEN10(dev_priv) || 
> IS_GEN11(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
>   else if (IS_GEN9_LP(dev_priv))
>   I915_WRITE(GEN8_L3_LRA_1_GPGPU, 
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fb10602..f2ee225 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7203,6 +7203,7 @@ enum {
>  /* GEN8 chicken */
>  #define HDC_CHICKEN0 _MMIO(0x7300)
>  #define CNL_HDC_CHICKEN0 _MMIO(0xE5F0)
> +#define ICL_HDC_CHICKEN0 _MMIO(0xE5F4)
>  #define  HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE  (1<<15)
>  #define  HDC_FENCE_DEST_SLM_DISABLE  (1<<14)
>  #define  HDC_DONOT_FETCH_MEM_WHEN_MASKED (1<<11)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 029901a..2d6572a 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1636,6 +1636,8 @@ static int intel_init_workaround_bb(struct 
> intel_engine_cs *engine)
>   return -EINVAL;
>  
>   switch (INTEL_GEN(engine->i915)) {
> + case 11:
> + return 0;
>   case 10:
>   wa_bb_fn[0] = gen10_init_indirectctx_bb;
>   wa_bb_fn[1] = NULL;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4baab85..3b7d804 

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

[Ville Syrjälä]

On Thu, Apr 26, 2018 at 10:27:19AM -0400, Dave Jones wrote:
> [1.176131] [drm:i9xx_get_initial_plane_config] pipe A/primary A with fb: 
> size=800x600@32, offset=0, pitch 3200, size 0x1d4c00
> [1.176161] [drm:i915_gem_object_create_stolen_for_preallocated] creating 
> preallocated stolen object: stolen_offset=0x, 
> gtt_offset=0x, size=0x001d5000
> [1.176312] [drm:intel_alloc_initial_plane_obj.isra.127] initial plane fb 
> obj (ptrval)
> [1.176351] [drm:intel_modeset_init] pipe A active planes 0x1
> [1.176456] [drm:drm_atomic_helper_check_plane_state] Plane must cover 
> entire CRTC
> [1.176481] [drm:drm_rect_debug_print] dst: 800x600+0+0
> [1.176494] [drm:drm_rect_debug_print] clip: 1366x768+0+0

OK, so that's the problem right there. The fb we took over from the
BIOS was 800x600, but now we're trying to set up a 1366x768 mode.

We seem to be missing checks to make sure the initial fb is actually
big enough for the mode we're currently using :(

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

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

[Dave Jones]

On Thu, Apr 26, 2018 at 04:10:45PM +0300, Ville Syrjälä wrote:
 > On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote:
 > > This warning just started appearing during boot on a machine I upgraded
 > > to 4.17-rc2.  The warning seems to have been there since 2015, but it
 > > has never triggered before today.
 > 
 > Looks like we have bug open about this. I just asked for more
 > information there:
 > https://bugs.freedesktop.org/show_bug.cgi?id=105992#c5
 > 
 > If you can also boot with drm.debug=0xe maybe we can see some more
 > details about the supposedly bad watermarks.


[1.153294] calling  drm_kms_helper_init+0x0/0x15 @ 1
[1.153768] initcall drm_kms_helper_init+0x0/0x15 returned 0 after 0 usecs
[1.154242] calling  drm_core_init+0x0/0xea @ 1
[1.154760] initcall drm_core_init+0x0/0xea returned 0 after 53 usecs
[1.156781] [drm:intel_pch_type] Found LynxPoint PCH
[1.157254] [drm:intel_power_domains_init] Allowed DC state mask 00
[1.158717] [drm:i915_driver_load] ppgtt mode: 1
[1.159187] [drm:intel_uc_sanitize_options] enable_guc=0 (submission:no 
huc:no)
[1.159665] [drm:i915_driver_load] guc_log_level=0 (enabled:no verbosity:-1)
[1.160247] [drm:i915_ggtt_probe_hw] GGTT size = 2048M
[1.160720] [drm:i915_ggtt_probe_hw] GMADR size = 256M
[1.161189] [drm:i915_ggtt_probe_hw] DSM size = 64M
[1.162126] fb: switching to inteldrmfb from EFI VGA
[1.163161] fb: switching to inteldrmfb from VGA16 VGA
[1.163511] [drm] Replacing VGA console driver
[1.163819] [drm:i915_gem_init_stolen] Memory reserved for graphics device: 
65536K, usable: 64512K
[1.163868] [drm:intel_opregion_setup] graphic opregion physical addr: 
0xd9a13018
[1.163908] [drm:intel_opregion_setup] Public ACPI methods supported
[1.163924] [drm:intel_opregion_setup] SWSCI supported
[1.168084] [drm:intel_opregion_setup] SWSCI GBDA callbacks 0cb3, SBCB 
callbacks 00300483
[1.168107] [drm:intel_opregion_setup] ASLE supported
[1.168120] [drm:intel_opregion_setup] ASLE extension supported
[1.168136] [drm:intel_opregion_setup] Found valid VBT in ACPI OpRegion 
(Mailbox #4)
[1.168325] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.168341] [drm] Driver supports precise vblank timestamp query.
[1.168357] [drm:intel_bios_init] Set default to SSC at 12 kHz
[1.168373] [drm:intel_bios_init] VBT signature "$VBT HASWELL", BDB 
version 174
[1.168392] [drm:intel_bios_init] BDB_GENERAL_FEATURES int_tv_support 0 
int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 12 display_clock_mode 0 
fdi_rx_polarity_inverted 0
[1.168425] [drm:intel_bios_init] crt_ddc_bus_pin: 5
[1.171131] [drm:intel_opregion_get_panel_type] Ignoring OpRegion panel type 
(0)
[1.171151] [drm:intel_bios_init] Panel type: 2 (VBT)
[1.171164] [drm:intel_bios_init] DRRS supported mode is static
[1.171185] [drm:intel_bios_init] Found panel mode in BIOS VBT tables:
[1.171203] [drm:drm_mode_debug_printmodeline] Modeline 0:"1024x768" 0 65000 
1024 1048 1184 1344 768 771 777 806 0x8 0xa
[1.171227] [drm:intel_bios_init] VBT initial LVDS value 300
[1.171242] [drm:intel_bios_init] VBT backlight PWM modulation frequency 200 
Hz, active high, min brightness 0, level 255, controller 0
[1.171272] [drm:intel_bios_init] Found SDVO panel mode in BIOS VBT tables:
[1.171289] [drm:drm_mode_debug_printmodeline] Modeline 0:"1600x1200" 0 
162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa
[1.171314] [drm:intel_bios_init] DRRS State Enabled:1
[1.171327] [drm:intel_bios_init] No SDVO device info is found in VBT
[1.171344] [drm:intel_bios_init] Port B VBT info: DP:0 HDMI:0 DVI:1 EDP:0 
CRT:0
[1.171362] [drm:intel_bios_init] VBT HDMI level shift for port B: 6
[1.171377] [drm:intel_bios_init] Port D VBT info: DP:0 HDMI:1 DVI:1 EDP:0 
CRT:0
[1.171395] [drm:intel_bios_init] VBT HDMI level shift for port D: 11
[1.171470] [drm:intel_dsm_detect] no _DSM method for intel device
[1.171492] [drm:i915_driver_load] rawclk rate: 125000 kHz
[1.171524] [drm:intel_power_well_enable] enabling always-on
[1.171549] [drm:intel_power_well_enable] enabling display
[1.172946] [drm:intel_fbc_init] Sanitized enable_fbc value: 0
[1.172964] [drm:intel_print_wm_latency] Primary WM0 latency 20 (2.0 usec)
[1.172981] [drm:intel_print_wm_latency] Primary WM1 latency 4 (2.0 usec)
[1.172997] [drm:intel_print_wm_latency] Primary WM2 latency 36 (18.0 usec)
[1.173014] [drm:intel_print_wm_latency] Primary WM3 latency 90 (45.0 usec)
[1.173030] [drm:intel_print_wm_latency] Primary WM4 latency 160 (80.0 usec)
[1.173047] [drm:intel_print_wm_latency] Sprite WM0 latency 20 (2.0 usec)
[1.173063] [drm:intel_print_wm_latency] Sprite WM1 latency 4 (2.0 usec)
[1.173080] [drm:intel_print_wm_latency] Sprite WM2 latency 36 (18.0 usec)
[1.173096] [drm:intel_print_wm_latency] Sprite WM3 latency 90 (45.0 usec)
[

[Intel-gfx] [PATCH 3/3] drm/i915/icl: update ddb entry start/end mask during hw ddb readout

[Mahesh Kumar]

Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to
11 bits. This patch make changes to use proper mask for ICL+ during
hardware ddb value readout.

Changes since V1:
 - Use _MASK & _SHIFT macro (James)
Changes since V2:
 - use kernel type u8 instead of uint8_t
Changes since V3:
 - Rebase

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 drivers/gpu/drm/i915/intel_pm.c | 26 +++---
 2 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2dad655a710c..b94fa933530e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6481,6 +6481,9 @@ enum {
 
 #define _PLANE_BUF_CFG_1_B 0x7127c
 #define _PLANE_BUF_CFG_2_B 0x7137c
+#define  SKL_DDB_ENTRY_MASK0x3FF
+#define  ICL_DDB_ENTRY_MASK0x7FF
+#define  DDB_ENTRY_END_SHIFT   16
 #define _PLANE_BUF_CFG_1(pipe) \
_PIPE(pipe, _PLANE_BUF_CFG_1_A, _PLANE_BUF_CFG_1_B)
 #define _PLANE_BUF_CFG_2(pipe) \
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3e72e9eb736e..4126132eb707 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3864,10 +3864,18 @@ static unsigned int skl_cursor_allocation(int 
num_active)
return 8;
 }
 
-static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
+static void skl_ddb_entry_init_from_hw(struct drm_i915_private *dev_priv,
+  struct skl_ddb_entry *entry, u32 reg)
 {
-   entry->start = reg & 0x3ff;
-   entry->end = (reg >> 16) & 0x3ff;
+   u16 mask;
+
+   if (INTEL_GEN(dev_priv) >= 11)
+   mask = ICL_DDB_ENTRY_MASK;
+   else
+   mask = SKL_DDB_ENTRY_MASK;
+   entry->start = reg & mask;
+   entry->end = (reg >> DDB_ENTRY_END_SHIFT) & mask;
+
if (entry->end)
entry->end += 1;
 }
@@ -3884,7 +3892,8 @@ skl_ddb_get_hw_plane_state(struct drm_i915_private 
*dev_priv,
/* Cursor doesn't support NV12/planar, so no extra calculation needed */
if (plane_id == PLANE_CURSOR) {
val = I915_READ(CUR_BUF_CFG(pipe));
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   skl_ddb_entry_init_from_hw(dev_priv,
+  >plane[pipe][plane_id], val);
return;
}
 
@@ -3903,10 +3912,13 @@ skl_ddb_get_hw_plane_state(struct drm_i915_private 
*dev_priv,
val2 = I915_READ(PLANE_NV12_BUF_CFG(pipe, plane_id));
 
if (fourcc == DRM_FORMAT_NV12) {
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val2);
-   skl_ddb_entry_init_from_hw(>uv_plane[pipe][plane_id], val);
+   skl_ddb_entry_init_from_hw(dev_priv,
+  >plane[pipe][plane_id], val2);
+   skl_ddb_entry_init_from_hw(dev_priv,
+  >uv_plane[pipe][plane_id], val);
} else {
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], val);
+   skl_ddb_entry_init_from_hw(dev_priv,
+  >plane[pipe][plane_id], val);
}
 }
 
-- 
2.16.2

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

[Intel-gfx] [PATCH 2/3] drm/i915/icl: Enable 2nd DBuf slice only when needed

[Mahesh Kumar]

ICL has two slices of DBuf, each slice of size 1024 blocks.
We should not always enable slice-2. It should be enabled only if
display total required BW is > 12GBps OR more than 1 pipes are enabled.

Changes since V1:
 - typecast total_data_rate to u64 before multiplication to solve any
   possible overflow (Rodrigo)
 - fix where skl_wm_get_hw_state was memsetting ddb, resulting
   enabled_slices to become zero
 - Fix the logic of calculating ddb_size
Changes since V2:
 - If no-crtc is part of commit required_slices will have value "0",
   don't try to disable DBuf slice.
Changes since V3:
 - Create a generic helper to enable/disable slice
 - don't return early if total_data_rate is 0, it may be cursor only
   commit, or atomic modeset without any plane.
Changes since V4:
 - Solve checkpatch warnings
 - use kernel types u8/u64 instead of uint8_t/uint64_t
Changes since V5:
 - Rebase

Signed-off-by: Mahesh Kumar 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_display.c| 10 +
 drivers/gpu/drm/i915/intel_drv.h|  6 +++
 drivers/gpu/drm/i915/intel_pm.c | 57 +++--
 drivers/gpu/drm/i915/intel_runtime_pm.c | 65 ++---
 4 files changed, 113 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e5ad95d0af1b..a61909dc90ba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12256,6 +12256,8 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state)
bool progress;
enum pipe pipe;
int i;
+   u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
+   u8 required_slices = intel_state->wm_results.ddb.enabled_slices;
 
const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
 
@@ -12264,6 +12266,10 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state)
if (new_crtc_state->active)
entries[i] = 
_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
 
+   /* If 2nd DBuf slice required, enable it here */
+   if (INTEL_GEN(dev_priv) >= 11 && required_slices > hw_enabled_slices)
+   icl_dbuf_slices_update(dev_priv, required_slices);
+
/*
 * Whenever the number of active pipes changes, we need to make sure we
 * update the pipes in the right order so that their ddb allocations
@@ -12314,6 +12320,10 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state)
progress = true;
}
} while (progress);
+
+   /* If 2nd DBuf slice is no more required disable it */
+   if (INTEL_GEN(dev_priv) >= 11 && required_slices < hw_enabled_slices)
+   icl_dbuf_slices_update(dev_priv, required_slices);
 }
 
 static void intel_atomic_helper_free_state(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9bba0354ccd3..11a1932cde6e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -144,6 +144,10 @@
 #define KHz(x) (1000 * (x))
 #define MHz(x) KHz(1000 * (x))
 
+#define KBps(x) (1000 * (x))
+#define MBps(x) KBps(1000 * (x))
+#define GBps(x) ((u64)1000 * MBps((x)))
+
 /*
  * Display related stuff
  */
@@ -1931,6 +1935,8 @@ bool intel_display_power_get_if_enabled(struct 
drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
 void intel_display_power_put(struct drm_i915_private *dev_priv,
 enum intel_display_power_domain domain);
+void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
+   u8 req_slices);
 
 static inline void
 assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a29e6d512771..3e72e9eb736e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3771,9 +3771,42 @@ bool intel_can_enable_sagv(struct drm_atomic_state 
*state)
return true;
 }
 
+static unsigned int intel_get_ddb_size(struct drm_i915_private *dev_priv,
+  const struct intel_crtc_state *cstate,
+  const unsigned int total_data_rate,
+  const int num_active,
+  struct skl_ddb_allocation *ddb)
+{
+   const struct drm_display_mode *adjusted_mode;
+   u64 total_data_bw;
+   u16 ddb_size = INTEL_INFO(dev_priv)->ddb_size;
+
+   WARN_ON(ddb_size == 0);
+
+   if (INTEL_GEN(dev_priv) < 11)
+   return ddb_size - 4; /* 4 blocks for bypass path allocation */
+
+   adjusted_mode = >base.adjusted_mode;
+   total_data_bw = (u64)total_data_rate * drm_mode_vrefresh(adjusted_mode);
+
+   /*
+* 

[Intel-gfx] [PATCH 1/3] drm/i915/icl: track dbuf slice-2 status

[Mahesh Kumar]

This patch adds support to start tracking status of DBUF slices.
This is foundation to introduce support for enabling/disabling second
DBUF slice dynamically for ICL.

Changes Since V1:
 - use kernel type u8 over uint8_t

Signed-off-by: Mahesh Kumar 
Reviewed-by: James Ausmus 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_display.c|  5 +
 drivers/gpu/drm/i915/intel_pm.c | 20 
 drivers/gpu/drm/i915/intel_runtime_pm.c |  4 
 4 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..193176bcddf5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1189,6 +1189,7 @@ struct skl_ddb_allocation {
/* packed/y */
struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES];
struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   u8 enabled_slices; /* GEN11 has configurable 2 slices */
 };
 
 struct skl_ddb_values {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 09e96d547c01..e5ad95d0af1b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11445,6 +11445,11 @@ static void verify_wm_state(struct drm_crtc *crtc,
skl_ddb_get_hw_state(dev_priv, _ddb);
sw_ddb = _priv->wm.skl_hw.ddb;
 
+   if (INTEL_GEN(dev_priv) >= 11)
+   if (hw_ddb.enabled_slices != sw_ddb->enabled_slices)
+   DRM_ERROR("mismatch in DBUF Slices (expected %u, got 
%u)\n",
+ sw_ddb->enabled_slices,
+ hw_ddb.enabled_slices);
/* planes */
for_each_universal_plane(dev_priv, pipe, plane) {
hw_plane_wm = _wm.planes[plane];
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4baab858e442..a29e6d512771 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3567,6 +3567,23 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
 }
 
+static u8 intel_enabled_dbuf_slices_num(struct drm_i915_private *dev_priv)
+{
+   u8 enabled_slices;
+
+   /* Slice 1 will always be enabled */
+   enabled_slices = 1;
+
+   /* Gen prior to GEN11 have only one DBuf slice */
+   if (INTEL_GEN(dev_priv) < 11)
+   return enabled_slices;
+
+   if (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE)
+   enabled_slices++;
+
+   return enabled_slices;
+}
+
 /*
  * 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.
@@ -3870,6 +3887,8 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
 
memset(ddb, 0, sizeof(*ddb));
 
+   ddb->enabled_slices = intel_enabled_dbuf_slices_num(dev_priv);
+
for_each_intel_crtc(_priv->drm, crtc) {
enum intel_display_power_domain power_domain;
enum plane_id plane_id;
@@ -5088,6 +5107,7 @@ skl_copy_ddb_for_pipe(struct skl_ddb_values *dst,
   sizeof(dst->ddb.uv_plane[pipe]));
memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
   sizeof(dst->ddb.plane[pipe]));
+   dst->ddb.enabled_slices = src->ddb.enabled_slices;
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ec59992cf87a..afc6ef81ca0c 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2656,6 +2656,8 @@ static void icl_dbuf_enable(struct drm_i915_private 
*dev_priv)
if (!(I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
!(I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
DRM_ERROR("DBuf power enable timeout\n");
+   else
+   dev_priv->wm.skl_hw.ddb.enabled_slices = 2;
 }
 
 static void icl_dbuf_disable(struct drm_i915_private *dev_priv)
@@ -2669,6 +2671,8 @@ static void icl_dbuf_disable(struct drm_i915_private 
*dev_priv)
if ((I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
(I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
DRM_ERROR("DBuf power disable timeout!\n");
+   else
+   dev_priv->wm.skl_hw.ddb.enabled_slices = 0;
 }
 
 static void icl_mbus_init(struct drm_i915_private *dev_priv)
-- 
2.16.2

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

[Intel-gfx] [PATCH 0/3] Optimize use of DBuf slices

[Mahesh Kumar]

Patches in this series were originally part of series:
https://patchwork.freedesktop.org/series/36993/

Reposting it here after rebase
use kernel types u8/u16 etc instead of uint8_t

Changes:
 - Rebase the series

Mahesh Kumar (3):
  drm/i915/icl: track dbuf slice-2 status
  drm/i915/icl: Enable 2nd DBuf slice only when needed
  drm/i915/icl: update ddb entry start/end mask during hw ddb readout

 drivers/gpu/drm/i915/i915_drv.h |   1 +
 drivers/gpu/drm/i915/i915_reg.h |   3 +
 drivers/gpu/drm/i915/intel_display.c|  15 +
 drivers/gpu/drm/i915/intel_drv.h|   6 ++
 drivers/gpu/drm/i915/intel_pm.c | 103 ++--
 drivers/gpu/drm/i915/intel_runtime_pm.c |  69 -
 6 files changed, 165 insertions(+), 32 deletions(-)

-- 
2.16.2

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

Re: [Intel-gfx] [PATCH v11 06/11] drm: Add DRM client cap for aspect-ratio

[Ville Syrjälä]

On Mon, Apr 23, 2018 at 01:11:25PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
> > 
> > 
> > On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> > >> From: Ankit Nautiyal 
> > >>
> > >> To enable aspect-ratio support in DRM, blindly exposing the aspect
> > >> ratio information along with mode, can break things in existing
> > >> user-spaces which have no intention or support to use this aspect
> > >> ratio information.
> > >>
> > >> To avoid this, a new drm client cap is required to enable a
> > >> user-space to advertise if it supports modes with aspect-ratio. Based
> > >> on this cap value, the kernel will take a call on exposing the aspect
> > >> ratio info in modes or not.
> > >>
> > >> This patch adds the client cap for aspect-ratio.
> > >>
> > >> Cc: Ville Syrjala 
> > >> Cc: Shashank Sharma 
> > >> Signed-off-by: Ankit Nautiyal 
> > >>
> > >> V3: rebase
> > >> V4: As suggested by Marteen Lankhorst modified the commit message
> > >>  explaining the need to use the DRM cap for aspect-ratio. Also,
> > >>  tweaked the comment lines in the code for better understanding and
> > >>  clarity, as recommended by Shashank Sharma.
> > >> V5: rebase
> > >> V6: rebase
> > >> V7: rebase
> > >> V8: rebase
> > >> V9: rebase
> > >> V10: added comment explaining that no userspace breaks on aspect-ratio
> > >>   mode bits.
> > >>
> > >> Reviewed-by: Shashank Sharma 
> > >> ---
> > >>   drivers/gpu/drm/drm_ioctl.c | 9 +
> > >>   include/drm/drm_file.h  | 8 
> > >>   include/uapi/drm/drm.h  | 7 +++
> > >>   3 files changed, 24 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > >> index af78291..39c8eab 100644
> > >> --- a/drivers/gpu/drm/drm_ioctl.c
> > >> +++ b/drivers/gpu/drm/drm_ioctl.c
> > >> @@ -325,6 +325,15 @@ drm_setclientcap(struct drm_device *dev, void 
> > >> *data, struct drm_file *file_priv)
> > >>  file_priv->atomic = req->value;
> > >>  file_priv->universal_planes = req->value;
> > >>  break;
> > >> +case DRM_CLIENT_CAP_ASPECT_RATIO:
> > >> +if (req->value > 1)
> > >> +return -EINVAL;
> > >> +/*
> > >> + * No Atomic userspace blows up on aspect ratio mode bits. 
> > >> Checked in
> > >> + * wayland/weston, xserver, and hardware-composer modeset paths.
> > >> + */
> > > Bogus indentation.
> > 
> > Thanks to point that out, will fix this.
> > 
> > > Also where's the aspect_ratio_allowed handling for the atomic cap?
> > > Or did we decide against it after all?
> > 
> > As discussed, aspect ratio is handled in the atomic modeset path, where 
> > in the modeset requests with aspect-ratios
> > are rejected, if the aspect-ratio cap not set.
> 
> That is not what we discussed on irc. What Daniel was suggesting is
> always enabling the aspect ratio cap for atomic clients, just as we
> already enable the univerals planes cap for atomic clients.

And to make sure we're on the same page finally

@@ -320,14 +320,15 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
case DRM_CLIENT_CAP_ATOMIC:
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
return -EINVAL;
if (req->value > 1)
return -EINVAL;
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
+   file_priv->aspect_ratio_allowed = req->value;
break;
default:
return -EINVAL;
}
 
return 0;
 }

is what we're talking about here.

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

[Patchwork]

== Series Details ==

Series: drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen
URL   : https://patchwork.freedesktop.org/series/42331/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8813_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8813_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8813_full, 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/42331/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8813_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP

igt@gem_mocs_settings@mocs-rc6-bsd1:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

  Here are the changes found in Patchwork_8813_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_cs_tlb@basic-default:
  shard-snb:  PASS -> INCOMPLETE (fdo#105411)

igt@gem_ppgtt@blt-vs-render-ctxn:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#106087)

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#105363, fdo#102887)


 Possible fixes 

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  FAIL (fdo#103928) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4103 -> Patchwork_8813

  CI_DRM_4103: 96d389ab8f2f1e05b9ba5feacef7185f59a129db @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8813: d58b3639fa7c187535960d42372463103a13d409 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8813/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Compile out engine debug for release

[Patchwork]

== Series Details ==

Series: drm/i915: Compile out engine debug for release
URL   : https://patchwork.freedesktop.org/series/42327/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8812_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8812_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8812_full, 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/42327/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8812_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-bsd1:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

  Here are the changes found in Patchwork_8812_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_ppgtt@blt-vs-render-ctxn:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#102887)

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368) +3


 Possible fixes 

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  FAIL (fdo#103928) -> PASS

igt@kms_sysfs_edid_timing:
  shard-apl:  WARN (fdo#100047) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4103 -> Patchwork_8812

  CI_DRM_4103: 96d389ab8f2f1e05b9ba5feacef7185f59a129db @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8812: 5271cd637c80f6960e17d44da1fd499597dc510b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8812/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: link config compute refactoring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: link config compute refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/41215/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4103_full -> Patchwork_8810_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8810_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8810_full, 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/41215/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8810_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-bsd1:
  shard-kbl:  SKIP -> PASS +1

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  PASS -> SKIP +1


== Known issues ==

  Here are the changes found in Patchwork_8810_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge:
  shard-apl:  PASS -> FAIL (fdo#104671)

igt@kms_flip@blocking-wf_vblank:
  shard-hsw:  PASS -> FAIL (fdo#103928)

igt@kms_flip@flip-vs-absolute-wf_vblank-interruptible:
  shard-apl:  PASS -> FAIL (fdo#100368)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#105363, fdo#102887)

igt@kms_flip@wf_vblank-ts-check-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368)

igt@kms_rotation_crc@primary-rotation-180:
  shard-apl:  PASS -> DMESG-WARN (fdo#105127)

igt@kms_vblank@pipe-a-accuracy-idle:
  shard-hsw:  PASS -> FAIL (fdo#102583)


 Possible fixes 

igt@kms_flip@2x-wf_vblank-ts-check:
  shard-hsw:  FAIL (fdo#103928) -> PASS

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671
  fdo#105127 https://bugs.freedesktop.org/show_bug.cgi?id=105127
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4103 -> Patchwork_8810

  CI_DRM_4103: 96d389ab8f2f1e05b9ba5feacef7185f59a129db @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8810: 1e9bea0cb9c8bbc98e77ff536ec9942a58802ff8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8810/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.

[Lis, Tomasz]

On 2018-03-30 21:45, Daniele Ceraolo Spurio wrote:



On 30/03/18 08:42, Lis, Tomasz wrote:



On 2018-03-29 00:28, Chris Wilson wrote:

Quoting Lis, Tomasz (2018-03-28 17:06:58)


On 2018-03-28 01:27, Chris Wilson wrote:

Quoting Tomasz Lis (2018-03-27 16:17:59)
The patch adds support of preempt-to-idle requesting by setting a 
proper
bit within Execlist Control Register, and receiving preemption 
result from

Context Status Buffer.

Preemption in previous gens required a special batch buffer to be 
executed,
so the Command Streamer never preempted to idle directly. In 
Icelake it is
possible, as there is a hardware mechanism to inform the kernel 
about

status of the preemption request.

This patch does not cover using the new preemption mechanism when 
GuC is

active.

Bspec: 18922
Signed-off-by: Tomasz Lis 
---
   drivers/gpu/drm/i915/i915_drv.h  |  2 ++
   drivers/gpu/drm/i915/i915_pci.c  |  3 ++-
   drivers/gpu/drm/i915/intel_device_info.h |  1 +
   drivers/gpu/drm/i915/intel_lrc.c | 45 
+++-

   drivers/gpu/drm/i915/intel_lrc.h |  1 +
   5 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 800230b..c32580b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2514,6 +2514,8 @@ intel_info(const struct drm_i915_private 
*dev_priv)

((dev_priv)->info.has_logical_ring_elsq)
   #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
((dev_priv)->info.has_logical_ring_preemption)
+#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \
+ ((dev_priv)->info.has_hw_preempt_to_idle)
   #define HAS_EXECLISTS(dev_priv) 
HAS_LOGICAL_RING_CONTEXTS(dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c 
b/drivers/gpu/drm/i915/i915_pci.c

index 4364922..66b6700 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -595,7 +595,8 @@ static const struct intel_device_info 
intel_cannonlake_info = {

  GEN(11), \
  .ddb_size = 2048, \
  .has_csr = 0, \
-   .has_logical_ring_elsq = 1
+   .has_logical_ring_elsq = 1, \
+   .has_hw_preempt_to_idle = 1
   static const struct intel_device_info intel_icelake_11_info = {
  GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h

index 933e316..4eb97b5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -98,6 +98,7 @@ enum intel_platform {
  func(has_logical_ring_contexts); \
  func(has_logical_ring_elsq); \
  func(has_logical_ring_preemption); \
+   func(has_hw_preempt_to_idle); \
  func(has_overlay); \
  func(has_pooled_eu); \
  func(has_psr); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
b/drivers/gpu/drm/i915/intel_lrc.c

index ba7f783..1a22de4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -153,6 +153,7 @@
   #define GEN8_CTX_STATUS_ACTIVE_IDLE    (1 << 3)
   #define GEN8_CTX_STATUS_COMPLETE   (1 << 4)
   #define GEN8_CTX_STATUS_LITE_RESTORE   (1 << 15)
+#define GEN11_CTX_STATUS_PREEMPT_IDLE  (1 << 29)
   #define GEN8_CTX_STATUS_COMPLETED_MASK \
   (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
@@ -183,7 +184,9 @@ static inline bool need_preempt(const struct 
intel_engine_cs *engine,

  const struct i915_request *last,
  int prio)
   {
-   return engine->i915->preempt_context && prio > 
max(rq_prio(last), 0);

+   return (engine->i915->preempt_context ||
+   HAS_HW_PREEMPT_TO_IDLE(engine->i915)) &&
Well, you haven't actually disabled allocating the preempt_context 
so...

Yes.. I had mixed feelings about changing needs_preempt_context() now,
as that would mean adding a temporary condition on GuC until the GuC
preemption is merged.
I will add the conditions and disable the allocation in v2 of the 
patch.
But at any rate, making this an engine->flag would eliminate one 
pointer

dance.

Could be an interesting idea for a separate patch.

To land first ;)

:)
Sure, I can do that.

+    prio > max(rq_prio(last), 0);
   }
   /**
@@ -535,6 +538,25 @@ static void inject_preempt_context(struct 
intel_engine_cs *engine)

execlists_set_active(>execlists, EXECLISTS_ACTIVE_PREEMPT);
   }
+static void gen11_preempt_to_idle(struct intel_engine_cs *engine)
+{
+   struct intel_engine_execlists *execlists = 
>execlists;

+
+   GEM_TRACE("%s\n", engine->name);
+
+   /*
+    * hardware which HAS_HW_PREEMPT_TO_IDLE(), always also
+    * HAS_LOGICAL_RING_ELSQ(), so we can assume ctrl_reg is set
+    */
+   GEM_BUG_ON(execlists->ctrl_reg != NULL);
+
+   /* trigger preemption to idle */
+   writel(EL_CTRL_PREEMPT_TO_IDLE, execlists->ctrl_reg);

Future plans? Because just inserting the branch 

Re: [Intel-gfx] [PATCH 2/3] drm/rect: Handle rounding errors in drm_rect_clip_scaled

[Ville Syrjälä]

On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_rect.c | 65 +++---
>  1 file changed, 47 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index b179c7c73cc5..71b6b7f5d58f 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -50,6 +50,24 @@ bool drm_rect_intersect(struct drm_rect *r1, const struct 
> drm_rect *r2)
>  }
>  EXPORT_SYMBOL(drm_rect_intersect);
>  
> +static int drm_calc_scale(int src, int dst)
> +{
> + int scale = 0;
> +
> + if (WARN_ON(src < 0 || dst < 0))
> + return -EINVAL;
> +
> + if (dst == 0)
> + return 0;
> +
> + if (src > (dst << 16))
> + return DIV_ROUND_UP(src, dst);
> + else
> + scale = src / dst;
> +
> + return scale;
> +}
> +
>  /**
>   * drm_rect_clip_scaled - perform a scaled clip operation
>   * @src: source window rectangle
> @@ -71,49 +89,60 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct 
> drm_rect *dst,
>  {
>   int diff;
>  
> + /*
> +  * When scale is near 0x1 rounding errors may cause the scaling
> +  * factor to the other side. Some hardware may support
> +  * upsampling, but not downsampling, and that would break when
> +  * rounding.
> +  */
> +#define FIXUP(oldscale, fn, m, second) do { \
> + if (oldscale != 1 << 16) { \
> + int newscale = drm_calc_scale(fn(src), fn(dst)); \
> + \
> + if (newscale < 0) \
> + return false; \
> + \
> + if ((oldscale < 0x1) != (newscale < 0x1)) { \
> + if (!second) \
> + src->m##1 = src->m##2 - ((fn(dst) - diff) << 
> 16); \
> + else \
> + src->m##2 = src->m##1 + ((fn(dst) - diff) << 
> 16); \

This is starting to get very messy. Also are we sure the x2/y2 can't
go past the initial value here?

It's starting to feel like we should do the clip with the rounding the
orher way, which should guarantee we never flip between up and down
scaling by accident. And then just do a post-clip check for final scale
factor with the pessimistic rounding direction to make sure we stay
within the limits.

> + } \
> + } \
> + } while (0)
> +
>   diff = clip->x1 - dst->x1;
>   if (diff > 0) {
>   int64_t tmp = src->x1 + (int64_t) diff * hscale;
>   src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 0);
>   }
> +
>   diff = clip->y1 - dst->y1;
>   if (diff > 0) {
>   int64_t tmp = src->y1 + (int64_t) diff * vscale;
>   src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 0);
>   }
> +
>   diff = dst->x2 - clip->x2;
>   if (diff > 0) {
>   int64_t tmp = src->x2 - (int64_t) diff * hscale;
>   src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 1);
>   }
>   diff = dst->y2 - clip->y2;
>   if (diff > 0) {
>   int64_t tmp = src->y2 - (int64_t) diff * vscale;
>   src->y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 1);
>   }
> +#undef FIXUP
>  
>   return drm_rect_intersect(dst, clip);
>  }
>  EXPORT_SYMBOL(drm_rect_clip_scaled);
>  
> -static int drm_calc_scale(int src, int dst)
> -{
> - int scale = 0;
> -
> - if (WARN_ON(src < 0 || dst < 0))
> - return -EINVAL;
> -
> - if (dst == 0)
> - return 0;
> -
> - if (src > (dst << 16))
> - return DIV_ROUND_UP(src, dst);
> - else
> - scale = src / dst;
> -
> - return scale;
> -}
> -
>  /**
>   * drm_rect_calc_hscale - calculate the horizontal scaling factor
>   * @src: source window rectangle
> -- 
> 2.17.0

-- 
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] drm/core: Remove drm_dev_unref() and it's uses

[Daniel Vetter]

On Thu, Apr 26, 2018 at 3:14 PM, Alexandre Belloni
 wrote:
> Hi,
>
> On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > > It's been a while since we introduced drm_dev{get/put} functions
>> > > to replace reference/unreference in drm subsystem for the
>> > > consistency purpose. So, with this patch, let's just replace
>> > > all current use cases of drm_dev_unref() with drm_dev_put and remove
>> > > the function itself.
>> > >
>> > > Coccinelle was used for mass-patching.
>> > >
>> > > Signed-off-by: Vaishali Thakkar 
>> >
>> > Thanks for doing this. Unfortunately drm moves pretty fast, so already a
>> > conflict when I tried to apply this. Some drivers are also in their own
>> > trees, so this might lead to more fun :-/
>> >
>> > Can you pls split it up per-driver (just the directories under
>> > drivers/gpu/drm/ is enough)? Final patch to remove the function might then
>> > get stalled a bit ofc.
>>
>> I requested a single patch instead of splitting it per driver, you might want
>> to blame me for that.
>>
>
> Doesn't splitting the change per driver break bisectability unless there
> is a guarantee that the change in include/drm/drm_drv.h is applied after
> all the driver trees have been merged?

That's why I said the final patch will likely take a bit longer to get
merged, since we have to wait until all the trees converge again. But
since I have conflicts already looks like we can't take the shortcut
:-(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: remove check for aux irq

[Ville Syrjälä]

On Wed, Apr 25, 2018 at 02:55:24PM -0700, Lucas De Marchi wrote:
> This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> GMBUS and AUX interrupts on gen4/g4x").
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  3 +--
>  drivers/gpu/drm/i915/intel_dp.c  | 22 +++---
>  drivers/gpu/drm/i915/intel_drv.h |  1 -
>  drivers/gpu/drm/i915/intel_psr.c |  2 +-
>  4 files changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8444ca8d5aa3..09e1c2289ea1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2545,7 +2545,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
>  
>  /*
> - * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> interrupts
> + * gmbus irq on gen4 seems to be able to generate legacy interrupts

Why are you removing vital information from the comment?

>   * even when in MSI mode. This results in spurious interrupt warnings if the
>   * legacy irq no. is shared with another device. The kernel then disables 
> that
>   * interrupt source and so prevents the other device from working properly.
> @@ -2553,7 +2553,6 @@ intel_info(const struct drm_i915_private *dev_priv)
>   * Since we don't enable MSI anymore on gen4, we can always use GMBUS/AUX
>   * interrupts.
>   */
> -#define HAS_AUX_IRQ(dev_priv)   true
>  #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
>  
>  /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..fd417473b6a9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
>  }
>  
>  static uint32_t
> -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
>   i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool 
> has_aux_irq)
>   bool done;
>  
>  #define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) 
> == 0)
> - if (has_aux_irq)
> - done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> -   msecs_to_jiffies_timeout(10));
> - else
> - done = wait_for(C, 10) == 0;
> + done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> +   msecs_to_jiffies_timeout(10));
>   if (!done)
> - DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
> -   has_aux_irq);
> + DRM_ERROR("dp aux hw did not signal timeout!\n");
>  #undef C
>  
>   return status;
> @@ -1016,7 +1012,6 @@ static uint32_t skl_get_aux_clock_divider(struct 
> intel_dp *intel_dp, int index)
>  }
>  
>  static uint32_t g4x_get_aux_send_ctl(struct intel_dp *intel_dp,
> -  bool has_aux_irq,
>int send_bytes,
>uint32_t aux_clock_divider)
>  {
> @@ -1037,7 +1032,7 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp 
> *intel_dp,
>  
>   return DP_AUX_CH_CTL_SEND_BUSY |
>  DP_AUX_CH_CTL_DONE |
> -(has_aux_irq ? DP_AUX_CH_CTL_INTERRUPT : 0) |
> +DP_AUX_CH_CTL_INTERRUPT |
>  DP_AUX_CH_CTL_TIME_OUT_ERROR |
>  timeout |
>  DP_AUX_CH_CTL_RECEIVE_ERROR |
> @@ -1047,13 +1042,12 @@ static uint32_t g4x_get_aux_send_ctl(struct intel_dp 
> *intel_dp,
>  }
>  
>  static uint32_t skl_get_aux_send_ctl(struct intel_dp *intel_dp,
> -   bool has_aux_irq,
> int send_bytes,
> uint32_t unused)
>  {
>   return DP_AUX_CH_CTL_SEND_BUSY |
>  DP_AUX_CH_CTL_DONE |
> -(has_aux_irq ? DP_AUX_CH_CTL_INTERRUPT : 0) |
> +DP_AUX_CH_CTL_INTERRUPT |
>  DP_AUX_CH_CTL_TIME_OUT_ERROR |
>  DP_AUX_CH_CTL_TIME_OUT_MAX |
>  DP_AUX_CH_CTL_RECEIVE_ERROR |
> @@ -1076,7 +1070,6 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>   int i, ret, recv_bytes;
>   uint32_t status;
>   int try, clock = 0;
> - bool has_aux_irq = HAS_AUX_IRQ(dev_priv);
>   bool vdd;
>  
>   ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> @@ -1131,7 +1124,6 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp,
>  
>   while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
> clock++))) {
>   u32 send_ctl = 

Re: [Intel-gfx] [RFC] drm/i915: Rework "Potential atomic update error" to handle PSR exit

[Ville Syrjälä]

On Wed, Apr 25, 2018 at 07:10:09PM -0700, tarun.v...@intel.com wrote:
> From: Tarun 
> 
> The Display scanline counter freezes on PSR entry. Inside
> intel_pipe_update_start, once Vblank interrupts are enabled, we start
> exiting PSR, but by the time the scanline counter is read, we may not
> have completely exited PSR which leads us to schedule out and check back
> later.
> On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but
> lags w.r.t core kernel code, hot plugging an external display triggers
> tons of "potential atomic update errors" in the dmesg, on *pipe A*. A
> closer analysis reveals that we try to read the scanline 3 times and
> eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL stuck @
> 1599.
> This issue is not seen on upstream kernels, b/c for *some* reason we
> loop inside intel_pipe_update start for ~2+ msec which in this case is
> more than enough to exit PSR fully, hence an *unstuck* PIPEDSL counter,
> hence no error. On the other hand, the ChromeOS kernel spends ~1.1 msec
> looping inside intel_pipe_update_start and hence errors out b/c the
> source is still in PSR.
> 
> If PSR is enabled, then we should *wait* for  the PSR
> state to move to IDLE before re-reading the PIPEDSL so as to avoid bogus
> and annoying "potential atomic update error" messages.
> 
> P.S: This scenario applies to a configuration with an additional pipe,
> as of now.
> 
> Signed-off-by: Tarun 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index aa1dfaa692b9..77dd3b936131 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -92,11 +92,13 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   const struct drm_display_mode *adjusted_mode = 
> _crtc_state->base.adjusted_mode;
>   long timeout = msecs_to_jiffies_timeout(1);
> - int scanline, min, max, vblank_start;
> + int scanline, min, max, vblank_start, old_scanline, new_scanline;
> + bool retried = false;
>   wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
>   bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || 
> IS_CHERRYVIEW(dev_priv)) &&
>   intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
>   DEFINE_WAIT(wait);
> + old_scanline = new_scanline = -1;
>  
>   vblank_start = adjusted_mode->crtc_vblank_start;
>   if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> @@ -126,15 +128,24 @@ void intel_pipe_update_start(const struct 
> intel_crtc_state *new_crtc_state)
>* read the scanline.
>*/
>   prepare_to_wait(wq, , TASK_UNINTERRUPTIBLE);
> -
> +retry:
>   scanline = intel_get_crtc_scanline(crtc);
> + old_scanline = new_scanline, new_scanline = scanline;
> +
>   if (scanline < min || scanline > max)
>   break;
>  
>   if (timeout <= 0) {
> - DRM_ERROR("Potential atomic update failure on pipe 
> %c\n",
> + if(!i915.enable_psr || retried) {
> + DRM_ERROR("Potential atomic update failure on 
> pipe %c\n",
> pipe_name(crtc->pipe));
> - break;
> + break;
> + }
> + else if(old_scanline == new_scanline && !retried) {
> + retried = true;
> + intel_wait_for_register(dev_priv, 
> EDP_PSR_STATUS_CTL, EDP_PSR_STATUS_STATE_MASK, EDP_PSR_STATUS_STATE_IDLE, 10);

What's the point of obfuscating the loop with this stuff?
Just wait for the PSR exit before we even enter the loop?

> + goto retry;
> + }
>   }
>  
>   local_irq_enable();
> -- 
> 2.13.5
> 
> ___
> 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 v2 2/3] drm/i915/dp: Fix sink-crc reads.

[Ville Syrjälä]

On Wed, Apr 25, 2018 at 02:57:57PM -0700, Dhinakaran Pandiyan wrote:
> Sink crc is calculated by the sink for static frames irrespective of
> what the driver sets in TEST_SINK_START dpcd. Since PSR is the only use
> case for sink crc, we don't really need the sink_crc_{start, stop} code.
> 
> The second problem with the current implementation is vblank waits.
> Enabling vblank interrupts triggers PSR exit, which means we aren't
> really reading the correct CRC values for PSR tests. vblank waits are
> replaced by delays.
> 
> With the changes made in this patch, sink CRC is available only for
> static frames. I have tested this on a SKL laptop with PSR panel.
> 
> v2: Use refresh rate to calculate frame time.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |   4 +-
>  drivers/gpu/drm/i915/intel_dp.c | 115 
> +---
>  drivers/gpu/drm/i915/intel_drv.h|   3 +-
>  3 files changed, 18 insertions(+), 104 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 2f05f5262bba..e4ba6527c16e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2749,6 +2749,7 @@ static int i915_sink_crc(struct seq_file *m, void *data)
>   struct drm_crtc *crtc;
>   struct drm_connector_state *state;
>   struct intel_crtc_state *crtc_state;
> + int vrefresh;
>  
>   if (connector->base.connector_type != DRM_MODE_CONNECTOR_eDP)
>   continue;
> @@ -2783,8 +2784,9 @@ static int i915_sink_crc(struct seq_file *m, void *data)
>   }
>  
>   intel_dp = enc_to_intel_dp(state->best_encoder);
> + vrefresh = crtc_state->base.adjusted_mode.vrefresh;

Hmm. Is vrefresh always populated correctly for us?

-- 
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 2/3] drm/rect: Handle rounding errors in drm_rect_clip_scaled

[Daniel Vetter]

On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
> 
> Signed-off-by: Maarten Lankhorst 

I think this and the previous patch are perfect candidates for in-kernel
selftests. Can I volunteer you to get those started for the kms side? We
already have a drm_mm selftest, but I think splitting things a bit might
be useful.

Or we rename that one and just stuff all the kms tests in there, dunno.
-Daniel

> ---
>  drivers/gpu/drm/drm_rect.c | 65 +++---
>  1 file changed, 47 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index b179c7c73cc5..71b6b7f5d58f 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -50,6 +50,24 @@ bool drm_rect_intersect(struct drm_rect *r1, const struct 
> drm_rect *r2)
>  }
>  EXPORT_SYMBOL(drm_rect_intersect);
>  
> +static int drm_calc_scale(int src, int dst)
> +{
> + int scale = 0;
> +
> + if (WARN_ON(src < 0 || dst < 0))
> + return -EINVAL;
> +
> + if (dst == 0)
> + return 0;
> +
> + if (src > (dst << 16))
> + return DIV_ROUND_UP(src, dst);
> + else
> + scale = src / dst;
> +
> + return scale;
> +}
> +
>  /**
>   * drm_rect_clip_scaled - perform a scaled clip operation
>   * @src: source window rectangle
> @@ -71,49 +89,60 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct 
> drm_rect *dst,
>  {
>   int diff;
>  
> + /*
> +  * When scale is near 0x1 rounding errors may cause the scaling
> +  * factor to the other side. Some hardware may support
> +  * upsampling, but not downsampling, and that would break when
> +  * rounding.
> +  */
> +#define FIXUP(oldscale, fn, m, second) do { \
> + if (oldscale != 1 << 16) { \
> + int newscale = drm_calc_scale(fn(src), fn(dst)); \
> + \
> + if (newscale < 0) \
> + return false; \
> + \
> + if ((oldscale < 0x1) != (newscale < 0x1)) { \
> + if (!second) \
> + src->m##1 = src->m##2 - ((fn(dst) - diff) << 
> 16); \
> + else \
> + src->m##2 = src->m##1 + ((fn(dst) - diff) << 
> 16); \
> + } \
> + } \
> + } while (0)
> +
>   diff = clip->x1 - dst->x1;
>   if (diff > 0) {
>   int64_t tmp = src->x1 + (int64_t) diff * hscale;
>   src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 0);
>   }
> +
>   diff = clip->y1 - dst->y1;
>   if (diff > 0) {
>   int64_t tmp = src->y1 + (int64_t) diff * vscale;
>   src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 0);
>   }
> +
>   diff = dst->x2 - clip->x2;
>   if (diff > 0) {
>   int64_t tmp = src->x2 - (int64_t) diff * hscale;
>   src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(hscale, drm_rect_width, x, 1);
>   }
>   diff = dst->y2 - clip->y2;
>   if (diff > 0) {
>   int64_t tmp = src->y2 - (int64_t) diff * vscale;
>   src->y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
> + FIXUP(vscale, drm_rect_height, y, 1);
>   }
> +#undef FIXUP
>  
>   return drm_rect_intersect(dst, clip);
>  }
>  EXPORT_SYMBOL(drm_rect_clip_scaled);
>  
> -static int drm_calc_scale(int src, int dst)
> -{
> - int scale = 0;
> -
> - if (WARN_ON(src < 0 || dst < 0))
> - return -EINVAL;
> -
> - if (dst == 0)
> - return 0;
> -
> - if (src > (dst << 16))
> - return DIV_ROUND_UP(src, dst);
> - else
> - scale = src / dst;
> -
> - return scale;
> -}
> -
>  /**
>   * drm_rect_calc_hscale - calculate the horizontal scaling factor
>   * @src: source window rectangle
> -- 
> 2.17.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Don't pass the index to drm_property_add_enum() (rev3)

[Patchwork]

== Series Details ==

Series: drm: Don't pass the index to drm_property_add_enum() (rev3)
URL   : https://patchwork.freedesktop.org/series/40122/
State : failure

== Summary ==

Applying: drm: Don't pass the index to drm_property_add_enum()
error: patch failed: drivers/gpu/drm/drm_connector.c:1069
error: drivers/gpu/drm/drm_connector.c: patch does not apply
error: patch failed: drivers/gpu/drm/drm_property.c:169
error: drivers/gpu/drm/drm_property.c: patch does not apply
error: patch failed: drivers/gpu/drm/gma500/cdv_device.c:485
error: drivers/gpu/drm/gma500/cdv_device.c: patch does not apply
error: patch failed: drivers/gpu/drm/gma500/psb_intel_sdvo.c:2281
error: drivers/gpu/drm/gma500/psb_intel_sdvo.c: patch does not apply
error: patch failed: drivers/gpu/drm/i915/intel_sdvo.c:2779
error: drivers/gpu/drm/i915/intel_sdvo.c: patch does not apply
error: patch failed: drivers/gpu/drm/nouveau/nouveau_display.c:338
error: drivers/gpu/drm/nouveau/nouveau_display.c: patch does not apply
error: patch failed: include/drm/drm_property.h:260
error: include/drm/drm_property.h: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/gma500/psb_intel_sdvo.c
M   include/drm/drm_property.h
Patch failed at 0001 drm: Don't pass the index to drm_property_add_enum()
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

[Ville Syrjälä]

On Mon, Apr 23, 2018 at 11:27:13AM -0400, Dave Jones wrote:
> This warning just started appearing during boot on a machine I upgraded
> to 4.17-rc2.  The warning seems to have been there since 2015, but it
> has never triggered before today.

Looks like we have bug open about this. I just asked for more
information there:
https://bugs.freedesktop.org/show_bug.cgi?id=105992#c5

If you can also boot with drm.debug=0xe maybe we can see some more
details about the supposedly bad watermarks.

> 
>   Dave
> 
> [1.158500] fb: switching to inteldrmfb from EFI VGA
> [1.159073] Console: switching to colour dummy device 80x25
> [1.159523] checking generic (a 1) vs hw (e000 1000)
> [1.159539] fb: switching to inteldrmfb from VGA16 VGA
> [1.159752] [drm] Replacing VGA console driver
> [1.164454] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [1.164472] [drm] Driver supports precise vblank timestamp query.
> [1.167285] i915 :00:02.0: vgaarb: changed VGA decodes: 
> olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [1.170212] [ cut here ]
> [1.170230] Could not determine valid watermarks for inherited state
> [1.170267] WARNING: CPU: 1 PID: 1 at 
> drivers/gpu/drm/i915/intel_display.c:14584 sanitize_watermarks+0x17b/0x1c0
> [1.170291] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc2+ #1
> [1.170308] Hardware name: Shuttle Inc. SH87R/FH87, BIOS 2.03 06/19/2014
> [1.170325] RIP: 0010:sanitize_watermarks+0x17b/0x1c0
> [1.170338] RSP: :a944c0023bf0 EFLAGS: 00010246
> [1.170352] RAX:  RBX: 9193508c RCX: 
> 
> [1.170369] RDX: 0001 RSI: 990b7399 RDI: 
> 990b7399
> [1.170385] RBP: 9193508c R08: 0001 R09: 
> 0001
> [1.170401] R10:  R11:  R12: 
> ffea
> [1.170418] R13: 9193508faa88 R14: 919350823528 R15: 
> 9193508c0a08
> [1.170434] FS:  () GS:91935640() 
> knlGS:
> [1.170453] CS:  0010 DS:  ES:  CR0: 80050033
> [1.170466] CR2:  CR3: 00011d224001 CR4: 
> 000606e0
> [1.170483] Call Trace:
> [1.170493]  intel_modeset_init+0x769/0x18f0
> [1.170506]  i915_driver_load+0x9b9/0xf30
> [1.170519]  ? _raw_spin_unlock_irqrestore+0x3f/0x70
> [1.170534]  pci_device_probe+0xa3/0x120
> [1.170546]  driver_probe_device+0x28a/0x320
> [1.170557]  __driver_attach+0x9e/0xb0
> [1.170568]  ? driver_probe_device+0x320/0x320
> [1.170581]  bus_for_each_dev+0x68/0xc0
> [1.170592]  bus_add_driver+0x11d/0x210
> [1.170604]  ? mipi_dsi_bus_init+0x11/0x11
> [1.170615]  driver_register+0x5b/0xd0
> [1.170627]  do_one_initcall+0x10b/0x33f
> [1.170638]  ? do_early_param+0x8b/0x8b
> [1.170651]  ? rcu_read_lock_sched_held+0x66/0x70
> [1.170663]  ? do_early_param+0x8b/0x8b
> [1.170674]  kernel_init_freeable+0x1c3/0x249
> [1.170687]  ? rest_init+0xc0/0xc0
> [1.170697]  kernel_init+0xa/0x100
> [1.170707]  ret_from_fork+0x24/0x30
> [1.170717] Code: 00 00 00 65 48 33 04 25 28 00 00 00 75 4f 48 8d a4 24 88 
> 00 00 00 5b 5d 41 5c 41 5d 41 5e c3 48 c7 c7 e0 5d 04 9a e8 25 33 b1 ff <0f> 
> 0b eb a4 48 c7 c6 d5 73 04 9a 48 c7 c7 0f c6 fe 99 e8 0e 33 
> [1.170847] irq event stamp: 1449710
> [1.170858] hardirqs last  enabled at (1449709): [] 
> console_unlock+0x51b/0x6b0
> [1.170879] hardirqs last disabled at (1449710): [] 
> error_entry+0x86/0x100
> [1.170900] softirqs last  enabled at (1449580): [] 
> __do_softirq+0x3dd/0x521
> [1.170922] softirqs last disabled at (1449563): [] 
> irq_exit+0xb7/0xc0
> 
> 
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
> Core Processor Integrated Graphics Controller (rev 06)
> 
> (That's 8086:0402 fwiw)
> 
> ___
> 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] drm/core: Remove drm_dev_unref() and it's uses

[Vaishali Thakkar]

On Thu, Apr 26, 2018 at 6:15 PM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > It's been a while since we introduced drm_dev{get/put} functions
>> > to replace reference/unreference in drm subsystem for the
>> > consistency purpose. So, with this patch, let's just replace
>> > all current use cases of drm_dev_unref() with drm_dev_put and remove
>> > the function itself.
>> >
>> > Coccinelle was used for mass-patching.
>> >
>> > Signed-off-by: Vaishali Thakkar 
>>
>> Thanks for doing this. Unfortunately drm moves pretty fast, so already a
>> conflict when I tried to apply this. Some drivers are also in their own
>> trees, so this might lead to more fun :-/
>>
>> Can you pls split it up per-driver (just the directories under
>> drivers/gpu/drm/ is enough)? Final patch to remove the function might then
>> get stalled a bit ofc.
>
> I requested a single patch instead of splitting it per driver, you might want
> to blame me for that.
>
>> Also can you pls update ./scripts/coccinelle/api/drm-get-put.cocci and
>> remove that spatch hunk in the final patch, since we no longer need it?
>
> How about just rerunning the coccinelle patch when it's time to apply this ?
> There's precedent for performing such automated changes, and it would ensure
> that no driver is left out.

I was planning to send patches to remove all remaining reference/unreference
functions by the weekend [as there aren't much remaining now and I see that
new drivers keeps adding them instead of new API]. So, wanted to delete whole
cocci file after that. I thought of dividing a patch per function because
Laurent requested to send a single patch for all files.

But if we are going to split it per driver under gpu/drm, would it work if per
driver patch contains all function cases? Also, would you be fine with taking a
patch for removal of coccinelle file via your tree? Then I can include that in
the same patchset as well.

Thanks!

>> > ---
>> >
>> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
>> >  drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
>> >  drivers/gpu/drm/armada/armada_drv.c|  6 +++---
>> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--
>> >  drivers/gpu/drm/drm_drv.c  | 13 -
>> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 ++--
>> >  drivers/gpu/drm/exynos/exynos_drm_drv.c|  4 ++--
>> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |  4 ++--
>> >  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  4 ++--
>> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  8 
>> >  drivers/gpu/drm/i915/selftests/huge_pages.c|  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_request.c  |  2 +-
>> >  drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
>> >  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
>> >  drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
>> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +++---
>> >  drivers/gpu/drm/msm/msm_drv.c  |  8 
>> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 ++--
>> >  drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
>> >  drivers/gpu/drm/omapdrm/omap_drv.c |  4 ++--
>> >  drivers/gpu/drm/pl111/pl111_drv.c  |  4 ++--
>> >  drivers/gpu/drm/qxl/qxl_drv.c  |  2 +-
>> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  2 +-
>> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  4 ++--
>> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  4 ++--
>> >  drivers/gpu/drm/sti/sti_drv.c  |  8 
>> >  drivers/gpu/drm/stm/drv.c  |  4 ++--
>> >  drivers/gpu/drm/sun4i/sun4i_drv.c  |  4 ++--
>> >  drivers/gpu/drm/tegra/drm.c|  4 ++--
>> >  drivers/gpu/drm/tinydrm/core/tinydrm-core.c|  6 +++---
>> >  drivers/gpu/drm/tve200/tve200_drv.c|  4 ++--
>> >  drivers/gpu/drm/udl/udl_drv.c  |  2 +-
>> >  drivers/gpu/drm/vc4/vc4_drv.c  |  4 ++--
>> >  drivers/gpu/drm/vgem/vgem_drv.c|  2 +-
>> >  drivers/gpu/drm/virtio/virtgpu_drm_bus.c   |  2 +-
>> >  drivers/gpu/drm/zte/zx_drm_drv.c   |  4 ++--
>> >  include/drm/drm_drv.h  |  1 -
>> >  41 files changed, 73 insertions(+), 87 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>



-- 
Vaishali

Re: [Intel-gfx] [PATCH] drm/i915: Request driver probe from an async task

[Imre Deak]

On Thu, Apr 26, 2018 at 03:41:57PM +0300, David Weinehall wrote:
> On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> > As we are careful not to register external interfaces before the
> > internals are brought up, we are not dependent upon a synchronous
> > probing and can allow ourselves to be probed from a secondary thread
> > during system bootup. We already do relegate some configuration to
> > asynchronous tasks (such as setting up the fbdev), now do the entire
> > probe.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=105622
> > Signed-off-by: Chris Wilson 
> 
> LGTM, and still seems to apply cleanly.
> 
> Reviewed-by: David Weinehall 

One problem with this is that atm in snd_hdac_i915_init()
request_module() is expected to return only once the i915 probe function
has run. With async probing this won't be any more the case.

+Takashi

> 
> > Cc: Imre Deak 
> > Cc: Ville Syrjälä 
> > Cc: David Weinehall 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 4364922e935d..be7b03d48229 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -726,6 +726,7 @@ static struct pci_driver i915_pci_driver = {
> > .probe = i915_pci_probe,
> > .remove = i915_pci_remove,
> > .driver.pm = _pm_ops,
> > +   .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> >  };
> >  
> >  static int __init i915_init(void)
> > -- 
> > 2.16.2
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Request driver probe from an async task

[Chris Wilson]

Quoting David Weinehall (2018-04-26 13:41:57)
> On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> > As we are careful not to register external interfaces before the
> > internals are brought up, we are not dependent upon a synchronous
> > probing and can allow ourselves to be probed from a secondary thread
> > during system bootup. We already do relegate some configuration to
> > asynchronous tasks (such as setting up the fbdev), now do the entire
> > probe.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=105622
> > Signed-off-by: Chris Wilson 
> 
> LGTM, and still seems to apply cleanly.
> 
> Reviewed-by: David Weinehall 

The one downside to this was that it's only useful for builtins. For
modules, the finit_module call serialises on the async task, so
parallelisation has to occur in userspace.

> > Cc: Imre Deak 
> > Cc: Ville Syrjälä 
> > Cc: David Weinehall 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 4364922e935d..be7b03d48229 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -726,6 +726,7 @@ static struct pci_driver i915_pci_driver = {
> >   .probe = i915_pci_probe,
> >   .remove = i915_pci_remove,
> >   .driver.pm = _pm_ops,
> > + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,

I thought I sent a v2 with IS_BUILTIN() ? PREFER_ASYNC : 0,
possibly not.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Laurent Pinchart]

Hi Daniel,

On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> > It's been a while since we introduced drm_dev{get/put} functions
> > to replace reference/unreference in drm subsystem for the
> > consistency purpose. So, with this patch, let's just replace
> > all current use cases of drm_dev_unref() with drm_dev_put and remove
> > the function itself.
> > 
> > Coccinelle was used for mass-patching.
> > 
> > Signed-off-by: Vaishali Thakkar 
> 
> Thanks for doing this. Unfortunately drm moves pretty fast, so already a
> conflict when I tried to apply this. Some drivers are also in their own
> trees, so this might lead to more fun :-/
> 
> Can you pls split it up per-driver (just the directories under
> drivers/gpu/drm/ is enough)? Final patch to remove the function might then
> get stalled a bit ofc.

I requested a single patch instead of splitting it per driver, you might want 
to blame me for that.

> Also can you pls update ./scripts/coccinelle/api/drm-get-put.cocci and
> remove that spatch hunk in the final patch, since we no longer need it?

How about just rerunning the coccinelle patch when it's time to apply this ? 
There's precedent for performing such automated changes, and it would ensure 
that no driver is left out.

> > ---
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
> >  drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
> >  drivers/gpu/drm/armada/armada_drv.c|  6 +++---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--
> >  drivers/gpu/drm/drm_drv.c  | 13 -
> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 ++--
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c|  4 ++--
> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |  4 ++--
> >  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  4 ++--
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  8 
> >  drivers/gpu/drm/i915/selftests/huge_pages.c|  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_request.c  |  2 +-
> >  drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
> >  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
> >  drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +++---
> >  drivers/gpu/drm/msm/msm_drv.c  |  8 
> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 ++--
> >  drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
> >  drivers/gpu/drm/omapdrm/omap_drv.c |  4 ++--
> >  drivers/gpu/drm/pl111/pl111_drv.c  |  4 ++--
> >  drivers/gpu/drm/qxl/qxl_drv.c  |  2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  2 +-
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  4 ++--
> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  4 ++--
> >  drivers/gpu/drm/sti/sti_drv.c  |  8 
> >  drivers/gpu/drm/stm/drv.c  |  4 ++--
> >  drivers/gpu/drm/sun4i/sun4i_drv.c  |  4 ++--
> >  drivers/gpu/drm/tegra/drm.c|  4 ++--
> >  drivers/gpu/drm/tinydrm/core/tinydrm-core.c|  6 +++---
> >  drivers/gpu/drm/tve200/tve200_drv.c|  4 ++--
> >  drivers/gpu/drm/udl/udl_drv.c  |  2 +-
> >  drivers/gpu/drm/vc4/vc4_drv.c  |  4 ++--
> >  drivers/gpu/drm/vgem/vgem_drv.c|  2 +-
> >  drivers/gpu/drm/virtio/virtgpu_drm_bus.c   |  2 +-
> >  drivers/gpu/drm/zte/zx_drm_drv.c   |  4 ++--
> >  include/drm/drm_drv.h  |  1 -
> >  41 files changed, 73 insertions(+), 87 deletions(-)

-- 
Regards,

Laurent Pinchart



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

Re: [Intel-gfx] [PATCH] drm: Don't pass the index to drm_property_add_enum()

[Lisovskiy, Stanislav]

Reviewed-by: Stanislav Lisovskiy 

Best Regards,

Lisovskiy Stanislav

Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of 
Lisovskiy, Stanislav [stanislav.lisovs...@intel.com]
Sent: Monday, April 23, 2018 4:59 PM
To: Ville Syrjala; dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben Skeggs
Subject: Re: [Intel-gfx] [PATCH] drm: Don't pass the index to 
drm_property_add_enum()

Acked-by: Stanislav Lisovskiy 

Best Regards,

Lisovskiy Stanislav

Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo>


From: Ville Syrjala [ville.syrj...@linux.intel.com]
Sent: Friday, March 16, 2018 9:04 PM
To: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org; Patrik Jakobsson; Ben Skeggs; 
nouv...@lists.freedesktop.org
Subject: [PATCH] drm: Don't pass the index to drm_property_add_enum()

From: Ville Syrjälä 

drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.

Cc: Patrik Jakobsson 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c   |  6 +++---
 drivers/gpu/drm/drm_property.c| 27 +--
 drivers/gpu/drm/gma500/cdv_device.c   |  4 ++--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +---
 include/drm/drm_property.h|  2 +-
 7 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..dfc8ca1e9413 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1069,7 +1069,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
goto nomem;

for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.tv_mode_property, i,
+   drm_property_add_enum(dev->mode_config.tv_mode_property,
  i, modes[i]);

dev->mode_config.tv_brightness_property =
@@ -1156,7 +1156,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
struct drm_property *scaling_mode_property;
-   int i, j = 0;
+   int i;
const unsigned valid_scaling_mode_mask =
(1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;

@@ -1177,7 +1177,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
if (!(BIT(i) & scaling_mode_mask))
continue;

-   ret = drm_property_add_enum(scaling_mode_property, j++,
+   ret = drm_property_add_enum(scaling_mode_property,
drm_scaling_mode_enum_list[i].type,
drm_scaling_mode_enum_list[i].name);

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 8f4672daac7f..1f8031e30f53 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -169,9 +169,9 @@ struct drm_property *drm_property_create_enum(struct 
drm_device *dev,
return NULL;

for (i = 0; i < num_values; i++) {
-   ret = drm_property_add_enum(property, i,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -209,7 +209,7 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 uint64_t supported_bits)
 {
struct drm_property *property;
-   int i, ret, index = 0;
+   int i, ret;
int num_values = hweight64(supported_bits);

flags |= DRM_MODE_PROP_BITMASK;
@@ -221,14 +221,9 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
if (!(supported_bits & (1ULL << props[i].type)))
continue;

-   if (WARN_ON(index >= num_values)) {
-   drm_property_destroy(dev, property);
-   return NULL;
-   }
-
-   ret = drm_property_add_enum(property, index++,
- 

Re: [Intel-gfx] 4.17-rc2: Could not determine valid watermarks for inherited state

[Jani Nikula]

Cc: Maarten, Ville

On Mon, 23 Apr 2018, Dave Jones  wrote:
> This warning just started appearing during boot on a machine I upgraded
> to 4.17-rc2.  The warning seems to have been there since 2015, but it
> has never triggered before today.
>
>   Dave
>
> [1.158500] fb: switching to inteldrmfb from EFI VGA
> [1.159073] Console: switching to colour dummy device 80x25
> [1.159523] checking generic (a 1) vs hw (e000 1000)
> [1.159539] fb: switching to inteldrmfb from VGA16 VGA
> [1.159752] [drm] Replacing VGA console driver
> [1.164454] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [1.164472] [drm] Driver supports precise vblank timestamp query.
> [1.167285] i915 :00:02.0: vgaarb: changed VGA decodes: 
> olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [1.170212] [ cut here ]
> [1.170230] Could not determine valid watermarks for inherited state
> [1.170267] WARNING: CPU: 1 PID: 1 at 
> drivers/gpu/drm/i915/intel_display.c:14584 sanitize_watermarks+0x17b/0x1c0
> [1.170291] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc2+ #1
> [1.170308] Hardware name: Shuttle Inc. SH87R/FH87, BIOS 2.03 06/19/2014
> [1.170325] RIP: 0010:sanitize_watermarks+0x17b/0x1c0
> [1.170338] RSP: :a944c0023bf0 EFLAGS: 00010246
> [1.170352] RAX:  RBX: 9193508c RCX: 
> 
> [1.170369] RDX: 0001 RSI: 990b7399 RDI: 
> 990b7399
> [1.170385] RBP: 9193508c R08: 0001 R09: 
> 0001
> [1.170401] R10:  R11:  R12: 
> ffea
> [1.170418] R13: 9193508faa88 R14: 919350823528 R15: 
> 9193508c0a08
> [1.170434] FS:  () GS:91935640() 
> knlGS:
> [1.170453] CS:  0010 DS:  ES:  CR0: 80050033
> [1.170466] CR2:  CR3: 00011d224001 CR4: 
> 000606e0
> [1.170483] Call Trace:
> [1.170493]  intel_modeset_init+0x769/0x18f0
> [1.170506]  i915_driver_load+0x9b9/0xf30
> [1.170519]  ? _raw_spin_unlock_irqrestore+0x3f/0x70
> [1.170534]  pci_device_probe+0xa3/0x120
> [1.170546]  driver_probe_device+0x28a/0x320
> [1.170557]  __driver_attach+0x9e/0xb0
> [1.170568]  ? driver_probe_device+0x320/0x320
> [1.170581]  bus_for_each_dev+0x68/0xc0
> [1.170592]  bus_add_driver+0x11d/0x210
> [1.170604]  ? mipi_dsi_bus_init+0x11/0x11
> [1.170615]  driver_register+0x5b/0xd0
> [1.170627]  do_one_initcall+0x10b/0x33f
> [1.170638]  ? do_early_param+0x8b/0x8b
> [1.170651]  ? rcu_read_lock_sched_held+0x66/0x70
> [1.170663]  ? do_early_param+0x8b/0x8b
> [1.170674]  kernel_init_freeable+0x1c3/0x249
> [1.170687]  ? rest_init+0xc0/0xc0
> [1.170697]  kernel_init+0xa/0x100
> [1.170707]  ret_from_fork+0x24/0x30
> [1.170717] Code: 00 00 00 65 48 33 04 25 28 00 00 00 75 4f 48 8d a4 24 88 
> 00 00 00 5b 5d 41 5c 41 5d 41 5e c3 48 c7 c7 e0 5d 04 9a e8 25 33 b1 ff <0f> 
> 0b eb a4 48 c7 c6 d5 73 04 9a 48 c7 c7 0f c6 fe 99 e8 0e 33 
> [1.170847] irq event stamp: 1449710
> [1.170858] hardirqs last  enabled at (1449709): [] 
> console_unlock+0x51b/0x6b0
> [1.170879] hardirqs last disabled at (1449710): [] 
> error_entry+0x86/0x100
> [1.170900] softirqs last  enabled at (1449580): [] 
> __do_softirq+0x3dd/0x521
> [1.170922] softirqs last disabled at (1449563): [] 
> irq_exit+0xb7/0xc0
>
>
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen 
> Core Processor Integrated Graphics Controller (rev 06)
>
> (That's 8086:0402 fwiw)
>

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

Re: [Intel-gfx] [PATCH] drm/i915: Request driver probe from an async task

[David Weinehall]

On Fri, Mar 23, 2018 at 08:30:48AM +, Chris Wilson wrote:
> As we are careful not to register external interfaces before the
> internals are brought up, we are not dependent upon a synchronous
> probing and can allow ourselves to be probed from a secondary thread
> during system bootup. We already do relegate some configuration to
> asynchronous tasks (such as setting up the fbdev), now do the entire
> probe.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105622
> Signed-off-by: Chris Wilson 

LGTM, and still seems to apply cleanly.

Reviewed-by: David Weinehall 

> Cc: Imre Deak 
> Cc: Ville Syrjälä 
> Cc: David Weinehall 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 4364922e935d..be7b03d48229 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -726,6 +726,7 @@ static struct pci_driver i915_pci_driver = {
>   .probe = i915_pci_probe,
>   .remove = i915_pci_remove,
>   .driver.pm = _pm_ops,
> + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
>  };
>  
>  static int __init i915_init(void)
> -- 
> 2.16.2
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

[Patchwork]

== Series Details ==

Series: drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen
URL   : https://patchwork.freedesktop.org/series/42331/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8813 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42331/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8813 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: PASS -> FAIL (fdo#102575)

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)

igt@kms_frontbuffer_tracking@basic:
  fi-cnl-y3:  PASS -> FAIL (fdo#103167)


 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128) -> PASS

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-elk-e7500:   DMESG-WARN (fdo#103989, fdo#105225) -> PASS

igt@kms_flip@basic-plain-flip:
  fi-elk-e7500:   DMESG-WARN (fdo#105225) -> PASS


  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#105225 https://bugs.freedesktop.org/show_bug.cgi?id=105225


== Participating hosts (38 -> 35) ==

  Additional (1): fi-pnv-d510 
  Missing(4): fi-byt-j1900 fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4103 -> Patchwork_8813

  CI_DRM_4103: 96d389ab8f2f1e05b9ba5feacef7185f59a129db @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8813: d58b3639fa7c187535960d42372463103a13d409 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

d58b3639fa7c drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8813/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Daniel Vetter]

On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with drm_dev_put and remove
> the function itself.
> 
> Coccinelle was used for mass-patching.
> 
> Signed-off-by: Vaishali Thakkar 

Thanks for doing this. Unfortunately drm moves pretty fast, so already a
conflict when I tried to apply this. Some drivers are also in their own
trees, so this might lead to more fun :-/

Can you pls split it up per-driver (just the directories under
drivers/gpu/drm/ is enough)? Final patch to remove the function might then
get stalled a bit ofc.

Also can you pls update ./scripts/coccinelle/api/drm-get-put.cocci and
remove that spatch hunk in the final patch, since we no longer need it?

Thanks, Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
>  drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
>  drivers/gpu/drm/armada/armada_drv.c|  6 +++---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--
>  drivers/gpu/drm/drm_drv.c  | 13 -
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|  4 ++--
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |  4 ++--
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  4 ++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  8 
>  drivers/gpu/drm/i915/selftests/huge_pages.c|  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_request.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +++---
>  drivers/gpu/drm/msm/msm_drv.c  |  8 
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c |  4 ++--
>  drivers/gpu/drm/pl111/pl111_drv.c  |  4 ++--
>  drivers/gpu/drm/qxl/qxl_drv.c  |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  4 ++--
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  4 ++--
>  drivers/gpu/drm/sti/sti_drv.c  |  8 
>  drivers/gpu/drm/stm/drv.c  |  4 ++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c  |  4 ++--
>  drivers/gpu/drm/tegra/drm.c|  4 ++--
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c|  6 +++---
>  drivers/gpu/drm/tve200/tve200_drv.c|  4 ++--
>  drivers/gpu/drm/udl/udl_drv.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_drv.c  |  4 ++--
>  drivers/gpu/drm/vgem/vgem_drv.c|  2 +-
>  drivers/gpu/drm/virtio/virtgpu_drm_bus.c   |  2 +-
>  drivers/gpu/drm/zte/zx_drm_drv.c   |  4 ++--
>  include/drm/drm_drv.h  |  1 -
>  41 files changed, 73 insertions(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 0b19482b36b8..5fb455febeba 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -647,7 +647,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>  err_pci:
>   pci_disable_device(pdev);
>  err_free:
> - drm_dev_unref(dev);
> + drm_dev_put(dev);
>   return ret;
>  }
>  
> @@ -657,7 +657,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>   struct drm_device *dev = pci_get_drvdata(pdev);
>  
>   drm_dev_unregister(dev);
> - drm_dev_unref(dev);
> + drm_dev_put(dev);
>   pci_disable_device(pdev);
>   pci_set_drvdata(pdev, NULL);
>  }
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c 
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index f067de4e1e82..dcb06d4e9135 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -216,7 +216,7 @@ static int arcpgu_probe(struct platform_device *pdev)
>   arcpgu_unload(drm);
>  
>  err_unref:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
>  
>   return ret;
>  }
> @@ -227,7 +227,7 @@ static int arcpgu_remove(struct platform_device *pdev)
>  
>   drm_dev_unregister(drm);
>   arcpgu_unload(drm);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Compile out engine debug for release

[Patchwork]

== Series Details ==

Series: drm/i915: Compile out engine debug for release
URL   : https://patchwork.freedesktop.org/series/42327/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8812 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42327/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8812 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: PASS -> FAIL (fdo#102575)

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-cnl-psr: PASS -> FAIL (fdo#100368)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128) -> PASS

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-elk-e7500:   DMESG-WARN (fdo#103989, fdo#105225) -> PASS

igt@kms_flip@basic-plain-flip:
  fi-elk-e7500:   DMESG-WARN (fdo#105225) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#105225 https://bugs.freedesktop.org/show_bug.cgi?id=105225
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084


== Participating hosts (38 -> 35) ==

  Additional (1): fi-pnv-d510 
  Missing(4): fi-byt-j1900 fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4103 -> Patchwork_8812

  CI_DRM_4103: 96d389ab8f2f1e05b9ba5feacef7185f59a129db @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8812: 5271cd637c80f6960e17d44da1fd499597dc510b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

5271cd637c80 drm/i915: Compile out engine debug for release

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8812/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Boris Brezillon]

On Thu, 26 Apr 2018 15:58:19 +0530
Vaishali Thakkar  wrote:

> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with drm_dev_put and remove
> the function itself.
> 
> Coccinelle was used for mass-patching.
> 
> Signed-off-by: Vaishali Thakkar 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
>  drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
>  drivers/gpu/drm/armada/armada_drv.c|  6 +++---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--

For atmel-hlcdc:

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

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Thierry Reding]

On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with drm_dev_put and remove
> the function itself.
> 
> Coccinelle was used for mass-patching.
> 
> Signed-off-by: Vaishali Thakkar 

Yes, please.

Acked-by: Thierry Reding 


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/core: Remove drm_dev_unref() and it's uses

[Patchwork]

== Series Details ==

Series: drm/core: Remove drm_dev_unref() and it's uses
URL   : https://patchwork.freedesktop.org/series/42325/
State : failure

== Summary ==

Applying: drm/core: Remove drm_dev_unref() and it's uses
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/drm_drv.c
M   drivers/gpu/drm/exynos/exynos_drm_drv.c
M   drivers/gpu/drm/mxsfb/mxsfb_drv.c
M   drivers/gpu/drm/omapdrm/omap_drv.c
M   drivers/gpu/drm/sti/sti_drv.c
M   drivers/gpu/drm/stm/drv.c
M   drivers/gpu/drm/tegra/drm.c
M   drivers/gpu/drm/tinydrm/core/tinydrm-core.c
M   drivers/gpu/drm/udl/udl_drv.c
M   drivers/gpu/drm/vc4/vc4_drv.c
M   include/drm/drm_drv.h
Falling back to patching base and 3-way merge...
Auto-merging include/drm/drm_drv.h
Auto-merging drivers/gpu/drm/vc4/vc4_drv.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/vc4/vc4_drv.c
Auto-merging drivers/gpu/drm/udl/udl_drv.c
Auto-merging drivers/gpu/drm/tinydrm/core/tinydrm-core.c
Auto-merging drivers/gpu/drm/tegra/drm.c
Auto-merging drivers/gpu/drm/stm/drv.c
Auto-merging drivers/gpu/drm/sti/sti_drv.c
Auto-merging drivers/gpu/drm/omapdrm/omap_drv.c
Auto-merging drivers/gpu/drm/mxsfb/mxsfb_drv.c
Auto-merging drivers/gpu/drm/exynos/exynos_drm_drv.c
Auto-merging drivers/gpu/drm/drm_drv.c
Patch failed at 0001 drm/core: Remove drm_dev_unref() and it's uses
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: link config compute refactoring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: link config compute refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/41215/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4103 -> Patchwork_8810 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/41215/revisions/2/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8810 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)

igt@gem_mmap_gtt@basic-small-bo-tiledx:
  fi-gdg-551: PASS -> FAIL (fdo#102575)

igt@gem_ringfill@basic-default-hang:
  fi-pnv-d510:NOTRUN -> DMESG-WARN (fdo#101600)


 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128) -> PASS

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-elk-e7500:   DMESG-WARN (fdo#103989, fdo#105225) -> PASS

igt@kms_flip@basic-plain-flip:
  fi-elk-e7500:   DMESG-WARN (fdo#105225) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   DMESG-WARN (fdo#106084) -> PASS


  fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#105225 https://bugs.freedesktop.org/show_bug.cgi?id=105225
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084


== Participating hosts (38 -> 35) ==

  Additional (1): fi-pnv-d510 
  Missing(4): fi-byt-j1900 fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4103 -> Patchwork_8810

  CI_DRM_4103: 96d389ab8f2f1e05b9ba5feacef7185f59a129db @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8810: 1e9bea0cb9c8bbc98e77ff536ec9942a58802ff8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

1e9bea0cb9c8 drm/i915/dp: fix compliance test adjustments
23a3db24b5ca drm/i915/dp: abstract link config selection
25d6751364a6 drm/i915/dp: group link config limits in a struct
a1d4ab2f8138 drm/i915/dp: move eDP VBT bpp clamping code to 
intel_dp_compute_bpp()
612c61de1aa6 drm/i915/dp: abstract dp link config computation from the rest
ff040231fec8 drm/i915/dp: move link_bw and rate_select debugging where used
e404413cc8c9 drm/i915/dp: remove stale comment about bw constants

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8810/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dp: link config compute refactoring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: link config compute refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/41215/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/dp: remove stale comment about bw constants
Okay!

Commit: drm/i915/dp: move link_bw and rate_select debugging where used
Okay!

Commit: drm/i915/dp: abstract dp link config computation from the rest
Okay!

Commit: drm/i915/dp: move eDP VBT bpp clamping code to intel_dp_compute_bpp()
Okay!

Commit: drm/i915/dp: group link config limits in a struct
Okay!

Commit: drm/i915/dp: abstract link config selection
Okay!

Commit: drm/i915/dp: fix compliance test adjustments
-O:drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using sizeof(void)

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: link config compute refactoring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: link config compute refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/41215/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e404413cc8c9 drm/i915/dp: remove stale comment about bw constants
ff040231fec8 drm/i915/dp: move link_bw and rate_select debugging where used
612c61de1aa6 drm/i915/dp: abstract dp link config computation from the rest
a1d4ab2f8138 drm/i915/dp: move eDP VBT bpp clamping code to 
intel_dp_compute_bpp()
25d6751364a6 drm/i915/dp: group link config limits in a struct
-:69: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#69: FILE: drivers/gpu/drm/i915/intel_dp.c:1746:
+   limits.min_clock = limits.max_clock = index;

-:70: WARNING:LONG_LINE: line over 100 characters
#70: FILE: drivers/gpu/drm/i915/intel_dp.c:1747:
+   limits.min_lane_count = limits.max_lane_count = 
intel_dp->compliance.test_lane_count;

-:70: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#70: FILE: drivers/gpu/drm/i915/intel_dp.c:1747:
+   limits.min_lane_count = limits.max_lane_count = 
intel_dp->compliance.test_lane_count;

total: 0 errors, 1 warnings, 2 checks, 96 lines checked
23a3db24b5ca drm/i915/dp: abstract link config selection
1e9bea0cb9c8 drm/i915/dp: fix compliance test adjustments
-:47: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#47: FILE: drivers/gpu/drm/i915/intel_dp.c:1709:
+   limits->min_bpp = limits->max_bpp = bpp;

-:66: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#66: FILE: drivers/gpu/drm/i915/intel_dp.c:1728:
+   limits->min_clock = limits->max_clock = index;

-:67: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#67: FILE: drivers/gpu/drm/i915/intel_dp.c:1729:
+   limits->min_lane_count = limits->max_lane_count =

total: 0 errors, 0 warnings, 3 checks, 88 lines checked

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

Re: [Intel-gfx] [PATCH v2 RESEND] drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

[Tvrtko Ursulin]

On 26/04/2018 12:35, Jani Nikula wrote:

Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
circumstances.

v2: don't change device info dump (Chris)

Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/intel_device_info.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a32ba72c514e..0fd13df424cf 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -848,7 +848,7 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
gen9_sseu_info_init(dev_priv);
else if (INTEL_GEN(dev_priv) == 10)
gen10_sseu_info_init(dev_priv);
-   else if (INTEL_INFO(dev_priv)->gen >= 11)
+   else if (INTEL_GEN(dev_priv) >= 11)
gen11_sseu_info_init(dev_priv);
  
  	/* Initialize command stream timestamp frequency */




Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH v2 RESEND] drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

[Jani Nikula]

Prefer INTEL_GEN() over INTEL_INFO()->gen except in special
circumstances.

v2: don't change device info dump (Chris)

Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_device_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index a32ba72c514e..0fd13df424cf 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -848,7 +848,7 @@ void intel_device_info_runtime_init(struct 
intel_device_info *info)
gen9_sseu_info_init(dev_priv);
else if (INTEL_GEN(dev_priv) == 10)
gen10_sseu_info_init(dev_priv);
-   else if (INTEL_INFO(dev_priv)->gen >= 11)
+   else if (INTEL_GEN(dev_priv) >= 11)
gen11_sseu_info_init(dev_priv);
 
/* Initialize command stream timestamp frequency */
-- 
2.11.0

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

[Intel-gfx] [PULL] drm-misc-next

[Maarten Lankhorst]

Hi Dave,

This is my first pull request for v4.18. Only UAPI change is adding a generic 
plane
alpha property, which replaces the driver specific ones in sun4i, rcar-du and 
atmel-hclcdc.

drm-misc-next-2018-04-26:
drm-misc-next for v4.18:

UAPI Changes:
- Add support for a generic plane alpha property to sun4i, rcar-du and 
atmel-hclcdc. (Maxime)

Core Changes:
- Stop looking at legacy plane->fb and crtc members in atomic drivers. (Ville)
- mode_valid return type fixes. (Luc)
- Handle zpos normalization in the core. (Peter)

Driver Changes:
- Implement CTM, plane alpha and generic async cursor support in vc4. (Stefan)
- Various fixes for HPD and aux chan in drm_bridge/analogix_dp. (Lin, Zain, 
Douglas)
- Add support for MIPI DSI to sun4i. (Maxime)

The following changes since commit 694f54f680f7fd8e9561928fbfc537d9afbc3d79:

Merge branch 'drm-misc-next-fixes' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-03-29 09:25:13 
+1000)

are available in the Git repository at:

git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-04-26

for you to fetch changes up to 741c3aeb82c78e173aa7155aaffb971e5c73ab3c:

drm/bridge/synopsys: dsi: use adjusted_mode in mode_set (2018-04-26 08:24:26 
+0200)

And lots of various fixes and cleanups. :)

Cc: Luc Van Oostenryck 
Cc: Daniel Vetter 
Cc: Maxime Ripard 
Cc: Stefan Schake 
Cc: Ville Syrjälä 
Cc: Peter Ujfalusi 
Cc: Douglas Anderson 
Cc: zain wang 
Cc: Lin Huang 


drm-misc-next for v4.18:

UAPI Changes:
- Add support for a generic plane alpha property to sun4i, rcar-du and 
atmel-hclcdc. (Maxime)

Core Changes:
- Stop looking at legacy plane->fb and crtc members in atomic drivers. (Ville)
- mode_valid return type fixes. (Luc)
- Handle zpos normalization in the core. (Peter)

Driver Changes:
- Implement CTM, plane alpha and generic async cursor support in vc4. (Stefan)
- Various fixes for HPD and aux chan in drm_bridge/analogix_dp. (Lin, Zain, 
Douglas)
- Add support for MIPI DSI to sun4i. (Maxime)


Andy Shevchenko (1):
drm/dp/mst: Fix off-by-one typo when dump payload table

Arushi Singhal (2):
gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry
gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

Boris Brezillon (3):
drm/atomic: Add sanity checks to drm_atomic_helper_async_commit()
drm/bridge: Add Cadence DSI driver
dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

Daniel Stone (1):
drm: Reshuffle getfb error returns

Daniel Vetter (14):
drm/gem: Document that handle_create must be the last step
drm/tinydrm: Use gem_free_object_unlocked
staging/vboxvideo: Use gem_free_object_unlocked
drm/rockchip: fixup comment for gem_free_object_unlocked
drm/udl: Get rid of dev->struct_mutex usage
drm/vmwgfx: Remove no-op prepare/cleanup_fb callbacks
drm: Move simple_display_pipe prepare_fb helper into gem fb helpers
drm/tve200: Use simple_display_pipe prepare_fb helper
drm/pl111: Use simple_display_pipe prepare_fb helper
drm/mxsfb: Use simple_display_pipe prepare_fb helper
drm/atomic: better doc for implicit vs explicit fencing
drm/xen-front: use simple display pipe prepare_fb helper
drm: Don't EXPORT drm_add/reset_display_info
drm/todo: Fallout from v3d review

Douglas Anderson (4):
drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner
drm/bridge: analogix_dp: Properly log AUX CH errors
drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
drm/bridge: analogix_dp: Split the platform-specific poweron in two parts

Eric Anholt (1):
drm/vc4: Add some missing HVS register definitions.

Fabio Estevam (1):
drm: dw-hdmi-i2s: Remove owner assignment from platform_driver

Gustavo Padovan (1):
drm/vc4: update cursors asynchronously through atomic

Haneen Mohammed (1):
drm: Remove drm_property_{un/reference}_blob aliases

Hans de Goede (2):
drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad Mixx 310
drm: panel-orientation-quirks: Add quirk for Lenovo Ideapad Mixx 320

Jacopo Mondi (2):
dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
drm: bridge: Add thc63lvd1024 LVDS decoder driver

Jani Nikula (3):
drm: prefer inline over __inline__
drm: remove old documentation comment cruft from drmP.h
drm: make drm_core_check_feature() bool that it is

John Keeping (1):
drm/rockchip: fix VOP vblank race

Kieran Bingham (2):
dt-bindings: adv7511: Extend bindings to allow specifying slave map addresses
drm: adv7511: Add support for i2c_new_secondary_device

Lin Huang (6):
drm/bridge: analogix_dp: Move enable video into config_video()
drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer
drm/bridge: analogix_dp: 

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Laurent Pinchart]

Hi Vaishali,

Thank you for the patch.

On Thursday, 26 April 2018 13:28:19 EEST Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with drm_dev_put and remove
> the function itself.
> 
> Coccinelle was used for mass-patching.
> 
> Signed-off-by: Vaishali Thakkar 

I love seeing deprecated functions go.

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
>  drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
>  drivers/gpu/drm/armada/armada_drv.c|  6 +++---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--
>  drivers/gpu/drm/drm_drv.c  | 13 -
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|  4 ++--
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |  4 ++--
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  4 ++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  8 
>  drivers/gpu/drm/i915/selftests/huge_pages.c|  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_request.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +++---
>  drivers/gpu/drm/msm/msm_drv.c  |  8 
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c |  4 ++--
>  drivers/gpu/drm/pl111/pl111_drv.c  |  4 ++--
>  drivers/gpu/drm/qxl/qxl_drv.c  |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  4 ++--
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  4 ++--
>  drivers/gpu/drm/sti/sti_drv.c  |  8 
>  drivers/gpu/drm/stm/drv.c  |  4 ++--
>  drivers/gpu/drm/sun4i/sun4i_drv.c  |  4 ++--
>  drivers/gpu/drm/tegra/drm.c|  4 ++--
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c|  6 +++---
>  drivers/gpu/drm/tve200/tve200_drv.c|  4 ++--
>  drivers/gpu/drm/udl/udl_drv.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_drv.c  |  4 ++--
>  drivers/gpu/drm/vgem/vgem_drv.c|  2 +-
>  drivers/gpu/drm/virtio/virtgpu_drm_bus.c   |  2 +-
>  drivers/gpu/drm/zte/zx_drm_drv.c   |  4 ++--
>  include/drm/drm_drv.h  |  1 -
>  41 files changed, 73 insertions(+), 87 deletions(-)

-- 
Regards,

Laurent Pinchart



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

Re: [Intel-gfx] [PATCH] drm/i915: Add documentation to gen9_set_dc_state()

[Imre Deak]

On Wed, Apr 25, 2018 at 11:47:28AM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-04-17 at 14:31 +0300, Imre Deak wrote:
> > Add documentation to gen9_set_dc_state() on what enabling a given DC
> > state means and at what point HW/DMC actually enters/exits these states.
> > 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +++
> >  1 file changed, 23 insertions(+)
> > 
> > [ On IRC I stated that PSR entry would be prevented in a given DC state,
> >   but looking more at it I haven't found any proof for this. So as I
> >   understand the only connection between PSR and DC states is that if
> >   DC5/6 is disabled power saving will be blocked, which would otherwise
> >   be possible when PSR is active and the display pipe is off. ]
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 53ea564f971e..40a7955886d4 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -542,6 +542,29 @@ void gen9_sanitize_dc_state(struct drm_i915_private 
> > *dev_priv)
> > dev_priv->csr.dc_state = val;
> >  }
> >  
> > +/**
> > + * gen9_set_dc_state - set target display C power state
> > + * @dev_priv: i915 device instance
> > + * @state: target DC power state
> > + * - DC_STATE_DISABLE
> > + * - DC_STATE_EN_UPTO_DC5
> > + * - DC_STATE_EN_UPTO_DC6
> > + * - DC_STATE_EN_DC9
> > + *
> > + * Signal to DMC firmware/HW the target DC power state passed in @state.
> > + * DMC/HW can turn off individual display clocks and power rails when 
> > entering
> 
> Any chance you could eliminate the firmware/HW ambiguity? Not knowing
> whether it is the firmware or the HW leads to potentially incorrect
> assumptions.

It's not specified. What I understood about current DMC firmware blobs
is that they will prevent entering DC5/6 if there is a pending
GT/display interrupt. So all other gating - for instance based on a
pipe's active state - happens outside of the firmware.

> > + * a deeper DC power state (higher in number) and turns these back when 
> > exiting
> > + * that state to a shallower power state (lower in number). The HW will 
> > decide
> > + * when to actually enter a given state on an on-demand basis, for instance
> > + * depending on the active state of display pipes. The state of display
> > + * registers backed by affected power rails are saved/restored as needed.
> > + *
> 
> One of things that is completely misleading is the enable_dc6 debug
> message we print. It is all over dmesg, but like you already wrote, HW
> needs PSR to be enabled and only in a single-pipe active case, the
> display controller can go to DC6. So, with PSR disabled upstream, there
> is really no chance that the HW can go to DC6 without all displays
> disabled.

Yes, that is how things work. The driver only enables - or allows if you
like - these states and this enabling is what the debug message is about
The actual toggling of power rails, clocks etc. will happen behind the
scenes. This is similar to how RC6 works for instance, with DC states
you just need more assistance atm from the driver, hence the need for
more cases where we have to disable/re-enable DC states.

> > + * Based on the above enabling a deeper DC power state is asynchronous wrt.
> > + * enabling it. Disabling a deeper power state is synchronous: for instance
> > + * setting %DC_STATE_DISABLE won't complete until all HW resources are 
> > turned
> > + * back on and register state is restored. This is guaranteed by the MMIO 
> > write
> > + * to DC_STATE_EN blocking until the state is restored.
> > + */
> >  static void gen9_set_dc_state(struct drm_i915_private *dev_priv, uint32_t 
> > state)
> >  {
> > uint32_t val;
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for RFC drm/i915: Switch to kernel context before idling at runtime

[Chris Wilson]

Quoting Patchwork (2018-04-26 11:18:58)
> == Series Details ==
> 
> Series: RFC drm/i915: Switch to kernel context before idling at runtime
> URL   : https://patchwork.freedesktop.org/series/42321/
> State : failure
> 
> == Summary ==
> 
> = CI Bug Log - changes from CI_DRM_4101 -> Patchwork_8809 =
> 
> == Summary - FAILURE ==
> 
>   Serious unknown changes coming with Patchwork_8809 absolutely need to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_8809, 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/42321/revisions/1/mbox/
> 
> == Possible new issues ==
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_8809:
> 
>   === IGT changes ===
> 
>  Possible regressions 

Welp, that was embarrassing. So imagine I remembered to add the lock.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI] drm/i915: Compile out engine debug for release

[Chris Wilson]

The majority of the engine state dumping is too voluminous to be useful
outside of a controlled setup, though a few do accompany severe errors.
Keep the debug dumps next to the errors, but hide the others behind a CI
compile flag. This becomes more useful when adding more dumps to latency
sensitive paths.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c  | 2 +-
 drivers/gpu/drm/i915/i915_gem.h  | 6 ++
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 +-
 drivers/gpu/drm/i915/intel_hangcheck.c   | 2 +-
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..6b0c67a4f214 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3312,7 +3312,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 
GEM_TRACE("start\n");
 
-   if (drm_debug & DRM_UT_DRIVER) {
+   if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
 
for_each_engine(engine, i915, id)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index deaf78d2ae8b..525920404ede 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -30,6 +30,9 @@
 struct drm_i915_private;
 
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
+
+#define GEM_SHOW_DEBUG() (drm_debug & DRM_UT_DRIVER)
+
 #define GEM_BUG_ON(condition) do { if (unlikely((condition))) {\
pr_err("%s:%d GEM_BUG_ON(%s)\n", \
   __func__, __LINE__, __stringify(condition)); \
@@ -45,6 +48,9 @@ struct drm_i915_private;
 #define GEM_DEBUG_BUG_ON(expr) GEM_BUG_ON(expr)
 
 #else
+
+#define GEM_SHOW_DEBUG() (0)
+
 #define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
 #define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
 
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 5ce4f51232f5..18e643df523e 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -82,7 +82,7 @@ static unsigned long wait_timeout(void)
 
 static noinline void missed_breadcrumb(struct intel_engine_cs *engine)
 {
-   if (drm_debug & DRM_UT_DRIVER) {
+   if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
 
intel_engine_dump(engine, ,
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
b/drivers/gpu/drm/i915/intel_hangcheck.c
index fd0ffb8328d0..309e38b00e95 100644
--- a/drivers/gpu/drm/i915/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/intel_hangcheck.c
@@ -356,7 +356,7 @@ static void hangcheck_accumulate_sample(struct 
intel_engine_cs *engine,
break;
 
case ENGINE_DEAD:
-   if (drm_debug & DRM_UT_DRIVER) {
+   if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer("hangcheck");
intel_engine_dump(engine, , "%s\n", engine->name);
}
-- 
2.17.0

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

[Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

[Vaishali Thakkar]

It's been a while since we introduced drm_dev{get/put} functions
to replace reference/unreference in drm subsystem for the
consistency purpose. So, with this patch, let's just replace
all current use cases of drm_dev_unref() with drm_dev_put and remove
the function itself.

Coccinelle was used for mass-patching.

Signed-off-by: Vaishali Thakkar 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 ++--
 drivers/gpu/drm/arc/arcpgu_drv.c   |  4 ++--
 drivers/gpu/drm/armada/armada_drv.c|  6 +++---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |  4 ++--
 drivers/gpu/drm/drm_drv.c  | 13 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  4 ++--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |  4 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  4 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  8 
 drivers/gpu/drm/i915/selftests/huge_pages.c|  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
 drivers/gpu/drm/i915/selftests/i915_request.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
 drivers/gpu/drm/imx/imx-drm-core.c |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +++---
 drivers/gpu/drm/msm/msm_drv.c  |  8 
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  4 ++--
 drivers/gpu/drm/nouveau/nouveau_platform.c |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c |  4 ++--
 drivers/gpu/drm/pl111/pl111_drv.c  |  4 ++--
 drivers/gpu/drm/qxl/qxl_drv.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  4 ++--
 drivers/gpu/drm/shmobile/shmob_drm_drv.c   |  4 ++--
 drivers/gpu/drm/sti/sti_drv.c  |  8 
 drivers/gpu/drm/stm/drv.c  |  4 ++--
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  4 ++--
 drivers/gpu/drm/tegra/drm.c|  4 ++--
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c|  6 +++---
 drivers/gpu/drm/tve200/tve200_drv.c|  4 ++--
 drivers/gpu/drm/udl/udl_drv.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.c  |  4 ++--
 drivers/gpu/drm/vgem/vgem_drv.c|  2 +-
 drivers/gpu/drm/virtio/virtgpu_drm_bus.c   |  2 +-
 drivers/gpu/drm/zte/zx_drm_drv.c   |  4 ++--
 include/drm/drm_drv.h  |  1 -
 41 files changed, 73 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0b19482b36b8..5fb455febeba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -647,7 +647,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
 err_pci:
pci_disable_device(pdev);
 err_free:
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
return ret;
 }
 
@@ -657,7 +657,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
 
drm_dev_unregister(dev);
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
 }
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index f067de4e1e82..dcb06d4e9135 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -216,7 +216,7 @@ static int arcpgu_probe(struct platform_device *pdev)
arcpgu_unload(drm);
 
 err_unref:
-   drm_dev_unref(drm);
+   drm_dev_put(drm);
 
return ret;
 }
@@ -227,7 +227,7 @@ static int arcpgu_remove(struct platform_device *pdev)
 
drm_dev_unregister(drm);
arcpgu_unload(drm);
-   drm_dev_unref(drm);
+   drm_dev_put(drm);
 
return 0;
 }
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 4b11b6b52f1d..d1705d298a39 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -109,7 +109,7 @@ static int armada_drm_bind(struct device *dev)
 
/*
 * The drm_device structure must be at the start of
-* armada_private for drm_dev_unref() to work correctly.
+* armada_private for drm_dev_put() to work correctly.
 */
BUILD_BUG_ON(offsetof(struct armada_private, drm) != 0);
 
@@ -180,7 +180,7 @@ static int armada_drm_bind(struct device *dev)
drm_mode_config_cleanup(>drm);
drm_mm_takedown(>linear);

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use seqlock in engine stats (rev3)

[Tvrtko Ursulin]

On 26/04/2018 09:16, Patchwork wrote:

== Series Details ==

Series: drm/i915: Use seqlock in engine stats (rev3)
URL   : https://patchwork.freedesktop.org/series/38347/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8806 =

== Summary - SUCCESS ==

   No regressions found.

   External URL: 
https://patchwork.freedesktop.org/api/1.0/series/38347/revisions/3/mbox/

== Known issues ==

   Here are the changes found in Patchwork_8806 that come from known issues:

   === IGT changes ===

  Possible fixes 

 igt@debugfs_test@read_all_entries:
   fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

 igt@kms_flip@basic-flip-vs-dpms:
   fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS

 
   fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

   fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927


== Participating hosts (37 -> 35) ==

   Missing(2): fi-ilk-m540 fi-skl-6700hq


== Build changes ==

 * Linux: CI_DRM_4100 -> Patchwork_8806

   CI_DRM_4100: 05cc701ce9d22b01f2f4afa9fddd521b931ed163 @ 
git://anongit.freedesktop.org/gfx-ci/linux
   IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
   Patchwork_8806: 9ce2e374546c8bd06ae6e97f8b5b7b6cdf8e7f0e @ 
git://anongit.freedesktop.org/gfx-ci/linux
   piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

9ce2e374546c drm/i915: Use seqlock in engine stats


Pushed, thanks for the suggestion and review!

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 07/18] drm/i915: Combine tasklet_kill and tasklet_disable

[Chris Wilson]

Quoting Mika Kuoppala (2018-04-26 11:19:14)
> Chris Wilson  writes:
> 
> > Quoting Mika Kuoppala (2018-04-24 13:26:11)
> >> Chris Wilson  writes:
> >> 
> >> > Ideally, we want to atomically flush and disable the tasklet before
> >> > resetting the GPU. At present, we rely on being the only part to touch
> >> > our tasklet and serialisation of the reset process to ensure that we can
> >> > suspend the tasklet from the mix of reset/wedge pathways. In this patch,
> >> > we move the tasklet abuse into its own function and tweak it such that
> >> > we only do a synchronous operation the first time it is disabled around
> >> > the reset. This allows us to avoid the sync inside a softirq context in
> >> > subsequent patches.
> >> >
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: Mika Kuoppala 
> >> > Cc: Michał Winiarski 
> >> > CC: Michel Thierry 
> >> > Cc: Jeff McGee 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_lrc.c | 14 +++---
> >> >  1 file changed, 11 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >> > b/drivers/gpu/drm/i915/intel_lrc.c
> >> > index bbcc6439a2a1..d5640f3d5276 100644
> >> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> >> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> >> > @@ -1754,6 +1754,16 @@ static int gen9_init_render_ring(struct 
> >> > intel_engine_cs *engine)
> >> >   return init_workarounds_ring(engine);
> >> >  }
> >> >  
> >> > +static void tasklet_kill_and_disable(struct tasklet_struct *t)
> >> > +{
> >> > + if (!atomic_read(>count))
> >> > + tasklet_kill(t);
> >> > +
> >> > + if (atomic_inc_return(>count) == 1)
> >> > + tasklet_unlock_wait(t);
> >> 
> >> You would spin only on the first try regardless. Is this
> >> just to prevent one extra spinlock on reset path?
> >
> > No, the end goal is to prevent a recursive lock.
> 
> Ok so you want to be able to call this from inside the
> tasklet itself.
> 
> On the bigger picture, if the preempt has has already
> timeouted and we want to reset, does it matter between
> resetting from wq or from timer irq. In another
> words what do we gain for this much of added complexity?

Yes. A reset and recovery is microseconds. Scheduling the wq is orders
of magnitude indeterminably worse latency. (Calling schedule() itself
will take as long as the reset.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Lionel Landwerlin]

On 26/04/18 11:00, Joonas Lahtinen wrote:

Quoting Lionel Landwerlin (2018-04-25 14:45:21)

From: Chris Wilson 

We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.

The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.

This hit a dead end last time due to the system wide policy needed to
avoid two parties fighting over the slice count (and going back and
forth between two slice counts would counter the benefits received from
this).

Do we now have a solution for the contention? I don't see code to
negotiate a global value, just raw setter.

Regards, Joonas


I've tried to come up with some numbers about the cost of the back & 
forth (see igt series).


Other than that, I don't think we can expect the kernel to workaround 
the inefficient use of the hardware by userspace.





We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,

 struct drm_i915_gem_context_param arg;
 struct drm_i915_gem_context_param_sseu sseu = { .flags = 
I915_EXEC_RENDER };

 memset(, 0, sizeof(arg));
 arg.ctx_id = ctx;
 arg.param = I915_CONTEXT_PARAM_SSEU;
 arg.value = (uintptr_t) 
 if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
 sseu.packed.subslice_mask = 0;

 drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
 }

could be used to disable all subslices where supported.

v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)

v3: Add ability to program this per engine (Chris)

v4: Move most get_sseu() into i915_gem_context.c (Lionel)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Signed-off-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
c: Dmitry Rogozhkin 
CC: Tvrtko Ursulin 
CC: Zhipeng Gong 
CC: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_gem_context.c | 82 -
  drivers/gpu/drm/i915/intel_lrc.c| 55 +
  drivers/gpu/drm/i915/intel_lrc.h|  4 ++
  include/uapi/drm/i915_drm.h | 28 +
  4 files changed, 168 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index bdf050beeb94..b97ddcf47514 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -740,6 +740,26 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, 
void *data,
 return 0;
  }
  
+static struct i915_gem_context_sseu

+i915_gem_context_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
+const struct 
drm_i915_gem_context_param_sseu *user_sseu)
+{
+   struct i915_gem_context_sseu value = {
+   .slice_mask = user_sseu->packed.slice_mask == 0 ?
+ sseu->slice_mask :
+ (user_sseu->packed.slice_mask & sseu->slice_mask),
+   .subslice_mask = user_sseu->packed.subslice_mask == 0 ?
+sseu->subslice_mask[0] :
+(user_sseu->packed.subslice_mask & 
sseu->subslice_mask[0]),
+   .min_eus_per_subslice = 
min(user_sseu->packed.min_eus_per_subslice,
+   sseu->max_eus_per_subslice),
+   .max_eus_per_subslice = 
min(user_sseu->packed.max_eus_per_subslice,
+   sseu->max_eus_per_subslice),
+   };
+
+   return value;
+}
+
  int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file)
  {
@@ -777,6 +797,37 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
 case I915_CONTEXT_PARAM_PRIORITY:
 args->value = ctx->sched.priority;
 break;
+   case I915_CONTEXT_PARAM_SSEU: {
+   struct drm_i915_gem_context_param_sseu param_sseu;
+   struct intel_engine_cs *engine;
+
+   if (copy_from_user(_sseu, 

[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC drm/i915: Switch to kernel context before idling at runtime

[Patchwork]

== Series Details ==

Series: RFC drm/i915: Switch to kernel context before idling at runtime
URL   : https://patchwork.freedesktop.org/series/42321/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4101 -> Patchwork_8809 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8809 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8809, 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/42321/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8809:

  === IGT changes ===

 Possible regressions 

igt@drv_hangman@error-state-basic:
  fi-elk-e7500:   PASS -> DMESG-WARN +15
  fi-byt-n2820:   PASS -> DMESG-WARN +3
  fi-hsw-4770:PASS -> DMESG-WARN +3

igt@gem_busy@basic-busy-default:
  fi-glk-j4005:   PASS -> DMESG-WARN +32
  fi-snb-2520m:   PASS -> DMESG-WARN +7
  fi-hsw-4770r:   PASS -> DMESG-WARN +3
  fi-hsw-4200u:   PASS -> DMESG-WARN +3

igt@gem_busy@basic-hang-default:
  fi-pnv-d510:NOTRUN -> DMESG-WARN +12
  fi-byt-j1900:   PASS -> DMESG-WARN +6
  fi-cfl-8700k:   PASS -> DMESG-WARN +4
  fi-cnl-y3:  PASS -> DMESG-WARN +4
  fi-cfl-s3:  PASS -> DMESG-WARN +4
  fi-kbl-7567u:   PASS -> DMESG-WARN +2

igt@gem_close_race@basic-process:
  fi-ivb-3770:PASS -> DMESG-WARN +3
  fi-bdw-gvtdvm:  PASS -> DMESG-WARN +2
  fi-ilk-650: PASS -> DMESG-WARN +3
  fi-skl-gvtdvm:  PASS -> DMESG-WARN +6
  fi-blb-e6850:   PASS -> DMESG-WARN +3
  fi-bxt-dsi: NOTRUN -> DMESG-WARN +2
  fi-bxt-j4205:   PASS -> DMESG-WARN +4
  fi-snb-2600:PASS -> DMESG-WARN +3

igt@gem_close_race@basic-threads:
  fi-skl-6600u:   PASS -> DMESG-WARN +6
  fi-skl-guc: PASS -> DMESG-WARN +26
  fi-kbl-7567u:   PASS -> INCOMPLETE
  fi-bwr-2160:PASS -> DMESG-WARN +11
  fi-bdw-5557u:   PASS -> DMESG-WARN +6
  fi-kbl-7500u:   PASS -> DMESG-WARN +6
  fi-blb-e6850:   PASS -> INCOMPLETE
  fi-hsw-4200u:   PASS -> INCOMPLETE
  fi-hsw-4770r:   PASS -> INCOMPLETE
  fi-kbl-r:   PASS -> DMESG-WARN +6
  fi-snb-2600:PASS -> INCOMPLETE
  fi-ilk-650: PASS -> INCOMPLETE
  fi-ivb-3770:PASS -> INCOMPLETE
  fi-hsw-4770:PASS -> INCOMPLETE

igt@gem_cs_tlb@basic-default:
  fi-ivb-3520m:   PASS -> DMESG-WARN +7
  fi-cfl-s3:  PASS -> INCOMPLETE
  fi-cfl-8700k:   PASS -> INCOMPLETE

igt@gem_ctx_create@basic:
  fi-skl-6770hq:  PASS -> DMESG-WARN +6

igt@gem_ctx_create@basic-files:
  fi-kbl-r:   PASS -> INCOMPLETE
  fi-skl-6260u:   PASS -> DMESG-WARN +38
  fi-ivb-3520m:   PASS -> INCOMPLETE
  fi-skl-6770hq:  PASS -> INCOMPLETE
  fi-skl-6600u:   PASS -> INCOMPLETE
  fi-kbl-7500u:   PASS -> INCOMPLETE
  fi-bdw-5557u:   PASS -> INCOMPLETE

igt@gem_ctx_param@basic:
  fi-cnl-psr: PASS -> DMESG-WARN +26

igt@gem_exec_basic@basic-default:
  fi-cfl-u:   PASS -> DMESG-WARN +32

igt@gem_exec_basic@basic-render:
  fi-bsw-n3050:   PASS -> DMESG-WARN +31

igt@gem_exec_basic@readonly-blt:
  fi-skl-6700k2:  PASS -> DMESG-WARN +26

igt@gem_exec_basic@readonly-render:
  fi-gdg-551: PASS -> DMESG-WARN +10

igt@gem_exec_create@basic:
  fi-gdg-551: PASS -> INCOMPLETE
  fi-skl-guc: PASS -> INCOMPLETE
  fi-pnv-d510:NOTRUN -> INCOMPLETE
  fi-skl-6700k2:  PASS -> INCOMPLETE

igt@gem_exec_flush@basic-batch-kernel-default-uc:
  fi-cfl-u:   PASS -> INCOMPLETE
  fi-skl-6260u:   PASS -> INCOMPLETE
  fi-bsw-n3050:   PASS -> INCOMPLETE

igt@gem_exec_nop@basic-parallel:
  fi-bwr-2160:PASS -> INCOMPLETE


== Known issues ==

  Here are the changes found in Patchwork_8809 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_close_race@basic-threads:
  fi-bdw-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)
  fi-byt-n2820:   PASS -> INCOMPLETE (fdo#102657)
  fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)

igt@gem_cs_tlb@basic-default:
  fi-bxt-j4205:   PASS -> INCOMPLETE (fdo#103927)
  fi-cnl-y3:  PASS -> INCOMPLETE (fdo#105086)

igt@gem_ctx_create@basic-files:
  fi-skl-gvtdvm:  PASS -> INCOMPLETE (fdo#105600)
  fi-byt-j1900:   PASS -> INCOMPLETE (fdo#102657)
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@gem_exec_create@basic:
 

Re: [Intel-gfx] [PATCH 07/18] drm/i915: Combine tasklet_kill and tasklet_disable

[Mika Kuoppala]

Chris Wilson  writes:

> Quoting Mika Kuoppala (2018-04-24 13:26:11)
>> Chris Wilson  writes:
>> 
>> > Ideally, we want to atomically flush and disable the tasklet before
>> > resetting the GPU. At present, we rely on being the only part to touch
>> > our tasklet and serialisation of the reset process to ensure that we can
>> > suspend the tasklet from the mix of reset/wedge pathways. In this patch,
>> > we move the tasklet abuse into its own function and tweak it such that
>> > we only do a synchronous operation the first time it is disabled around
>> > the reset. This allows us to avoid the sync inside a softirq context in
>> > subsequent patches.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Cc: Mika Kuoppala 
>> > Cc: Michał Winiarski 
>> > CC: Michel Thierry 
>> > Cc: Jeff McGee 
>> > ---
>> >  drivers/gpu/drm/i915/intel_lrc.c | 14 +++---
>> >  1 file changed, 11 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
>> > b/drivers/gpu/drm/i915/intel_lrc.c
>> > index bbcc6439a2a1..d5640f3d5276 100644
>> > --- a/drivers/gpu/drm/i915/intel_lrc.c
>> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> > @@ -1754,6 +1754,16 @@ static int gen9_init_render_ring(struct 
>> > intel_engine_cs *engine)
>> >   return init_workarounds_ring(engine);
>> >  }
>> >  
>> > +static void tasklet_kill_and_disable(struct tasklet_struct *t)
>> > +{
>> > + if (!atomic_read(>count))
>> > + tasklet_kill(t);
>> > +
>> > + if (atomic_inc_return(>count) == 1)
>> > + tasklet_unlock_wait(t);
>> 
>> You would spin only on the first try regardless. Is this
>> just to prevent one extra spinlock on reset path?
>
> No, the end goal is to prevent a recursive lock.

Ok so you want to be able to call this from inside the
tasklet itself.

On the bigger picture, if the preempt has has already
timeouted and we want to reset, does it matter between
resetting from wq or from timer irq. In another
words what do we gain for this much of added complexity?
-Mika


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

Re: [Intel-gfx] [PATCH 13/18] drm/i915: Compile out engine debug for release

[Mika Kuoppala]

Chris Wilson  writes:

> The majority of the engine state dumping is too voluminous to be useful
> outside of a controlled setup, though a few do accompany severe errors.
> Keep the debug dumps next to the errors, but hide the others behind a CI
> compile flag. This becomes more useful when adding more dumps to latency
> sensitive paths.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem.c  | 2 +-
>  drivers/gpu/drm/i915/i915_gem.h  | 6 ++
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 +-
>  drivers/gpu/drm/i915/intel_hangcheck.c   | 2 +-
>  4 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 42a387ff0eaa..cec52bbd1b41 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3267,7 +3267,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
>  
>   GEM_TRACE("start\n");
>  
> - if (drm_debug & DRM_UT_DRIVER) {
> + if (GEM_SHOW_DEBUG()) {
>   struct drm_printer p = drm_debug_printer(__func__);
>  
>   for_each_engine(engine, i915, id)
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index deaf78d2ae8b..525920404ede 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -30,6 +30,9 @@
>  struct drm_i915_private;
>  
>  #ifdef CONFIG_DRM_I915_DEBUG_GEM
> +
> +#define GEM_SHOW_DEBUG() (drm_debug & DRM_UT_DRIVER)
> +
>  #define GEM_BUG_ON(condition) do { if (unlikely((condition))) {  \
>   pr_err("%s:%d GEM_BUG_ON(%s)\n", \
>  __func__, __LINE__, __stringify(condition)); \
> @@ -45,6 +48,9 @@ struct drm_i915_private;
>  #define GEM_DEBUG_BUG_ON(expr) GEM_BUG_ON(expr)
>  
>  #else
> +
> +#define GEM_SHOW_DEBUG() (0)
> +
>  #define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
>  #define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
>  
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index ca0b04d9747c..ad761b8d843d 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -82,7 +82,7 @@ static unsigned long wait_timeout(void)
>  
>  static noinline void missed_breadcrumb(struct intel_engine_cs *engine)
>  {
> - if (drm_debug & DRM_UT_DRIVER) {
> + if (GEM_SHOW_DEBUG()) {
>   struct drm_printer p = drm_debug_printer(__func__);
>  
>   intel_engine_dump(engine, ,
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index fd0ffb8328d0..309e38b00e95 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -356,7 +356,7 @@ static void hangcheck_accumulate_sample(struct 
> intel_engine_cs *engine,
>   break;
>  
>   case ENGINE_DEAD:
> - if (drm_debug & DRM_UT_DRIVER) {
> + if (GEM_SHOW_DEBUG()) {
>   struct drm_printer p = drm_debug_printer("hangcheck");
>   intel_engine_dump(engine, , "%s\n", engine->name);
>   }
> -- 
> 2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wait for idle between idle resets as well

[Chris Wilson]

Quoting Chris Wilson (2018-04-11 13:03:46)
> Even though we weren't injecting guilty requests to be reset, we could
> still fall over the issue of resetting the same request too fast -- where
> the GPU refuses to start again. (Although it is interesting to note that
> reloading the driver is sufficient, suggesting that we could recover if
> we delayed the setup after reset?) Continue to paper over the problem by
> adding a small delay by waiting for the engine to idle between tests,
> and ensure that the engines are idle before starting the idle tests.
> 
> References: 028666793a02 ("drm/i915/selftests: Avoid repeatedly harming the 
> same innocent context")
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michał Winiarski 
> Cc: Michel Thierry 
> Cc: Tvrtko Ursulin 

Ping?

> ---
>  .../gpu/drm/i915/selftests/intel_hangcheck.c  | 48 ++-
>  1 file changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index 24f913f26a7b..7e23e6a6719c 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -454,6 +454,11 @@ static int igt_global_reset(void *arg)
> return err;
>  }
>  
> +static bool wait_for_idle(struct intel_engine_cs *engine)
> +{
> +   return wait_for(intel_engine_is_idle(engine), 50) == 0;
> +}
> +
>  static int __igt_reset_engine(struct drm_i915_private *i915, bool active)
>  {
> struct intel_engine_cs *engine;
> @@ -481,6 +486,13 @@ static int __igt_reset_engine(struct drm_i915_private 
> *i915, bool active)
> if (active && !intel_engine_can_store_dword(engine))
> continue;
>  
> +   if (!wait_for_idle(engine)) {
> +   pr_err("%s failed to idle before reset\n",
> +  engine->name);
> +   err = -EIO;
> +   break;
> +   }
> +
> reset_count = i915_reset_count(>gpu_error);
> reset_engine_count = i915_reset_engine_count(>gpu_error,
>  engine);
> @@ -542,6 +554,19 @@ static int __igt_reset_engine(struct drm_i915_private 
> *i915, bool active)
> err = -EINVAL;
> break;
> }
> +
> +   if (!wait_for_idle(engine)) {
> +   struct drm_printer p =
> +   drm_info_printer(i915->drm.dev);
> +
> +   pr_err("%s failed to idle after reset\n",
> +  engine->name);
> +   intel_engine_dump(engine, ,
> + "%s\n", engine->name);
> +
> +   err = -EIO;
> +   break;
> +   }
> } while (time_before(jiffies, end_time));
> clear_bit(I915_RESET_ENGINE + id, >gpu_error.flags);
>  
> @@ -696,6 +721,13 @@ static int __igt_reset_engines(struct drm_i915_private 
> *i915,
> !intel_engine_can_store_dword(engine))
> continue;
>  
> +   if (!wait_for_idle(engine)) {
> +   pr_err("i915_reset_engine(%s:%s): failed to idle 
> before reset\n",
> +  engine->name, test_name);
> +   err = -EIO;
> +   break;
> +   }
> +
> memset(threads, 0, sizeof(threads));
> for_each_engine(other, i915, tmp) {
> struct task_struct *tsk;
> @@ -772,6 +804,20 @@ static int __igt_reset_engines(struct drm_i915_private 
> *i915,
> i915_request_wait(rq, 0, 
> MAX_SCHEDULE_TIMEOUT);
> i915_request_put(rq);
> }
> +
> +   if (!(flags & TEST_SELF) && !wait_for_idle(engine)) {
> +   struct drm_printer p =
> +   drm_info_printer(i915->drm.dev);
> +
> +   pr_err("i915_reset_engine(%s:%s):"
> +  " failed to idle after reset\n",
> +  engine->name, test_name);
> +   intel_engine_dump(engine, ,
> + "%s\n", engine->name);
> +
> +   err = -EIO;
> +   break;
> +   }
> } while (time_before(jiffies, end_time));
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/rect: Round above 1 << 16 upwards to correct scale calculation functions.

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to 
correct scale calculation functions.
URL   : https://patchwork.freedesktop.org/series/42317/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4100_full -> Patchwork_8808_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8808_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8808_full, 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/42317/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8808_full:

  === IGT changes ===

 Possible regressions 

igt@kms_color@pipe-c-ctm-0-5:
  shard-kbl:  PASS -> FAIL


 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  SKIP -> PASS

igt@gem_mocs_settings@mocs-rc6-bsd1:
  shard-kbl:  PASS -> SKIP


== Known issues ==

  Here are the changes found in Patchwork_8808_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_flip@2x-flip-vs-absolute-wf_vblank:
  shard-hsw:  PASS -> FAIL (fdo#100368) +1

igt@kms_flip@blocking-absolute-wf_vblank:
  shard-kbl:  PASS -> DMESG-WARN (fdo#103558, fdo#105602) +3

igt@kms_flip@modeset-vs-vblank-race-interruptible:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@plain-flip-fb-recreate-interruptible:
  shard-glk:  PASS -> FAIL (fdo#100368) +1

igt@kms_rotation_crc@primary-rotation-180:
  shard-apl:  PASS -> FAIL (fdo#103925)

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)


 Possible fixes 

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
  shard-hsw:  FAIL (fdo#104873) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-glk:  FAIL (fdo#103060) -> PASS

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-apl:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#102887, fdo#105363) -> PASS

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-hsw:  FAIL (fdo#103928) -> PASS
  shard-glk:  FAIL (fdo#100368) -> PASS +1
  shard-apl:  FAIL (fdo#105312) -> PASS

igt@kms_flip@plain-flip-fb-recreate:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
  shard-apl:  FAIL (fdo#103167) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
  fdo#105312 https://bugs.freedesktop.org/show_bug.cgi?id=105312
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4100 -> Patchwork_8808

  CI_DRM_4100: 05cc701ce9d22b01f2f4afa9fddd521b931ed163 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8808: 968d77e5a49fd4ff0001f0b305c67cfeadfc2b65 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8808/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Joonas Lahtinen]

Quoting Lionel Landwerlin (2018-04-25 14:45:21)
> From: Chris Wilson 
> 
> We want to allow userspace to reconfigure the subslice configuration for
> its own use case. To do so, we expose a context parameter to allow
> adjustment of the RPCS register stored within the context image (and
> currently not accessible via LRI). If the context is adjusted before
> first use, the adjustment is for "free"; otherwise if the context is
> active we flush the context off the GPU (stalling all users) and forcing
> the GPU to save the context to memory where we can modify it and so
> ensure that the register is reloaded on next execution.
> 
> The overhead of managing additional EU subslices can be significant,
> especially in multi-context workloads. Non-GPGPU contexts should
> preferably disable the subslices it is not using, and others should
> fine-tune the number to match their workload.

This hit a dead end last time due to the system wide policy needed to
avoid two parties fighting over the slice count (and going back and
forth between two slice counts would counter the benefits received from
this).

Do we now have a solution for the contention? I don't see code to
negotiate a global value, just raw setter.

Regards, Joonas

> 
> We expose complete control over the RPCS register, allowing
> configuration of slice/subslice, via masks packed into a u64 for
> simplicity. For example,
> 
> struct drm_i915_gem_context_param arg;
> struct drm_i915_gem_context_param_sseu sseu = { .flags = 
> I915_EXEC_RENDER };
> 
> memset(, 0, sizeof(arg));
> arg.ctx_id = ctx;
> arg.param = I915_CONTEXT_PARAM_SSEU;
> arg.value = (uintptr_t) 
> if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
> sseu.packed.subslice_mask = 0;
> 
> drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
> }
> 
> could be used to disable all subslices where supported.
> 
> v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
> 
> v3: Add ability to program this per engine (Chris)
> 
> v4: Move most get_sseu() into i915_gem_context.c (Lionel)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
> Signed-off-by: Chris Wilson 
> Signed-off-by: Lionel Landwerlin 
> c: Dmitry Rogozhkin 
> CC: Tvrtko Ursulin 
> CC: Zhipeng Gong 
> CC: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_gem_context.c | 82 -
>  drivers/gpu/drm/i915/intel_lrc.c| 55 +
>  drivers/gpu/drm/i915/intel_lrc.h|  4 ++
>  include/uapi/drm/i915_drm.h | 28 +
>  4 files changed, 168 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index bdf050beeb94..b97ddcf47514 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -740,6 +740,26 @@ int i915_gem_context_destroy_ioctl(struct drm_device 
> *dev, void *data,
> return 0;
>  }
>  
> +static struct i915_gem_context_sseu
> +i915_gem_context_sseu_from_user_sseu(const struct sseu_dev_info *sseu,
> +const struct 
> drm_i915_gem_context_param_sseu *user_sseu)
> +{
> +   struct i915_gem_context_sseu value = {
> +   .slice_mask = user_sseu->packed.slice_mask == 0 ?
> + sseu->slice_mask :
> + (user_sseu->packed.slice_mask & 
> sseu->slice_mask),
> +   .subslice_mask = user_sseu->packed.subslice_mask == 0 ?
> +sseu->subslice_mask[0] :
> +(user_sseu->packed.subslice_mask & 
> sseu->subslice_mask[0]),
> +   .min_eus_per_subslice = 
> min(user_sseu->packed.min_eus_per_subslice,
> +   sseu->max_eus_per_subslice),
> +   .max_eus_per_subslice = 
> min(user_sseu->packed.max_eus_per_subslice,
> +   sseu->max_eus_per_subslice),
> +   };
> +
> +   return value;
> +}
> +
>  int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file)
>  {
> @@ -777,6 +797,37 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
> *dev, void *data,
> case I915_CONTEXT_PARAM_PRIORITY:
> args->value = ctx->sched.priority;
> break;
> +   case I915_CONTEXT_PARAM_SSEU: {
> +   struct drm_i915_gem_context_param_sseu param_sseu;
> +   struct intel_engine_cs *engine;
> +
> +   if (copy_from_user(_sseu, u64_to_user_ptr(args->value),
> +  sizeof(param_sseu))) {
> +  

[Intel-gfx] [PATCH] RFC drm/i915: Switch to kernel context before idling at runtime

[Chris Wilson]

We can reduce our exposure to random neutrinos by resting on the kernel
context having flushed out the user contexts to system memory and
beyond. The corollary is that we then we require two passes through the
idle handler to go to sleep, which on a truly idle system involves an
extra pass through the slow and irregular retire work handler.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..041a11c395a3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3554,6 +3554,16 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (!READ_ONCE(dev_priv->gt.awake))
return;
 
+   /*
+* Flush out the last user context, leaving only the pinned
+* kernel context resident. When we are idling on the kernel_context,
+* no more new requests (with a context switch) are emitted and we
+* can finally rest. A consequence is that the idle work handler is
+* always called at least twice before idling (and if the system is
+* idle that implies a round trip through the retire worker).
+*/
+   i915_gem_switch_to_kernel_context(dev_priv);
+
/*
 * Wait for last execlists context complete, but bail out in case a
 * new request is submitted. As we don't trust the hardware, we
-- 
2.17.0

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

[Intel-gfx] [PULL] drm-intel-fixes

[Joonas Lahtinen]

Hi Dave,

And welcome back! Hope you had a good one.

We got a few -rc2 induced 3rd party bugs to CI (but that's nowadays
more the rule than an exception), but other than that the results look
solid.

Main thing are the fixes for the user reported black screen (DP MST)
and HDA codec interop issues (no audio on GLK). Then two smaller fixes
to avoid more rare corner cases.

We have Walpurgis night incoming next Tuesday, and I guess many are taking
the Monday off too (like me), so might be a quieter week next week.

Regards, Joonas

drm-intel-fixes-2018-04-26:
- Fix for black screen issues (FDO #104158 and #104425)
- A correction for wrongly applied display W/A
- Fixes for HDA codec interop issue (no audio) and too eager HW timeouts

The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:

  Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-04-26

for you to fetch changes up to 0b551f1e0fc50ee4e3cde2dd639cb010dae5b997:

  drm/i915/fbdev: Enable late fbdev initial configuration (2018-04-25 09:50:35 
+0300)


- Fix for black screen issues (FDO #104158 and #104425)
- A correction for wrongly applied display W/A
- Fixes for HDA codec interop issue (no audio) and too eager HW timeouts


Abhay Kumar (1):
  drm/i915/audio: set minimum CD clock to twice the BCLK

Imre Deak (1):
  drm/i915: Enable display WA#1183 from its correct spot

José Roberto de Souza (1):
  drm/i915/fbdev: Enable late fbdev initial configuration

Mika Kuoppala (1):
  drm/i915: Use ktime on wait_for

 drivers/gpu/drm/i915/intel_cdclk.c  | 16 ++--
 drivers/gpu/drm/i915/intel_drv.h|  4 ++--
 drivers/gpu/drm/i915/intel_fbdev.c  |  2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
 4 files changed, 22 insertions(+), 11 deletions(-)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/rect: Round above 1 << 16 upwards to correct scale calculation functions.

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to 
correct scale calculation functions.
URL   : https://patchwork.freedesktop.org/series/42317/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8808 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/42317/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_8808 that come from known issues:

  === IGT changes ===

 Possible fixes 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@kms_flip@basic-flip-vs-dpms:
  fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS


  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927


== Participating hosts (37 -> 35) ==

  Missing(2): fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4100 -> Patchwork_8808

  CI_DRM_4100: 05cc701ce9d22b01f2f4afa9fddd521b931ed163 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8808: 968d77e5a49fd4ff0001f0b305c67cfeadfc2b65 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

968d77e5a49f drm/i915: Do not adjust scale when out of bounds, v2.
4362fe643c06 drm/rect: Handle rounding errors in drm_rect_clip_scaled
3e26302006d1 drm/rect: Round above 1 << 16 upwards to correct scale calculation 
functions.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8808/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use seqlock in engine stats (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Use seqlock in engine stats (rev3)
URL   : https://patchwork.freedesktop.org/series/38347/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4100_full -> Patchwork_8806_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8806_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8806_full, 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/38347/revisions/3/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_8806_full:

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-render:
  shard-kbl:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_8806_full that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic:
  shard-hsw:  PASS -> FAIL (fdo#104873)

igt@kms_flip@2x-plain-flip-fb-recreate:
  shard-hsw:  PASS -> FAIL (fdo#100368)

igt@kms_flip@modeset-vs-vblank-race:
  shard-glk:  PASS -> FAIL (fdo#103060) +1

igt@kms_frontbuffer_tracking@fbc-tilingchange:
  shard-apl:  PASS -> FAIL (fdo#103167)

igt@kms_sysfs_edid_timing:
  shard-apl:  PASS -> WARN (fdo#100047)


 Possible fixes 

igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
  shard-hsw:  FAIL (fdo#104873) -> PASS

igt@kms_flip@absolute-wf_vblank-interruptible:
  shard-glk:  FAIL (fdo#106087) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-glk:  FAIL (fdo#103060) -> PASS

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-apl:  FAIL (fdo#103060) -> PASS

igt@kms_flip@flip-vs-wf_vblank-interruptible:
  shard-hsw:  FAIL (fdo#103928) -> PASS
  shard-glk:  FAIL (fdo#100368) -> PASS +1
  shard-apl:  FAIL (fdo#105312) -> PASS

igt@kms_flip@plain-flip-fb-recreate:
  shard-hsw:  FAIL (fdo#100368) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
  shard-apl:  FAIL (fdo#103167) -> PASS


  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
  fdo#105312 https://bugs.freedesktop.org/show_bug.cgi?id=105312
  fdo#106087 https://bugs.freedesktop.org/show_bug.cgi?id=106087


== Participating hosts (6 -> 5) ==

  Missing(1): shard-glkb 


== Build changes ==

* Linux: CI_DRM_4100 -> Patchwork_8806

  CI_DRM_4100: 05cc701ce9d22b01f2f4afa9fddd521b931ed163 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8806: 9ce2e374546c8bd06ae6e97f8b5b7b6cdf8e7f0e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8806/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/rect: Round above 1 << 16 upwards to correct scale calculation functions.

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to 
correct scale calculation functions.
URL   : https://patchwork.freedesktop.org/series/42317/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/rect: Round above 1 << 16 upwards to correct scale calculation 
functions.
Okay!

Commit: drm/rect: Handle rounding errors in drm_rect_clip_scaled
+drivers/gpu/drm/drm_rect.c:117:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:117:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:117:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:117:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:117:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:117:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:117:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:124:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:124:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:124:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:124:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:124:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:124:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:124:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:131:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:131:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:131:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:131:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:131:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:131:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:131:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:137:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:137:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:137:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:137:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:137:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:137:27: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_rect.c:137:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:77:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:77:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:77:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:77:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:77:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:77:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:77:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:82:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:82:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:82:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:82:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:82:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:82:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:82:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:87:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:87:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:87:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:87:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:87:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:87:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:87:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:92:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:92:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:92:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:92:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:92:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:92:27: warning: expression using sizeof(void)
-O:drivers/gpu/drm/drm_rect.c:92:27: warning: expression using sizeof(void)

Commit: drm/i915: Do not adjust scale when out of bounds, v2.
Okay!

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/rect: Round above 1 << 16 upwards to correct scale calculation functions.

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/rect: Round above 1 << 16 upwards to 
correct scale calculation functions.
URL   : https://patchwork.freedesktop.org/series/42317/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3e26302006d1 drm/rect: Round above 1 << 16 upwards to correct scale calculation 
functions.
-:25: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or 
return
#25: FILE: drivers/gpu/drm/drm_rect.c:111:
+   return DIV_ROUND_UP(src, dst);
+   else

total: 0 errors, 1 warnings, 0 checks, 47 lines checked
4362fe643c06 drm/rect: Handle rounding errors in drm_rect_clip_scaled
-:33: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or 
return
#33: FILE: drivers/gpu/drm/drm_rect.c:65:
+   return DIV_ROUND_UP(src, dst);
+   else

-:52: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'oldscale' - possible 
side-effects?
#52: FILE: drivers/gpu/drm/drm_rect.c:98:
+#define FIXUP(oldscale, fn, m, second) do { \
+   if (oldscale != 1 << 16) { \
+   int newscale = drm_calc_scale(fn(src), fn(dst)); \
+ \
+   if (newscale < 0) \
+   return false; \
+ \
+   if ((oldscale < 0x1) != (newscale < 0x1)) { \
+   if (!second) \
+   src->m##1 = src->m##2 - ((fn(dst) - diff) << 
16); \
+   else \
+   src->m##2 = src->m##1 + ((fn(dst) - diff) << 
16); \
+   } \
+   } \
+ } while (0)

-:52: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fn' - possible side-effects?
#52: FILE: drivers/gpu/drm/drm_rect.c:98:
+#define FIXUP(oldscale, fn, m, second) do { \
+   if (oldscale != 1 << 16) { \
+   int newscale = drm_calc_scale(fn(src), fn(dst)); \
+ \
+   if (newscale < 0) \
+   return false; \
+ \
+   if ((oldscale < 0x1) != (newscale < 0x1)) { \
+   if (!second) \
+   src->m##1 = src->m##2 - ((fn(dst) - diff) << 
16); \
+   else \
+   src->m##2 = src->m##1 + ((fn(dst) - diff) << 
16); \
+   } \
+   } \
+ } while (0)

-:55: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#55: FILE: drivers/gpu/drm/drm_rect.c:101:
+ \$

-:58: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#58: FILE: drivers/gpu/drm/drm_rect.c:104:
+ \$

-:59: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'oldscale < 
0x1'
#59: FILE: drivers/gpu/drm/drm_rect.c:105:
+   if ((oldscale < 0x1) != (newscale < 0x1)) { \

-:59: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'newscale < 
0x1'
#59: FILE: drivers/gpu/drm/drm_rect.c:105:
+   if ((oldscale < 0x1) != (newscale < 0x1)) { \

-:66: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#66: FILE: drivers/gpu/drm/drm_rect.c:112:
+ } while (0)$

total: 0 errors, 4 warnings, 4 checks, 102 lines checked
968d77e5a49f drm/i915: Do not adjust scale when out of bounds, v2.
-:180: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#180: FILE: drivers/gpu/drm/i915/intel_sprite.c:1030:
+   if (INTEL_GEN(dev_priv) < 9 && (

total: 0 errors, 0 warnings, 1 checks, 179 lines checked

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: link config compute refactoring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: link config compute refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/41215/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4100 -> Patchwork_8807 =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_8807 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8807, 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/41215/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8807:

  === IGT changes ===

 Possible regressions 

igt@debugfs_test@read_all_entries:
  fi-kbl-7560u:   PASS -> INCOMPLETE

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-kbl-7567u:   PASS -> FAIL


== Known issues ==

  Here are the changes found in Patchwork_8807 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-ivb-3520m:   PASS -> DMESG-WARN (fdo#106084)


 Possible fixes 

igt@debugfs_test@read_all_entries:
  fi-snb-2520m:   INCOMPLETE (fdo#103713) -> PASS

igt@kms_flip@basic-flip-vs-dpms:
  fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS


  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084


== Participating hosts (37 -> 35) ==

  Missing(2): fi-ilk-m540 fi-skl-6700hq 


== Build changes ==

* Linux: CI_DRM_4100 -> Patchwork_8807

  CI_DRM_4100: 05cc701ce9d22b01f2f4afa9fddd521b931ed163 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4449: 0350f0e7f6a0e07281445fc3082aa70419f4aac7 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8807: 57809a508243f1af959fa08ef562b900425fe19d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4449: ad8992d3fb27fd604b9ab15e7963c42421ced85c @ 
git://anongit.freedesktop.org/piglit


== Linux commits ==

57809a508243 drm/i915/dp: fix compliance test adjustments
3f113e6072d7 drm/i915/dp: abstract link config selection
d8ade2bdaa7a drm/i915/dp: group link config limits in a struct
ff5c64d21d93 drm/i915/dp: move eDP VBT bpp clamping code to 
intel_dp_compute_bpp()
4f3c34480f92 drm/i915/dp: abstract dp link config computation from the rest
77ae7b48939b drm/i915/dp: move link_bw and rate_select debugging where used
8226b468bdc1 drm/i915/dp: remove stale comment about bw constants

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8807/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dp: link config compute refactoring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: link config compute refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/41215/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/dp: remove stale comment about bw constants
Okay!

Commit: drm/i915/dp: move link_bw and rate_select debugging where used
Okay!

Commit: drm/i915/dp: abstract dp link config computation from the rest
Okay!

Commit: drm/i915/dp: move eDP VBT bpp clamping code to intel_dp_compute_bpp()
Okay!

Commit: drm/i915/dp: group link config limits in a struct
Okay!

Commit: drm/i915/dp: abstract link config selection
Okay!

Commit: drm/i915/dp: fix compliance test adjustments
-O:drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:1667:23: warning: expression using sizeof(void)

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: link config compute refactoring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: link config compute refactoring (rev2)
URL   : https://patchwork.freedesktop.org/series/41215/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8226b468bdc1 drm/i915/dp: remove stale comment about bw constants
77ae7b48939b drm/i915/dp: move link_bw and rate_select debugging where used
4f3c34480f92 drm/i915/dp: abstract dp link config computation from the rest
ff5c64d21d93 drm/i915/dp: move eDP VBT bpp clamping code to 
intel_dp_compute_bpp()
d8ade2bdaa7a drm/i915/dp: group link config limits in a struct
-:69: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#69: FILE: drivers/gpu/drm/i915/intel_dp.c:1746:
+   limits.min_clock = limits.max_clock = index;

-:70: WARNING:LONG_LINE: line over 100 characters
#70: FILE: drivers/gpu/drm/i915/intel_dp.c:1747:
+   limits.min_lane_count = limits.max_lane_count = 
intel_dp->compliance.test_lane_count;

-:70: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#70: FILE: drivers/gpu/drm/i915/intel_dp.c:1747:
+   limits.min_lane_count = limits.max_lane_count = 
intel_dp->compliance.test_lane_count;

total: 0 errors, 1 warnings, 2 checks, 96 lines checked
3f113e6072d7 drm/i915/dp: abstract link config selection
57809a508243 drm/i915/dp: fix compliance test adjustments
-:47: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#47: FILE: drivers/gpu/drm/i915/intel_dp.c:1709:
+   limits->min_bpp = limits->max_bpp = bpp;

-:66: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#66: FILE: drivers/gpu/drm/i915/intel_dp.c:1728:
+   limits->min_clock = limits->max_clock = index;

-:67: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#67: FILE: drivers/gpu/drm/i915/intel_dp.c:1729:
+   limits->min_lane_count = limits->max_lane_count =

total: 0 errors, 0 warnings, 3 checks, 88 lines checked

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

[Intel-gfx] [PATCH 3/3] drm/i915: Do not adjust scale when out of bounds, v2.

[Maarten Lankhorst]

With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where the screen didn't show what was requested, and now
instead we reject it outright. This simplifies check_sprite_plane a lot.

Changes since v1:
- Set crtc_h to the height correctly.
- Reject < 3x3 rectangles instead of making them invisible for 
---
 drivers/gpu/drm/i915/intel_sprite.c | 144 +++-
 1 file changed, 35 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aa1dfaa692b9..970015dcc6f1 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -936,22 +936,12 @@ intel_check_sprite_plane(struct intel_plane *plane,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = state->base.fb;
-   int crtc_x, crtc_y;
-   unsigned int crtc_w, crtc_h;
-   uint32_t src_x, src_y, src_w, src_h;
-   struct drm_rect *src = >base.src;
-   struct drm_rect *dst = >base.dst;
-   struct drm_rect clip = {};
int max_stride = INTEL_GEN(dev_priv) >= 9 ? 32768 : 16384;
-   int hscale, vscale;
int max_scale, min_scale;
bool can_scale;
int ret;
uint32_t pixel_format = 0;
 
-   *src = drm_plane_state_src(>base);
-   *dst = drm_plane_state_dest(>base);
-
if (!fb) {
state->base.visible = false;
return 0;
@@ -990,64 +980,19 @@ intel_check_sprite_plane(struct intel_plane *plane,
min_scale = plane->can_scale ? 1 : (1 << 16);
}
 
-   /*
-* FIXME the following code does a bunch of fuzzy adjustments to the
-* coordinates and sizes. We probably need some way to decide whether
-* more strict checking should be done instead.
-*/
-   drm_rect_rotate(src, fb->width << 16, fb->height << 16,
-   state->base.rotation);
-
-   hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
-   BUG_ON(hscale < 0);
-
-   vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
-   BUG_ON(vscale < 0);
-
-   if (crtc_state->base.enable)
-   drm_mode_get_hv_timing(_state->base.mode,
-  , );
-
-   state->base.visible = drm_rect_clip_scaled(src, dst, , hscale, 
vscale);
-
-   crtc_x = dst->x1;
-   crtc_y = dst->y1;
-   crtc_w = drm_rect_width(dst);
-   crtc_h = drm_rect_height(dst);
+   ret = drm_atomic_helper_check_plane_state(>base,
+ _state->base,
+ min_scale, max_scale,
+ true, true);
+   if (ret)
+   return ret;
 
if (state->base.visible) {
-   /* check again in case clipping clamped the results */
-   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
-   if (hscale < 0) {
-   DRM_DEBUG_KMS("Horizontal scaling factor out of 
limits\n");
-   drm_rect_debug_print("src: ", src, true);
-   drm_rect_debug_print("dst: ", dst, false);
-
-   return hscale;
-   }
-
-   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
-   if (vscale < 0) {
-   DRM_DEBUG_KMS("Vertical scaling factor out of 
limits\n");
-   drm_rect_debug_print("src: ", src, true);
-   drm_rect_debug_print("dst: ", dst, false);
-
-   return vscale;
-   }
-
-   /* Make the source viewport size an exact multiple of the 
scaling factors. */
-   drm_rect_adjust_size(src,
-drm_rect_width(dst) * hscale - 
drm_rect_width(src),
-drm_rect_height(dst) * vscale - 
drm_rect_height(src));
-
-   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16,
-   state->base.rotation);
-
-   /* sanity check to make sure the src viewport wasn't enlarged */
-   WARN_ON(src->x1 < (int) state->base.src_x ||
-   src->y1 < (int) state->base.src_y ||
-   src->x2 > (int) state->base.src_x + state->base.src_w ||
-   src->y2 > (int) state->base.src_y + state->base.src_h);
+   struct drm_rect *src = >base.src;
+   struct drm_rect *dst = >base.dst;
+   unsigned int crtc_w = 

[Intel-gfx] [PATCH 1/3] drm/rect: Round above 1 << 16 upwards to correct scale calculation functions.

[Maarten Lankhorst]

When calculating limits we want to be as pessimistic as possible,
so we have to explicitly say whether we want to round up or down
to accurately calculate whether we are below min_scale or above
max_scale.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_rect.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 9817c1445ba9..b179c7c73cc5 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -106,7 +106,10 @@ static int drm_calc_scale(int src, int dst)
if (dst == 0)
return 0;
 
-   scale = src / dst;
+   if (src > (dst << 16))
+   return DIV_ROUND_UP(src, dst);
+   else
+   scale = src / dst;
 
return scale;
 }
@@ -121,6 +124,9 @@ static int drm_calc_scale(int src, int dst)
  * Calculate the horizontal scaling factor as
  * (@src width) / (@dst width).
  *
+ * If the scale is below 1 << 16, round down, if above up. This will
+ * calculate the scale with the most pessimistic limit calculation.
+ *
  * RETURNS:
  * The horizontal scaling factor, or errno of out of limits.
  */
@@ -152,6 +158,9 @@ EXPORT_SYMBOL(drm_rect_calc_hscale);
  * Calculate the vertical scaling factor as
  * (@src height) / (@dst height).
  *
+ * If the scale is below 1 << 16, round down, if above up. This will
+ * calculate the scale with the most pessimistic limit calculation.
+ *
  * RETURNS:
  * The vertical scaling factor, or errno of out of limits.
  */
@@ -189,6 +198,9 @@ EXPORT_SYMBOL(drm_rect_calc_vscale);
  * If the calculated scaling factor is above @max_vscale,
  * decrease the height of rectangle @src to compensate.
  *
+ * If the scale is below 1 << 16, round down, if above up. This will
+ * calculate the scale with the most pessimistic limit calculation.
+ *
  * RETURNS:
  * The horizontal scaling factor.
  */
@@ -239,6 +251,9 @@ EXPORT_SYMBOL(drm_rect_calc_hscale_relaxed);
  * If the calculated scaling factor is above @max_vscale,
  * decrease the height of rectangle @src to compensate.
  *
+ * If the scale is below 1 << 16, round down, if above up. This will
+ * calculate the scale with the most pessimistic limit calculation.
+ *
  * RETURNS:
  * The vertical scaling factor.
  */
-- 
2.17.0

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

[Intel-gfx] [PATCH 2/3] drm/rect: Handle rounding errors in drm_rect_clip_scaled

[Maarten Lankhorst]

No matter how you perform the clip adjustments, a small
error may push the scaling factor to the other side of
0x1. Solve this with a macro that will fixup the
scale to 0x1 if we accidentally wrap to the other side.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_rect.c | 65 +++---
 1 file changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index b179c7c73cc5..71b6b7f5d58f 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -50,6 +50,24 @@ bool drm_rect_intersect(struct drm_rect *r1, const struct 
drm_rect *r2)
 }
 EXPORT_SYMBOL(drm_rect_intersect);
 
+static int drm_calc_scale(int src, int dst)
+{
+   int scale = 0;
+
+   if (WARN_ON(src < 0 || dst < 0))
+   return -EINVAL;
+
+   if (dst == 0)
+   return 0;
+
+   if (src > (dst << 16))
+   return DIV_ROUND_UP(src, dst);
+   else
+   scale = src / dst;
+
+   return scale;
+}
+
 /**
  * drm_rect_clip_scaled - perform a scaled clip operation
  * @src: source window rectangle
@@ -71,49 +89,60 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct 
drm_rect *dst,
 {
int diff;
 
+   /*
+* When scale is near 0x1 rounding errors may cause the scaling
+* factor to the other side. Some hardware may support
+* upsampling, but not downsampling, and that would break when
+* rounding.
+*/
+#define FIXUP(oldscale, fn, m, second) do { \
+   if (oldscale != 1 << 16) { \
+   int newscale = drm_calc_scale(fn(src), fn(dst)); \
+ \
+   if (newscale < 0) \
+   return false; \
+ \
+   if ((oldscale < 0x1) != (newscale < 0x1)) { \
+   if (!second) \
+   src->m##1 = src->m##2 - ((fn(dst) - diff) << 
16); \
+   else \
+   src->m##2 = src->m##1 + ((fn(dst) - diff) << 
16); \
+   } \
+   } \
+ } while (0)
+
diff = clip->x1 - dst->x1;
if (diff > 0) {
int64_t tmp = src->x1 + (int64_t) diff * hscale;
src->x1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
+   FIXUP(hscale, drm_rect_width, x, 0);
}
+
diff = clip->y1 - dst->y1;
if (diff > 0) {
int64_t tmp = src->y1 + (int64_t) diff * vscale;
src->y1 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
+   FIXUP(vscale, drm_rect_height, y, 0);
}
+
diff = dst->x2 - clip->x2;
if (diff > 0) {
int64_t tmp = src->x2 - (int64_t) diff * hscale;
src->x2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
+   FIXUP(hscale, drm_rect_width, x, 1);
}
diff = dst->y2 - clip->y2;
if (diff > 0) {
int64_t tmp = src->y2 - (int64_t) diff * vscale;
src->y2 = clamp_t(int64_t, tmp, INT_MIN, INT_MAX);
+   FIXUP(vscale, drm_rect_height, y, 1);
}
+#undef FIXUP
 
return drm_rect_intersect(dst, clip);
 }
 EXPORT_SYMBOL(drm_rect_clip_scaled);
 
-static int drm_calc_scale(int src, int dst)
-{
-   int scale = 0;
-
-   if (WARN_ON(src < 0 || dst < 0))
-   return -EINVAL;
-
-   if (dst == 0)
-   return 0;
-
-   if (src > (dst << 16))
-   return DIV_ROUND_UP(src, dst);
-   else
-   scale = src / dst;
-
-   return scale;
-}
-
 /**
  * drm_rect_calc_hscale - calculate the horizontal scaling factor
  * @src: source window rectangle
-- 
2.17.0

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

[Intel-gfx] [PATCH v2 3/7] drm/i915/dp: abstract dp link config computation from the rest

[Jani Nikula]

Abstract a new intel_dp_compute_link_config() from
intel_dp_compute_config(), with the parts related to link configuration,
i.e. bpp, link rate, and lane count selection. No functional changes.

v2: Fix a checkpatch warn about spacing.

Reviewed-by: Manasi Navare 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 161 ++--
 1 file changed, 88 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 81cf363e71af..81da96b9ef33 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1685,19 +1685,14 @@ static bool intel_edp_compare_alt_mode(struct 
drm_display_mode *m1,
return bres;
 }
 
-bool
-intel_dp_compute_config(struct intel_encoder *encoder,
-   struct intel_crtc_state *pipe_config,
-   struct drm_connector_state *conn_state)
+static bool
+intel_dp_compute_link_config(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
-   enum port port = encoder->port;
-   struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
-   struct intel_digital_connector_state *intel_conn_state =
-   to_intel_digital_connector_state(conn_state);
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1706,9 +1701,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
int bpp, mode_rate;
int link_avail, link_clock;
int common_len;
-   bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
-  DP_DPCD_QUIRK_LIMITED_M_N);
-
common_len = intel_dp_common_len_rate_limit(intel_dp,
intel_dp->max_link_rate);
 
@@ -1717,51 +1709,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 
max_clock = common_len - 1;
 
-   if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
-   pipe_config->has_pch_encoder = true;
-
-   pipe_config->has_drrs = false;
-   if (IS_G4X(dev_priv) || port == PORT_A)
-   pipe_config->has_audio = false;
-   else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
-   pipe_config->has_audio = intel_dp->has_audio;
-   else
-   pipe_config->has_audio = intel_conn_state->force_audio == 
HDMI_AUDIO_ON;
-
-   if (intel_dp_is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
-   struct drm_display_mode *panel_mode =
-   intel_connector->panel.alt_fixed_mode;
-   struct drm_display_mode *req_mode = _config->base.mode;
-
-   if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
-   panel_mode = intel_connector->panel.fixed_mode;
-
-   drm_mode_debug_printmodeline(panel_mode);
-
-   intel_fixed_panel_mode(panel_mode, adjusted_mode);
-
-   if (INTEL_GEN(dev_priv) >= 9) {
-   int ret;
-   ret = skl_update_scaler_crtc(pipe_config);
-   if (ret)
-   return ret;
-   }
-
-   if (HAS_GMCH_DISPLAY(dev_priv))
-   intel_gmch_panel_fitting(intel_crtc, pipe_config,
-conn_state->scaling_mode);
-   else
-   intel_pch_panel_fitting(intel_crtc, pipe_config,
-   conn_state->scaling_mode);
-   }
-
-   if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
-   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
-
-   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
-   return false;
-
/* Use values requested by Compliance Test Request */
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
int index;
@@ -1831,6 +1778,83 @@ intel_dp_compute_config(struct intel_encoder *encoder,
return false;
 
 found:
+   pipe_config->lane_count = lane_count;
+   pipe_config->pipe_bpp = bpp;
+   pipe_config->port_clock = intel_dp->common_rates[clock];
+
+   DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
+ pipe_config->lane_count, pipe_config->port_clock, bpp);
+   DRM_DEBUG_KMS("DP link bw required %i available %i\n",
+ mode_rate, link_avail);
+
+   return true;
+}
+
+bool
+intel_dp_compute_config(struct 

[Intel-gfx] [PATCH v2 2/7] drm/i915/dp: move link_bw and rate_select debugging where used

[Jani Nikula]

We call intel_dp_compute_rate() in intel_dp_compute_config() only to be
able to debug log the link_bw and rate_select parameters; we don't use
the parameters here for anything else. We call intel_dp_compute_rate()
again during link training where we actually need and use the
parameters.

Move the debug logging of link_bw and rate_select to
intel_dp_link_training_clock_recovery(), and clean up the extra
intel_dp_compute_rate() call and extra clutter from the already
overcrowded intel_dp_compute_config().

v2: Rewrote commit message (Rodrigo, Manasi)

Reviewed-by: Manasi Navare 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c   | 9 ++---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 5 +
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5f4b30faf6a2..81cf363e71af 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1706,7 +1706,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
int bpp, mode_rate;
int link_avail, link_clock;
int common_len;
-   uint8_t link_bw, rate_select;
bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
   DP_DPCD_QUIRK_LIMITED_M_N);
 
@@ -1852,12 +1851,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->pipe_bpp = bpp;
pipe_config->port_clock = intel_dp->common_rates[clock];
 
-   intel_dp_compute_rate(intel_dp, pipe_config->port_clock,
- _bw, _select);
-
-   DRM_DEBUG_KMS("DP link bw %02x rate select %02x lane count %d clock %d 
bpp %d\n",
- link_bw, rate_select, pipe_config->lane_count,
- pipe_config->port_clock, bpp);
+   DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
+ pipe_config->lane_count, pipe_config->port_clock, bpp);
DRM_DEBUG_KMS("DP link bw required %i available %i\n",
  mode_rate, link_avail);
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..3fcaa98b9055 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -139,6 +139,11 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
intel_dp_compute_rate(intel_dp, intel_dp->link_rate,
  _bw, _select);
 
+   if (link_bw)
+   DRM_DEBUG_KMS("Using LINK_BW_SET value %02x\n", link_bw);
+   else
+   DRM_DEBUG_KMS("Using LINK_RATE_SET value %02x\n", rate_select);
+
/* Write the link configuration data */
link_config[0] = link_bw;
link_config[1] = intel_dp->lane_count;
-- 
2.11.0

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

[Intel-gfx] [PATCH v2 5/7] drm/i915/dp: group link config limits in a struct

[Jani Nikula]

Also use same min/max model for bpp, and adjust debug logging while at
it.

Reviewed-by: Manasi Navare 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 57 -
 1 file changed, 33 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 430c206e77fc..9ef29b63b237 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1647,6 +1647,12 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, 
int port_clock,
}
 }
 
+struct link_config_limits {
+   int min_clock, max_clock;
+   int min_lane_count, max_lane_count;
+   int min_bpp, max_bpp;
+};
+
 static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config)
 {
@@ -1704,21 +1710,25 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
 {
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
-   int lane_count, clock;
-   int min_lane_count = 1;
-   int max_lane_count = intel_dp_max_lane_count(intel_dp);
-   int min_clock = 0;
-   int max_clock;
-   int bpp, mode_rate;
-   int link_avail, link_clock;
+   struct link_config_limits limits;
+   int bpp, clock, lane_count;
+   int mode_rate, link_avail, link_clock;
int common_len;
+
common_len = intel_dp_common_len_rate_limit(intel_dp,
intel_dp->max_link_rate);
 
/* No common link rates between source and sink */
WARN_ON(common_len <= 0);
 
-   max_clock = common_len - 1;
+   limits.min_clock = 0;
+   limits.max_clock = common_len - 1;
+
+   limits.min_lane_count = 1;
+   limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
+
+   limits.min_bpp = 6 * 3;
+   limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
 
/* Use values requested by Compliance Test Request */
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
@@ -1733,18 +1743,11 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
intel_dp->num_common_rates,

intel_dp->compliance.test_link_rate);
if (index >= 0)
-   min_clock = max_clock = index;
-   min_lane_count = max_lane_count = 
intel_dp->compliance.test_lane_count;
+   limits.min_clock = limits.max_clock = index;
+   limits.min_lane_count = limits.max_lane_count = 
intel_dp->compliance.test_lane_count;
}
}
-   DRM_DEBUG_KMS("DP link computation with max lane count %i "
- "max bw %d pixel clock %iKHz\n",
- max_lane_count, intel_dp->common_rates[max_clock],
- adjusted_mode->crtc_clock);
 
-   /* Walk through all bpp values. Luckily they're all nicely spaced with 2
-* bpc in between. */
-   bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
if (intel_dp_is_edp(intel_dp)) {
/*
 * Use the maximum clock and number of lanes the eDP panel
@@ -1753,18 +1756,24 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
 * configuration, and typically these values correspond to the
 * native resolution of the panel.
 */
-   min_lane_count = max_lane_count;
-   min_clock = max_clock;
+   limits.min_lane_count = limits.max_lane_count;
+   limits.min_clock = limits.max_clock;
}
 
-   for (; bpp >= 6*3; bpp -= 2*3) {
+   DRM_DEBUG_KMS("DP link computation with max lane count %i "
+ "max rate %d max bpp %d pixel clock %iKHz\n",
+ limits.max_lane_count,
+ intel_dp->common_rates[limits.max_clock],
+ limits.max_bpp, adjusted_mode->crtc_clock);
+
+   for (bpp = limits.max_bpp; bpp >= limits.min_bpp; bpp -= 2 * 3) {
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
   bpp);
 
-   for (clock = min_clock; clock <= max_clock; clock++) {
-   for (lane_count = min_lane_count;
-   lane_count <= max_lane_count;
-   lane_count <<= 1) {
+   for (clock = limits.min_clock; clock <= limits.max_clock; 
clock++) {
+   for (lane_count = limits.min_lane_count;
+lane_count <= limits.max_lane_count;
+lane_count <<= 1) {
 

[Intel-gfx] [PATCH v2 1/7] drm/i915/dp: remove stale comment about bw constants

[Jani Nikula]

We haven't used the DP bw constants here for a while. No functional
changes.

Reviewed-by: Rodrigo Vivi 
Reviewed-by: Manasi Navare 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..5f4b30faf6a2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1701,7 +1701,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
-   /* Conveniently, the link BW constants become indices with a shift...*/
int min_clock = 0;
int max_clock;
int bpp, mode_rate;
-- 
2.11.0

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

[Intel-gfx] [PATCH v2 6/7] drm/i915/dp: abstract link config selection

[Jani Nikula]

For now, there's just the one link config selection, optimizing for slow
and wide link. No functional changes.

Keep the debug logging in the caller, to avoid duplication later on if
alternative link confing selection gets added.

v2: Improved commit message

Reviewed-by: Manasi Navare 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dp.c | 81 +
 1 file changed, 50 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9ef29b63b237..d622db76b9c3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1704,6 +1704,42 @@ static bool intel_edp_compare_alt_mode(struct 
drm_display_mode *m1,
return bres;
 }
 
+/* Optimize link config in order: max bpp, min clock, min lanes */
+static bool
+intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ const struct link_config_limits *limits)
+{
+   struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
+   int bpp, clock, lane_count;
+   int mode_rate, link_clock, link_avail;
+
+   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+  bpp);
+
+   for (clock = limits->min_clock; clock <= limits->max_clock; 
clock++) {
+   for (lane_count = limits->min_lane_count;
+lane_count <= limits->max_lane_count;
+lane_count <<= 1) {
+   link_clock = intel_dp->common_rates[clock];
+   link_avail = intel_dp_max_data_rate(link_clock,
+   lane_count);
+
+   if (mode_rate <= link_avail) {
+   pipe_config->lane_count = lane_count;
+   pipe_config->pipe_bpp = bpp;
+   pipe_config->port_clock = link_clock;
+
+   return true;
+   }
+   }
+   }
+   }
+
+   return false;
+}
+
 static bool
 intel_dp_compute_link_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config)
@@ -1711,8 +1747,6 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct link_config_limits limits;
-   int bpp, clock, lane_count;
-   int mode_rate, link_avail, link_clock;
int common_len;
 
common_len = intel_dp_common_len_rate_limit(intel_dp,
@@ -1766,37 +1800,22 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
  intel_dp->common_rates[limits.max_clock],
  limits.max_bpp, adjusted_mode->crtc_clock);
 
-   for (bpp = limits.max_bpp; bpp >= limits.min_bpp; bpp -= 2 * 3) {
-   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
-  bpp);
-
-   for (clock = limits.min_clock; clock <= limits.max_clock; 
clock++) {
-   for (lane_count = limits.min_lane_count;
-lane_count <= limits.max_lane_count;
-lane_count <<= 1) {
-
-   link_clock = intel_dp->common_rates[clock];
-   link_avail = intel_dp_max_data_rate(link_clock,
-   lane_count);
-
-   if (mode_rate <= link_avail) {
-   goto found;
-   }
-   }
-   }
-   }
-
-   return false;
-
-found:
-   pipe_config->lane_count = lane_count;
-   pipe_config->pipe_bpp = bpp;
-   pipe_config->port_clock = intel_dp->common_rates[clock];
+   /*
+* Optimize for slow and wide. This is the place to add alternative
+* optimization policy.
+*/
+   if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config, ))
+   return false;
 
DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
- pipe_config->lane_count, pipe_config->port_clock, bpp);
-   DRM_DEBUG_KMS("DP link bw required %i available %i\n",
- mode_rate, link_avail);
+ pipe_config->lane_count, pipe_config->port_clock,
+ pipe_config->pipe_bpp);
+
+   DRM_DEBUG_KMS("DP link rate required